Move forward, securely.

Your security training taught your team one rule above all: don't click links, don't open attachments from strangers. This month, Microsoft patched a set of flaws that break that rule entirely.

On October 13, Microsoft released its largest Patch Tuesday on record — more than 1,400 security fixes in one bundle. Inside it: five critical Outlook remote-code-execution flaws, each rated 9.8 out of 10 (CVE-2026-70242, CVE-2026-70291, CVE-2026-88156, CVE-2026-97016, CVE-2026-97749). For at least two of them, Microsoft's own description says it plainly: “Simply viewing the message in the Outlook Reading Pane could trigger the vulnerability, without the recipient opening the message or clicking anything in it.” The Reading Pane is the preview area Outlook shows when you select a message — on by default. No click. No attachment. No login for the attacker. Just an email arriving in the inbox.

To be fair: Microsoft rates active exploitation of these five as “less likely,” and none has been seen in the wild yet. But one companion flaw is a different story: CVE-2026-96951, a Windows Shell vulnerability, is being actively exploited right now. It lets a malicious file slip past Mark of the Web — the label Windows attaches to downloaded files that triggers SmartScreen and Office warnings. With that label stripped, a booby-trapped download opens without the usual warnings. CISA added it to its Known Exploited Vulnerabilities catalog on October 13 and gave U.S. federal agencies until October 16. That deadline has already passed.

What this means for a Calgary small business: Outlook is the front door of your company, and every employee's preview pane is a window left open. Your phishing training still matters — but it cannot stop an email that only needs to be looked at. Patching is the fix, and it is the boring operational kind: updates installed, machines restarted, someone confirming it actually happened.

Do three things this week.

First, confirm the October update actually landed. Patches only protect when installed — and the machine restarts. Check that your team's devices picked up the October 13 update, including the always-on PC in the back office that nobody ever restarts. Microsoft 365 Apps, Office LTSC 2021 and 2024, and even Office for Mac are all affected.

Second, restart what never sleeps. The shared front-desk machine, the shop-floor PC, the server nobody logs into — updates sit pending on these for weeks. A patch waiting on a restart is a patch you do not have.

Third, look backward, not just forward. The Windows Shell flaw was exploited before the patch existed, so patching today does not clean up a foothold from last week. Review the past two weeks of Defender alerts for suspicious executions, and treat any odd recent download with extra suspicion.

At Canlus, this is the unglamorous work we do for Calgary small businesses: making sure updates actually install, machines actually restart, and the basics get done. Book a free consultation at canlus.com and find out what your October patch status really looks like.

Sources: CrowdStrike — “October 2026 Patch Tuesday: Updates and Analysis”; CISA Known Exploited Vulnerabilities Catalog; Security Affairs — “U.S. CISA adds Microsoft Windows Shell flaw to its Known Exploited Vulnerabilities catalog”; Microsoft MSRC — CVE-2026-96951

您的安全培训教给团队的第一条规矩就是：不要点击链接，不要打开陌生人发来的附件。而本月，微软修补的一组漏洞，把这条规矩彻底打破了。

10 月 13 日，微软发布了有史以来规模最大的“补丁星期二”更新——一次打包了 1,400 多个安全修复。其中包括五个严重的 Outlook 远程代码执行漏洞，严重程度评分均为 9.8 分（满分 10 分）（CVE-2026-70242、CVE-2026-70291、CVE-2026-88156、CVE-2026-97016、CVE-2026-97749）。其中至少有两个，微软自己的描述说得很直白：“只需在 Outlook 阅读窗格中查看邮件，就可能触发该漏洞，收件人无需打开邮件，也无需点击邮件中的任何内容。”阅读窗格是您在 Outlook 中选中一封邮件时显示的预览区域——默认开启。不用点击。没有附件。攻击者也不需要登录。只需要一封邮件送达收件箱。

公平地说：微软将这五个漏洞被实际利用的可能性评级为“较低”，目前也尚未在野外发现利用案例。但与之同期的另一个漏洞完全是另一回事：CVE-2026-96951，一个 Windows Shell 漏洞，正在被实际利用。它能让恶意文件绕过“网络标记”（Mark of the Web）——这是 Windows 给下载文件附加的标签，用来触发 SmartScreen 和 Office 的安全警告。标签一旦被剥掉，埋了陷阱的下载文件打开时就不会再出现通常的警告。CISA 已于 10 月 13 日将它列入“已知被利用漏洞”目录，并要求美国联邦机构在 10 月 16 日前完成修复。这个截止日期已经过了。

这对卡尔加里的小企业意味着什么：Outlook 是您公司的前门，而每位员工的预览窗格都是一扇敞开的窗。您的钓鱼防范培训依然重要——但它拦不住一封只需要看一眼就能得逞的邮件。修复办法就是打补丁，而且是最枯燥的那种运维工作：装好更新、重启机器、再有人确认真的做完了。

本周就做三件事。

第一，确认十月的更新真的装上了。补丁只有装上、而且机器重启之后才起作用。检查团队的设备是否都装上了 10 月 13 日的更新，包括办公室里间那台常年开着、从来没人重启的电脑。Microsoft 365 应用、Office LTSC 2021 和 2024，甚至 Mac 版 Office 都在受影响之列。

第二，把从不关机的机器重启一遍。前台共用的电脑、车间里的电脑、没人登录的服务器——更新在这些机器上挂起待重启，一挂就是好几个星期。等着重启的补丁，等于您根本没有的补丁。

第三，不光往前看，也要往回查。Windows Shell 漏洞在补丁出现之前就已被利用，所以今天打上补丁，并不能清除上星期可能已经留下的立足点。检查过去两周的 Defender 警报里有没有可疑的程序执行，对最近任何可疑的下载都要格外警惕。

在 Canlus，我们为卡尔加里小企业做的正是这种不光鲜的工作：确保更新真的装上、机器真的重启、把基本功做到位。在 canlus.com 预约免费咨询，看看您十月的补丁状态到底怎么样。

来源：CrowdStrike——《2026 年 10 月补丁星期二：更新与分析》；CISA 已知被利用漏洞目录；Security Affairs——《美国 CISA 将 Microsoft Windows Shell 漏洞列入已知被利用漏洞目录》；Microsoft MSRC——CVE-2026-96951

您的安全培訓教給團隊的第一條規矩就是：不要點擊連結，不要開啟陌生人寄來的附件。而本月，微軟修補的一組漏洞，把這條規矩徹底打破了。

10 月 13 日，微軟發布了有史以來規模最大的「修補星期二」更新——一次打包了 1,400 多個安全修復。其中包括五個嚴重的 Outlook 遠端程式碼執行漏洞，嚴重程度評分均為 9.8 分（滿分 10 分）（CVE-2026-70242、CVE-2026-70291、CVE-2026-88156、CVE-2026-97016、CVE-2026-97749）。其中至少有兩個，微軟自己的描述說得很直白：「只需在 Outlook 讀取窗格中檢視郵件，就可能觸發該漏洞，收件人無需開啟郵件，也無需點擊郵件中的任何內容。」讀取窗格是您在 Outlook 中選取一封郵件時顯示的預覽區域——預設開啟。不用點擊。沒有附件。攻擊者也不需要登入。只需要一封郵件送達收件匣。

公平地說：微軟將這五個漏洞被實際利用的可能性評級為「較低」，目前也尚未在野外發現利用案例。但與之同期的另一個漏洞完全是另一回事：CVE-2026-96951，一個 Windows Shell 漏洞，正在被實際利用。它能讓惡意檔案繞過「網路標記」（Mark of the Web）——這是 Windows 給下載檔案附加的標籤，用來觸發 SmartScreen 和 Office 的安全警告。標籤一旦被剝掉，埋了陷阱的下載檔案開啟時就不會再出現通常的警告。CISA 已於 10 月 13 日將它列入「已知被利用漏洞」目錄，並要求美國聯邦機構在 10 月 16 日前完成修復。這個截止日期已經過了。

這對卡爾加里的小企業意味著什麼：Outlook 是您公司的前門，而每位員工的預覽窗格都是一扇敞開的窗。您的釣魚防範培訓依然重要——但它攔不住一封只需要看一眼就能得逞的郵件。修復辦法就是安裝修補程式，而且是最枯燥的那種維運工作：裝好更新、重新啟動機器、再有人確認真的做完了。

本週就做三件事。

第一，確認十月的更新真的裝上了。修補程式只有裝上、而且機器重新啟動之後才起作用。檢查團隊的裝置是否都裝上了 10 月 13 日的更新，包括辦公室裡間那台常年開著、從來沒人重新啟動的電腦。Microsoft 365 應用程式、Office LTSC 2021 和 2024，甚至 Mac 版 Office 都在受影響之列。

第二，把從不關機的機器重新啟動一遍。前台共用的電腦、車間裡的電腦、沒人登入的伺服器——更新在這些機器上擱置等待重新啟動，一擱就是好幾個星期。等著重新啟動的修補程式，等於您根本沒有的修補程式。

第三，不光往前看，也要往回查。Windows Shell 漏洞在修補程式出現之前就已被利用，所以今天裝上修補程式，並不能清除上星期可能已經留下的立足點。檢查過去兩週的 Defender 警報裡有沒有可疑的程式執行，對最近任何可疑的下載都要格外警惕。

在 Canlus，我們為卡爾加里小企業做的正是這種不光鮮的工作：確保更新真的裝上、機器真的重新啟動、把基本功做到位。在 canlus.com 預約免費諮詢，看看您十月的修補狀態到底怎麼樣。

來源：CrowdStrike——《2026 年 10 月修補星期二：更新與分析》；CISA 已知被利用漏洞目錄；Security Affairs——《美國 CISA 將 Microsoft Windows Shell 漏洞列入已知被利用漏洞目錄》；Microsoft MSRC——CVE-2026-96951

セキュリティ研修でチームに叩き込まれた最重要ルールは、リンクをクリックしないこと、知らない相手の添付ファイルを開かないことです。今月、Microsoftが修正した一連の欠陥は、そのルールを根底から覆します。

10月13日、Microsoftは過去最大規模の「パッチチューズデー」を公開しました——1,400件を超えるセキュリティ修正を一度にまとめたものです。その中には、10点満点中9.8と評価された5つの重大なOutlookのリモートコード実行の脆弱性（CVE-2026-70242、CVE-2026-70291、CVE-2026-88156、CVE-2026-97016、CVE-2026-97749）が含まれていました。少なくともそのうち2つについて、Microsoft自身の説明は率直です。「Outlookの閲覧ウィンドウでメッセージを表示するだけで脆弱性が発動する可能性があり、受信者がメッセージを開いたり、中のものをクリックしたりする必要はありません。」閲覧ウィンドウとは、Outlookでメッセージを選択したときに表示されるプレビュー領域で、既定で有効になっています。クリック不要。添付ファイル不要。攻撃者のログインも不要。受信トレイにメールが届くだけでよいのです。

公平を期すと、Microsoftはこの5件の実際の悪用可能性を「低め」と評価しており、実際の悪用はまだ確認されていません。しかし、同時に公開された別の欠陥は事情が違います。Windows Shellの脆弱性CVE-2026-96951は、まさに今悪用が進んでいます。これにより、悪意のあるファイルが「Mark of the Web」——ダウンロードしたファイルにWindowsが付け、SmartScreenやOfficeの警告を起動させるラベル——をすり抜けられます。このラベルが剥がされると、仕掛けのあるダウンロードファイルが通常の警告なしに開いてしまいます。CISAは10月13日にこの脆弱性を「悪用が確認された脆弱性カタログ」に追加し、米連邦機関に10月16日までの対応を求めました。その期限はすでに過ぎています。

カルガリーの中小企業にとっての意味はこうです。Outlookは会社の正面玄関であり、従業員一人ひとりのプレビューウィンドウは開け放たれた窓です。フィッシング研修は今も重要ですが、見るだけで成立するメールは止められません。対策はパッチ適用であり、それも地味な運用作業の積み重ねです。更新をインストールし、機械を再起動し、誰かが実際に完了したことを確認する——それだけです。

今週、次の3つを実行してください。

第一に、10月の更新が実際に適用されたか確認すること。パッチはインストールされ、機械が再起動して初めて効果を発揮します。チームのデバイスが10月13日の更新を取り込んでいるか、誰も再起動しないバックオフィスの常時稼働PCも含めて確認してください。Microsoft 365アプリ、Office LTSC 2021と2024、さらにはMac版Officeもすべて影響を受けます。

第二に、眠らない機械を再起動すること。受付の共有マシン、現場のPC、誰もログインしないサーバー——更新はこうした機械で何週間も再起動待ちのまま放置されます。再起動待ちのパッチは、存在しないのと同じです。

第三に、前だけでなく後ろも振り返ること。Windows Shellの欠陥はパッチが存在する前から悪用されていたため、今日パッチを当てても先週の侵入の足場は消えません。過去2週間のDefenderアラートに不審な実行がないか確認し、最近の不審なダウンロードは特に警戒してください。

Canlusがカルガリーの中小企業のために行っているのは、まさにこうした地味な仕事です。更新が実際にインストールされ、機械が実際に再起動され、基本が確実に実行されること。canlus.comで無料相談を予約し、あなたの10月のパッチ適用状況が実際どうなっているか確認してください。

出典：CrowdStrike — “October 2026 Patch Tuesday: Updates and Analysis”; CISA Known Exploited Vulnerabilities Catalog; Security Affairs — “U.S. CISA adds Microsoft Windows Shell flaw to its Known Exploited Vulnerabilities catalog”; Microsoft MSRC — CVE-2026-96951

보안 교육에서 팀에 가르친 가장 중요한 규칙은 링크를 클릭하지 말고, 모르는 사람이 보낸 첨부 파일을 열지 말라는 것이었습니다. 이번 달, Microsoft가 패치한 일련의 취약점은 그 규칙을 완전히 무너뜨립니다.

10월 13일, Microsoft는 역대 최대 규모의 패치 화요일(Patch Tuesday)을 발표했습니다 — 한 번에 1,400개가 넘는 보안 수정 사항이 포함된 묶음입니다. 그 안에는 10점 만점에 9.8점으로 평가된 다섯 가지 치명적인 Outlook 원격 코드 실행 취약점(CVE-2026-70242, CVE-2026-70291, CVE-2026-88156, CVE-2026-97016, CVE-2026-97749)이 들어 있었습니다. 이 중 최소 두 가지에 대해 Microsoft의 설명은 분명합니다. "Outlook 읽기 창에서 메시지를 보기만 해도 취약점이 발동될 수 있으며, 받는 사람이 메시지를 열거나 그 안의 어떤 것도 클릭할 필요가 없습니다." 읽기 창은 Outlook에서 메시지를 선택하면 표시되는 미리 보기 영역으로, 기본으로 켜져 있습니다. 클릭 없음. 첨부 파일 없음. 공격자의 로그인도 없음. 받은 편지함에 이메일이 도착하는 것만으로 충분합니다.

공정하게 말하면, Microsoft는 이 다섯 가지의 실제 악용 가능성을 "낮은 편"으로 평가했고, 아직 실제 공격 사례는 확인되지 않았습니다. 하지만 함께 공개된 또 다른 취약점은 사정이 다릅니다. Windows Shell 취약점인 CVE-2026-96951은 지금 이 순간에도 악용되고 있습니다. 이 취약점을 이용하면 악성 파일이 Mark of the Web — 다운로드한 파일에 Windows가 붙이는 표시로, SmartScreen과 Office 경고를 작동시키는 라벨 — 을 빠져나갈 수 있습니다. 이 라벨이 제거되면 악성 다운로드 파일은 평소의 경고 없이 열립니다. CISA는 10월 13일 이 취약점을 알려진 악용 취약점 목록(Known Exploited Vulnerabilities)에 추가하고 미국 연방 기관에 10월 16일까지 조치할 것을 요구했습니다. 그 기한은 이미 지났습니다.

캘거리의 소규모 사업자에게 이것이 의미하는 바는 이렇습니다. Outlook은 회사의 현관문이고, 모든 직원의 미리 보기 창은 열어 둔 창문입니다. 피싱 교육은 여전히 중요하지만, 보기만 해도 성립하는 이메일은 막을 수 없습니다. 해법은 패치이며, 그것도 지루한 운영 작업의 연속입니다. 업데이트를 설치하고, 기기를 재시작하고, 누군가가 실제로 완료됐는지 확인하는 일입니다.

이번 주 세 가지를 하십시오.

첫째, 10월 업데이트가 실제로 적용됐는지 확인하십시오. 패치는 설치되고 기기가 재시작될 때만 효과가 있습니다. 팀의 기기가 10월 13일 업데이트를 받았는지 확인하십시오. 아무도 재시작하지 않는 사무실 안쪽의 상시 켜진 PC도 포함해서입니다. Microsoft 365 앱, Office LTSC 2021 및 2024, 심지어 Mac용 Office까지 모두 영향을 받습니다.

둘째, 절대 잠들지 않는 기기들을 재시작하십시오. 프런트 데스크 공용 기기, 현장 PC, 아무도 로그인하지 않는 서버 — 업데이트는 이런 기기에서 몇 주씩 재시작을 기다리며 대기 상태로 남아 있습니다. 재시작을 기다리는 패치는 없는 패치나 마찬가지입니다.

셋째, 앞만 보지 말고 뒤도 돌아보십시오. Windows Shell 취약점은 패치가 나오기 전부터 악용됐기 때문에, 오늘 패치해도 지난주의 침투 거점이 사라지지는 않습니다. 지난 2주간의 Defender 경고에서 의심스러운 실행이 있었는지 검토하고, 최근의 이상한 다운로드는 특히 더 의심하십시오.

Canlus가 캘거리 소규모 사업자를 위해 하는 일이 바로 이런 화려하지 않은 작업입니다. 업데이트가 실제로 설치되고, 기기가 실제로 재시작되고, 기본이 제대로 지켜지게 하는 일입니다. canlus.com에서 무료 상담을 예약하고, 귀사의 10월 패치 상태가 실제로 어떤지 확인해 보십시오.

출처: CrowdStrike — “October 2026 Patch Tuesday: Updates and Analysis”; CISA Known Exploited Vulnerabilities Catalog; Security Affairs — “U.S. CISA adds Microsoft Windows Shell flaw to its Known Exploited Vulnerabilities catalog”; Microsoft MSRC — CVE-2026-96951

If your business website runs on WordPress — and most small-business websites do — you probably believe that keeping WordPress and your plugins updated is what keeps you safe. This morning, that assumption broke.

On October 21, 2026, the PHP security team released an emergency patch for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. Security researchers call them PHP2Shell: they let a remote attacker run their own code on your web server without logging in. Details of the flaws leaked a day early; Dutch government services, including DigiD and MijnOverheid, took systems offline as a precaution, and Cloudflare reports it is already seeing the first attacks.

Here is what this means for a Calgary small business owner. PHP is the language your website is built on — WordPress, Drupal, and Magento all run on it. The flaw sits in the language itself, not in WordPress. So updating WordPress does nothing. Your web host has to update the PHP version on the server. And here is the uncomfortable part: today's patch only covers supported PHP versions (8.2 through 8.5). If your site still runs PHP 5, 7, or 8.0/8.1, no patch is coming — the PHP team put it bluntly: updating is the only safe choice. A large share of small-business sites sit on shared hosting running PHP versions the host hasn't touched in years. Those are exactly the sites attackers scan for first.

Do three things today.

First, find out what PHP version your site runs. Ask your web host or your web person one question: what PHP version is my site on, and is today's PHP2Shell patch applied? If you can't get a straight answer within a day, that is a red flag about your provider.

Second, get patched or get off the old version. On PHP 8.2 to 8.5, the fix is available today — your host should apply it now. On PHP 5, 7, 8.0, or 8.1, plan the upgrade; staying put means staying exposed with no fix coming.

Third, check what else is exposed. Cloudflare's emergency filters are a stopgap, not a fix — they only help if your server's real address is hidden behind them. An attacker who knows your server's IP can bypass the filter entirely. Make sure your host blocks direct traffic to your server.

At Canlus, this is the exact check we run for Calgary small businesses: what your website actually runs on, what your host never told you, and where the gaps are. Book a free consultation at canlus.com and find out before an attacker does.

Sources: PHP security advisory — Critical remote code execution vulnerabilities, update now (php.net); The Hacker News — “PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches” (October 23, 2026); PHP.net — official advisory on CVE-2026-115560 (session upload progress; mitigation: session.upload_progress.enabled=0)

如果您的企业网站运行在 WordPress 上——而大多数小企业网站都是如此——您大概认为，只要保持 WordPress 和插件更新，网站就是安全的。今天早上，这个想法被打破了。

2026 年 10 月 21 日，PHP 安全团队针对两个严重漏洞发布了紧急补丁：CVE-2026-109618 和 CVE-2026-109619，两者的严重程度评分都是 9.2 分（满分 10 分）。安全研究人员将它们称为 PHP2Shell：它们允许远程攻击者在不登录的情况下，在您的 Web 服务器上运行自己的代码。漏洞细节提前一天被泄露；荷兰政府服务（包括 DigiD 和 MijnOverheid）出于谨慎将系统下线，Cloudflare 也报告称已经监测到第一批攻击。

这对卡尔加里的小企业主意味着什么。PHP 是构建您网站所用的语言——WordPress、Drupal 和 Magento 都运行在它之上。漏洞出在语言本身，而不是 WordPress。所以更新 WordPress 毫无作用。您的网站主机商必须更新服务器上的 PHP 版本。而令人不安的是：今天的补丁只覆盖受支持的 PHP 版本（8.2 到 8.5）。如果您的网站仍在运行 PHP 5、7 或 8.0/8.1，就不会有补丁到来——PHP 团队说得很直白：升级是唯一安全的选择。很大一部分小企业网站托管在共享主机上，运行着主机商多年未曾动过的 PHP 版本。而这些正是攻击者最先扫描的网站。

今天就做三件事。

第一，弄清您的网站运行的是哪个 PHP 版本。向您的主机商或负责网站的人问一个问题：我的网站用的是哪个 PHP 版本？今天的 PHP2Shell 补丁打上了吗？如果一天之内得不到明确答复，这本身就是关于这家服务商的一个危险信号。

第二，打上补丁，或者离开旧版本。对于 PHP 8.2 到 8.5，修复程序今天就已提供——您的主机商应该立即应用。对于 PHP 5、7、8.0 或 8.1，请规划升级；原地不动意味着持续暴露，而且不会有修复到来。

第三，检查还有哪些东西暴露在外。Cloudflare 的紧急过滤只是权宜之计，并非修复——只有当您服务器的真实地址藏在它们后面时才起作用。知道您服务器 IP 地址的攻击者可以完全绕过这层过滤。请确保您的主机商阻断了直达服务器的流量。

在 Canlus，这正是我们为卡尔加里小企业所做的检查：您的网站实际运行在什么之上、您的主机商从未告诉过您的事情，以及缺口在哪里。在 canlus.com 预约免费咨询，赶在攻击者之前查清楚。

来源：PHP 官方安全公告——严重远程代码执行漏洞，请立即更新（php.net）；The Hacker News——《PHP 在 PHP2Shell 紧急补丁发布两天后警告又一未修复的 RCE 风险》（2026 年 10 月 23 日）；PHP.net 官方公告——CVE-2026-115560（会话上传进度；缓解措施：session.upload_progress.enabled=0）

如果您的企業網站運行在 WordPress 上——而大多數小企業網站都是如此——您大概認為，只要保持 WordPress 和外掛更新，網站就是安全的。今天早上，這個想法被打破了。

2026 年 10 月 21 日，PHP 安全團隊針對兩個嚴重漏洞發布了緊急修補：CVE-2026-109618 和 CVE-2026-109619，兩者的嚴重程度評分都是 9.2 分（滿分 10 分）。安全研究人員將它們稱為 PHP2Shell：它們允許遠端攻擊者在不登入的情況下，在您的 Web 伺服器上執行自己的程式碼。漏洞細節提前一天被洩露；荷蘭政府服務（包括 DigiD 和 MijnOverheid）出於謹慎將系統下線，Cloudflare 也報告稱已經監測到第一批攻擊。

這對卡爾加里的小企業主意味著什麼。PHP 是建構您網站所用的語言——WordPress、Drupal 和 Magento 都運行在它之上。漏洞出在語言本身，而不是 WordPress。所以更新 WordPress 毫無作用。您的網站主機商必須更新伺服器上的 PHP 版本。而令人不安的是：今天的修補只覆蓋受支援的 PHP 版本（8.2 到 8.5）。如果您的網站仍在運行 PHP 5、7 或 8.0/8.1，就不會有修補到來——PHP 團隊說得很直白：升級是唯一安全的選擇。很大一部分小企業網站託管在共用主機上，運行著主機商多年未曾動過的 PHP 版本。而這些正是攻擊者最先掃描的網站。

今天就做三件事。

第一，弄清您的網站運行的是哪個 PHP 版本。向您的主機商或負責網站的人問一個問題：我的網站用的是哪個 PHP 版本？今天的 PHP2Shell 修補打上了嗎？如果一天之內得不到明確答覆，這本身就是關於這家服務商的一個危險信號。

第二，打上修補，或者離開舊版本。對於 PHP 8.2 到 8.5，修復程式今天就已提供——您的主機商應該立即套用。對於 PHP 5、7、8.0 或 8.1，請規劃升級；原地不動意味著持續暴露，而且不會有修復到來。

第三，檢查還有哪些東西暴露在外。Cloudflare 的緊急過濾只是權宜之計，並非修復——只有當您伺服器的真實位址藏在它們後面時才起作用。知道您伺服器 IP 位址的攻擊者可以完全繞過這層過濾。請確保您的主機商阻斷了直達伺服器的流量。

在 Canlus，這正是我們為卡爾加里小企業所做的檢查：您的網站實際運行在什麼之上、您的主機商從未告訴過您的事情，以及缺口在哪裡。在 canlus.com 預約免費諮詢，趕在攻擊者之前查清楚。

來源：PHP 官方安全公告——嚴重遠端程式碼執行漏洞，請立即更新（php.net）；The Hacker News——《PHP 在 PHP2Shell 緊急修補發布兩天後警告又一未修復的 RCE 風險》（2026 年 10 月 23 日）；PHP.net 官方公告——CVE-2026-115560（會話上傳進度；緩解措施：session.upload_progress.enabled=0）

御社のビジネスウェブサイトがWordPressで動いているなら——そして中小企業のウェブサイトのほとんどがそうです——WordPressとプラグインを最新の状態に保つことが安全につながると、たぶん思っているはずです。今朝、その前提が崩れました。

2026年10月21日、PHPセキュリティチームは2件の重大な脆弱性（CVE-2026-109618とCVE-2026-109619）に対する緊急パッチを公開しました。深刻度はどちらも10点満点中9.2です。セキュリティ研究者はこれらをPHP2Shellと呼んでいます。リモートの攻撃者がログインすることなく、あなたのWebサーバー上で自分のコードを実行できてしまう欠陥です。欠陥の詳細は1日早く漏洩し、オランダの政府サービス（DigiDやMijnOverheidを含む）は予防措置としてシステムをオフラインにしました。Cloudflareは、すでに最初の攻撃を観測していると報告しています。

カルガリーの中小企業経営者にとって、これは何を意味するのでしょうか。PHPはあなたのウェブサイトを構築する言語です——WordPress、Drupal、MagentoはいずれもPHP上で動作します。欠陥はWordPressではなく、言語そのものにあります。だからWordPressを更新しても何も解決しません。サーバー上のPHPのバージョンを更新しなければならないのは、あなたのウェブホストです。そして厄介なのはここからです。今回のパッチが対象とするのは、サポート対象のPHPバージョン（8.2から8.5）だけです。サイトがPHP 5、7、8.0/8.1のままなら、パッチは提供されません——PHPチームは率直に述べています。更新することこそが唯一の安全な選択だ、と。中小企業のサイトの多くは、ホストが何年も手を付けていないPHPバージョンのまま、共有ホスティングに置かれています。まさにそうしたサイトこそ、攻撃者が真っ先にスキャンする標的です。

今日、次の3つを実行してください。

第一に、サイトがどのPHPバージョンで動いているかを確認すること。ウェブホスト、またはウェブサイトの担当者に、こう聞いてください。「私のサイトのPHPバージョンは何ですか。今日のPHP2Shellパッチは適用されていますか」。1日以内に明確な答えが得られないなら、それ自体がその事業者に対する危険信号です。

第二に、パッチを当てるか、古いバージョンから離れること。PHP 8.2から8.5については、修正は今日すでに提供されています——ホストは今すぐ適用すべきです。PHP 5、7、8.0、8.1については、アップグレードを計画してください。そのままでは、修正が来ないまま晒され続けることになります。

第三に、他に何が晒されているかを確認すること。Cloudflareの緊急フィルターは応急処置であって、修正ではありません——サーバーの実際のアドレスがその背後に隠れている場合にのみ効果があります。サーバーのIPアドレスを知っている攻撃者は、フィルターを完全にかいくぐることができます。ホストがサーバーへの直接のトラフィックを遮断しているか、必ず確認してください。

Canlusがカルガリーの中小企業のために行っているのは、まさにこの確認です。あなたのウェブサイトが実際に何の上で動いているのか、ホストが決して教えてこなかったことは何か、そして隙間はどこにあるのか。canlus.comで無料相談を予約し、攻撃者より先に把握してください。

出典：PHP security advisory — Critical remote code execution vulnerabilities, update now (php.net); The Hacker News — “PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches” (October 23, 2026); PHP.net — official advisory on CVE-2026-115560 (session upload progress; mitigation: session.upload_progress.enabled=0)

귀사의 비즈니스 웹사이트가 WordPress로 운영되고 있다면 — 그리고 대부분의 소규모 사업자 웹사이트가 그렇습니다 — WordPress와 플러그인을 최신 상태로 유지하는 것이 곧 안전이라고 믿고 계실 것입니다. 오늘 아침, 그 믿음이 깨졌습니다.

2026년 10월 21일, PHP 보안 팀은 두 가지 치명적인 취약점 CVE-2026-109618과 CVE-2026-109619에 대한 긴급 패치를 발표했습니다. 두 취약점 모두 10점 만점에 9.2점으로 평가되었습니다. 보안 연구자들은 이를 PHP2Shell이라고 부릅니다. 원격 공격자가 로그인 없이 귀사의 웹 서버에서 자신의 코드를 실행할 수 있게 하는 취약점입니다. 취약점 세부 정보는 하루 먼저 유출되었고, DigiD와 MijnOverheid를 포함한 네덜란드 정부 서비스는 예방 차원에서 시스템을 오프라인으로 전환했으며, Cloudflare는 이미 첫 공격을 관측하고 있다고 밝혔습니다.

캘거리의 소규모 사업자에게 이것이 의미하는 바는 이렇습니다. PHP는 귀사의 웹사이트가 구축된 언어입니다. WordPress, Drupal, Magento 모두 PHP 위에서 동작합니다. 취약점은 WordPress가 아니라 언어 자체에 있습니다. 따라서 WordPress를 업데이트해도 아무 소용이 없습니다. 서버의 PHP 버전을 업데이트해야 하는 주체는 웹 호스트입니다. 그리고 불편한 부분이 있습니다. 오늘의 패치는 지원되는 PHP 버전(8.2부터 8.5)만 해당합니다. 사이트가 여전히 PHP 5, 7, 8.0/8.1을 사용하고 있다면 패치는 오지 않습니다. PHP 팀은 단도직입적으로 말했습니다. 업데이트만이 유일하게 안전한 선택이라고요. 상당수의 소규모 사업자 사이트가 호스트가 수년간 손대지 않은 PHP 버전을 실행하는 공유 호스팅에 놓여 있습니다. 바로 그런 사이트가 공격자가 가장 먼저 스캔하는 대상입니다.

오늘 세 가지를 하십시오.

첫째, 사이트가 어떤 PHP 버전을 실행하는지 확인하십시오. 웹 호스트나 웹사이트 담당자에게 한 가지 질문을 하십시오. 제 사이트의 PHP 버전은 무엇이며, 오늘의 PHP2Shell 패치가 적용되었습니까? 하루 안에 명확한 답변을 받을 수 없다면, 그 자체가 해당 업체에 대한 위험 신호입니다.

둘째, 패치를 적용하거나 구버전에서 벗어나십시오. PHP 8.2부터 8.5까지는 수정 사항이 오늘 이미 제공됩니다. 호스트가 지금 바로 적용해야 합니다. PHP 5, 7, 8.0, 8.1이라면 업그레이드를 계획하십시오. 그대로 두는 것은 수정이 오지 않는 상태에서 계속 노출되는 것을 의미합니다.

셋째, 그 밖에 무엇이 노출되어 있는지 확인하십시오. Cloudflare의 긴급 필터는 임시방편일 뿐 수정이 아닙니다. 서버의 실제 주소가 그 뒤에 숨겨져 있을 때만 도움이 됩니다. 서버의 IP 주소를 아는 공격자는 필터를 완전히 우회할 수 있습니다. 호스트가 서버로의 직접 트래픽을 차단하고 있는지 확인하십시오.

Canlus가 캘거리 소규모 사업자를 위해 하는 일이 바로 이 점검입니다. 귀사의 웹사이트가 실제로 무엇 위에서 운영되는지, 호스트가 한 번도 알려주지 않은 것, 그리고 빈틈이 어디인지 말입니다. canlus.com에서 무료 상담을 예약하고, 공격자보다 먼저 확인하십시오.

출처: PHP security advisory — Critical remote code execution vulnerabilities, update now (php.net); The Hacker News — “PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches” (October 23, 2026); PHP.net — official advisory on CVE-2026-115560 (session upload progress; mitigation: session.upload_progress.enabled=0)

You locked the front door. You gave every employee MFA. You even ran phishing training. Last week, none of that would have stopped the attack that walked into 173 Microsoft 365 tenants.

What happened: on October 14, 2026, ConnectWise discovered that attackers had compromised the application credentials behind ConnectWise Cloud Backup — the tool formerly known as SkyKick that thousands of IT providers use to back up their clients' Microsoft 365 data. The attackers didn't phish anyone or steal a password. They signed straight into customer tenants as the trusted application itself.

That is the part that should worry you. Application identities don't get MFA prompts. The stolen app already held broad, standing permissions — mailboxes, OneDrive, SharePoint, Teams, directory data — granted long ago by customers who had forgotten about them. Microsoft is tracking it as an "active supply chain attack": on October 15, the attackers authenticated as the app's service principal from a single IP address and pulled Microsoft Graph tokens across customer tenants. Security firm Huntress confirmed unauthorized sign-ins in 173 partner and customer tenants — all of them on October 15, between 06:13 and 08:34 UTC, moving through the tenants in sorted order seconds apart, like a script working down a target list. In at least one tenant, the attackers used a related ConnectWise app to grant itself Global Administrator and plant new credentials — new secret keys added to other trusted applications, including the provider's own management tool — backdoors that survive even after the original app is disabled.

On October 17, ConnectWise disabled seven application identities and suspended Cloud Backup, SaaS Security, and Cloud Management. The stored backup archives stayed encrypted and untouched. The live tenants were not so lucky.

What this means for a small business in Calgary: your security boundary doesn't end at your own tenant's front door. Every third-party app your IT provider has connected to your Microsoft 365 — backup tools, monitoring agents, migration utilities — holds keys to your data. If that vendor's key is stolen, the attacker inherits everything the app was allowed to touch. Your MFA never rings. This is the exact blind spot you inherit when you outsource IT and never ask what's plugged in.

Do three things this week.

First, inventory your third-party access. In Microsoft Entra, open Enterprise applications and list every non-Microsoft app connected to your tenant. Ask your IT provider two blunt questions: do you run ConnectWise Cloud Backup against our tenant — and what did you check on October 15? And for every app on the list: what can each of these read and write, and why does it need that?

Second, cut standing over-privilege. Anything holding broad rights like Directory.ReadWrite.All that doesn't need them should be trimmed now. Turn on the admin consent workflow so no new app connects silently in the future.

Third, make your vendors prove it. Ask your provider how application credentials are stored and rotated, and what their incident plan is when one of their tools is compromised. After any vendor incident, independently review service-principal sign-in logs in Entra — disabling an app doesn't remove backdoors it already planted. And turn on alerts for application-level changes: a new service-principal credential, a privilege escalation, or a fresh admin-consent grant should notify a human the moment it happens, because those are exactly the moves the attackers made here.

At Canlus, this is the work we do for Calgary small businesses: Microsoft 365 and Entra ID reviews that surface the trusted apps and forgotten permissions everyone stopped looking at. Book a free consultation at canlus.com and find out who's holding keys to your tenant.

Sources: Huntress — ConnectWise (SkyKick) vendor credentials abused in Microsoft 365 attacks

You locked the front door. You gave every employee MFA. You even ran phishing training. Last week, none of that would have stopped the attack that walked into 173 Microsoft 365 tenants.

What happened: on October 14, 2026, ConnectWise discovered that attackers had compromised the application credentials behind ConnectWise Cloud Backup — the tool formerly known as SkyKick that thousands of IT providers use to back up their clients' Microsoft 365 data. The attackers didn't phish anyone or steal a password. They signed straight into customer tenants as the trusted application itself.

That is the part that should worry you. Application identities don't get MFA prompts. The stolen app already held broad, standing permissions — mailboxes, OneDrive, SharePoint, Teams, directory data — granted long ago by customers who had forgotten about them. Microsoft is tracking it as an "active supply chain attack": on October 15, the attackers authenticated as the app's service principal from a single IP address and pulled Microsoft Graph tokens across customer tenants. Security firm Huntress confirmed unauthorized sign-ins in 173 partner and customer tenants — all of them on October 15, between 06:13 and 08:34 UTC, moving through the tenants in sorted order seconds apart, like a script working down a target list. In at least one tenant, the attackers used a related ConnectWise app to grant itself Global Administrator and plant new credentials — new secret keys added to other trusted applications, including the provider's own management tool — backdoors that survive even after the original app is disabled.

On October 17, ConnectWise disabled seven application identities and suspended Cloud Backup, SaaS Security, and Cloud Management. The stored backup archives stayed encrypted and untouched. The live tenants were not so lucky.

What this means for a small business in Calgary: your security boundary doesn't end at your own tenant's front door. Every third-party app your IT provider has connected to your Microsoft 365 — backup tools, monitoring agents, migration utilities — holds keys to your data. If that vendor's key is stolen, the attacker inherits everything the app was allowed to touch. Your MFA never rings. This is the exact blind spot you inherit when you outsource IT and never ask what's plugged in.

Do three things this week.

First, inventory your third-party access. In Microsoft Entra, open Enterprise applications and list every non-Microsoft app connected to your tenant. Ask your IT provider two blunt questions: do you run ConnectWise Cloud Backup against our tenant — and what did you check on October 15? And for every app on the list: what can each of these read and write, and why does it need that?

Second, cut standing over-privilege. Anything holding broad rights like Directory.ReadWrite.All that doesn't need them should be trimmed now. Turn on the admin consent workflow so no new app connects silently in the future.

Third, make your vendors prove it. Ask your provider how application credentials are stored and rotated, and what their incident plan is when one of their tools is compromised. After any vendor incident, independently review service-principal sign-in logs in Entra — disabling an app doesn't remove backdoors it already planted. And turn on alerts for application-level changes: a new service-principal credential, a privilege escalation, or a fresh admin-consent grant should notify a human the moment it happens, because those are exactly the moves the attackers made here.

At Canlus, this is the work we do for Calgary small businesses: Microsoft 365 and Entra ID reviews that surface the trusted apps and forgotten permissions everyone stopped looking at. Book a free consultation at canlus.com and find out who's holding keys to your tenant.

Sources: Huntress — ConnectWise (SkyKick) vendor credentials abused in Microsoft 365 attacks

Last month, a cybercriminal broke into websites belonging to more than 100 companies — including Deere, SharkNinja, and Cummins — and did almost none of the work himself.

According to a Reuters exclusive published Monday, the entire campaign was outsourced to AI agents. The findings come from Snorre Fagerland, threat researcher at NorForge, who found about two dozen exposed dashboards of Cairn, an open-source AI platform that has become popular with criminals. Because the attacker left those control panels unauthenticated, Fagerland could read the operation in full: instructions shorter than 100 Chinese characters, followed by hours of fully autonomous probing.

The numbers are the story. The campaign began around September 25, aimed at e-commerce sites in the US, Canada, Australia, and Japan. Each successful break-in took roughly 23 hours of agent work from first contact to working access — with no human in the loop. Fagerland puts the whole run at about $5,000 in AI tokens, roughly $50 per successful hack.

Reuters independently verified the victims' identities but could not establish whether any data was actually extracted. The open doors are confirmed; what walked out through them is not yet known.

NorForge was not the only team watching this toolchain at work. Gambit Security reconstructed an earlier September wave of the same campaign — the same Cairn platform doing the exploiting end-to-end, alongside Strix, which found the vulnerabilities, and Hermes, which orchestrated the operation — from the attacker's own staging server. Between September 10 and 15, that wave launched 105 attack projects and compromised at least 27 companies, at an average cost of just $25.46 per company. From only two victims, the attackers took more than 600,000 unexpired credit card records, and skimmer scripts that silently copy card numbers at checkout were planted on 19 victims' websites. One victim even lost 180 database tables when the attacker's cleanup script misfired — a reminder that when AI agents go wrong, they go wrong at machine speed too.

Why Calgary small businesses should care

The old model was a crew of skilled humans picking targets. This one is a single person, fewer than 100 characters of instruction, and an AI that works 23-hour shifts without sleeping. It doesn't need to outsmart your website — it needs one unpatched plugin, one exposed login page, one forgotten admin account. And it can hit a thousand websites in the same span.

Targets were filtered by traffic — 200,000 to 1.5 million visits a month — which covers plenty of mid-size business websites. And the reported goal was an uploader webshell: a foothold planted for later use. The damage may not surface until long after the break-in.

Three things to do this week

1. Update everything your website runs on. AI agents hunt known, published vulnerabilities — not exotic zero-days. Content management systems, plugins, themes, and server software all have update buttons that too many small sites ignore.
2. Lock down your admin doors. Move admin logins off guessable URLs, put MFA on every administrative account, and kill default or shared credentials. A password built from today's date is barely a password at all — and entire industries have been breached for less.
3. Watch for the planted foothold. The reported end goal was a hidden uploader on the victim's server. Ask your web host or IT provider to scan for unknown files and unexpected new URLs, and set up alerts for changes you didn't make. And if you take payments online, watch your checkout page like a cash register: have someone monitor the scripts that load there, because a skimmer hides inside legitimate files — you won't see it just by looking at the page.

A single attacker's overnight project now costs less per victim than a tank of gas. The defenses are boring, cheap, and overdue. Which of the three above have you actually done?

Canlus offers a free Calgary small-business security review: we'll check your website's exposed surface and hand you a prioritized fix list. Book your free consultation at canlus.com.

Last month, a cybercriminal broke into websites belonging to more than 100 companies — including Deere, SharkNinja, and Cummins — and did almost none of the work himself.

According to a Reuters exclusive published Monday, the entire campaign was outsourced to AI agents. The findings come from Snorre Fagerland, threat researcher at NorForge, who found about two dozen exposed dashboards of Cairn, an open-source AI platform that has become popular with criminals. Because the attacker left those control panels unauthenticated, Fagerland could read the operation in full: instructions shorter than 100 Chinese characters, followed by hours of fully autonomous probing.

The numbers are the story. The campaign began around September 25, aimed at e-commerce sites in the US, Canada, Australia, and Japan. Each successful break-in took roughly 23 hours of agent work from first contact to working access — with no human in the loop. Fagerland puts the whole run at about $5,000 in AI tokens, roughly $50 per successful hack.

Reuters independently verified the victims' identities but could not establish whether any data was actually extracted. The open doors are confirmed; what walked out through them is not yet known.

NorForge was not the only team watching this toolchain at work. Gambit Security reconstructed an earlier September wave of the same campaign — the same Cairn platform doing the exploiting end-to-end, alongside Strix, which found the vulnerabilities, and Hermes, which orchestrated the operation — from the attacker's own staging server. Between September 10 and 15, that wave launched 105 attack projects and compromised at least 27 companies, at an average cost of just $25.46 per company. From only two victims, the attackers took more than 600,000 unexpired credit card records, and skimmer scripts that silently copy card numbers at checkout were planted on 19 victims' websites. One victim even lost 180 database tables when the attacker's cleanup script misfired — a reminder that when AI agents go wrong, they go wrong at machine speed too.

Why Calgary small businesses should care

The old model was a crew of skilled humans picking targets. This one is a single person, fewer than 100 characters of instruction, and an AI that works 23-hour shifts without sleeping. It doesn't need to outsmart your website — it needs one unpatched plugin, one exposed login page, one forgotten admin account. And it can hit a thousand websites in the same span.

Targets were filtered by traffic — 200,000 to 1.5 million visits a month — which covers plenty of mid-size business websites. And the reported goal was an uploader webshell: a foothold planted for later use. The damage may not surface until long after the break-in.

Three things to do this week

1. Update everything your website runs on. AI agents hunt known, published vulnerabilities — not exotic zero-days. Content management systems, plugins, themes, and server software all have update buttons that too many small sites ignore.
2. Lock down your admin doors. Move admin logins off guessable URLs, put MFA on every administrative account, and kill default or shared credentials. A password built from today's date is barely a password at all — and entire industries have been breached for less.
3. Watch for the planted foothold. The reported end goal was a hidden uploader on the victim's server. Ask your web host or IT provider to scan for unknown files and unexpected new URLs, and set up alerts for changes you didn't make. And if you take payments online, watch your checkout page like a cash register: have someone monitor the scripts that load there, because a skimmer hides inside legitimate files — you won't see it just by looking at the page.

A single attacker's overnight project now costs less per victim than a tank of gas. The defenses are boring, cheap, and overdue. Which of the three above have you actually done?

Canlus offers a free Calgary small-business security review: we'll check your website's exposed surface and hand you a prioritized fix list. Book your free consultation at canlus.com.

If you gave your team Microsoft Copilot — or let anyone plug an AI tool into company data — here's an uncomfortable question: can you name every AI agent currently operating inside your business, and say what each one is allowed to see?

According to Veeam's Data Trust & Resilience Report 2026, 88% of organizations are already using or piloting AI agents, but only 7% qualify as truly AI-ready. More striking: over 82% of enterprises have AI agents running in their IT environments that nobody knows about. Shadow AI isn't a future problem. It's already on your payroll, with access to your files.

This week the industry started treating it like the governance gap it is. Veeam launched Intelligent ResOps for Microsoft 365 (generally available October 18): it discovers Copilot and other AI agents in your tenant, maps exactly which sensitive data each agent can reach, closes oversharing gaps, and can precisely undo files an agent changed or deleted. It continuously classifies sensitive and regulated data across SharePoint, OneDrive, Teams, and Exchange — and lets your team ask "what did that agent touch?" in plain language. In parallel, Singapore's IMDA and the AI Verify Foundation released a toolkit for testing AI agents for safety and reliability. Regulators are formalizing what good agent oversight looks like.

Why Calgary small businesses should care

An AI agent acts with the permissions of whoever set it up. If your SharePoint is full of "everyone except external users" sharing links — and most small businesses are — then every agent connected to your tenant inherits that reach. An agent can read client files no human would ever open, rename or delete documents at 2 a.m., and the audit trail won't read like a person did it. This week's incident reports keep making the same point from the other direction: AI systems with broad access and no permission or spending limits are already causing real damage.

Three things to do this week

1. Inventory your agents. List every AI agent and app with access to your Microsoft 365: Copilot, custom agents, third-party tools. For each one, note who approved it and what data it can reach. If you can't produce this list, that's finding number one.
2. Fix oversharing at the source. Review sharing links in SharePoint and OneDrive — "anyone with the link" and company-wide links are the usual leak. Tighten the data permissions first; an agent can only touch what those permissions allow.
3. Put guardrails in writing. Decide which data AI agents may touch, turn on audit logging for agent actions, and set usage or spending alerts wherever the platform allows. A one-page AI acceptable-use rule beats a post-incident scramble.

You don't need an enterprise governance platform to start. You need to know what's already running in your tenant — most small businesses are surprised by the answer.

Canlus offers a free Calgary small-business Microsoft 365 security review: we'll map the apps and AI agents inside your tenant and hand you a prioritized harden list.

If you gave your team Microsoft Copilot — or let anyone plug an AI tool into company data — here's an uncomfortable question: can you name every AI agent currently operating inside your business, and say what each one is allowed to see?

According to Veeam's Data Trust & Resilience Report 2026, 88% of organizations are already using or piloting AI agents, but only 7% qualify as truly AI-ready. More striking: over 82% of enterprises have AI agents running in their IT environments that nobody knows about. Shadow AI isn't a future problem. It's already on your payroll, with access to your files.

This week the industry started treating it like the governance gap it is. Veeam launched Intelligent ResOps for Microsoft 365 (generally available October 18): it discovers Copilot and other AI agents in your tenant, maps exactly which sensitive data each agent can reach, closes oversharing gaps, and can precisely undo files an agent changed or deleted. It continuously classifies sensitive and regulated data across SharePoint, OneDrive, Teams, and Exchange — and lets your team ask "what did that agent touch?" in plain language. In parallel, Singapore's IMDA and the AI Verify Foundation released a toolkit for testing AI agents for safety and reliability. Regulators are formalizing what good agent oversight looks like.

Why Calgary small businesses should care

An AI agent acts with the permissions of whoever set it up. If your SharePoint is full of "everyone except external users" sharing links — and most small businesses are — then every agent connected to your tenant inherits that reach. An agent can read client files no human would ever open, rename or delete documents at 2 a.m., and the audit trail won't read like a person did it. This week's incident reports keep making the same point from the other direction: AI systems with broad access and no permission or spending limits are already causing real damage.

Three things to do this week

1. Inventory your agents. List every AI agent and app with access to your Microsoft 365: Copilot, custom agents, third-party tools. For each one, note who approved it and what data it can reach. If you can't produce this list, that's finding number one.
2. Fix oversharing at the source. Review sharing links in SharePoint and OneDrive — "anyone with the link" and company-wide links are the usual leak. Tighten the data permissions first; an agent can only touch what those permissions allow.
3. Put guardrails in writing. Decide which data AI agents may touch, turn on audit logging for agent actions, and set usage or spending alerts wherever the platform allows. A one-page AI acceptable-use rule beats a post-incident scramble.

You don't need an enterprise governance platform to start. You need to know what's already running in your tenant — most small businesses are surprised by the answer.

Canlus offers a free Calgary small-business Microsoft 365 security review: we'll map the apps and AI agents inside your tenant and hand you a prioritized harden list.

If you gave your team Microsoft Copilot — or let anyone plug an AI tool into company data — here's an uncomfortable question: can you name every AI agent currently operating inside your business, and say what each one is allowed to see?

According to Veeam's Data Trust & Resilience Report 2026, 88% of organizations are already using or piloting AI agents, but only 7% qualify as truly AI-ready. More striking: over 82% of enterprises have AI agents running in their IT environments that nobody knows about. Shadow AI isn't a future problem. It's already on your payroll, with access to your files.

This week the industry started treating it like the governance gap it is. Veeam launched Intelligent ResOps for Microsoft 365 (generally available October 18): it discovers Copilot and other AI agents in your tenant, maps exactly which sensitive data each agent can reach, closes oversharing gaps, and can precisely undo files an agent changed or deleted. It continuously classifies sensitive and regulated data across SharePoint, OneDrive, Teams, and Exchange — and lets your team ask "what did that agent touch?" in plain language. In parallel, Singapore's IMDA and the AI Verify Foundation released a toolkit for testing AI agents for safety and reliability. Regulators are formalizing what good agent oversight looks like.

Why Calgary small businesses should care

An AI agent acts with the permissions of whoever set it up. If your SharePoint is full of "everyone except external users" sharing links — and most small businesses are — then every agent connected to your tenant inherits that reach. An agent can read client files no human would ever open, rename or delete documents at 2 a.m., and the audit trail won't read like a person did it. This week's incident reports keep making the same point from the other direction: AI systems with broad access and no permission or spending limits are already causing real damage.

Three things to do this week

1. Inventory your agents. List every AI agent and app with access to your Microsoft 365: Copilot, custom agents, third-party tools. For each one, note who approved it and what data it can reach. If you can't produce this list, that's finding number one.
2. Fix oversharing at the source. Review sharing links in SharePoint and OneDrive — "anyone with the link" and company-wide links are the usual leak. Tighten the data permissions first; an agent can only touch what those permissions allow.
3. Put guardrails in writing. Decide which data AI agents may touch, turn on audit logging for agent actions, and set usage or spending alerts wherever the platform allows. A one-page AI acceptable-use rule beats a post-incident scramble.

You don't need an enterprise governance platform to start. You need to know what's already running in your tenant — most small businesses are surprised by the answer.

Canlus offers a free Calgary small-business Microsoft 365 security review: we'll map the apps and AI agents inside your tenant and hand you a prioritized harden list.

If you gave your team Microsoft Copilot — or let anyone plug an AI tool into company data — here's an uncomfortable question: can you name every AI agent currently operating inside your business, and say what each one is allowed to see?

According to Veeam's Data Trust & Resilience Report 2026, 88% of organizations are already using or piloting AI agents, but only 7% qualify as truly AI-ready. More striking: over 82% of enterprises have AI agents running in their IT environments that nobody knows about. Shadow AI isn't a future problem. It's already on your payroll, with access to your files.

This week the industry started treating it like the governance gap it is. Veeam launched Intelligent ResOps for Microsoft 365 (generally available October 18): it discovers Copilot and other AI agents in your tenant, maps exactly which sensitive data each agent can reach, closes oversharing gaps, and can precisely undo files an agent changed or deleted. It continuously classifies sensitive and regulated data across SharePoint, OneDrive, Teams, and Exchange — and lets your team ask "what did that agent touch?" in plain language. In parallel, Singapore's IMDA and the AI Verify Foundation released a toolkit for testing AI agents for safety and reliability. Regulators are formalizing what good agent oversight looks like.

Why Calgary small businesses should care

An AI agent acts with the permissions of whoever set it up. If your SharePoint is full of "everyone except external users" sharing links — and most small businesses are — then every agent connected to your tenant inherits that reach. An agent can read client files no human would ever open, rename or delete documents at 2 a.m., and the audit trail won't read like a person did it. This week's incident reports keep making the same point from the other direction: AI systems with broad access and no permission or spending limits are already causing real damage.

Three things to do this week

1. Inventory your agents. List every AI agent and app with access to your Microsoft 365: Copilot, custom agents, third-party tools. For each one, note who approved it and what data it can reach. If you can't produce this list, that's finding number one.
2. Fix oversharing at the source. Review sharing links in SharePoint and OneDrive — "anyone with the link" and company-wide links are the usual leak. Tighten the data permissions first; an agent can only touch what those permissions allow.
3. Put guardrails in writing. Decide which data AI agents may touch, turn on audit logging for agent actions, and set usage or spending alerts wherever the platform allows. A one-page AI acceptable-use rule beats a post-incident scramble.

You don't need an enterprise governance platform to start. You need to know what's already running in your tenant — most small businesses are surprised by the answer.

Canlus offers a free Calgary small-business Microsoft 365 security review: we'll map the apps and AI agents inside your tenant and hand you a prioritized harden list.

If you gave your team Microsoft Copilot — or let anyone plug an AI tool into company data — here's an uncomfortable question: can you name every AI agent currently operating inside your business, and say what each one is allowed to see?

According to Veeam's Data Trust & Resilience Report 2026, 88% of organizations are already using or piloting AI agents, but only 7% qualify as truly AI-ready. More striking: over 82% of enterprises have AI agents running in their IT environments that nobody knows about. Shadow AI isn't a future problem. It's already on your payroll, with access to your files.

This week the industry started treating it like the governance gap it is. Veeam launched Intelligent ResOps for Microsoft 365 (generally available October 18): it discovers Copilot and other AI agents in your tenant, maps exactly which sensitive data each agent can reach, closes oversharing gaps, and can precisely undo files an agent changed or deleted. It continuously classifies sensitive and regulated data across SharePoint, OneDrive, Teams, and Exchange — and lets your team ask "what did that agent touch?" in plain language. In parallel, Singapore's IMDA and the AI Verify Foundation released a toolkit for testing AI agents for safety and reliability. Regulators are formalizing what good agent oversight looks like.

Why Calgary small businesses should care

An AI agent acts with the permissions of whoever set it up. If your SharePoint is full of "everyone except external users" sharing links — and most small businesses are — then every agent connected to your tenant inherits that reach. An agent can read client files no human would ever open, rename or delete documents at 2 a.m., and the audit trail won't read like a person did it. This week's incident reports keep making the same point from the other direction: AI systems with broad access and no permission or spending limits are already causing real damage.

Three things to do this week

1. Inventory your agents. List every AI agent and app with access to your Microsoft 365: Copilot, custom agents, third-party tools. For each one, note who approved it and what data it can reach. If you can't produce this list, that's finding number one.
2. Fix oversharing at the source. Review sharing links in SharePoint and OneDrive — "anyone with the link" and company-wide links are the usual leak. Tighten the data permissions first; an agent can only touch what those permissions allow.
3. Put guardrails in writing. Decide which data AI agents may touch, turn on audit logging for agent actions, and set usage or spending alerts wherever the platform allows. A one-page AI acceptable-use rule beats a post-incident scramble.

You don't need an enterprise governance platform to start. You need to know what's already running in your tenant — most small businesses are surprised by the answer.

Canlus offers a free Calgary small-business Microsoft 365 security review: we'll map the apps and AI agents inside your tenant and hand you a prioritized harden list.

Your employees are downloading AI tools faster than anyone can vet them. That habit just became an attack vector.

On October 14, ANY.RUN published research linking 1,258 confirmed sandbox analyses — collected between April and October 2026 — to campaigns impersonating the AI brands your team uses every day: Claude, ChatGPT, GitHub Copilot, Gemini, Perplexity, and others. Claude and ChatGPT fakes alone account for 81% of cases. The payloads are infostealers and remote-access trojans; the prize is browser sessions and business accounts.

This is not the phishing email of 2019. The lures hide in sponsored search results — the "official site" at the top of Google may be a paid ad — and on fake download pages hosted on trusted platforms like GitHub Pages, Cloudflare Pages, and Google Sites, which sail past web filters. In 45% of cases, victims are talked into pasting a command into the Windows Run dialog, PowerShell, or Terminal. The moment they hit Enter, the attacker owns the session. Developers and marketing teams are the top targets, and US businesses are the second-most-hit country.

Why Calgary small businesses should care

You probably don’t have a software approval process — most 20-person companies don’t. That means anyone on your team can Google "Claude download," click the first result, and install a trojaned copy before lunch. One pasted command bypasses every password and MFA prompt you paid for, because session theft doesn’t need your credentials. The campaigns peaked in May but never stopped: 108 to 151 confirmed cases every month through September.

Three things to do this week

1. Only download from the vendor’s real domain — typed by hand. Bookmark anthropic.com, openai.com, and the other official sites. Never install from a search result, especially a sponsored one. If the URL looks even slightly off, stop.
2. Publish a one-page approved AI tools list. It takes ten minutes: name the AI tools your team is allowed to use, and require a quick IT check before anything else gets installed. Most "I just needed it for one task" installs disappear once there’s a list.
3. Draw a hard red line at "paste this command." No legitimate installer asks you to paste commands into PowerShell or the Run dialog. Teach every employee this single rule in a five-minute huddle — and back it up with phishing-resistant MFA (like an authenticator app or security key) so a stolen session alone isn’t enough.

AI tools are genuinely useful for small businesses. The fakes work precisely because the real ones are so popular. A ten-minute policy today beats an incident-response call next month.

Canlus offers a free Calgary small-business security risk assessment: we’ll map the software your team actually runs and hand you a prioritized harden list.

你的员工下载 AI 工具的速度，比任何人审核的速度都快。这个习惯刚刚变成了一个攻击入口。

10 月 14 日，ANY.RUN 发布研究报告，将 1,258 起已确认的沙箱分析（2026 年 4 月至 10 月收集）与仿冒你团队每天使用的 AI 品牌的攻击活动关联起来：Claude、ChatGPT、GitHub Copilot、Gemini、Perplexity 等。仅仿冒 Claude 和 ChatGPT 的就占 81%。载荷是信息窃取木马和远程控制木马；攻击者要的是浏览器会话和企业账号。

这不是 2019 年的钓鱼邮件。诱饵藏在赞助搜索结果里——Google 顶部的"官网"可能是付费广告——也藏在托管于 GitHub Pages、Cloudflare Pages、Google Sites 等可信平台的假下载页上，这些页面能轻松绕过网页过滤。在 45% 的案例中，受害者被诱导把命令粘贴进 Windows 运行对话框、PowerShell 或终端。按下回车的那一刻，攻击者就接管了会话。开发者和市场团队是头号目标，美国企业是受害第二多的国家。

卡尔加里小企业为什么要在意

你很可能没有软件审批流程——大多数 20 人的公司都没有。这意味着你团队里的任何人都可以搜一下"Claude 下载"，点第一个结果，午饭前就装上一个带木马的版本。一条粘贴的命令就能绕过你花钱买的所有密码和 MFA，因为会话劫持根本不需要你的凭证。攻击活动在 5 月达到高峰，但从未停止：6 月到 9 月，每月都有 108 到 151 起已确认案例。

本周要做的 3 件事

1. 只从厂商的真实域名下载——手动输入。把 anthropic.com、openai.com 等官网加入书签。永远不要从搜索结果安装，尤其是赞助结果。网址看起来稍有不对就停下。
2. 发布一页纸的"可用 AI 工具清单"。只要十分钟：列出团队允许使用的 AI 工具，其他任何工具安装前都要经过 IT 快速确认。有了清单，"我就临时用一下"的安装大多会消失。
3. 对"粘贴这条命令"划红线。没有任何正规安装程序会让你往 PowerShell 或运行对话框里粘贴命令。用五分钟的晨会把这一条规则教给每个员工——再配上防钓鱼的 MFA（比如验证器 App 或安全密钥），这样光偷走会话还不够。

AI 工具对小企业是真的有用。仿冒品之所以得手，恰恰因为正品太受欢迎。今天花十分钟定个规矩，好过下个月打电话请人做应急响应。

Canlus 为卡尔加里小企业提供免费安全风险评估：我们会梳理你团队实际在用的软件，给你一份按优先级排好的加固清单。

你的員工下載 AI 工具的速度，比任何人審核的速度都快。這個習慣剛剛變成了一個攻擊入口。

10 月 14 日，ANY.RUN 發布研究報告，將 1,258 起已確認的沙箱分析（2026 年 4 月至 10 月收集）與仿冒你團隊每天使用的 AI 品牌的攻擊活動關聯起來：Claude、ChatGPT、GitHub Copilot、Gemini、Perplexity 等。僅仿冒 Claude 和 ChatGPT 的就佔 81%。載荷是資訊竊取木馬和遠端控制木馬；攻擊者要的是瀏覽器工作階段和企業帳號。

這不是 2019 年的釣魚郵件。誘餌藏在贊助搜尋結果裡——Google 頂部的「官網」可能是付費廣告——也藏在託管於 GitHub Pages、Cloudflare Pages、Google Sites 等可信平台的假下載頁上，這些頁面能輕鬆繞過網頁過濾。在 45% 的案例中，受害者被誘導把命令貼進 Windows 執行對話方塊、PowerShell 或終端機。按下 Enter 的那一刻，攻擊者就接管了工作階段。開發者和市場團隊是頭號目標，美國企業是受害第二多的國家。

卡加利小企業為什麼要在意

你很可能沒有軟體審批流程——大多數 20 人的公司都沒有。這意味著你團隊裡的任何人都可以搜一下「Claude 下載」，點第一個結果，午飯前就裝上一個帶木馬的版本。一條貼上的命令就能繞過你花錢買的所有密碼和 MFA，因為工作階段劫持根本不需要你的憑證。攻擊活動在 5 月達到高峰，但從未停止：6 月到 9 月，每月都有 108 到 151 起已確認案例。

本週要做的 3 件事

1. 只從廠商的真實網域下載——手動輸入。把 anthropic.com、openai.com 等官網加入書籤。永遠不要從搜尋結果安裝，尤其是贊助結果。網址看起來稍有不對就停下。
2. 發布一頁紙的「可用 AI 工具清單」。只要十分鐘：列出團隊允許使用的 AI 工具，其他任何工具安裝前都要經過 IT 快速確認。有了清單，「我就臨時用一下」的安裝大多會消失。
3. 對「貼上這條命令」劃紅線。沒有任何正規安裝程式會讓你往 PowerShell 或執行對話方塊裡貼命令。用五分鐘的晨會把這一條規則教給每個員工——再配上防釣魚的 MFA（比如驗證器 App 或安全密鑰），這樣光偷走工作階段還不夠。

AI 工具對小企業是真的有用。仿冒品之所以得手，恰恰因為正品太受歡迎。今天花十分鐘定個規矩，好過下個月打電話請人做應急響應。

Canlus 為卡加利小企業提供免費安全風險評估：我們會梳理你團隊實際在用的軟體，給你一份按優先級排好的加固清單。

あなたの会社の従業員は、誰かが審査できるよりも速いペースでAIツールをダウンロードしている。その習慣が今、攻撃経路になった。

10月14日、ANY.RUNは1,258件の確認済みサンドボックス分析（2026年4月〜10月に収集）を、チームが毎日使うAIブランドを偽装したキャンペーンと結びつける調査結果を発表した：Claude、ChatGPT、GitHub Copilot、Gemini、Perplexityなどだ。ClaudeとChatGPTの偽装だけで81%を占める。ペイロードはインフォスティーラーとリモートアクセス型トロイの木馬。狙いはブラウザのセッションとビジネスアカウントだ。

これは2019年のフィッシングメールではない。誘い文句はスポンサー検索結果に隠れている——Googleの上部に表示される「公式サイト」は有料広告かもしれない——そしてGitHub Pages、Cloudflare Pages、Google Sitesといった信頼できるプラットフォームにホストされた偽ダウンロードページにもあり、Webフィルターをすり抜ける。45%のケースでは、被害者はWindowsの「ファイル名を指定して実行」ダイアログ、PowerShell、ターミナルにコマンドを貼り付けるよう誘導される。Enterを押した瞬間、攻撃者がセッションを乗っ取る。開発者とマーケティングチームが最大の標的で、米国の企業が2番目に被害が多い国だ。

カルガリーの中小企業が気にかけるべき理由

おそらくあなたの会社にはソフトウェア承認プロセスがない——20人規模の会社のほとんどがそうだ。つまりチームの誰でも「Claude ダウンロード」と検索し、最初の結果をクリックして、昼食前にトロイの木馬入りのコピーをインストールできてしまう。貼り付けた1つのコマンドが、あなたがお金を払ったすべてのパスワードとMFAを回避する。セッションの窃取にはあなたの認証情報は不要だからだ。キャンペーンは5月にピークを迎えたが止まってはいない。6月から9月まで、毎月108〜151件の確認済みケースが続いている。

今週やるべき3つのこと

1. ベンダーの本物のドメインからのみダウンロードする——手入力で。anthropic.com、openai.comなどの公式サイトをブックマークする。検索結果、特にスポンサー結果からは絶対にインストールしない。URLが少しでも怪しければ止める。
2. 1ページの「承認済みAIツールリスト」を公開する。10分でできる。チームが使ってよいAIツールを明記し、それ以外のインストールにはITの簡単な確認を必須にする。リストがあるだけで「ちょっと1回だけ使いたかった」インストールはほとんど消える。
3. 「このコマンドを貼り付けて」には固い一線を引く。正規のインストーラーがPowerShellや「ファイル名を指定して実行」ダイアログへのコマンド貼り付けを求めることはない。5分の朝会でこの1つのルールを全従業員に教える——そしてフィッシング耐性のあるMFA（認証アプリやセキュリティキーなど）を併用し、セッションを盗まれただけでは不十分にする。

AIツールは中小企業にとって本当に役立つ。偽物が通用するのは、まさに本物が人気だからだ。今日の10分のルール作りが、来月のインシデント対応の電話に勝る。

Canlusはカルガリーの中小企業向けに無料のセキュリティリスクアセスメントを提供している。チームが実際に使っているソフトウェアを洗い出し、優先順位付きの強化リストをお渡しする。

직원들은 누구도 검토할 수 없을 만큼 빠른 속도로 AI 도구를 다운로드하고 있다. 그 습관이 이제 공격 경로가 되었다.

10월 14일, ANY.RUN은 1,258건의 확인된 샌드박스 분석(2026년 4월~10월 수집)을 팀이 매일 사용하는 AI 브랜드를 사칭한 캠페인과 연결한 연구 결과를 발표했다: Claude, ChatGPT, GitHub Copilot, Gemini, Perplexity 등이다. Claude와 ChatGPT 사칭만으로 81%를 차지한다. 페이로드는 인포스틸러와 원격 액세스 트로이목마. 노리는 것은 브라우저 세션과 기업 계정이다.

이건 2019년의 피싱 이메일이 아니다. 미끼는 스폰서 검색 결과에 숨어 있다——Google 상단의 '공식 사이트'는 유료 광고일 수 있다——그리고 GitHub Pages, Cloudflare Pages, Google Sites 같은 신뢰할 수 있는 플랫폼에 호스팅된 가짜 다운로드 페이지에도 있어 웹 필터를 가볍게 통과한다. 45%의 사례에서 피해자는 Windows 실행 대화상자, PowerShell, 터미널에 명령을 붙여넣도록 유도된다. Enter를 누르는 순간 공격자가 세션을 장악한다. 개발자와 마케팅 팀이 최대 표적이고, 미국 기업이 두 번째로 피해가 많은 국가다.

캘거리 중소기업이 신경 써야 하는 이유

아마 당신의 회사에는 소프트웨어 승인 절차가 없을 것이다——20명 규모 회사의 대부분이 그렇다. 즉 팀의 누구든 "Claude 다운로드"를 검색해 첫 번째 결과를 클릭하고 점심 전에 트로이목마가 심긴 복사본을 설치할 수 있다. 붙여넣은 하나의 명령이 당신이 돈 주고 산 모든 비밀번호와 MFA를 우회한다. 세션 탈취에는 당신의 자격 증명이 필요 없기 때문이다. 캠페인은 5월에 정점을 찍었지만 멈추지 않았다. 6월부터 9월까지 매달 108~151건의 확인된 사례가 이어졌다.

이번 주에 할 3가지

1. 벤더의 진짜 도메인에서만 다운로드하라——직접 입력해서. anthropic.com, openai.com 등 공식 사이트를 북마크하라. 검색 결과, 특히 스폰서 결과에서는 절대 설치하지 마라. URL이 조금이라도 이상하면 멈춰라.
2. 한 페이지짜리 "승인된 AI 도구 목록"을 공개하라. 10분이면 된다. 팀이 사용해도 되는 AI 도구를 명시하고, 그 외의 설치에는 IT의 간단한 확인을 필수로 하라. 목록 하나면 "한 번만 쓰려던" 설치가 대부분 사라진다.
3. "이 명령을 붙여넣으세요"에는 단호히 선을 그어라. 정상적인 설치 프로그램이 PowerShell이나 실행 대화상자에 명령 붙여넣기를 요구하는 일은 없다. 5분 조회 시간에 이 한 가지 규칙을 모든 직원에게 가르쳐라——그리고 피싱 방지 MFA(인증 앱이나 보안 키 등)를 함께 써서 세션만 훔쳤서는 부족하게 하라.

AI 도구는 중소기업에 정말 유용하다. 가짜가 통하는 이유는 바로 진짜가 인기 있기 때문이다. 오늘 10분의 규칙 만들기가 다음 달 침해 대응 전화보다 낫다.

Canlus는 캘거리 중소기업을 위한 무료 보안 위험 평가를 제공한다. 팀이 실제로 사용하는 소프트웨어를 파악하고 우선순위가 정리된 강화 목록을 건낄다.

Imagine a burglar breaking into your building with a key that was cut fifteen months ago — after you already changed the lock. That's not a metaphor. It's what happened this month to a water utility, a telecom provider, a regional government body, and a university, according to threat researchers at Symantec.

The ransomware operation Warlock (also Storm-2603) didn't need a new zero-day. It walked in through Microsoft SharePoint's ToolShell vulnerability chain — first patched in July 2025. The fix has been sitting on a shelf for fifteen months, and attackers are still using the same door.

Here is the part that should bother you most: "install the patch" was never the whole job. When ToolShell was exploited in 2025, attackers could steal the server's cryptographic machine keys — and those stolen keys keep working even after the server is patched, unless an administrator also rotates the keys and restarts the web services. Patching closed the door. Nobody changed the locks. That is why Warlock keeps returning to organizations that thought they handled this last summer.

If you run SharePoint on your own servers — 2016, 2019, or the Subscription Edition — this is your problem. (SharePoint Online, the cloud version, was never exposed to this chain.) The telltale sign of incomplete remediation: an organization that patched once in July 2025 but missed the follow-up emergency patches of July 19 and 22, after attackers found a way around the first fixes. That one-patch-and-done mindset is exactly what Warlock is counting on.

This is not exotic, nation-state-only territory. The backdrop is the busiest ransomware quarter ever recorded: Comparitech counted 2,627 claimed ransomware attacks worldwide in Q3 2026, and fewer than one in ten victims publicly admit it happened. Warlock's crew even deployed an "EDR-killing" tool across dozens of machines before encrypting — the very software meant to stop them, neutralized first.

Three things to do this week

1. Don't ask "did we patch SharePoint." Ask "did we finish the job." Confirm all four ToolShell patches are installed (July 8 pair and the July 19/22 emergency pair), then rotate the ASP.NET machine keys on every SharePoint server and restart IIS. Key rotation has been mandatory in Microsoft's guidance since 2025 — it is the step most teams skipped.
2. Hunt for squatters. A patch doesn't evict an intruder who already dropped a webshell. Have your IT provider review SharePoint and web-server logs: odd child processes from the SharePoint app pool (w3wp.exe), unexpected outbound connections, unauthorized remote-access tools.
3. Shrink the target. Organizations fully on SharePoint Online sidestepped this entire chain. If your server only exists because "we've always had it," price out what fifteen months of exposure has actually cost.

The cheapest ransomware defense is still a door that is actually locked — not one you locked last year and forgot. Canlus offers a free security risk assessment for Calgary small businesses: we'll check what's actually exposed and hand you a prioritized fix list.

想象一下：你明明已经换了锁，却有个贼拿着十五个月前配的钥匙大摇大摆进了你的楼。这不是比喻。根据 Symantec 威胁研究人员的报告，这个月，一家自来水公司、一家电信运营商、一家地方政府机构和一所大学，就是这么被攻破的。

Warlock 勒索团伙（也叫 Storm-2603）根本不需要新的 0day。它走的是微软 SharePoint 的 ToolShell 漏洞链——2025 年 7 月就已经有补丁了。修复方案在架子上躺了十五个月，攻击者还在走同一扇门。

最该让你警觉的是：「装上补丁」从来就不是全部工作。2025 年 ToolShell 被利用时，攻击者能偷走服务器的加密机器密钥——而这些被盗的密钥在服务器打完补丁后照样有效，除非管理员同时轮换密钥并重启 Web 服务。补丁关上了门，但没人换锁。这就是为什么 Warlock 能一再回到那些以为「去年夏天就搞定了」的机构。

如果你自己架设 SharePoint 服务器——2016、2019 或订阅版——这就是你的问题。（云端的 SharePoint Online 从不受这条漏洞链影响。）没做利索的典型信号：2025 年 7 月只打了一次补丁，却错过了 7 月 19 日和 22 日的紧急补丁——那是攻击者绕过第一版修复之后微软追加的。「打一次补丁就完事」的心态，正是 Warlock 指望的。

这不是什么国家级黑客的专属领地。背景是史上最猖獗的一个勒索季度：Comparitech 统计 2026 年第三季度全球有 2,627 起被认领的勒索攻击，而公开承认中招的受害者不到十分之一。Warlock 团伙甚至在加密之前，先往几十台机器上部署了「杀 EDR」工具——本该拦住他们的软件，先被干掉了。

本周要做的三件事

1. 别问「SharePoint 打补丁了吗」，要问「这事做完了吗」。确认四个 ToolShell 补丁全装了（7 月 8 日那一对和 7 月 19/22 日的紧急补丁），然后在每台 SharePoint 服务器上轮换 ASP.NET 机器密钥并重启 IIS。微软从 2025 年起就把密钥轮换列为强制步骤——这恰恰是大多数团队跳过的一步。
2. 搜捕赖着不走的入侵者。补丁赶不走已经埋下 webshell 的入侵者。让你的 IT 服务商查 SharePoint 和 Web 服务器日志：SharePoint 应用池（w3wp.exe）下奇怪的子进程、意外的对外连接、没授权的远程管理工具。
3. 缩小目标。全面使用 SharePoint Online 的机构完全避开了这条漏洞链。如果你的服务器纯粹是因为「一直都有」才留着，不妨算算十五个月的暴露到底值多少钱。

最便宜的勒索防御，依然是一扇真正锁上的门——而不是去年锁上就忘到脑后的那扇。Canlus 为卡尔加里小企业提供免费安全风险评估：我们帮你查清到底暴露了什么，给你一份排好优先级的修复清单。

想像一下：你明明已經換了鎖，卻有個賊拿著十五個月前配的鑰匙大搖大擺進了你的樓。這不是比喻。根據 Symantec 威脅研究人員的報告，這個月，一家自來水公司、一家電信營運商、一家地方政府機構和一所大學，就是這麼被攻破的。

Warlock 勒索團夥（也叫 Storm-2603）根本不需要新的 0day。它走的是微軟 SharePoint 的 ToolShell 漏洞鏈——2025 年 7 月就已經有補丁了。修復方案在架子上躺了十五個月，攻擊者還在走同一扇門。

最該讓你警覺的是：「裝上補丁」從來就不是全部工作。2025 年 ToolShell 被利用時，攻擊者能偷走伺服器的加密機器金鑰——而這些被盜的金鑰在伺服器打完補丁後照樣有效，除非管理員同時輪換金鑰並重啟 Web 服務。補丁關上了門，但沒人換鎖。這就是為什麼 Warlock 能一再回到那些以為「去年夏天就搞定了」的機構。

如果你自己架設 SharePoint 伺服器——2016、2019 或訂閱版——這就是你的問題。（雲端的 SharePoint Online 從不受這條漏洞鏈影響。）沒做利索的典型信號：2025 年 7 月只打了一次補丁，卻錯過了 7 月 19 日和 22 日的緊急補丁——那是攻擊者繞過第一版修復之後微軟追加的。「打一次補丁就完事」的心態，正是 Warlock 指望的。

這不是什麼國家級駭客的專屬領地。背景是史上最猖獗的一個勒索季度：Comparitech 統計 2026 年第三季度全球有 2,627 起被認領的勒索攻擊，而公開承認中招的受害者不到十分之一。Warlock 團夥甚至在加密之前，先往幾十台機器上部署了「殺 EDR」工具——本該攔住他們的軟體，先被幹掉了。

本週要做的三件事

1. 別問「SharePoint 打補丁了嗎」，要問「這事做完了嗎」。確認四個 ToolShell 補丁全裝了（7 月 8 日那一對和 7 月 19/22 日的緊急補丁），然後在每台 SharePoint 伺服器上輪換 ASP.NET 機器金鑰並重啟 IIS。微軟從 2025 年起就把金鑰輪換列為強制步驟——這恰恰是大多數團隊跳過的一步。
2. 搜捕賴著不走的入侵者。補丁趕不走已經埋下 webshell 的入侵者。讓你的 IT 服務商查 SharePoint 和 Web 伺服器日誌：SharePoint 應用池（w3wp.exe）下奇怪的子處理程序、意外的對外連線、沒授權的遠端管理工具。
3. 縮小目標。全面使用 SharePoint Online 的機構完全避開了這條漏洞鏈。如果你的伺服器純粹是因為「一直都有」才留著，不妨算算十五個月的暴露到底值多少錢。

最便宜的勒索防禦，依然是一扇真正鎖上的門——而不是去年鎖上就忘到腦後的那扇。Canlus 為卡爾加里小企業提供免費安全風險評估：我們幫你查清到底暴露了什麼，給你一份排好優先順序的修復清單。

鍵を替えたはずなのに、15か月前に作られた合鍵で泥棒が堂々とビルに入ってくる——そんな場面を想像してほしい。比喩ではない。Symantecの脅威研究者によれば、今月、水道事業者、通信事業者、地方行政機関、大学がまさにその手口で破られた。

ランサムウェア集団Warlock（Storm-2603とも呼ばれる）は、新しいゼロデイなど必要としなかった。使ったのはMicrosoft SharePointのToolShell脆弱性チェーン——2025年7月にすでにパッチが出ている。修正は15か月も棚に置かれたままで、攻撃者は今も同じドアを使い続けている。

一番気にしてほしいのはここだ。「パッチを当てる」が仕事の全部だったことは一度もない。2025年にToolShellが悪用された際、攻撃者はサーバーの暗号マシンキーを盗むことができた。そして盗まれたキーは、サーバーにパッチを当てた後も有効であり続ける。管理者がキーをローテーションし、Webサービスを再起動しない限り、だ。パッチはドアを閉めた。だが誰も鍵を替えなかった。Warlockが「去年の夏に対処済み」と思っていた組織に戻ってこられるのは、そのためだ。

自社でSharePointサーバーを運用しているなら——2016、2019、Subscription Edition——これはあなたの問題だ。（クラウド版のSharePoint Onlineは、このチェーンの影響を一度も受けていない。）中途半端な対処の典型的な兆候。2025年7月に一度だけパッチを当て、7月19日と22日の緊急パッチを逃している——攻撃者が最初の修正を回避した後にMicrosoftが追加したものだ。「一度当てれば終わり」という考え方こそ、Warlockが当てにしているものだ。

これは国家レベルの攻撃者だけの特別な話ではない。背景にあるのは、観測史上最も忙しいランサムウェア四半期だ。Comparitechの集計では、2026年第3四半期の世界全体で2,627件の身代金要求型攻撃が確認され、被害を公表したのは1割にも満たない。Warlockの一味は暗号化の前に、数十台のマシンに「EDRキラー」ツールを展開していた。本来なら彼らを止めるはずのソフトを、先に無力化したのだ。

今週やるべき3つのこと

1. 「SharePointにパッチを当てたか」ではなく「仕事をやり切ったか」と問う。4つのToolShellパッチがすべて入っているか確認し（7月8日のペアと7月19日・22日の緊急パッチ）、全SharePointサーバーのASP.NETマシンキーをローテーションしてIISを再起動する。キーのローテーションは2025年からMicrosoftのガイダンスで必須とされている——ほとんどのチームが飛ばした手順だ。
2. 居座る侵入者を狩る。パッチでは、すでに webshell を仕掛けた侵入者は排除できない。ITベンダーにSharePointとWebサーバーのログを見直させよう。SharePointアプリケーションプール（w3wp.exe）の不審な子プロセス、想定外の外部接続、無許可のリモート管理ツールだ。
3. 標的を小さくする。SharePoint Onlineに完全移行している組織は、このチェーン全体を回避した。サーバーが「昔からあるから」という理由だけで残っているなら、15か月の露出が実際にいくらかかったのか計算してみよう。

最も安いランサムウェア対策は、実際に鍵のかかったドアであり続けること——去年鍵をかけて忘れたドアではない。Canlusはカルガリーの中小企業向けに無料のセキュリティリスクアセスメントを提供している。実際に何が露出しているか洗い出し、優先順位付きの修正リストをお渡しする。

자물쇠를 분명히 바꿨는데, 15개월 전에 만든 열쇠로 도둑이 당당히 건물에 들어오는 모습을 상상해 보자. 비유가 아니다. Symantec 위협 연구자들에 따르면 이번 달 수도 사업자, 통신 사업자, 지방 행정 기관, 대학이 바로 그 수법으로 뚫렸다.

랜섬웨어 조직 Warlock(Storm-2603이라고도 불린다)은 새로운 제로데이가 필요 없었다. 이용한 것은 Microsoft SharePoint의 ToolShell 취약점 체인——2025년 7월에 이미 패치가 나와 있다. 수정안은 15개월째 선반에 놓여 있고, 공격자는 지금도 같은 문을 쓰고 있다.

가장 신경 써야 할 부분은 여기다. '패치를 설치한다'가 일의 전부였던 적은 한 번도 없다. 2025년 ToolShell이 악용될 당시 공격자는 서버의 암호 머신 키를 훔칠 수 있었고, 훔친 키는 서버에 패치를 한 뒤에도 계속 유효하다. 관리자가 키를 교체하고 웹 서비스를 재시작하지 않는 한 말이다. 패치는 문을 닫았다. 하지만 아무도 자물쇠를 바꾸지 않았다. Warlock이 '작년 여름에 처리했다'고 생각한 조직에 계속 돌아올 수 있는 이유다.

자체 SharePoint 서버를 운영 중이라면——2016, 2019, Subscription Edition——이건 당신의 문제다. (클라우드 버전인 SharePoint Online은 이 체인의 영향을 받은 적이 없다.) 어설픈 대응의 전형적인 징후. 2025년 7월에 한 번만 패치하고 7월 19일과 22일의 긴급 패치를 놓친 경우——공격자가 첫 수정을 우회한 뒤 Microsoft가 추가한 것이다. '한 번 패치하면 끝'이라는 생각이 바로 Warlock이 노리는 것이다.

이건 국가급 공격자만의 특별한 이야기가 아니다. 배경에는 관측 사상 가장 바쁜 랜섬웨어 분기가 있다. Comparitech 집계에 따르면 2026년 3분기 전 세계에서 2,627건의 랜섬웨어 공격이 확인됐고, 피해를 공개한 곳은 10곳 중 1곳도 안 된다. Warlock 일당은 암호화 전에 수십 대의 머신에 'EDR 킬러' 도구를 심었다. 본래라면 그들을 막았어야 할 소프트웨어를 먼저 무력화한 것이다.

이번 주에 할 3가지

1. 'SharePoint에 패치했나'가 아니라 '일을 끝까지 했나'라고 물어라. 4개의 ToolShell 패치가 모두 설치됐는지 확인하고(7월 8일 쌍과 7월 19일·22일 긴급 패치), 모든 SharePoint 서버의 ASP.NET 머신 키를 교체한 뒤 IIS를 재시작한다. 키 교체는 2025년부터 Microsoft 지침상 필수다——대부분의 팀이 건너뛴 절차다.
2. 눌러앉은 침입자를 사냥하라. 패치로는 이미 webshell을 심은 침입자를 몰아낼 수 없다. IT 업체에 SharePoint와 웹 서버 로그를 다시 보게 하자. SharePoint 애플리케이션 풀(w3wp.exe)의 수상한 자식 프로세스, 예상 밖의 외부 연결, 허가받지 않은 원격 관리 도구다.
3. 표적을 줄여라. SharePoint Online으로 완전히 옮긴 조직은 이 체인 전체를 피했다. 서버가 '예전부터 있어서'라는 이유로만 남아 있다면, 15개월의 노출이 실제로 얼마였는지 계산해 보자.

가장 저렴한 랜섬웨어 방어는 여전히 실제로 잠긴 문이다——작년에 잠그고 잊은 문이 아니라. Canlus는 캘거리 중소기업을 위한 무료 보안 위험 평가를 제공한다. 실제로 무엇이 노출됐는지 짚어내고 우선순위가 정리된 수정 목록을 건넨다.

Every workday, your remote employees open the same front door: the company VPN. They type a username, a password, maybe approve a notification on their phone, and they're in.

Now imagine someone walking through that same door with a forged hall pass — no username, no password, nothing to click. The door inspects the pass, decides it looks fine, and waves them through. As far as your network is concerned, the intruder is just another employee working from home.

That is not a hypothetical. It is CVE-2026-0257, a flaw in Palo Alto Networks' GlobalProtect — one of the most widely deployed corporate VPNs in the world. Palo Alto disclosed it in May 2026, and on October 11 threat researchers at ReliaQuest confirmed ransomware groups are actively exploiting it right now.

Here is how it works, minus the jargon. To spare trusted users from logging in repeatedly, the VPN hands out a small digital token — think of it as a hall pass. The bug: the system decrypts the pass but never checks whether it is genuine. Anyone who can see your company's public website certificate can forge a pass for any user — including the administrator. No password needed. No phishing email. No employee mistake.

The groups doing this are not amateurs. Arctic Wolf's investigation found the Qilin ransomware operation breaking in through this flaw and, once inside, stealing every password in the building (the full Active Directory database), mapping the network for the fastest route to the crown jewels, copying data out to cloud storage, and only then running ransomware. A second crew, Settra, goes further: it installs a tampered driver to blind security software at the deepest level of Windows, then plants remote-management tools so it can return even after being kicked out.

"But we don't use Palo Alto."

Maybe not directly. But three things still apply to you:

First, your IT provider might. Ask them — today — whether any VPN equipment they manage for you runs the affected software, and whether it is patched. And note the part vendors bury in the fine print: patching alone does not evict intruders who are already inside. After patching, every VPN session must be terminated and every user forced to log in again. Make sure that step actually happens.

Second, the pattern is bigger than one vendor. Industry data puts remote-access services behind roughly 87% of ransomware insurance claims in 2025, with VPNs accounting for about 73% of cases where the entry point could be identified. If your people connect from home to office files, your VPN is your front door — whatever brand is on it.

Third, a successful VPN login is no longer proof of a legitimate user. Review your VPN logs going back to May: look for logins from places your employees never travel to, administrator logins from cloud hosting providers, and odd device names (investigators have seen "kali"). Anything you can't explain deserves a closer look.

Three things to do this week

1. Call your IT provider. "Are we on a patched VPN? After patching, did you kill all active sessions and force everyone to re-login?" If they hesitate, that is your answer.
2. Put a second lock on the door. Multi-factor authentication on every VPN login. Restrict which internet addresses can even reach your VPN portal. Consider device certificates — a forged hall pass can't fake those.
3. Check who's been coming in. Pull VPN login records since May and look for the anomalies above. Five minutes of log review beats five months of incident response.

The cheapest ransomware defense is still a locked, monitored front door. Canlus offers a free security risk assessment for Calgary small businesses: we'll check what's exposed and hand you a prioritized fix list, no obligation.

每个工作日，你的远程员工都会打开同一扇前门：公司 VPN。输入用户名、密码，也许再在手机上点一下确认，就进去了。

现在想象一下，有人拿着一张伪造的通行证从同一扇门大摇大摆走进去——没有用户名，没有密码，什么都不用点。门检查了一下通行证，觉得看起来没问题，就挥手放行了。在你的网络看来，这个入侵者不过是又一个在家办公的员工。

这不是假设。它就是 CVE-2026-0257，Palo Alto Networks GlobalProtect 的一个漏洞——GlobalProtect 是全球部署最广的企业 VPN 之一。Palo Alto 在 2026 年 5 月披露了它，10 月 11 日，ReliaQuest 的威胁研究人员确认，勒索团伙正在积极利用它。

说人话解释一下原理。为了让可信用户不用反复登录，VPN 会发一个小小的数字令牌——可以把它想象成一张通行证。漏洞在于：系统会解密这张通行证，却从不验证它是真是假。任何能看到你公司官网公开证书的人，都能给任意用户伪造一张通行证——包括管理员。不需要密码，不需要钓鱼邮件，员工也不需要犯任何错。

干这事的不是业余选手。Arctic Wolf 的调查发现，Qilin 勒索团伙正是从这个漏洞打进来，得手后偷走了全公司的所有密码（整个 Active Directory 数据库），绘制网络地图寻找最快通往核心资产的路径，把数据拷贝到云存储，最后才运行勒索软件。另一个团伙 Settra 更进一步：它安装被篡改过的驱动，在 Windows 最底层让安全软件失明，再植入远程管理工具，这样即使被踢出去也能回来。

「可是我们不用 Palo Alto。」

也许你们不直接用。但下面三件事依然和你有关：

第一，你的 IT 服务商可能在用。今天就问他们：替你们管的 VPN 设备里有没有跑受影响软件的，打补丁了吗？再注意厂商藏在小字里的那句：只打补丁，赶不走已经在里面的入侵者。打完补丁必须终止所有 VPN 会话、强制每个人重新登录。确认这一步真的做了。

第二，这个规律比一家厂商大得多。行业数据表明，2025 年约 87% 的勒索保险理赔都和远程接入服务有关；在能确定入口的案例里，VPN 占了约 73%。如果你的员工要从家里连回公司文件，那 VPN 就是你的前门——不管门上贴的是哪个牌子。

第三，一次成功的 VPN 登录早已不再是合法用户的证明。把 5 月以来的 VPN 日志翻出来看：找找有没有来自员工从没去过的地方的登录、有没有来自云服务商的管理员登录、有没有奇怪的设备名（调查人员见过叫「kali」的）。解释不清的，都值得深挖。

本周要做的三件事

1. 给你的 IT 服务商打电话。「我们的 VPN 打补丁了吗？打完补丁有没有杀掉所有在线会话、强制所有人重新登录？」如果对方支支吾吾，你就知道答案了。
2. 给门再加一道锁。所有 VPN 登录都开多因素认证。限制哪些互联网地址能连到你的 VPN 门户。考虑设备证书——伪造的通行证可伪造不了这个。
3. 查查都有谁进来过。把 5 月以来的 VPN 登录记录拉出来，对照上面的异常逐一排查。花 5 分钟看日志，胜过花 5 个月做应急响应。

最便宜的勒索防御，依然是一扇真正锁好、有人盯着的前门。Canlus 为卡尔加里小企业提供免费安全风险评估：我们帮你查清暴露面，给你一份排好优先级的修复清单，不附带任何义务。

每個工作日，你的遠端員工都會打開同一扇前門：公司 VPN。輸入使用者名稱、密碼，也許再在手機上點一下確認，就進去了。

現在想像一下，有人拿著一張偽造的通行證從同一扇門大搖大擺走進去——沒有使用者名稱，沒有密碼，什麼都不用點。門檢查了一下通行證，覺得看起來沒問題，就揮手放行了。在你的網路看來，這個入侵者不過是又一個在家辦公的員工。

這不是假設。它就是 CVE-2026-0257，Palo Alto Networks GlobalProtect 的一個漏洞——GlobalProtect 是全球部署最廣的企業 VPN 之一。Palo Alto 在 2026 年 5 月披露了它，10 月 11 日，ReliaQuest 的威脅研究人員確認，勒索團夥正在積極利用它。

說人話解釋一下原理。為了讓可信使用者不用反覆登入，VPN 會發一個小小的數位權杖——可以把它想像成一張通行證。漏洞在於：系統會解密這張通行證，卻從不驗證它是真是假。任何能看到你公司官網公開憑證的人，都能給任意使用者偽造一張通行證——包括管理員。不需要密碼，不需要釣魚郵件，員工也不需要犯任何錯。

幹這事的不是業餘選手。Arctic Wolf 的調查發現，Qilin 勒索團夥正是從這個漏洞打進來，得手後偷走了全公司的所有密碼（整個 Active Directory 資料庫），繪製網路地圖尋找最快通往核心資產的路徑，把資料拷貝到雲端儲存，最後才執行勒索軟體。另一個團夥 Settra 更進一步：它安裝被竄改過的驅動程式，在 Windows 最底層讓安全軟體失明，再植入遠端管理工具，這樣即使被踢出去也能回來。

「可是我們不用 Palo Alto。」

也許你們不直接用。但下面三件事依然和你有關：

第一，你的 IT 服務商可能在用。今天就問他們：替你們管的 VPN 設備裡有沒有跑受影響軟體的，打補丁了嗎？再注意廠商藏在小字裡的那句：只打補丁，趕不走已經在裡面的入侵者。打完補丁必須終止所有 VPN 工作階段、強制每個人重新登入。確認這一步真的做了。

第二，這個規律比一家廠商大得多。行業數據表明，2025 年約 87% 的勒索保險理賠都和遠端存取服務有關；在能確定入口的案例裡，VPN 佔了約 73%。如果你的員工要從家裡連回公司檔案，那 VPN 就是你的前門——不管門上貼的是哪個牌子。

第三，一次成功的 VPN 登入早已不再是合法使用者的證明。把 5 月以來的 VPN 日誌翻出來看：找找有沒有來自員工從沒去過的地方的登入、有沒有來自雲端服務商的管理員登入、有沒有奇怪的裝置名稱（調查人員見過叫「kali」的）。解釋不清的，都值得深挖。

本週要做的三件事

1. 給你的 IT 服務商打電話。「我們的 VPN 打補丁了嗎？打完補丁有沒有殺掉所有線上工作階段、強制所有人重新登入？」如果對方支支吾吾，你就知道答案了。
2. 給門再加一道鎖。所有 VPN 登入都開多因素認證。限制哪些網際網路位址能連到你的 VPN 入口。考慮裝置憑證——偽造的通行證可偽造不了這個。
3. 查查都有誰進來過。把 5 月以來的 VPN 登入紀錄拉出來，對照上面的異常逐一排查。花 5 分鐘看日誌，勝過花 5 個月做應急回應。

最便宜的勒索防禦，依然是一扇真正鎖好、有人盯著的前門。Canlus 為卡爾加里小企業提供免費安全風險評估：我們幫你查清暴露面，給你一份排好優先順序的修復清單，不附帶任何義務。

毎営業日、リモート勤務の社員は同じ玄関を開ける。会社のVPNだ。ユーザー名とパスワードを入力し、スマホの通知を承認すれば、中に入れる。

さて想像してほしい。誰かが偽造の通行証を持って、同じドアから堂々と入ってくるところを——ユーザー名なし、パスワードなし、クリックすら不要。ドアは通行証を検査し、問題なさそうだと判断して、そのまま通してしまう。ネットワークから見れば、侵入者は在宅勤務中の社員と区別がつかない。

これは仮定の話ではない。CVE-2026-0257、Palo Alto NetworksのGlobalProtectの欠陥だ。GlobalProtectは世界で最も広く導入されている企業向けVPNの一つである。Palo Altoは2026年5月にこれを開示し、10月11日、ReliaQuestの脅威研究者がランサムウェア集団が現在まさにこれを悪用中であることを確認した。

仕組みを専門用語なしで説明しよう。信頼できるユーザーに何度もログインさせないため、VPNは小さなデジタルトークンを配る——通行証のようなものだ。欠陥はここにある。システムは通行証を復号するが、それが本物かどうかの検証をしない。会社の公開Webサイト証明書を見られる者なら誰でも、任意のユーザー——管理者を含む——の通行証を偽造できる。パスワード不要。フィッシングメール不要。社員のミスも不要。

やっているのは素人ではない。Arctic Wolfの調査によれば、Qilinランサムウェア集団はこの欠陥から侵入し、社内の全パスワード（Active Directoryデータベース全体）を盗み、重要資産への最短ルートを探すためにネットワークをマッピングし、データをクラウドストレージに持ち出してから、最後にランサムウェアを実行した。もう一つの集団Settraはさらに一歩進んでいる。改ざんしたドライバを仕込んでWindowsの最深部でセキュリティソフトの目を潰し、リモート管理ツールを植え付ける。追い出されても戻ってこられるようにするためだ。

「うちはPalo Altoを使っていない」

直接は使っていないかもしれない。だが次の3点はあなたにも当てはまる。

第一に、あなたのITベンダーが使っているかもしれない。今日聞こう——あなたのために管理しているVPN機器に、影響を受けるソフトウェアが動いているものはあるか、パッチは当たっているか。そしてベンダーが小さな字で書いている一文に注意してほしい。パッチを当てるだけでは、すでに入り込んでいる侵入者は排除できない。パッチ適用後は全VPNセッションを終了させ、全ユーザーに再ログインを強制しなければならない。その手順が実際に行われたか確認すること。

第二に、この構図は一社だけの話より大きい。業界データによれば、2025年のランサムウェア保険請求の約87%にリモートアクセスサービスが絡み、侵入口が特定できたケースの約73%でVPNが占めた。社員が自宅から社内ファイルに接続するなら、VPNは会社の玄関だ——ドアにどのメーカーの看板が付いていようと。

第三に、VPNログインの成功は、もはや正規ユーザーの証明ではない。5月以降のVPNログを見直そう。社員が行ったことのない場所からのログイン、クラウド事業者からの管理者ログイン、見慣れないデバイス名（調査では「kali」という名前が見つかっている）を探す。説明のつかないものは、掘り下げる価値がある。

今週やるべき3つのこと

1. ITベンダーに電話する。「うちのVPNにパッチは当たっているか。パッチ後に全セッションを切断し、全員に再ログインさせたか。」相手が口ごもったら、それが答えだ。
2. ドアにもう一つの鍵を付ける。すべてのVPNログインに多要素認証を。VPNポータルに到達できるインターネットアドレスを制限する。デバイス証明書も検討しよう——偽造の通行証ではごまかせない。
3. 誰が出入りしていたか確認する。5月以降のVPNログイン記録を取り出し、上記の異常に照らして調べる。ログ5分の確認は、5か月のインシデント対応に勝る。

最も安いランサムウェア対策は、きちんと鍵がかかり、監視されている玄関であり続ける。Canlusはカルガリーの中小企業向けに無料のセキュリティリスクアセスメントを提供している。露出面を洗い出し、優先順位付きの修正リストをお渡しする。条件はない。

매 영업일마다 원격 근무 직원들은 같은 현관을 연다. 회사 VPN이다. 사용자 이름과 비밀번호를 입력하고, 휴대폰 알림을 승인하면 들어간다.

이제 상상해 보자. 누군가 위조된 출입증을 들고 같은 문으로 당당히 들어오는 모습을——사용자 이름도, 비밀번호도, 클릭조차 필요 없다. 문은 출입증을 검사하고 문제없어 보인다고 판단해 그냥 통과시킨다. 네트워크 입장에서 침입자는 재택근무 중인 직원과 구분되지 않는다.

가정이 아니다. CVE-2026-0257, Palo Alto Networks GlobalProtect의 결함이다. GlobalProtect는 세계에서 가장 널리 도입된 기업용 VPN 중 하나다. Palo Alto는 2026년 5월에 이를 공개했고, 10월 11일 ReliaQuest의 위협 연구자들이 랜섬웨어 조직이 바로 지금 이를 악용 중임을 확인했다.

전문 용어 없이 원리를 설명하겠다. 신뢰할 수 있는 사용자가 반복 로그인하지 않도록 VPN은 작은 디지털 토큰을 발급한다——출입증이라 생각하면 된다. 결함은 여기 있다. 시스템은 출입증을 복호화하지만 진짜인지 검증하지 않는다. 회사 공개 웹사이트 인증서를 볼 수 있는 사람이라면 누구든 임의의 사용자——관리자 포함——의 출입증을 위조할 수 있다. 비밀번호 불필요. 피싱 메일 불필요. 직원 실수도 불필요.

이 일을 하는 자들은 아마추어가 아니다. Arctic Wolf 조사에 따르면 Qilin 랜섬웨어 조직은 이 결함으로 침투해, 사내 모든 비밀번호(Active Directory 데이터베이스 전체)를 훔치고, 핵심 자산으로 가는 최단 경로를 찾기 위해 네트워크를 매핑한 뒤, 데이터를 클라우드 스토리지로 빼내고, 마지막에 랜섬웨어를 실행했다. 또 다른 조직 Settra는 한 걸음 더 나아간다. 변조된 드라이버를 심어 Windows 최하층에서 보안 소프트웨어의 눈을 멀게 하고, 원격 관리 도구를 심는다. 쫓겨나도 돌아올 수 있도록 하기 위해서다.

'우리는 Palo Alto를 쓰지 않는데.'

직접 쓰지 않을 수도 있다. 하지만 다음 세 가지는 당신에게도 해당된다.

첫째, 당신의 IT 업체가 쓰고 있을 수 있다. 오늘 물어보자——당신을 위해 관리하는 VPN 장비 중에 영향받는 소프트웨어가 돌아가는 것이 있는지, 패치가 됐는지. 그리고 업체가 작은 글씨로 적어둔 한 문장에 주목하라. 패치만으로는 이미 들어와 있는 침입자를 몰아낼 수 없다. 패치 후에는 모든 VPN 세션을 종료시키고 전원에게 재로그인을 강제해야 한다. 그 절차가 실제로 이뤄졌는지 확인하라.

둘째, 이 구도는 한 회사만의 이야기가 아니다. 업계 데이터에 따르면 2025년 랜섬웨어 보험 청구의 약 87%에 원격 액세스 서비스가 관련됐고, 침입 경로가 확인된 사례의 약 73%를 VPN이 차지했다. 직원이 집에서 회사 파일에 접속한다면 VPN은 회사의 현관이다——문에 어떤 제조사 간판이 붙어 있든.

셋째, VPN 로그인 성공은 더 이상 정상 사용자의 증명이 아니다. 5월 이후의 VPN 로그를 들여다보자. 직원이 가본 적 없는 곳에서의 로그인, 클라우드 사업자로부터의 관리자 로그인, 낯선 장치 이름(조사에서는 'kali'라는 이름이 발견됐다)을 찾는다. 설명할 수 없는 것은 파헤칠 가치가 있다.

이번 주에 할 3가지

1. IT 업체에 전화하라. '우리 VPN에 패치가 됐나. 패치 후에 모든 세션을 끊고 전원에게 재로그인을 시켰나.' 상대가 말끝을 흐리면, 그게 답이다.
2. 문에 자물쇠를 하나 더 달아라. 모든 VPN 로그인에 다중 인증을. VPN 포털에 닿을 수 있는 인터넷 주소를 제한한다. 장치 인증서도 검토하자——위조된 출입증으로는 속일 수 없다.
3. 누가 드나들었는지 확인하라. 5월 이후의 VPN 로그인 기록을 뽑아 위의 이상 징후와 대조해 조사한다. 로그 5분 확인이 5개월 인시던트 대응을 이긴다.

가장 저렴한 랜섬웨어 방어는 여전히 제대로 잠그고 지켜보는 현관이다. Canlus는 캘거리 중소기업을 위한 무료 보안 위험 평가를 제공한다. 노출면을 점검하고 우선순위가 정리된 수정 목록을 건넨다. 조건은 없다.

If someone offered to fix your computer remotely, you'd expect them to ask permission first. The tool they use to do it — AnyDesk — had a flaw that let attackers skip the asking entirely. And the company fixed it months ago without telling anyone.

On October 8, security researchers published AnyPwn, a full working exploit for a pre-authentication remote code execution vulnerability in AnyDesk for Linux. Pre-authentication means the attacker needs no username, no password, and — critically for a remote-desktop tool — no click on "Accept" from anyone sitting at the machine. The flaw is a heap buffer overflow in AnyDesk's session protocol: a crafted packet makes the application allocate a far-too-small buffer, corrupt adjacent memory, and run the attacker's commands with root privileges. It works over direct TCP connections on port 7070 and targets AnyDesk Linux build 8.0.2.

Here's the part that should anger you. Researcher Rick de Jager of the V12 security team disclosed the flaw to AnyDesk on June 22. AnyDesk shipped a fix in version 8.0.3 the very next day. But it assigned no CVE, published no security advisory, and described the change in its changelog only as a bug "that could lead to a crash." If you weren't updating AnyDesk for unrelated reasons, you have been sitting on a pre-authentication root RCE for three and a half months — with no way to know. AnyDesk has since pulled the vulnerable 8.0.2 build from its download page. Windows and macOS versions are not affected; the current release is 8.1.0. (One caveat from the researchers: the published exploit is probabilistic and tuned to the 8.0.2 build; they also note the vulnerable code path is reachable via AnyDesk's relay servers, though they haven't demonstrated a full exploit there.)

What this means for your business

AnyDesk is the standard tool IT support technicians — including outsourced providers — use to remote into small-business machines. If any Linux machine in your environment runs the vulnerable build with direct connections exposed (port 7070 facing the internet), an attacker doesn't need to phish anyone. They just connect.

Three things to do this week

1. Check the version — on every Linux machine. Open AnyDesk, or ask your IT provider: are we on 8.0.3 or later? Anything older must be updated to the current 8.1.0 release. This is a five-minute check with a "patch today" answer.
2. Don't expose port 7070 to the internet. AnyDesk direct connections should never face the public internet — use the relay infrastructure or, better, put remote access behind a VPN. The flaw is exploitable over direct TCP on 7070, so closing that door matters whether or not you've patched.
3. Turn on automatic updates for remote-access tools. The real lesson of AnyPwn isn't the bug — it's the silence. Vendors sometimes fix critical flaws without telling you. If your remote-access software doesn't update itself, you're betting the vendor will always announce the bad news. They won't.

Software you trust with the keys to your machines deserves the strictest update discipline. Canlus offers a free security risk assessment for Calgary small businesses: we'll inventory what's exposed and hand you a prioritized fix list, no obligation.

如果有人要远程帮你修电脑，你肯定希望他先征得你的同意。AnyDesk 就是干这个的工具——而它曾经有个漏洞，能让攻击者直接跳过"征得同意"这一步。更离谱的是，厂商几个月前就修好了，却没告诉任何人。

10 月 8 日，安全研究人员公开了 AnyPwn——针对 Linux 版 AnyDesk 预认证远程代码执行漏洞的完整可用 exploit。"预认证"意味着攻击者不需要用户名、不需要密码——对于远程桌面工具来说最关键的是——不需要坐在电脑前的人点一下"接受"。漏洞出在 AnyDesk 会话协议的堆缓冲区溢出：精心构造的数据包让程序分配了过小的缓冲区，破坏相邻内存，从而以 root 权限执行攻击者的命令。它通过 7070 端口的直接 TCP 连接利用，目标是 Linux 版 8.0.2。

真正让人恼火的是这部分。V12 安全团队的研究员 Rick de Jager 在 6 月 22 日向 AnyDesk 披露了这个漏洞，AnyDesk 第二天就在 8.0.3 版本中修复了。但它没有分配 CVE 编号，没有发布安全公告，在更新日志里只写"修复了一个可能导致崩溃的 bug"。如果你不是因为别的原因去更新 AnyDesk，你已经在毫不知情的情况下，带着一个预认证 root RCE 过了三个半月。AnyDesk 后来已把有漏洞的 8.0.2 从下载页下架。Windows 和 macOS 版本不受影响，当前版本是 8.1.0。（研究人员的一个提醒：公开的 exploit 是概率性的、针对 8.0.2 特定版本调优的；他们还指出，通过 AnyDesk 的中继服务器也能到达这段有漏洞的代码，只是还没演示出完整利用。）

这对你的公司意味着什么

AnyDesk 是 IT 技术支持人员（包括外包服务商）远程接入小企业电脑的标准工具。如果你的环境里有 Linux 机器运行着有漏洞的版本，且直接连接暴露在外（7070 端口对着公网），攻击者根本不需要钓鱼，直接连进来就行。

本周要做的三件事

1. 查版本——每一台 Linux 机器都要查。打开 AnyDesk，或者问你的 IT 服务商：我们是不是 8.0.3 或更新版本？更老的必须升到最新的 8.1.0。这是个五分钟的检查，结论就是"今天打补丁"。
2. 别把 7070 端口暴露到公网。AnyDesk 的直接连接永远不该对着公网——走中继，或者更好，把远程访问放到 VPN 后面。这个漏洞就是通过 7070 的直接 TCP 连接利用的，所以不管打没打补丁，关上这扇门都很重要。
3. 给远程访问工具打开自动更新。AnyPwn 真正的教训不是这个 bug，而是沉默。厂商有时修了严重漏洞也不告诉你。如果你的远程访问软件不会自己更新，你就是在赌厂商每次都会主动通报坏消息。他们不会。

拿着你所有机器钥匙的软件，配得上最严格的更新纪律。Canlus 为卡尔加里小企业提供免费安全风险评估：我们帮你盘点暴露面，给你一份按优先级排序的修复清单，无任何附加条件。

如果有人要遠端幫你修電腦，你肯定希望他先徵得你的同意。AnyDesk 就是幹這個的工具——而它曾經有個漏洞，能讓攻擊者直接跳過"徵得同意"這一步。更離譜的是，廠商幾個月前就修好了，卻沒告訴任何人。

10 月 8 日，安全研究人員公開了 AnyPwn——針對 Linux 版 AnyDesk 預認證遠端程式碼執行漏洞的完整可用 exploit。"預認證"意味著攻擊者不需要使用者名稱、不需要密碼——對於遠端桌面工具來說最關鍵的是——不需要坐在電腦前的人點一下"接受"。漏洞出在 AnyDesk 工作階段協定的堆積緩衝區溢位：精心構造的資料封包讓程式分配了過小的緩衝區，破壞相鄰記憶體，從而以 root 權限執行攻擊者的命令。它透過 7070 連接埠的直接 TCP 連線利用，目標是 Linux 版 8.0.2。

真正讓人惱火的是這部分。V12 安全團隊的研究員 Rick de Jager 在 6 月 22 日向 AnyDesk 揭露了這個漏洞，AnyDesk 第二天就在 8.0.3 版本中修復了。但它沒有分配 CVE 編號，沒有發布安全公告，在更新日誌裡只寫"修復了一個可能導致崩潰的 bug"。如果你不是因為別的原因去更新 AnyDesk，你已經在毫不知情的情況下，帶著一個預認證 root RCE 過了三個半月。AnyDesk 後來已把有漏洞的 8.0.2 從下載頁下架。Windows 和 macOS 版本不受影響，當前版本是 8.1.0。（研究人員的一個提醒：公開的 exploit 是機率性的、針對 8.0.2 特定版本調校的；他們還指出，透過 AnyDesk 的中繼伺服器也能到達這段有漏洞的程式碼，只是還沒演示出完整利用。）

這對你的公司意味著什麼

AnyDesk 是 IT 技術支援人員（包括外包服務商）遠端接入小企業電腦的標準工具。如果你的環境裡有 Linux 機器執行著有漏洞的版本，且直接連線暴露在外（7070 連接埠對著公網），攻擊者根本不需要釣魚，直接連進來就行。

本週要做的三件事

1. 查版本——每一台 Linux 機器都要查。打開 AnyDesk，或者問你的 IT 服務商：我們是不是 8.0.3 或更新版本？更老的必須升到最新的 8.1.0。這是個五分鐘的檢查，結論就是"今天打補丁"。
2. 別把 7070 連接埠暴露到公網。AnyDesk 的直接連線永遠不該對著公網——走中繼，或者更好，把遠端存取放到 VPN 後面。這個漏洞就是透過 7070 的直接 TCP 連線利用的，所以不管打沒打補丁，關上這扇門都很重要。
3. 給遠端存取工具打開自動更新。AnyPwn 真正的教訓不是這個 bug，而是沉默。廠商有時修了嚴重漏洞也不告訴你。如果你的遠端存取軟體不會自己更新，你就是在賭廠商每次都會主動通報壞消息。他們不會。

拿著你所有機器鑰匙的軟體，配得上最嚴格的更新紀律。Canlus 為卡加利小企業提供免費安全風險評估：我們幫你盤點暴露面，給你一份按優先順序排序的修復清單，無任何附加條件。

リモートでパソコンを修理してもらうなら、まず許可を求めてほしいと思うはずだ。そのためのツールがAnyDesk——しかしこのツールには、攻撃者がその「許可」を丸ごとスキップできる欠陥があった。さらに驚くべきことに、メーカーは数か月前に修正済みだったのに、誰にも知らせていなかった。

10月8日、セキュリティ研究者がAnyPwnを公開した。Linux版AnyDeskの認証前リモートコード実行の脆弱性に対する、完全に動作するエクスプロイトだ。「認証前」とは、攻撃者にユーザー名もパスワードも不要で、リモートデスクトップツールにとって決定的なのは、目の前の利用者が「承諾」をクリックする必要すらない、ということだ。欠陥はAnyDeskのセッションプロトコルにおけるヒープバッファオーバーフローで、細工されたパケットが小さすぎるバッファを確保させ、隣接メモリを破壊して、攻撃者のコマンドをroot権限で実行させる。ポート7070への直接TCP接続で悪用され、対象はLinux版8.0.2だ。

本当に腹が立つのはここからだ。V12セキュリティチームの研究者Rick de Jagerは6月22日にこの欠陥をAnyDeskに報告し、AnyDeskは翌日にバージョン8.0.3で修正した。しかしCVE番号は付与されず、セキュリティアドバイザリも出されず、変更履歴には「クラッシュにつながる可能性のあるバグを修正」とだけ書かれた。別の理由でAnyDeskを更新していなければ、知らないうちに3か月半もの間、認証前root RCEを抱えたままだったことになる。AnyDeskはその後、脆弱な8.0.2をダウンロードページから取り下げた。Windows版とmacOS版に影響はなく、現行は8.1.0だ。（研究者からの注意点：公開されたエクスプロイトは確率的で8.0.2の特定ビルド向けに調整されている。また、AnyDeskの中継サーバー経由でも脆弱なコードに到達可能としているが、完全な悪用の実証はまだない。）

あなたの会社にとっての意味

AnyDeskは、ITサポート技術者（外部委託先を含む）が中小企業のパソコンにリモート接続する際の標準ツールだ。環境内のLinuxマシンが脆弱なバージョンのままで、直接接続が外部に晒されている（ポート7070がインターネットに面している）場合、攻撃者にフィッシングは不要だ。ただ接続するだけでいい。

今週やるべき3つのこと

1. バージョンを確認——すべてのLinuxマシンで。AnyDeskを開くか、IT担当者に聞く：8.0.3以降か？古いものは最新の8.1.0へ更新する。5分の確認で、答えは「今日パッチを当てる」だ。
2. ポート7070をインターネットに晒さない。AnyDeskの直接接続を公共インターネットに向けてはならない——中継を使うか、より良いのはVPNの背後に置くことだ。この欠陥は7070への直接TCPで悪用されるため、パッチの有無にかかわらずこの扉を閉めることが重要だ。
3. リモートアクセスツールの自動更新をオンに。AnyPwnの本当の教訓はバグではなく「沈黙」だ。メーカーは重大な欠陥を修正しても知らせないことがある。リモートアクセスソフトが自動更新されなければ、メーカーが毎回ちゃんと知らせてくれることに賭けているのと同じだ。彼らは知らせない。

あなたのマシンの鍵を預けるソフトには、最も厳格な更新の規律が必要だ。Canlusはカルガリーの中小企業向けに無料のセキュリティリスク評価を提供している。露出面を棚卸しし、優先順位付きの修正リストを渡す。条件は一切ない。

원격으로 컴퓨터를 고쳐준다면, 먼저 허락을 구할 것이라 기대할 것이다. 그 일을 하는 도구가 AnyDesk인데——이 도구에는 공격자가 그 '허락 구하기'를 통째로 건너뛸 수 있는 결함이 있었다. 더 기가 막힌 것은, 제조사가 몇 달 전에 이미 고쳐놓고도 아무에게도 알리지 않았다는 점이다.

10월 8일, 보안 연구자들이 AnyPwn을 공개했다. Linux용 AnyDesk의 인증 전 원격 코드 실행 취약점에 대한 완전히 동작하는 익스플로잇이다. '인증 전'이란 공격자에게 사용자 이름도, 비밀번호도 필요 없고——원격 데스크톱 도구에서 결정적인 것은——앞에 앉은 사람이 '수락'을 클릭할 필요조차 없다는 뜻이다. 결함은 AnyDesk 세션 프로토콜의 힙 버퍼 오버플로우로, 정교하게 조작된 패킷이 너무 작은 버퍼를 할당하게 만들어 인접 메모리를 손상시키고, 공격자의 명령을 root 권한으로 실행시킨다. 포트 7070으로의 직접 TCP 연결을 통해 악용되며, 대상은 Linux용 8.0.2 빌드다.

정말 화가 나는 부분은 지금부터다. V12 보안팀의 연구자 Rick de Jager는 6월 22일에 이 결함을 AnyDesk에 제보했고, AnyDesk는 바로 다음 날 버전 8.0.3에서 수정했다. 하지만 CVE 번호는 부여하지 않았고, 보안 권고도 발표하지 않았으며, 변경 로그에는 '충돌을 일으킬 수 있는 버그를 수정'이라고만 적었다. 다른 이유로 AnyDesk를 업데이트하지 않았다면, 모르는 사이에 석 달 반 동안 인증 전 root RCE를 안고 있었던 셈이다. AnyDesk는 이후 취약한 8.0.2를 다운로드 페이지에서 내렸다. Windows와 macOS 버전은 영향이 없으며, 현재 릴리스는 8.1.0이다. (연구자들의 주의점: 공개된 익스플로잇은 확률적이며 8.0.2 특정 빌드에 맞춰 조정됐다. 또한 AnyDesk의 릴레이 서버를 경유해도 취약한 코드에 도달할 수 있다고 하지만, 완전한 악용 실증은 아직 없다.)

우리 회사에 주는 의미

AnyDesk는 IT 지원 기술자(외주 업체 포함)가 중소기업 PC에 원격 접속할 때 쓰는 표준 도구다. 환경 내 Linux 머신이 취약한 버전을 실행 중이고 직접 연결이 외부에 노출돼 있다면(포트 7070이 인터넷을 향하고 있다면), 공격자에게 피싱은 필요 없다. 그냥 연결하면 된다.

이번 주에 할 3가지

1. 버전 확인——모든 Linux 머신에서. AnyDesk를 열거나 IT 담당자에게 묻자: 8.0.3 이상인가? 그보다 오래된 것은 최신 8.1.0으로 업데이트한다. 5분이면 끝나는 확인이고, 답은 '오늘 패치한다'다.
2. 포트 7070을 인터넷에 노출하지 마라. AnyDesk 직접 연결을 공용 인터넷에 노출해서는 안 된다——릴레이를 쓰거나, 더 좋은 것은 VPN 뒤에 두는 것이다. 이 결함은 7070으로의 직접 TCP를 통해 악용되므로, 패치 여부와 관계없이 이 문을 닫는 것이 중요하다.
3. 원격 액세스 도구의 자동 업데이트를 켜라. AnyPwn의 진짜 교훈은 버그가 아니라 '침묵'이다. 제조사는 심각한 결함을 고치고도 알려주지 않을 때가 있다. 원격 액세스 소프트웨어가 스스로 업데이트되지 않는다면, 제조사가 매번 나쁜 소식을 꼬박꼬박 알려주리라 도박하는 셈이다. 그들은 알려주지 않는다.

당신 머신의 열쇠를 맡기는 소프트웨어에는 가장 엄격한 업데이트 규율이 필요하다. Canlus는 캘거리 중소기업을 위한 무료 보안 위험 평가를 제공한다. 노출면을 점검하고 우선순위가 정리된 수정 목록을 건넨다. 조건은 없다.

Most small and mid-sized businesses do not ignore cybersecurity. The more common problem is that day-to-day growth changes the environment faster than controls are updated. New cloud tools appear, employees change roles, contractors come and go, and a network that once served ten people now supports fifty. The result is rarely one dramatic failure. It is a handful of ordinary gaps that quietly increase exposure.

For Calgary businesses, the right response is not to copy an enterprise security program. It is to identify the few controls that reduce the most practical risk, assign clear ownership and verify that they work. These five blind spots are a useful place to begin.

1. Password reuse across business systems

When an employee reuses the same password for email, accounting, a vendor portal and a personal service, one unrelated breach can become a business incident. A strong-looking password does not solve the problem if it is used in several places. Shared team passwords create an additional issue: nobody can reliably tell who used the account, and access is difficult to remove when responsibilities change.

Action: Provide a business password manager, require a unique password for every account and replace shared credentials with named user access wherever the system allows it. Start with email, finance, remote access and administrator accounts. These systems have the highest potential impact and give the team a manageable first phase.

2. MFA is available but not enforced

Many cloud services offer multi-factor authentication, but “available” is not the same as “required.” Optional enrollment usually leaves a group of users unprotected. SMS verification is better than a password alone, but an authenticator app, passkey or hardware security key offers stronger protection. Administrator accounts deserve the strictest method because they can change security settings for everyone else.

Action: Review actual MFA registration and sign-in policies, not just the licence features. Enforce MFA for all users, block legacy authentication where possible and use phishing-resistant methods for privileged roles. Keep a controlled emergency-access account and test its monitoring and recovery procedure.

3. Backups exist, but restoration has never been tested

A dashboard showing “backup successful” proves that a job ran; it does not prove that the right data can be restored within the time the business needs. Backups can be incomplete, dependent on the same compromised administrator account or stored in a location that ransomware can also reach. Cloud platforms may protect service availability while leaving file deletion, retention and application-level recovery to the customer.

Action: Choose one critical workload and perform a documented restore test this month. Record what was restored, how long it took, who approved the result and what failed. Then schedule tests for the remaining priority systems. Keep at least one protected copy separated from normal production access.

4. Former-employee and contractor accounts remain active

Offboarding often focuses on returning a laptop and forwarding email. Access to SaaS applications, VPNs, file shares, shared mailboxes and vendor portals can remain active because no single person owns the full list. Dormant accounts are easy to overlook and may retain permissions that are no longer visible in normal operations.

Action: Use one offboarding checklist triggered by the confirmed departure time. Disable the primary identity first, revoke active sessions, remove group and application access, rotate any shared secrets and transfer business data through an approved process. Review inactive accounts quarterly to catch what the workflow missed.

5. Business, guest and device traffic share one Wi-Fi network

A single flat network is convenient, but it allows an unmanaged visitor device, smart television, camera or printer to sit close to employee computers and business systems. If one device is compromised, broad internal access can make the next step easier. Network segmentation does not need to be complicated to be useful.

Action: Create separate networks for managed business devices, guests and internet-connected equipment. Use different credentials, prevent guest traffic from reaching internal resources and restrict device networks to only the services they need. Document who manages the firewall and wireless equipment so future changes do not undo the separation.

Turn five fixes into a repeatable operating habit

These controls are not one-time purchases. Assign an owner, a review frequency and a simple piece of evidence for each one: an MFA coverage report, a restore-test record, an offboarding ticket or a network diagram. That makes security visible without creating unnecessary bureaucracy.

A short assessment can help separate urgent gaps from acceptable risk. Canlus offers a free initial consultation to review your current environment and identify a practical first step. The goal is not to sell a large program—it is to make the next decision clear.

多数中小企业并非不重视网络安全，真正的问题往往是：业务变化比安全控制更新得更快。团队扩大、云服务增加、员工转岗、外包人员进出，原本适合十个人的环境逐渐支撑五十个人，却没有同步调整权限、备份和网络设计。风险通常不是来自某个“惊天漏洞”，而是几个看似普通的缺口叠加在一起。

对 Calgary 的中小企业来说，正确做法不是照搬大型企业的复杂体系，而是先抓住最能降低实际风险的控制，明确负责人，并验证它们真的有效。以下五个盲区最值得优先检查。

一、密码重复使用

同一个密码同时用于邮箱、财务系统、供应商门户和个人网站时，任何一处泄露都可能演变成企业事件。密码再复杂，只要重复使用，风险仍然存在。多人共用同一个账号还会导致操作无法追溯，人员变动时也难以及时撤销权限。

可执行建议：为员工提供企业密码管理器，要求每个系统使用独立密码，并尽量把共享账号改为实名账号。第一阶段先覆盖邮箱、财务、远程访问和管理员账号，因为这些系统的影响最大，也最适合快速落地。

二、MFA 有功能但没有强制

很多云服务支持多因素认证，但“可以开启”不等于“所有人必须使用”。依赖员工自愿注册，通常会留下未保护账户。短信验证比单一密码更好，但身份验证器、Passkey 或硬件安全密钥更可靠；管理员账号应采用更严格的方法，因为它们能够修改全公司的安全设置。

可执行建议：检查真实注册率和登录策略，而不是只看许可证功能。对所有用户强制 MFA，在条件允许时关闭旧式身份验证，并优先为高权限角色部署抗钓鱼认证。保留受控的紧急访问账号，同时测试监控和恢复流程。

三、备份存在，但从未测试恢复

控制台显示“备份成功”，只说明任务运行过，并不能证明关键数据能在业务要求的时间内恢复。备份可能不完整、依赖同一个已被入侵的管理员账号，或存放在勒索软件同样能够访问的位置。云平台保障服务可用性，不代表自动承担所有文件删除、保留和应用恢复责任。

可执行建议：本月选一个关键系统做一次正式恢复演练，记录恢复了什么、耗时多久、由谁验收、哪里失败。然后按优先级安排其他系统。至少保留一份与生产权限隔离、不能被日常账号直接修改的受保护副本。

四、离职员工和外包账号没有及时关闭

离职流程常常只关注收回电脑和转发邮箱，却遗漏 SaaS、VPN、共享文件、共享邮箱和供应商门户。没有人掌握完整权限清单时，休眠账号会长期保留，而且过去授予的权限很难在日常工作中被发现。

可执行建议：建立由确认离职时间触发的统一清单：先停用主身份，撤销所有活动会话，再移除群组和应用权限，轮换共享密钥，并通过批准流程移交业务数据。每季度检查不活跃账号，发现流程遗漏。

五、办公、访客和智能设备共用同一 Wi-Fi

单一网络管理方便，却让访客手机、摄像头、打印机或智能电视与员工电脑和业务系统处在相近的信任范围。一台设备被攻破后，扁平网络会让攻击者更容易横向移动。有效隔离不一定复杂。

可执行建议：至少划分办公设备、访客和物联网设备三个网络，使用不同凭据，禁止访客访问内部资源，并让设备网络只能连接必要服务。同时记录谁负责防火墙和无线设备，避免后续变更破坏隔离。

把五项修复变成持续习惯

这些控制不是一次性采购。为每项控制指定负责人、复查频率和简单证据，例如 MFA 覆盖报告、恢复演练记录、离职工单或网络图。这样既能持续改进，也不会制造不必要的流程负担。

如果不确定先做哪一项，Canlus 可通过免费初步咨询了解现状，帮助区分紧急缺口与可接受风险，并明确一个现实的第一步。重点不是把项目做大，而是先把下一项决策做对。

多數中小企業並非不重視網路安全，真正的問題往往是：業務變化比安全控制更新得更快。團隊擴大、雲服務增加、員工轉崗、外包人員進出，原本適合十個人的環境逐漸支撐五十個人，卻沒有同步調整許可權、備份和網路設計。風險通常不是來自某個“驚天漏洞”，而是幾個看似普通的缺口疊加在一起。

對 Calgary 的中小企業來說，正確做法不是照搬大型企業的複雜體系，而是先抓住最能降低實際風險的控制，明確負責人，並驗證它們真的有效。以下五個盲區最值得優先檢查。

一、密碼重複使用

同一個密碼同時用於郵箱、財務系統、供應商門戶和個人網站時，任何一處洩露都可能演變成企業事件。密碼再複雜，只要重複使用，風險仍然存在。多人共用同一個賬號還會導致操作無法追溯，人員變動時也難以及時撤銷許可權。

可執行建議：為員工提供企業密碼管理器，要求每個系統使用獨立密碼，並儘量把共享賬號改為實名賬號。第一階段先覆蓋郵箱、財務、遠端訪問和管理員賬號，因為這些系統的影響最大，也最適合快速落地。

二、MFA 有功能但沒有強制

很多雲服務支援多因素認證，但“可以開啟”不等於“所有人必須使用”。依賴員工自願註冊，通常會留下未保護賬戶。簡訊驗證比單一密碼更好，但身份驗證器、Passkey 或硬體安全金鑰更可靠；管理員賬號應採用更嚴格的方法，因為它們能夠修改全公司的安全設定。

可執行建議：檢查真實註冊率和登入策略，而不是隻看許可證功能。對所有使用者強制 MFA，在條件允許時關閉舊式身份驗證，並優先為高許可權角色部署抗釣魚認證。保留受控的緊急訪問賬號，同時測試監控和恢復流程。

三、備份存在，但從未測試恢復

控制檯顯示“備份成功”，只說明任務執行過，並不能證明關鍵資料能在業務要求的時間內恢復。備份可能不完整、依賴同一個已被入侵的管理員賬號，或存放在勒索軟體同樣能夠訪問的位置。雲平臺保障服務可用性，不代表自動承擔所有檔案刪除、保留和應用恢復責任。

可執行建議：本月選一個關鍵系統做一次正式恢復演練，記錄恢復了什麼、耗時多久、由誰驗收、哪裡失敗。然後按優先順序安排其他系統。至少保留一份與生產許可權隔離、不能被日常賬號直接修改的受保護副本。

四、離職員工和外包賬號沒有及時關閉

離職流程常常只關注收回電腦和轉發郵箱，卻遺漏 SaaS、VPN、共享檔案、共享郵箱和供應商門戶。沒有人掌握完整許可權清單時，休眠賬號會長期保留，而且過去授予的許可權很難在日常工作中被發現。

可執行建議：建立由確認離職時間觸發的統一清單：先停用主身份，撤銷所有活動會話，再移除群組和應用許可權，輪換共享金鑰，並透過批准流程移交業務資料。每季度檢查不活躍賬號，發現流程遺漏。

五、辦公、訪客和智慧裝置共用同一 Wi-Fi

單一網路管理方便，卻讓訪客手機、攝像頭、印表機或智慧電視與員工電腦和業務系統處在相近的信任範圍。一臺裝置被攻破後，扁平網路會讓攻擊者更容易橫向移動。有效隔離不一定複雜。

可執行建議：至少劃分辦公裝置、訪客和物聯網裝置三個網路，使用不同憑據，禁止訪客訪問內部資源，並讓裝置網路只能連線必要服務。同時記錄誰負責防火牆和無線裝置，避免後續變更破壞隔離。

把五項修復變成持續習慣

這些控制不是一次性採購。為每項控制指定負責人、複查頻率和簡單證據，例如 MFA 覆蓋報告、恢復演練記錄、離職工單或網路圖。這樣既能持續改進，也不會製造不必要的流程負擔。

如果不確定先做哪一項，Canlus 可透過免費初步諮詢瞭解現狀，幫助區分緊急缺口與可接受風險，並明確一個現實的第一步。重點不是把專案做大，而是先把下一項決策做對。

中小企業の事故は、必ずしも高度な攻撃から始まるわけではありません。多くは、日常業務に残った小さな隙間が重なって起きます。次の5項目は、カルガリーの成長企業がまず確認すべき現実的な出発点です。

1. パスワードの使い回し

一つのサービスから認証情報が漏れると、同じ組み合わせでメールやクラウドへ侵入される恐れがあります。会社管理のパスワードマネージャーを導入し、長く固有のパスワードを使い、共有アカウントを減らしてください。

2. MFAが任意のまま

登録を案内しただけでは、全員への強制にはなりません。管理者を最優先に全ユーザーへMFAを適用し、未登録者と例外を定期的に確認します。可能ならSMSより強い認証方法を選びます。

3. バックアップを復元したことがない

成功通知だけでは復旧できる証拠になりません。重要なシステムごとに、どの時点へ戻すか、誰が復元するか、どれだけ時間がかかるかを決め、実際にテストして記録します。

4. 退職者や委託先のアカウントが残る

主アカウントだけでなく、SaaS、VPN、共有フォルダ、共有メール、取引先ポータルも対象です。退職日時を起点とするチェックリストを作り、セッション失効、権限削除、共有秘密の変更、データ引き継ぎまで確認します。

5. 社内・来客・IoTが同じWi-Fi

来客端末、カメラ、プリンターを業務端末と同じ信頼領域に置くと、侵害後の横移動が容易になります。少なくとも社内、来客、IoTを分離し、来客から社内資源への接続を禁止します。

継続できる仕組みにする

各対策に責任者、確認頻度、簡単な証跡を設定してください。どこから始めるべきか迷う場合、Canlusは無料相談で緊急の不足と受容できるリスクを整理し、現実的な最初の一歩を明確にします。

중소기업의 보안 사고는 반드시 고도화된 공격에서 시작하지 않습니다. 일상 업무에 남은 작은 빈틈이 겹치며 발생하는 경우가 많습니다. 다음 다섯 가지는 캘거리의 성장 기업이 먼저 확인할 현실적인 출발점입니다.

1. 비밀번호 재사용

한 서비스에서 자격 증명이 유출되면 같은 조합으로 이메일과 클라우드에 침입할 수 있습니다. 회사가 관리하는 비밀번호 관리자를 쓰고, 길고 고유한 비밀번호를 만들며, 공유 계정을 줄이세요.

2. MFA가 선택 사항인 상태

등록 안내만으로는 강제 적용이 아닙니다. 관리자부터 모든 사용자에게 MFA를 적용하고 미등록자와 예외를 정기적으로 검토하세요. 가능하다면 SMS보다 강한 인증 수단을 선택합니다.

3. 복원해 본 적 없는 백업

성공 알림만으로는 복구 가능성이 입증되지 않습니다. 중요 시스템마다 복구 시점, 담당자, 예상 시간을 정하고 실제 복원 시험 결과를 기록하세요.

4. 퇴사자와 계약자 계정이 남아 있음

주 계정뿐 아니라 SaaS, VPN, 공유 폴더, 공유 메일함, 공급업체 포털까지 확인해야 합니다. 퇴사 시간을 기준으로 세션 취소, 권한 제거, 공유 비밀 변경, 업무 데이터 이전을 완료합니다.

5. 사내·방문자·IoT가 같은 Wi-Fi 사용

방문자 휴대폰, 카메라, 프린터가 업무용 기기와 같은 신뢰 영역에 있으면 침해 후 측면 이동이 쉬워집니다. 최소한 업무, 방문자, IoT 네트워크를 분리하고 방문자에게 내부 접근을 허용하지 마세요.

지속 가능한 습관으로 만들기

각 통제에 담당자, 점검 주기, 간단한 증빙을 지정하세요. 어디서 시작할지 모르면 Canlus가 무료 상담에서 시급한 격차와 수용 가능한 위험을 구분하고 현실적인 첫 단계를 정리해 드립니다.

Microsoft 365 gives a small business professional email, collaboration and identity services without building its own infrastructure. That convenience can create a dangerous assumption: if the service is reputable and the licence is active, the environment must already be secure. In practice, the platform provides many security capabilities, but the business still has to decide how identities, devices, sharing and data should be controlled.

The purpose of this checklist is not to turn an owner into a Microsoft 365 administrator. It is to help leadership ask for clear evidence. Each item should produce an answer that can be verified, not “we think it is enabled.”

1. Multi-factor authentication

• Is MFA enforced for every interactive user? Registration alone is not enforcement. Ask for a report showing who is covered and which sign-in policy requires it.
• Are stronger methods used for privileged accounts? Administrators should use passkeys, certificate-based authentication or hardware security keys where practical, rather than relying only on SMS.
• Is legacy authentication blocked? Older protocols may bypass modern controls and should be disabled unless there is a documented business exception.
• Is emergency access controlled? Maintain a small number of monitored break-glass accounts, protect their credentials and test the process without using them for daily administration.

Owner’s question: “Can you show me the users who could still sign in with only a password?”

2. Conditional Access

• Do policies reflect risk and context? A good baseline can require MFA, block legacy authentication, apply stronger controls to administrators and restrict access from unexpected locations or unmanaged devices.
• Are exclusions documented? Every excluded user or application should have an owner, a reason and a review date. Permanent, unexplained exceptions become invisible risk.
• Are changes tested before enforcement? Use report-only mode and staged groups to understand impact, then move to enforcement through a controlled change.
• Are sign-in and risk alerts reviewed? Policies are useful only if someone watches the outcomes and investigates repeated failures or unusual activity.

Owner’s question: “Which sign-ins would we block today, and who reviews the exceptions?”

3. External sharing

• Who can invite guests? Limit invitation rights to appropriate users or groups instead of allowing everyone to create external access.
• Are anonymous links necessary? “Anyone with the link” is convenient but difficult to control. Prefer named recipients, expiration dates and view-only access where possible.
• Are inactive guests removed? Schedule access reviews for guest accounts, Teams, Microsoft 365 groups and sensitive SharePoint sites.
• Are high-value sites treated differently? Finance, HR and leadership content should not inherit the same sharing posture as low-risk collaboration spaces.

Owner’s question: “Can we list every external party with access to our sensitive sites, and when that access was last reviewed?”

4. Data loss prevention and information protection

• Has the business identified its sensitive data? Start with information whose exposure would create legal, contractual or operational impact: financial records, employee data, customer information and intellectual property.
• Are labels and DLP policies focused? Broad rules that generate constant false positives are ignored. Begin with a few important data types and high-risk actions, then tune them.
• Do users receive useful guidance? A policy tip should explain what happened and how to complete legitimate work safely, not simply block people with no path forward.
• Are alerts owned? Assign someone to investigate repeated sharing, unusual download activity and policy overrides.

Owner’s question: “What sensitive information are we trying to protect, and what happens when someone attempts to send it outside the company?”

5. Administrator accounts

• Do administrators have separate daily and privileged accounts? Email and web browsing should not happen from the identity that can change tenant-wide settings.
• Is privilege limited by role? Avoid assigning Global Administrator when a narrower role is enough.
• Is privileged access time-bound? Where licensing and operations permit, activate roles only when needed and require approval or justification for sensitive roles.
• Are administrator actions logged and reviewed? Monitor new role assignments, authentication-method changes, mailbox forwarding and security-policy changes.

Owner’s question: “How many people can make tenant-wide changes right now, and why does each person need that access?”

How to use the checklist

Do not attempt every improvement at once. Ask for evidence, record the gap, assign risk and agree on the next action. A practical first phase often secures administrator accounts, enforces MFA, reduces risky sharing and confirms who receives security alerts. Conditional Access and data protection can then be expanded with careful testing.

Canlus offers a free initial consultation for businesses that want an independent view of their Microsoft 365 posture. We can help translate technical configuration into clear business priorities and a realistic remediation sequence—without turning the review into a fear-based sales exercise.

Microsoft 365 让中小企业无需自建基础设施，就能获得企业邮箱、协作和身份服务。但这种便利容易带来一个误区：平台知名、许可证正常，环境就应该已经安全。实际上，Microsoft 提供了大量安全能力，但身份、设备、共享和数据如何控制，仍然需要企业主动配置和持续管理。

这份清单不是要让老板变成管理员，而是帮助管理层要求团队提供可以验证的证据。每一项都应有明确答案，而不是“应该已经开了”。

一、MFA 多因素认证

• 是否对所有交互式用户强制执行？完成注册不等于强制启用，应查看覆盖用户和实际登录策略。
• 高权限账号是否使用更强方法？管理员应优先使用 Passkey、证书或硬件安全密钥，而不是只依赖短信。
• 是否关闭旧式身份验证？旧协议可能绕过现代控制，除非有书面业务例外，否则应停用。
• 紧急访问账号是否受控？保留少量受监控的“破窗”账号，妥善保护凭据并定期测试，不用于日常管理。

老板要问：“能否列出目前仍可能只用密码登录的用户？”

二、条件访问

• 策略是否考虑风险和场景？基线策略应要求 MFA、阻止旧式身份验证，对管理员采用更强控制，并限制异常位置或未管理设备。
• 例外是否有记录？每个排除用户或应用都应有负责人、原因和复查日期。永久且无法解释的例外会成为隐形风险。
• 执行前是否测试？先用“仅报告”模式和分阶段用户组评估影响，再通过受控变更正式启用。
• 是否有人处理登录与风险告警？如果没人查看结果和调查异常，策略就无法形成闭环。

老板要问：“今天哪些登录会被阻止？谁负责审查例外？”

三、外部共享

• 谁能邀请外部来宾？邀请权限应只开放给适当用户或群组，而不是默认所有人。
• 是否真的需要匿名链接？“任何拿到链接的人”难以控制，应优先使用指定收件人、到期时间和只读权限。
• 是否清理长期不用的来宾？对来宾账号、Teams、Microsoft 365 群组和敏感 SharePoint 站点定期做访问复查。
• 高价值站点是否采用更严格规则？财务、人事和管理层资料不应与普通协作空间使用同一共享标准。

老板要问：“能否列出所有能够访问敏感站点的外部人员，以及上次复查时间？”

四、DLP 与信息保护

• 企业是否明确什么是敏感数据？优先识别一旦泄露会造成法律、合同或运营影响的信息，例如财务、员工、客户资料和知识产权。
• 标签和 DLP 策略是否聚焦？大量误报会让团队忽视告警。先保护少数关键数据类型和高风险操作，再逐步调优。
• 用户能否获得有效指导？策略提示应说明发生了什么，并给出安全完成合法工作的方式，而不是只阻断。
• 告警是否有人负责？明确谁调查重复外发、异常下载和策略覆盖行为。

老板要问：“我们要保护哪些敏感信息？员工试图把它发到公司外部时会发生什么？”

五、管理员账号

• 管理员是否分开日常账号和特权账号？能够修改全局设置的账号不应同时用于邮箱和日常浏览。
• 是否按角色最小授权？较小角色能够完成工作时，不要授予全局管理员。
• 高权限是否按需启用？在许可证和流程允许时，只在需要时激活角色，并对敏感角色要求审批或理由。
• 管理员操作是否记录并复查？重点监控新增角色、认证方式变更、邮箱转发和安全策略修改。

老板要问：“现在有多少人能修改整个租户？每个人为什么需要这项权限？”

如何使用这份清单

不要一次完成所有改进。先要求证据、记录缺口、评估风险并确认下一步。务实的第一阶段通常是保护管理员账号、强制 MFA、减少高风险共享，并确认安全告警由谁接收；随后再通过测试逐步扩展条件访问和数据保护。

如果需要独立视角，Canlus 可通过免费初步咨询了解 Microsoft 365 现状，把技术配置翻译成清晰的业务优先级和可执行的修复顺序，不用恐惧式营销推动不必要的项目。

Microsoft 365 讓中小企業無需自建基礎設施，就能獲得企業郵箱、協作和身份服務。但這種便利容易帶來一個誤區：平臺知名、許可證正常，環境就應該已經安全。實際上，Microsoft 提供了大量安全能力，但身份、裝置、共享和資料如何控制，仍然需要企業主動配置和持續管理。

這份清單不是要讓老闆變成管理員，而是幫助管理層要求團隊提供可以驗證的證據。每一項都應有明確答案，而不是“應該已經開了”。

一、MFA 多因素認證

• 是否對所有互動式使用者強制執行？完成註冊不等於強制啟用，應檢視覆蓋使用者和實際登入策略。
• 高許可權賬號是否使用更強方法？管理員應優先使用 Passkey、證書或硬體安全金鑰，而不是隻依賴簡訊。
• 是否關閉舊式身份驗證？舊協議可能繞過現代控制，除非有書面業務例外，否則應停用。
• 緊急訪問賬號是否受控？保留少量受監控的“破窗”賬號，妥善保護憑據並定期測試，不用於日常管理。

老闆要問：“能否列出目前仍可能只用密碼登入的使用者？”

二、條件訪問

• 策略是否考慮風險和場景？基線策略應要求 MFA、阻止舊式身份驗證，對管理員採用更強控制，並限制異常位置或未管理裝置。
• 例外是否有記錄？每個排除使用者或應用都應有負責人、原因和複查日期。永久且無法解釋的例外會成為隱形風險。
• 執行前是否測試？先用“僅報告”模式和分階段使用者組評估影響，再透過受控變更正式啟用。
• 是否有人處理登入與風險告警？如果沒人檢視結果和調查異常，策略就無法形成閉環。

老闆要問：“今天哪些登入會被阻止？誰負責審查例外？”

三、外部共享

• 誰能邀請外部來賓？邀請許可權應只開放給適當使用者或群組，而不是預設所有人。
• 是否真的需要匿名連結？“任何拿到連結的人”難以控制，應優先使用指定收件人、到期時間和只讀許可權。
• 是否清理長期不用的來賓？對來賓賬號、Teams、Microsoft 365 群組和敏感 SharePoint 站點定期做訪問複查。
• 高價值站點是否採用更嚴格規則？財務、人事和管理層資料不應與普通協作空間使用同一共享標準。

老闆要問：“能否列出所有能夠訪問敏感站點的外部人員，以及上次複查時間？”

四、DLP 與資訊保護

• 企業是否明確什麼是敏感資料？優先識別一旦洩露會造成法律、合同或運營影響的資訊，例如財務、員工、客戶資料和智慧財產權。
• 標籤和 DLP 策略是否聚焦？大量誤報會讓團隊忽視告警。先保護少數關鍵資料型別和高風險操作，再逐步調優。
• 使用者能否獲得有效指導？策略提示應說明發生了什麼，並給出安全完成合法工作的方式，而不是隻阻斷。
• 告警是否有人負責？明確誰調查重複外發、異常下載和策略覆蓋行為。

老闆要問：“我們要保護哪些敏感資訊？員工試圖把它發到公司外部時會發生什麼？”

五、管理員賬號

• 管理員是否分開日常賬號和特權賬號？能夠修改全域性設定的賬號不應同時用於郵箱和日常瀏覽。
• 是否按角色最小授權？較小角色能夠完成工作時，不要授予全域性管理員。
• 高許可權是否按需啟用？在許可證和流程允許時，只在需要時啟用角色，並對敏感角色要求審批或理由。
• 管理員操作是否記錄並複查？重點監控新增角色、認證方式變更、郵箱轉發和安全策略修改。

老闆要問：“現在有多少人能修改整個租戶？每個人為什麼需要這項許可權？”

如何使用這份清單

不要一次完成所有改進。先要求證據、記錄缺口、評估風險並確認下一步。務實的第一階段通常是保護管理員賬號、強制 MFA、減少高風險共享，並確認安全告警由誰接收；隨後再透過測試逐步擴充套件條件訪問和資料保護。

如果需要獨立視角，Canlus 可透過免費初步諮詢瞭解 Microsoft 365 現狀，把技術配置翻譯成清晰的業務優先順序和可執行的修復順序，不用恐懼式營銷推動不必要的專案。

Microsoft 365には多くの保護機能がありますが、ライセンスが有効なだけで安全になるわけではありません。このチェックリストは、経営者が設定そのものではなく、確認できる証拠を求めるためのものです。

1. 多要素認証

• 全ユーザーにMFAが実際に強制されているか。
• 管理者はパスキーやセキュリティキーなど強い方式を使っているか。
• 旧式認証は例外を除き停止されているか。
• 緊急アクセス用アカウントは監視・試験されているか。

経営者の質問：「パスワードだけで入れる利用者を一覧にできますか？」

2. 条件付きアクセス

管理者、異常な場所、未管理端末など、リスクと状況に応じた制御が必要です。除外には責任者、理由、見直し日を設定し、本番適用前にレポート専用モードで影響を確認します。

3. 外部共有

招待できる人を制限し、匿名リンクより指定受信者、有効期限、閲覧のみを優先します。ゲスト、Teams、Microsoft 365グループ、機密性の高いSharePointサイトを定期的に見直します。

4. DLPと情報保護

財務、従業員、顧客、知的財産など重要な情報から始め、誤検知だらけの広い規則を避けます。正当な作業を安全に続ける方法まで利用者に示し、警告の担当者を決めます。

5. 管理者アカウント

日常用と特権用を分け、必要最小限の役割を期限付きで付与し、役割追加、認証方法変更、転送設定、ポリシー変更を監視します。

チェックリストの使い方

一度にすべてを直す必要はありません。証拠を確認し、不足を記録して責任者と次の行動を決めます。Canlusは無料相談で技術設定を事業上の優先順位と現実的な改善順序へ整理します。

Microsoft 365에는 많은 보안 기능이 있지만 라이선스만 활성화했다고 안전해지는 것은 아닙니다. 이 체크리스트는 경영진이 설정 이름보다 검증 가능한 증빙을 요구하도록 돕습니다.

1. 다단계 인증

• 모든 사용자에게 MFA가 실제로 강제되는가?
• 관리자는 패스키나 보안 키처럼 더 강한 수단을 쓰는가?
• 문서화된 예외를 제외하고 레거시 인증을 차단했는가?
• 비상 접근 계정을 감시하고 시험하는가?

경영진 질문: “비밀번호만으로 로그인할 수 있는 사용자를 보여줄 수 있나요?”

2. 조건부 액세스

관리자, 비정상 위치, 관리되지 않은 기기 등 위험과 상황에 맞는 정책이 필요합니다. 제외 항목에는 담당자, 이유, 검토일을 지정하고 시행 전 보고서 전용 모드로 영향을 확인하세요.

3. 외부 공유

초대 권한을 제한하고 익명 링크보다 지정된 수신자, 만료일, 읽기 전용을 우선하세요. 게스트, Teams, Microsoft 365 그룹, 민감한 SharePoint 사이트를 정기적으로 검토합니다.

4. DLP와 정보 보호

재무, 직원, 고객, 지식재산처럼 중요한 정보부터 시작하고 오탐이 많은 광범위한 규칙은 피하세요. 사용자가 정상 업무를 안전하게 계속할 방법을 안내하고 경고 담당자를 정합니다.

5. 관리자 계정

일상 계정과 특권 계정을 분리하고, 최소 역할을 필요한 시간에만 부여하며, 역할 추가, 인증 방법 변경, 메일 전달, 보안 정책 변경을 모니터링합니다.

체크리스트 활용법

모든 것을 한 번에 고치지 마세요. 증빙을 확인하고 격차, 위험, 담당자, 다음 행동을 기록합니다. Canlus는 무료 상담에서 기술 설정을 비즈니스 우선순위와 현실적인 개선 순서로 바꿔 드립니다.

“Vulnerability scan” and “penetration test” are often used as if they describe the same service. They do not. Both can identify security weaknesses, but they answer different questions, use different levels of human judgement and produce different evidence. Choosing the wrong one can either leave important risk unexplored or spend money on depth the business does not yet need.

What a vulnerability scan does

A vulnerability scan uses automated tools to inspect systems, applications or cloud assets for known weaknesses. It may identify missing patches, outdated software, insecure services, weak encryption, exposed ports and configuration patterns associated with published vulnerabilities. Authenticated scans can log into systems with controlled credentials and see more than an external scan.

Scanning is broad, repeatable and relatively efficient. That makes it well suited to routine hygiene: checking a changing environment, measuring whether patching is improving, supporting a vulnerability-management program and finding obvious exposure before a deeper test. Its limitation is context. A scanner can report that a condition exists, but it may not understand whether the finding is reachable, exploitable or meaningful to your specific business. False positives and duplicate findings require review.

What a penetration test does

A penetration test is a controlled, time-bounded assessment performed by a security professional under an agreed scope and rules of engagement. The tester combines tools with manual analysis to determine whether weaknesses can be used to achieve a realistic objective: access sensitive data, move from one system to another, bypass a control or obtain a higher level of privilege.

The purpose is not to “hack everything.” It is to safely demonstrate credible attack paths and explain their business impact. A penetration test can connect several moderate issues that would look unrelated in a scan. It also tests assumptions: whether segmentation works, whether permissions contain an account compromise and whether an application’s business logic can be abused. Because it requires human judgement, it is narrower, more expensive and less suitable as a constant monitoring tool.

When vulnerability scanning is the right choice

• You need recurring visibility across many systems.
• Your priority is patching, asset hygiene and reducing known weaknesses.
• You have not yet established a basic vulnerability-management process.
• You need a baseline before deciding where deeper testing will create value.
• Your environment changes frequently and you want a repeatable check after updates.

Scanning should not be a one-time report. A useful process assigns each finding an owner, validates severity in business context, tracks remediation and rescans to confirm closure.

When a penetration test is the right choice

• You are launching an important internet-facing application or service.
• A customer, insurer, contract or governance program requires independent testing.
• You handle sensitive data or operate a system whose compromise would materially affect the business.
• You need to validate network segmentation, privilege boundaries or the effectiveness of recent security improvements.
• You want evidence of what an attacker could actually accomplish, not only a list of known issues.

A penetration test is strongest when the scope is tied to a decision. “Test our external environment” is less useful than “determine whether an unauthenticated attacker can reach customer information through these applications and supporting services.”

A typical vulnerability scanning process

1. Define assets and ownership. Confirm IP ranges, applications, cloud resources and approved credentials.
2. Configure and run the scan. Schedule around business operations and avoid unsafe checks where needed.
3. Validate and prioritize. Remove false positives, combine duplicates and consider exposure, exploitability and business impact.
4. Remediate. Patch, reconfigure, isolate or accept the risk through an approved process.
5. Rescan and report. Verify closure and track recurring patterns.

A typical penetration testing process

1. Scope and rules of engagement. Define targets, objectives, exclusions, timing, contacts, data handling and stop conditions.
2. Reconnaissance and analysis. Map the attack surface and identify likely paths.
3. Controlled exploitation. Safely test whether weaknesses can be combined or used to reach the objective.
4. Evidence and cleanup. Record reproducible proof, remove test artefacts and notify the client immediately if a critical issue requires urgent action.
5. Report and debrief. Explain technical findings, business impact, attack paths and prioritized remediation.
6. Retest. Confirm that important fixes address the demonstrated path.

Many businesses need both—at different frequencies

For many small and mid-sized businesses, the practical model is recurring vulnerability scanning for broad visibility and a focused penetration test at key moments: before a major launch, after significant architectural change or on a risk-based schedule. Scanning finds known weaknesses at scale; penetration testing shows how selected weaknesses behave in the context of your environment.

If you are unsure which level of testing is justified, Canlus offers a free initial consultation. We can help define the business question, identify an appropriate scope and recommend scanning, penetration testing or a phased combination—without selling depth that will not change a decision.

“漏洞扫描”和“渗透测试”经常被当成同一种服务，其实两者回答的问题不同，依赖人工判断的程度不同，最终提供的证据也不同。选错方案，可能导致关键风险没有被验证，也可能在基础工作尚未完成时，为不必要的深度投入预算。

漏洞扫描做什么

漏洞扫描使用自动化工具检查系统、应用和云资产中的已知弱点，例如缺失补丁、过期软件、不安全服务、弱加密、暴露端口，以及与公开漏洞相关的配置。经过授权的认证扫描还可以使用受控账号登录系统，从内部看到比外部扫描更多的信息。

扫描覆盖广、可重复、效率较高，适合日常安全卫生：定期检查变化中的环境、衡量补丁工作是否改善、支撑漏洞管理，并在深入测试前发现明显暴露。它的局限是缺少业务上下文。工具能报告某个条件存在，却未必能判断它在本环境中是否可达、可利用或真正重要，因此需要人工排除误报、合并重复项并重新评估优先级。

渗透测试做什么

渗透测试是在约定范围和交战规则下，由安全专业人员进行的受控、限时评估。测试人员结合工具和手工分析，判断弱点能否被利用来实现现实目标，例如访问敏感数据、从一台系统移动到另一台、绕过控制或提升权限。

它的目的不是“把所有系统都黑一遍”，而是在安全前提下证明可信攻击路径，并解释业务影响。渗透测试可以把扫描中几个看似无关的中等问题连接成一条实际路径，也能验证网络隔离、权限边界和应用业务逻辑是否真正有效。由于高度依赖人工判断，它范围更聚焦、成本更高，也不适合作为持续监控手段。

什么时候选择漏洞扫描

• 需要对大量系统进行周期性可见性检查；
• 当前重点是补丁、资产卫生和减少已知漏洞；
• 尚未建立基本漏洞管理流程；
• 希望先做基线，再决定哪里值得深入测试；
• 环境经常变化，需要在更新后重复验证。

扫描不应止于一次报告。有效流程要为发现指定负责人，结合业务背景确认严重性，跟踪修复，并通过重新扫描验证关闭。

什么时候选择渗透测试

• 即将上线重要的互联网应用或服务；
• 客户、保险、合同或治理要求需要独立测试；
• 处理敏感数据，或关键系统一旦受损会显著影响业务；
• 需要验证网络隔离、权限边界或近期安全改进是否有效；
• 希望知道攻击者实际能做到什么，而不仅是一份已知问题清单。

渗透测试的范围最好与决策直接相关。“测试外部环境”过于宽泛；“判断未登录攻击者能否通过这些应用及其支撑服务访问客户数据”更容易形成有价值的结论。

漏洞扫描的大致流程

1. 确认资产与负责人：明确 IP 范围、应用、云资源和批准使用的凭据。
2. 配置并执行：避开关键业务时段，必要时关闭可能影响稳定性的检查。
3. 验证与排序：排除误报、合并重复项，并结合暴露程度、可利用性和业务影响调整优先级。
4. 修复：通过补丁、配置、隔离或正式风险接受处理问题。
5. 复扫与报告：确认问题关闭，并跟踪反复出现的模式。

渗透测试的大致流程

1. 范围与交战规则：明确目标、排除项、时间、联系人、数据处理和停止条件。
2. 侦察与分析：绘制攻击面并识别可能路径。
3. 受控利用：安全验证弱点是否能够组合并达成目标。
4. 证据与清理：记录可复现证据，移除测试痕迹；如果发现需要立即处理的严重问题，及时通知客户。
5. 报告与讲解：说明技术发现、业务影响、攻击路径和修复优先级。
6. 复测：确认重要修复真正阻断已经证明的路径。

很多企业两者都需要，只是频率不同

对多数中小企业，实用模式是用周期性漏洞扫描保持广泛可见性，再在关键时点做聚焦渗透测试，例如重要系统上线前、重大架构变更后，或按风险制定周期。扫描擅长大范围发现已知弱点；渗透测试则说明这些弱点在具体环境中能产生什么后果。

如果不确定该选择哪种深度，Canlus 可通过免费初步咨询帮助明确业务问题、确定合理范围，并建议扫描、渗透测试或分阶段组合方案，不会为了扩大项目而出售对决策没有帮助的深度。

“漏洞掃描”和“滲透測試”經常被當成同一種服務，其實兩者回答的問題不同，依賴人工判斷的程度不同，最終提供的證據也不同。選錯方案，可能導致關鍵風險沒有被驗證，也可能在基礎工作尚未完成時，為不必要的深度投入預算。

漏洞掃描做什麼

漏洞掃描使用自動化工具檢查系統、應用和雲資產中的已知弱點，例如缺失補丁、過期軟體、不安全服務、弱加密、暴露埠，以及與公開漏洞相關的配置。經過授權的認證掃描還可以使用受控賬號登入系統，從內部看到比外部掃描更多的資訊。

掃描覆蓋廣、可重複、效率較高，適合日常安全衛生：定期檢查變化中的環境、衡量補丁工作是否改善、支撐漏洞管理，並在深入測試前發現明顯暴露。它的侷限是缺少業務上下文。工具能報告某個條件存在，卻未必能判斷它在本環境中是否可達、可利用或真正重要，因此需要人工排除誤報、合併重複項並重新評估優先順序。

滲透測試做什麼

滲透測試是在約定範圍和交戰規則下，由安全專業人員進行的受控、限時評估。測試人員結合工具和手工分析，判斷弱點能否被利用來實現現實目標，例如訪問敏感資料、從一臺系統移動到另一臺、繞過控制或提升許可權。

它的目的不是“把所有系統都黑一遍”，而是在安全前提下證明可信攻擊路徑，並解釋業務影響。滲透測試可以把掃描中幾個看似無關的中等問題連線成一條實際路徑，也能驗證網路隔離、許可權邊界和應用業務邏輯是否真正有效。由於高度依賴人工判斷，它範圍更聚焦、成本更高，也不適合作為持續監控手段。

什麼時候選擇漏洞掃描

• 需要對大量系統進行週期性可見性檢查；
• 當前重點是補丁、資產衛生和減少已知漏洞；
• 尚未建立基本漏洞管理流程；
• 希望先做基線，再決定哪裡值得深入測試；
• 環境經常變化，需要在更新後重複驗證。

掃描不應止於一次報告。有效流程要為發現指定負責人，結合業務背景確認嚴重性，跟蹤修復，並透過重新掃描驗證關閉。

什麼時候選擇滲透測試

• 即將上線重要的網際網路應用或服務；
• 客戶、保險、合同或治理要求需要獨立測試；
• 處理敏感資料，或關鍵系統一旦受損會顯著影響業務；
• 需要驗證網路隔離、許可權邊界或近期安全改進是否有效；
• 希望知道攻擊者實際能做到什麼，而不僅是一份已知問題清單。

滲透測試的範圍最好與決策直接相關。“測試外部環境”過於寬泛；“判斷未登入攻擊者能否透過這些應用及其支撐服務訪問客戶資料”更容易形成有價值的結論。

漏洞掃描的大致流程

1. 確認資產與負責人：明確 IP 範圍、應用、雲資源和批准使用的憑據。
2. 配置並執行：避開關鍵業務時段，必要時關閉可能影響穩定性的檢查。
3. 驗證與排序：排除誤報、合併重複項，並結合暴露程度、可利用性和業務影響調整優先順序。
4. 修復：透過補丁、配置、隔離或正式風險接受處理問題。
5. 復掃與報告：確認問題關閉，並跟蹤反覆出現的模式。

滲透測試的大致流程

1. 範圍與交戰規則：明確目標、排除項、時間、聯絡人、資料處理和停止條件。
2. 偵察與分析：繪製攻擊面並識別可能路徑。
3. 受控利用：安全驗證弱點是否能夠組合並達成目標。
4. 證據與清理：記錄可復現證據，移除測試痕跡；如果發現需要立即處理的嚴重問題，及時通知客戶。
5. 報告與講解：說明技術發現、業務影響、攻擊路徑和修復優先順序。
6. 複測：確認重要修復真正阻斷已經證明的路徑。

很多企業兩者都需要，只是頻率不同

對多數中小企業，實用模式是用週期性漏洞掃描保持廣泛可見性，再在關鍵時點做聚焦滲透測試，例如重要系統上線前、重大架構變更後，或按風險制定週期。掃描擅長大範圍發現已知弱點；滲透測試則說明這些弱點在具體環境中能產生什麼後果。

如果不確定該選擇哪種深度，Canlus 可透過免費初步諮詢幫助明確業務問題、確定合理範圍，並建議掃描、滲透測試或分階段組合方案，不會為了擴大專案而出售對決策沒有幫助的深度。

脆弱性スキャンと侵入テストは同じものではありません。どちらも弱点を見つけますが、答える問い、人的判断の深さ、得られる証拠が異なります。

脆弱性スキャンとは

自動化ツールで、未適用パッチ、古いソフトウェア、安全でないサービス、弱い暗号、公開ポート、既知の設定不備を広く反復的に調べます。日常的な脆弱性管理には適しますが、誤検知や業務上の重要度は人が確認する必要があります。

侵入テストとは

合意した範囲とルールの下で、専門家がツールと手作業を組み合わせ、機密情報への到達、権限昇格、制御回避など現実的な攻撃経路を安全に検証します。人の判断を要するため範囲は絞られ、常時監視には向きません。

スキャンが向く場面

• 多数のシステムを定期的に確認したい。
• パッチと資産衛生を改善したい。
• 脆弱性管理の基礎を作る段階である。
• 深いテストの前に基準を把握したい。

結果には責任者を割り当て、事業上の影響を考慮して優先順位を付け、修正後に再スキャンします。

侵入テストが向く場面

• 重要な外部公開サービスを開始する。
• 顧客、保険、契約が独立テストを求めている。
• ネットワーク分離や権限境界を確認したい。
• 攻撃者が実際に何を達成できるか知りたい。

有益なテストは意思決定に結びつく具体的な目的を持ちます。多くの企業では、定期スキャンと重要な変更時の集中侵入テストを組み合わせるのが現実的です。Canlusは無料相談で適切な範囲と方法を整理します。

취약점 스캔과 침투 테스트는 같은 서비스가 아닙니다. 둘 다 약점을 찾지만 답하는 질문, 사람의 판단 수준, 제공하는 증빙이 다릅니다.

취약점 스캔

자동화 도구로 누락된 패치, 오래된 소프트웨어, 안전하지 않은 서비스, 약한 암호화, 노출 포트, 알려진 구성 문제를 넓고 반복적으로 확인합니다. 일상적인 취약점 관리에 적합하지만 오탐과 비즈니스 중요도는 사람이 검토해야 합니다.

침투 테스트

합의한 범위와 규칙 아래 전문가가 도구와 수동 분석을 결합해 민감 정보 접근, 권한 상승, 통제 우회 같은 실제 공격 경로를 안전하게 검증합니다. 사람의 판단이 많이 필요해 범위가 좁고 상시 모니터링에는 맞지 않습니다.

스캔이 적합한 경우

• 많은 시스템을 주기적으로 확인해야 한다.
• 패치와 자산 위생을 개선하려 한다.
• 취약점 관리의 기본을 만드는 단계다.
• 심층 테스트 전 기준선을 알고 싶다.

각 발견에 담당자를 지정하고 비즈니스 영향을 고려해 우선순위를 정하며 수정 후 다시 스캔해야 합니다.

침투 테스트가 적합한 경우

• 중요한 외부 공개 서비스를 출시한다.
• 고객, 보험, 계약이 독립 테스트를 요구한다.
• 네트워크 분리나 권한 경계를 검증해야 한다.
• 공격자가 실제로 무엇을 할 수 있는지 알고 싶다.

좋은 테스트는 구체적인 의사결정과 연결됩니다. 많은 기업에는 정기 스캔과 중요한 변경 시점의 집중 침투 테스트 조합이 현실적입니다. Canlus는 무료 상담에서 목적과 적절한 범위를 정리합니다.

A virtual Chief Information Security Officer, or vCISO, gives an organization experienced security leadership on a part-time or retained basis. The role is not simply another monitoring service. A good vCISO helps leadership decide what matters, assigns ownership, connects technical work to business risk and keeps improvement moving after the initial assessment.

Small businesses often reach a point where security work is spread across an owner, an IT provider and several vendors. Each party handles a piece, but nobody owns the whole picture. Important questions remain open: Who accepts a risk? Who checks that a critical patch was completed? Who explains a customer security questionnaire? Who coordinates when an incident crosses email, endpoints, insurance and legal obligations?

What a vCISO should do

The engagement usually begins with a current-state review. The vCISO identifies critical systems and data, documents major risks and agrees on a practical plan with leadership. Monthly work may include identity and Microsoft 365 reviews, vulnerability and patch follow-up, policy updates, tabletop exercises, vendor-risk decisions and a concise report for management.

The vCISO also creates a decision process. Not every finding deserves an urgent project. Risks should be explained in business terms, assigned to an owner and either mitigated, transferred, avoided or formally accepted. This discipline prevents security from becoming an endless list of tools.

What a vCISO should not be

A vCISO should not replace hands-on IT operations, legal advice or a 24×7 security operations centre. The role must have clear boundaries and escalation paths. If the same provider recommends and sells every product, leadership should also understand how conflicts are managed. Useful reporting is specific: what changed, what is overdue, which decision is needed and what evidence supports the conclusion.

When the model fits

• Customers or insurers increasingly ask for documented controls.
• The company handles sensitive data but has no dedicated security leader.
• Technical findings recur because ownership and deadlines are unclear.
• Leadership needs a security roadmap and a predictable monthly cadence.
• An upcoming certification, contract or expansion requires stronger governance.

It may be too early when basic IT ownership is still unclear, assets are not inventoried or the organization only needs one focused project. In that case, begin with a bounded assessment and establish the operational foundation first.

Questions to ask before hiring

Ask who will actually deliver the service, what is included each month, how urgent incidents are handled, which reports leadership receives and whether implementation work is separate from governance. Agree on measurable outcomes for the first 90 days rather than buying an undefined block of hours.

Canlus offers a free initial consultation to determine whether a focused project, a monthly security program or a vCISO relationship is the right next step. The answer should match your operating needs—not a predetermined package.

虚拟首席信息安全官（vCISO）是以兼职或长期顾问方式，为企业提供资深安全领导力。它不是另一项单纯的监控服务。合格的 vCISO 要帮助管理层判断重点、明确负责人、把技术工作连接到业务风险，并在首次评估后持续推动改进。

很多中小企业发展到一定阶段后，安全责任分散在老板、IT 服务商和多个供应商之间。每一方负责一部分，却没有人掌握全局：谁接受某项风险？谁确认关键补丁真正完成？谁回答客户的安全问卷？当事件同时涉及邮箱、终端、保险和法律义务时，谁负责协调？

vCISO 应该做什么

合作通常从现状评估开始。vCISO 识别关键系统和数据，记录主要风险，并与管理层确定务实计划。月度工作可包括身份与 Microsoft 365 检查、漏洞和补丁跟进、政策更新、桌面演练、供应商风险决策，以及面向管理层的简明报告。

更重要的是建立决策机制。并非每个发现都值得紧急立项。风险应以业务语言解释，分配负责人，并选择降低、转移、避免或正式接受。这样才能避免安全工作变成无止境的工具采购清单。

vCISO 不应该替代什么

vCISO 不替代日常 IT 运维、法律意见或 7×24 安全运营中心。服务边界和升级路径必须明确。如果同一服务商既提出建议又销售所有产品，管理层也应了解如何处理利益冲突。有效报告要具体说明：发生了什么变化、哪些事项逾期、需要什么决策、结论有什么证据。

什么时候适合

• 客户或保险机构越来越多地要求提供控制证据；
• 企业处理敏感数据，却没有专职安全负责人；
• 技术问题反复出现，因为负责人和期限不清楚；
• 管理层需要安全路线图和固定月度节奏；
• 即将开展认证、重要合同或业务扩张，需要加强治理。

如果基础 IT 责任尚未明确、资产没有清单，或当前只需要完成一个专项项目，那么引入 vCISO 可能过早。此时应先做有边界的评估，建立运营基础。

聘用前要问什么

确认由谁实际交付、每月包含哪些内容、紧急事件如何支持、管理层收到什么报告，以及实施与治理是否分别计费。第一阶段应约定 90 天内的可衡量结果，而不是购买一块定义模糊的时间。

Canlus 可通过免费初步咨询帮助判断：当前更适合专项项目、月度安全代维，还是 vCISO 合作。答案应匹配真实运营需求，而不是预设套餐。

虛擬首席資訊保安官（vCISO）是以兼職或長期顧問方式，為企業提供資深安全領導力。它不是另一項單純的監控服務。合格的 vCISO 要幫助管理層判斷重點、明確負責人、把技術工作連線到業務風險，並在首次評估後持續推動改進。

很多中小企業發展到一定階段後，安全責任分散在老闆、IT 服務商和多個供應商之間。每一方負責一部分，卻沒有人掌握全域性：誰接受某項風險？誰確認關鍵補丁真正完成？誰回答客戶的安全問卷？當事件同時涉及郵箱、終端、保險和法律義務時，誰負責協調？

vCISO 應該做什麼

合作通常從現狀評估開始。vCISO 識別關鍵系統和資料，記錄主要風險，並與管理層確定務實計劃。月度工作可包括身份與 Microsoft 365 檢查、漏洞和補丁跟進、政策更新、桌面演練、供應商風險決策，以及面向管理層的簡明報告。

更重要的是建立決策機制。並非每個發現都值得緊急立項。風險應以業務語言解釋，分配負責人，並選擇降低、轉移、避免或正式接受。這樣才能避免安全工作變成無止境的工具採購清單。

vCISO 不應該替代什麼

vCISO 不替代日常 IT 運維、法律意見或 7×24 安全運營中心。服務邊界和升級路徑必須明確。如果同一服務商既提出建議又銷售所有產品，管理層也應瞭解如何處理利益衝突。有效報告要具體說明：發生了什麼變化、哪些事項逾期、需要什麼決策、結論有什麼證據。

什麼時候適合

• 客戶或保險機構越來越多地要求提供控制證據；
• 企業處理敏感資料，卻沒有專職安全負責人；
• 技術問題反覆出現，因為負責人和期限不清楚；
• 管理層需要安全路線圖和固定月度節奏；
• 即將開展認證、重要合同或業務擴張，需要加強治理。

如果基礎 IT 責任尚未明確、資產沒有清單，或當前只需要完成一個專項專案，那麼引入 vCISO 可能過早。此時應先做有邊界的評估，建立運營基礎。

聘用前要問什麼

確認由誰實際交付、每月包含哪些內容、緊急事件如何支援、管理層收到什麼報告，以及實施與治理是否分別計費。第一階段應約定 90 天內的可衡量結果，而不是購買一塊定義模糊的時間。

Canlus 可透過免費初步諮詢幫助判斷：當前更適合專項專案、月度安全代維，還是 vCISO 合作。答案應匹配真實運營需求，而不是預設套餐。

vCISOは、非常勤または継続契約で経験豊富なセキュリティリーダーを提供する仕組みです。単なる監視サービスではなく、経営が重要事項を判断し、責任者を決め、技術施策を事業リスクへ結びつける役割です。

中小企業では、経営者、IT事業者、複数のベンダーがそれぞれ一部を担当し、全体を所有する人がいないことがあります。リスク受容、重要パッチ、顧客質問票、事故時の保険・法務調整を誰が担うかが曖昧になります。

vCISOが行うこと

現状評価から始め、重要なシステムとデータ、主要リスク、実行可能な計画を経営と合意します。月次業務には、IDとMicrosoft 365の確認、脆弱性・パッチの追跡、方針更新、机上演習、ベンダーリスク判断、経営向け報告が含まれます。

vCISOが代替しないもの

日常IT運用、法律助言、24時間監視の代わりではありません。境界と緊急時の連絡方法を明確にし、製品販売との利益相反も説明されるべきです。

適している状況

• 顧客や保険会社から統制の証拠を求められる。
• 機密情報を扱うが専任責任者がいない。
• 担当と期限が曖昧で問題が繰り返される。
• ロードマップと月次の進行管理が必要。

基本ITの責任や資産一覧がない場合、まず範囲を限定した評価が適します。契約前には、実際の担当者、月次範囲、緊急対応、報告、導入作業との区分、最初の90日の成果を確認してください。

vCISO는 파트타임 또는 지속 계약으로 숙련된 보안 리더십을 제공하는 방식입니다. 단순 모니터링이 아니라 경영진이 중요한 위험을 판단하고 책임자를 정하며 기술 업무를 비즈니스 위험과 연결하도록 돕습니다.

중소기업에서는 소유자, IT 업체, 여러 공급업체가 각자 일부만 담당해 전체 책임자가 없을 수 있습니다. 위험 수용, 중요 패치, 고객 보안 설문, 사고 시 보험·법률 조정을 누가 맡는지 불분명해집니다.

vCISO가 하는 일

현재 상태 검토에서 시작해 중요 시스템과 데이터, 주요 위험, 실용적인 계획을 경영진과 합의합니다. 월간 업무에는 ID와 Microsoft 365 검토, 취약점과 패치 추적, 정책 업데이트, 모의훈련, 공급업체 위험 결정, 경영진 보고가 포함될 수 있습니다.

vCISO가 대체하지 않는 일

일상 IT 운영, 법률 자문, 24시간 보안 관제를 대체하지 않습니다. 경계와 긴급 대응 절차를 명확히 하고 제품 판매와의 이해 상충도 설명해야 합니다.

적합한 상황

• 고객이나 보험사가 통제 증빙을 요구한다.
• 민감 정보를 처리하지만 전담 보안 책임자가 없다.
• 담당자와 기한이 불명확해 문제가 반복된다.
• 로드맵과 월간 추진 주기가 필요하다.

기본 IT 책임과 자산 목록도 없다면 범위가 정해진 평가가 먼저입니다. 계약 전 실제 담당자, 월간 범위, 긴급 대응, 보고, 구현과 거버넌스의 구분, 첫 90일의 성과를 확인하세요.

Ransomware response is a coordination problem before it is a technical problem. The first decisions affect evidence, recovery, insurance, legal obligations and business continuity. A short plan with named contacts is more useful during an incident than a long policy nobody has practised.

The first hour: contain without destroying evidence

1. Activate one incident lead. Record the time, what was observed, affected users or systems and who is making decisions.
2. Isolate affected devices. Disconnect network access when it is safe, but do not wipe, reimage or power down systems unless the response lead advises it. Volatile evidence may matter.
3. Protect clean communications. If corporate email may be compromised, use a pre-agreed phone bridge or alternate channel. Do not discuss sensitive response details in a potentially monitored mailbox.
4. Secure identities. Revoke suspicious sessions, disable confirmed-compromised accounts and protect administrator access. Avoid broad password resets until the team understands how credentials and devices may be affected.
5. Call the right parties. Contact the IT and security responders, cyber insurer and legal/privacy counsel according to the plan. Follow insurer requirements before retaining services or negotiating.

The first day: understand scope and preserve options

Determine which systems, locations, identities and data are affected. Preserve logs, ransom notes, suspicious emails and forensic images when appropriate. Check whether attackers gained access before encryption and whether data may have been removed. Extortion involving stolen information can create different notification and legal considerations from operational disruption alone.

Confirm the status of backups without connecting protected copies to the compromised environment. Identify the last known clean point, the dependencies between systems and the minimum services needed to operate safely. Communicate internally using verified facts. Avoid promising a restoration time or stating that no data was taken before evidence supports the claim.

Recovery: rebuild trust, not just servers

Recovery should use clean systems, known-good credentials and a prioritized sequence. Restore the identity and management layers carefully because they control everything else. Patch or remove the entry path before reconnecting systems. Validate restored data and application behaviour with business owners, then increase monitoring for repeated access.

Whether to pay a ransom is a legal, financial, operational and ethical decision—not a purely technical recommendation. Payment does not guarantee decryption, deletion of stolen data or protection from future targeting. Engage counsel, the insurer and appropriate authorities, and check sanctions implications before any negotiation.

Prepare before the event

• Maintain offline or otherwise protected backups and test restoration.
• Record insurer, legal, IT, security and executive contacts outside the main environment.
• Define who can shut down systems, notify customers and approve major spending.
• Keep an asset list, network diagram and administrator-access record available.
• Run a short tabletop exercise at least annually and after major changes.

Canlus can review an existing response plan or facilitate a focused readiness session. A free initial consultation can identify the most important preparation gap without turning the conversation into a fear-based sale.

勒索软件响应首先是协调问题，其次才是技术问题。最初几个决定会影响证据、恢复、保险、法律义务和业务连续性。真正发生事件时，一份明确联系人和权限的短计划，往往比没人演练过的长政策更有用。

第一个小时：控制范围，不破坏证据

1. 启动唯一事件负责人：记录时间、观察到的现象、受影响用户或系统，以及谁负责决策。
2. 隔离受影响设备：在安全前提下断开网络，但除非响应负责人明确要求，不要立即擦除、重装或关机，以免丢失重要证据。
3. 保护干净通信：如果企业邮箱可能被入侵，使用预先约定的电话会议或备用渠道，不在可能被监控的邮箱讨论敏感细节。
4. 保护身份：撤销可疑会话，停用确认被入侵的账号，优先保护管理员权限。在不了解凭据和设备影响前，不要仓促大范围重置密码。
5. 联系正确人员：按计划通知 IT、安全响应、网络保险和法律/隐私顾问。聘用外部服务或谈判前，先确认保险要求。

第一天：判断范围，保留选择

确认哪些系统、地点、身份和数据受到影响。保存日志、勒索信、可疑邮件，并在适当情况下制作取证镜像。调查攻击者是否在加密前已经获得访问，以及数据是否可能被带走。涉及数据窃取的勒索，与单纯业务中断在通知和法律义务上可能不同。

在不把受保护副本接入受损环境的情况下确认备份状态，确定最后一个可信恢复点、系统依赖关系，以及安全维持运营所需的最小服务。内部沟通只使用已经验证的事实。在没有证据前，不承诺恢复时间，也不要断言“没有数据泄露”。

恢复：重建信任，而不只是恢复服务器

使用干净系统、可信凭据和明确优先顺序恢复。身份与管理层控制其他系统，应谨慎恢复。重新联网前修补或移除入侵路径，由业务负责人验证数据和应用行为，并加强对重复访问的监控。

是否支付赎金涉及法律、财务、运营和伦理，不是纯技术决定。付款不能保证解密、删除被盗数据或避免再次被攻击。任何谈判前应咨询法律顾问、保险机构和适当执法部门，并检查制裁风险。

事前准备

• 保留离线或受保护备份并测试恢复；
• 在主环境之外保存保险、法律、IT、安全和高管联系人；
• 明确谁有权关闭系统、通知客户和批准重大支出；
• 保留可访问的资产清单、网络图和管理员权限记录；
• 至少每年以及重大变更后进行一次桌面演练。

Canlus 可检查现有响应计划，或组织聚焦的准备度会议。免费初步咨询可以先找出最重要的准备缺口，不用恐惧式营销推动不必要的项目。

勒索軟體響應首先是協調問題，其次才是技術問題。最初幾個決定會影響證據、恢復、保險、法律義務和業務連續性。真正發生事件時，一份明確聯絡人和許可權的短計劃，往往比沒人演練過的長政策更有用。

第一個小時：控制範圍，不破壞證據

1. 啟動唯一事件負責人：記錄時間、觀察到的現象、受影響使用者或系統，以及誰負責決策。
2. 隔離受影響裝置：在安全前提下斷開網路，但除非響應負責人明確要求，不要立即擦除、重灌或關機，以免丟失重要證據。
3. 保護乾淨通訊：如果企業郵箱可能被入侵，使用預先約定的電話會議或備用渠道，不在可能被監控的郵箱討論敏感細節。
4. 保護身份：撤銷可疑會話，停用確認被入侵的賬號，優先保護管理員許可權。在不瞭解憑據和裝置影響前，不要倉促大範圍重置密碼。
5. 聯絡正確人員：按計劃通知 IT、安全響應、網路保險和法律/隱私顧問。聘用外部服務或談判前，先確認保險要求。

第一天：判斷範圍，保留選擇

確認哪些系統、地點、身份和資料受到影響。儲存日誌、勒索信、可疑郵件，並在適當情況下製作取證映象。調查攻擊者是否在加密前已經獲得訪問，以及資料是否可能被帶走。涉及資料竊取的勒索，與單純業務中斷在通知和法律義務上可能不同。

在不把受保護副本接入受損環境的情況下確認備份狀態，確定最後一個可信恢復點、系統依賴關係，以及安全維持運營所需的最小服務。內部溝通只使用已經驗證的事實。在沒有證據前，不承諾恢復時間，也不要斷言“沒有資料洩露”。

恢復：重建信任，而不只是恢復伺服器

使用乾淨系統、可信憑據和明確優先順序恢復。身份與管理層控制其他系統，應謹慎恢復。重新聯網前修補或移除入侵路徑，由業務負責人驗證資料和應用行為，並加強對重複訪問的監控。

是否支付贖金涉及法律、財務、運營和倫理，不是純技術決定。付款不能保證解密、刪除被盜資料或避免再次被攻擊。任何談判前應諮詢法律顧問、保險機構和適當執法部門，並檢查制裁風險。

事前準備

• 保留離線或受保護備份並測試恢復；
• 在主環境之外儲存保險、法律、IT、安全和高管聯絡人；
• 明確誰有權關閉系統、通知客戶和批准重大支出；
• 保留可訪問的資產清單、網路圖和管理員許可權記錄；
• 至少每年以及重大變更後進行一次桌面演練。

Canlus 可檢查現有響應計劃，或組織聚焦的準備度會議。免費初步諮詢可以先找出最重要的準備缺口，不用恐懼式營銷推動不必要的專案。

ランサムウェア対応は、技術以前に連携の問題です。最初の判断が証拠、復旧、保険、法的義務、事業継続を左右します。実践した短い計画の方が、誰も使ったことのない長い規程より役立ちます。

最初の1時間

1. 責任者を一人決める。時刻、事象、対象、意思決定者を記録します。
2. 対象端末を隔離する。安全ならネットワークを切りますが、指示なく消去・再構築・電源断をしません。
3. 安全な連絡手段を使う。メール侵害の可能性があれば、事前に決めた電話や代替チャネルへ移ります。
4. IDを守る。不審なセッションを失効し、侵害済みアカウントを停止して管理者アクセスを保護します。
5. 関係者へ連絡する。IT、セキュリティ、サイバー保険、法務・プライバシー担当へ計画どおり連絡します。

最初の1日

影響したシステム、拠点、ID、データを確認し、ログ、脅迫文、メール、必要な証拠を保存します。データ持ち出しの可能性と、保護されたバックアップの最終正常時点を確認します。証拠がない段階で復旧時刻や「漏えいはない」と断言しません。

復旧

クリーンなシステムと認証情報を使い、IDと管理基盤から優先順に復旧します。再接続前に侵入口を塞ぎ、業務担当者がデータと動作を確認し、監視を強化します。身代金の支払いは法務、財務、運用、倫理を含む判断であり、復号やデータ削除を保証しません。

平時の準備

• 隔離されたバックアップを維持し復元を試す。
• 保険、法務、IT、経営の連絡先を別環境に保存する。
• 停止、顧客通知、大口支出の権限を決める。
• 資産一覧、ネットワーク図、管理者記録を備える。
• 年1回と大きな変更後に机上演習を行う。

랜섬웨어 대응은 기술 문제이기 전에 조정 문제입니다. 초기 결정이 증거, 복구, 보험, 법적 의무, 업무 연속성에 영향을 줍니다. 연습한 짧은 계획이 아무도 써 본 적 없는 긴 정책보다 유용합니다.

첫 한 시간

1. 사고 책임자 한 명을 지정합니다.시간, 관찰 내용, 대상, 의사결정자를 기록합니다.
2. 영향받은 기기를 격리합니다.안전하면 네트워크를 끊되 지시 없이 삭제, 재설치, 전원 종료를 하지 않습니다.
3. 깨끗한 통신 채널을 씁니다.회사 메일이 침해됐을 수 있으면 사전 합의한 전화나 대체 채널로 이동합니다.
4. ID를 보호합니다.의심 세션을 취소하고 확인된 침해 계정을 비활성화하며 관리자 접근을 지킵니다.
5. 적절한 담당자에게 연락합니다.IT, 보안 대응, 사이버 보험, 법률·개인정보 담당자에게 계획대로 알립니다.

첫날

영향받은 시스템, 위치, ID, 데이터를 파악하고 로그, 랜섬 노트, 의심 메일, 필요한 증거를 보존합니다. 데이터 유출 가능성과 보호된 백업의 마지막 정상 시점을 확인하세요. 증거 없이 복구 시간을 약속하거나 “유출이 없다”고 말하지 않습니다.

복구

깨끗한 시스템과 자격 증명을 쓰고 ID와 관리 계층부터 우선순위대로 복구합니다. 재연결 전 침입 경로를 막고 업무 담당자가 데이터와 동작을 검증하며 모니터링을 강화합니다. 몸값 지급은 법률, 재무, 운영, 윤리가 얽힌 결정이며 복호화나 데이터 삭제를 보장하지 않습니다.

사전 준비

• 격리된 백업을 유지하고 복원을 시험한다.
• 보험, 법률, IT, 경영진 연락처를 별도 환경에 보관한다.
• 시스템 중단, 고객 통지, 큰 지출 권한을 정한다.
• 자산 목록, 네트워크 구성도, 관리자 기록을 준비한다.
• 매년과 주요 변경 후 모의훈련을 한다.

PIPEDA is Canada’s federal private-sector privacy law governing how covered organizations collect, use and disclose personal information in commercial activities. Provincial laws may apply instead of, or alongside, federal requirements in particular circumstances. This introduction is operational guidance, not legal advice; confirm the obligations that apply to your organization with qualified counsel.

Start with accountability

Privacy is not only a policy on a website. Someone must be accountable for the organization’s privacy practices, understand where personal information is held and coordinate requests or incidents. A small business does not need a large privacy office, but it does need a named owner, documented responsibilities and a path for employees to raise questions.

Collect for an appropriate, explained purpose

Before collecting personal information, identify why it is needed and whether a reasonable person would consider that purpose appropriate. Tell the individual in understandable language. Avoid collecting information “just in case.” Extra data increases breach impact, access-request effort and retention obligations without necessarily creating value.

Consent must be meaningful for the context. The form of consent can depend on sensitivity and reasonable expectations. Do not hide important uses in a long general statement. If the purpose changes materially, reassess whether new consent or another lawful basis is required.

Limit use, disclosure and retention

Use information for the identified purpose and disclose it only as permitted. Vendors that process information should be selected and governed with care; outsourcing a service does not outsource accountability. Contracts should address safeguards, access, incidents, deletion and any cross-border processing relevant to the service.

Define retention periods. Information should not remain forever because storage is inexpensive. Keep it long enough for legitimate operational, contractual or legal needs, then dispose of it securely. Apply the rule to email, shared drives, SaaS tools and backups—not only the primary database.

Use safeguards appropriate to sensitivity

Safeguards should reflect the sensitivity, amount, format and distribution of the information. Practical controls often include MFA, role-based access, secure sharing, endpoint management, encryption, tested backups, logging, employee awareness and timely offboarding. Protect administrator accounts more strongly because they can bypass other controls.

Support access and correction

Individuals may request access to personal information and ask for corrections, subject to applicable limits. The business needs a repeatable way to verify identity, search relevant systems, review information, respond within required timelines and record the outcome. An incomplete system inventory makes these requests difficult.

Prepare for breaches

Organizations subject to PIPEDA must assess breaches of security safeguards and follow reporting, notification and record-keeping requirements where applicable, including the “real risk of significant harm” threshold. A response plan should identify who assesses harm, who obtains legal advice, how affected records and people are identified and how decisions are documented.

A practical starting checklist

• Name the privacy accountable person.
• Inventory the personal information you collect, where it goes and who can access it.
• Review notices, consent language and high-risk vendor arrangements.
• Set retention and secure-disposal rules for priority records.
• Verify MFA, least privilege, backups and offboarding for systems holding personal information.
• Create an access-request and breach-response workflow.

Canlus can help assess technical and operational privacy readiness and organize remediation evidence. A free initial consultation can clarify whether your first need is an inventory, a safeguards review or a broader compliance-readiness assessment.

PIPEDA 是加拿大联邦私营部门隐私法，规范适用组织在商业活动中如何收集、使用和披露个人信息。在某些情况下，省级法律可能取代或与联邦要求同时适用。本文提供运营层面的入门说明，不构成法律意见；企业应与合格法律顾问确认自身适用义务。

从问责开始

隐私不只是网站上的一份政策。企业必须有人对隐私实践负责，了解个人信息存放在哪里，并协调访问请求或事件。小企业不需要庞大隐私部门，但需要明确负责人、书面职责，以及员工提出问题的路径。

为适当且已说明的目的收集

收集个人信息前，先明确为什么需要，以及合理的人是否会认为目的适当，并用容易理解的语言告知个人。不要为了“以后可能用到”而过度收集。额外数据会增加泄露影响、访问请求工作量和保留责任，却未必创造价值。

同意必须在具体场景中具有真实意义，形式会随信息敏感度和合理预期变化。重要用途不应隐藏在冗长通用声明中。如果目的发生重大变化，应重新判断是否需要新的同意或其他合法依据。

限制使用、披露和保留

信息只能用于已经说明的目的，并在允许范围内披露。选择和管理处理个人信息的供应商时要谨慎；外包服务不等于外包问责。合同应明确安全措施、访问、事件、删除，以及与服务相关的跨境处理。

建立保留期限。不能因为存储便宜就永久保存。信息应在合法运营、合同或法律需要期间保留，之后安全销毁。规则应覆盖邮箱、共享盘、SaaS 工具和备份，而不只是主数据库。

采用与敏感度匹配的保护措施

保护措施应考虑信息的敏感度、数量、格式和分布。常见实用控制包括 MFA、基于角色的访问、安全共享、终端管理、加密、已测试备份、日志、员工意识和及时离职处理。管理员账号能够绕过其他控制，应采用更严格保护。

支持访问与更正

个人可以在适用限制下请求访问并更正自己的信息。企业需要一套可重复流程来验证身份、搜索相关系统、审查信息、在要求时间内回应并记录结果。如果没有完整系统清单，这类请求会很困难。

做好泄露准备

受 PIPEDA 约束的组织必须评估安全保护措施泄露，并在适用时遵守报告、通知和记录要求，包括“造成重大伤害的真实风险”门槛。响应计划应明确谁评估伤害、谁取得法律意见、如何识别受影响记录和个人，以及如何记录决策。

实用起点清单

• 指定隐私问责负责人；
• 盘点收集的个人信息、流向和访问者；
• 检查隐私通知、同意文字和高风险供应商；
• 为重点记录设置保留和安全销毁规则；
• 验证保存个人信息系统的 MFA、最小权限、备份和离职流程；
• 建立访问请求和泄露响应流程。

Canlus 可协助评估技术和运营层面的隐私准备度，并整理修复证据。免费初步咨询可以帮助判断第一步是数据盘点、安全措施检查，还是更完整的合规就绪评估。

PIPEDA 是加拿大聯邦私營部門隱私法，規範適用組織在商業活動中如何收集、使用和披露個人資訊。在某些情況下，省級法律可能取代或與聯邦要求同時適用。本文提供運營層面的入門說明，不構成法律意見；企業應與合格法律顧問確認自身適用義務。

從問責開始

隱私不只是網站上的一份政策。企業必須有人對隱私實踐負責，瞭解個人資訊存放在哪裡，並協調訪問請求或事件。小企業不需要龐大隱私部門，但需要明確負責人、書面職責，以及員工提出問題的路徑。

為適當且已說明的目的收集

收集個人資訊前，先明確為什麼需要，以及合理的人是否會認為目的適當，並用容易理解的語言告知個人。不要為了“以後可能用到”而過度收集。額外資料會增加洩露影響、訪問請求工作量和保留責任，卻未必創造價值。

同意必須在具體場景中具有真實意義，形式會隨資訊敏感度和合理預期變化。重要用途不應隱藏在冗長通用宣告中。如果目的發生重大變化，應重新判斷是否需要新的同意或其他合法依據。

限制使用、披露和保留

資訊只能用於已經說明的目的，並在允許範圍內披露。選擇和管理處理個人資訊的供應商時要謹慎；外包服務不等於外包問責。合同應明確安全措施、訪問、事件、刪除，以及與服務相關的跨境處理。

建立保留期限。不能因為儲存便宜就永久儲存。資訊應在合法運營、合同或法律需要期間保留，之後安全銷燬。規則應覆蓋郵箱、共享盤、SaaS 工具和備份，而不只是主資料庫。

採用與敏感度匹配的保護措施

保護措施應考慮資訊的敏感度、數量、格式和分佈。常見實用控制包括 MFA、基於角色的訪問、安全共享、終端管理、加密、已測試備份、日誌、員工意識和及時離職處理。管理員賬號能夠繞過其他控制，應採用更嚴格保護。

支援訪問與更正

個人可以在適用限制下請求訪問並更正自己的資訊。企業需要一套可重複流程來驗證身份、搜尋相關係統、審查資訊、在要求時間內回應並記錄結果。如果沒有完整系統清單，這類請求會很困難。

做好洩露準備

受 PIPEDA 約束的組織必須評估安全保護措施洩露，並在適用時遵守報告、通知和記錄要求，包括“造成重大傷害的真實風險”門檻。響應計劃應明確誰評估傷害、誰取得法律意見、如何識別受影響記錄和個人，以及如何記錄決策。

實用起點清單

• 指定隱私問責負責人；
• 盤點收集的個人資訊、流向和訪問者；
• 檢查隱私通知、同意文字和高風險供應商；
• 為重點記錄設定保留和安全銷燬規則；
• 驗證儲存個人資訊系統的 MFA、最小許可權、備份和離職流程；
• 建立訪問請求和洩露響應流程。

Canlus 可協助評估技術和運營層面的隱私準備度，並整理修復證據。免費初步諮詢可以幫助判斷第一步是資料盤點、安全措施檢查，還是更完整的合規就緒評估。

PIPEDAは、対象となる民間組織が商業活動で個人情報を収集、利用、開示する方法を定めるカナダ連邦法です。状況により州法が代わりに、または併せて適用されます。以下は実務上の案内であり、法的助言ではありません。

説明責任から始める

個人情報の保管場所を把握し、問い合わせや事故を調整する責任者を決めます。大きな専門部署は不要でも、役割と社員からの相談経路は文書化が必要です。

適切で説明できる目的だけで収集する

収集前に必要性と合理性を確認し、本人へ分かりやすく伝えます。「念のため」の余分な収集は、漏えい被害、開示請求、保存義務を増やします。重要な利用目的を長い一般文に隠さず、目的変更時は同意等を再確認します。

利用、開示、保存を限定する

特定した目的の範囲で利用し、委託先には安全策、アクセス、事故、削除、越境処理を契約で定めます。正当な業務・契約・法的必要期間の後は、メール、共有ドライブ、SaaS、バックアップを含め安全に廃棄します。

機微性に合う保護策を使う

MFA、役割別アクセス、安全な共有、端末管理、暗号化、検証済みバックアップ、ログ、社員教育、迅速な退職処理を組み合わせ、管理者は特に強く保護します。

アクセスと訂正を支える

本人確認、関連システムの検索、情報の確認、期限内回答、結果記録を再現できる手順にします。資産とデータの一覧が不完全だと対応が困難です。

漏えいに備える

PIPEDAの対象組織は、重大な危害の現実的リスクなど該当要件に沿って評価、報告、通知、記録を行います。誰が危害を評価し、法務へ相談し、対象記録と本人を特定し、判断を記録するか決めてください。

最初のチェックリスト

• 個人情報保護の責任者を指名する。
• 収集情報、保存場所、アクセス者を棚卸しする。
• 通知、同意文、重要な委託先を見直す。
• 保存・廃棄ルールを決める。
• MFA、最小権限、バックアップ、退職処理を確認する。
• 開示請求と漏えい対応の手順を作る。

PIPEDA는 적용 대상 민간 조직이 상업 활동에서 개인정보를 수집, 사용, 공개하는 방식을 규율하는 캐나다 연방법입니다. 상황에 따라 주법이 대신 또는 함께 적용될 수 있습니다. 아래 내용은 운영 안내이며 법률 자문이 아닙니다.

책임성부터 시작

개인정보가 어디에 있는지 알고 요청과 사고를 조정할 책임자를 정하세요. 큰 전담 조직은 없어도 담당자, 문서화된 책임, 직원 문의 경로는 필요합니다.

적절하고 설명 가능한 목적만 수집

수집 전에 필요성과 합리성을 확인하고 이해하기 쉬운 말로 알립니다. “혹시 몰라서” 모은 정보는 유출 피해, 열람 요청, 보존 부담을 늘립니다. 중요한 목적을 긴 일반 문구에 숨기지 말고 목적이 크게 바뀌면 동의 등을 다시 검토하세요.

사용·공개·보존 제한

정한 목적 안에서 사용하고 공급업체 계약에는 보호, 접근, 사고, 삭제, 국경 간 처리를 포함합니다. 정당한 운영·계약·법적 기간이 지나면 이메일, 공유 드라이브, SaaS, 백업까지 안전하게 폐기합니다.

민감도에 맞는 보호 조치

MFA, 역할 기반 접근, 안전한 공유, 기기 관리, 암호화, 검증된 백업, 로그, 직원 교육, 신속한 퇴사 처리를 조합하고 관리자 계정은 더 강하게 보호합니다.

열람과 정정 지원

신원 확인, 관련 시스템 검색, 정보 검토, 기한 내 답변, 결과 기록을 반복 가능한 절차로 만드세요. 시스템과 데이터 목록이 불완전하면 대응이 어렵습니다.

유출 대비

PIPEDA 적용 조직은 중대한 피해의 실질적 위험 등 해당 기준에 따라 사고를 평가하고 보고, 통지, 기록해야 합니다. 피해 평가, 법률 자문, 대상 기록과 사람 식별, 결정 기록의 담당자를 정하세요.

실용적인 시작 목록

• 개인정보 책임자를 지정한다.
• 수집 정보, 위치, 접근자를 파악한다.
• 고지, 동의 문구, 주요 공급업체를 검토한다.
• 보존과 안전한 폐기 규칙을 정한다.
• MFA, 최소 권한, 백업, 퇴사 처리를 확인한다.
• 열람 요청과 유출 대응 절차를 만든다.