社内のセキュリティ対策を継続的に高めていく上で、脆弱性管理は欠かせない取り組みのひとつです。
例えば、アーカイバソフトなどで脆弱性が発見されると、添付ファイル展開時にマルウェアスキャンをすり抜ける可能性が生じ、結果として、エンドポイントが攻撃の踏み台となるリスクを抱えることになります。具体的な例としては米CISAのKnown Exploited Vulnerabilities Catalog（KEV）に追加された、7-Zipのゼロデイ脆弱性「CVE-2025-0411」が挙げられます。これは、7-Zipが解凍時にMark-of-the-Web（MoTW）属性を正しく継承しないことで、Windows のセキュリティ保護機能を回避し、悪意あるファイルを警告なしで実行できるというものです。ブラウザー、PDFリーダーなどのソフトウェアにおいても攻撃に悪用された事例が公開されています。
このように、「サーバー側の問題」だけではなく「ユーザー端末での脆弱性」も重大な課題となっており、当社ではこうした背景から、クライアント端末を含む脆弱性対策の強化を目的として、Microsoft Defender for Endpoint を活用した社内運用を試験的に実施しました。
Microsoft Defender for Endpoint は本来、EDR（Endpoint Detection and Response）ソリューションとしての位置づけが強く、脆弱性管理機能は副次的な要素として提供されています。
この機能をできる限りフル活用して価値を引き出したいと考え、既に当社内で導入済みであり改めて展開が不要であることから、脆弱性管理機能を中心とした運用を実際に展開することにしました。
社内運用では対象範囲を限定し、約60〜70名程度の社員を対象に、半年間の試験運用を実施しました。対象範囲に技術職と非技術職が混在するチームを含めることで、現場の多様な利用環境による対応差分も現れてきました。
本記事では、その半年間の取り組みを通じて得られた課題と気付きを共有します。
Microsoft Defender for Endpoint による脆弱性管理の実践
Microsoft Defender for Endpoint には、Threat & Vulnerability Management (TVM)という脆弱性管理機能が備わっています。ソフトウェアや構成の脆弱性を自動的に検出し、推奨アクションを提示してくれるため、管理者視点では非常に有用なツールです。
当社でもこの機能をそのまま活用して社内の脆弱性可視化を進めることを検討しましたが、Microsoft Defender for Endpoint は構造的に管理者中心の運用モデルであり、一般ユーザーが自分の端末の状態をポータル上で直接確認することはできません。
結果として、脆弱性情報の共有は「管理者が通知を出す → ユーザーが対応する」という一方向の流れにとどまってしまいます。
当社内のセキュリティ管理担当者へヒアリングを行った際にも、脆弱性情報の共有から対応まで全てをフォローするのは負荷が高すぎるとの意見をもらい、社内展開にあたってはユーザー側の自発的な対応を促す仕組みが必要となることが分かりました。
その結果、Microsoft Defender for Endpoint の脆弱性管理機能は、管理者が全体を把握するには有効だが、ユーザーが自ら行動するには適していないという結論に至りました。
この時点で、私たちは「単にツールを導入するだけではなく、ユーザーが自分の端末の状態を理解し、行動できる仕組みを別途整備する必要がある」という課題を明確に認識することができました。
ユーザー展開方法と運用上の課題
Microsoft Defender for Endpoint の情報をユーザーに展開する方法としては、
- ユーザーごとに Microsoft Defender for Endpoint デバイスグループを分けて表示する
- Power BI で Microsoft Defender for Endpoint をデータソースとして取得し、Row-Level-Security（RLS）でユーザープリンシパルが一致するレコードのみを表示する
- 独自アプリでREST APIを使用して脆弱性データを取得し、ユーザープリンシパルが一致するレコードのみを表示する
といった手段が考えられます。
1はユーザーのライフサイクルに合わせて作業が発生し、運用負荷が高すぎるため却下。
2は通知を行うために Azure Logic Apps などを組み合わせればうまく運用できる可能性はありましたが、Power BI の事前準備に大きなコストを割いてしまうことや、検討途中での仕様変更に柔軟に対応できない懸念がありました。
そこでまずは3の独自アプリ実装から、当社の運用に合わせる形を検討しました。
当社内のID基盤と連携し、シングルサインオンでログインできるようにすることで、個々人の利用デバイス情報と紐づけて、「ユーザーが自分の端末状態をブラウザ上で確認できる仕組み」を社内に展開しました。
個人の脆弱性対応時の課題
商用サービスや社内の情報基盤といった重要なシステムでは、管理担当者や担当部門が脆弱性対応を行い、影響範囲や再起動・停止リスクなどを含めた手順を定常運用に組み込んでいるケースが一般的です。
一方で、個人が使用する端末については、OSレベルのアップデートを除き脆弱性対応が後回しになりがちです。これは、管理者側の負荷が高すぎることに加え、ユーザー側も「対応しなければ何が起こるのか」を実感しづらいためです。
利用端末の脆弱性対応をユーザーの責任範囲としたい一方で、ユーザー自身にとっては望まぬ業務量の増加となるため、対応を促すための何らかの仕掛けが必要になります。
ネットワーク的に隔離するなどの強制的手段も検討しましたが、試験導入段階であったため、まずは自発的な対応を促す運用にとどめました。
具体的な実装については伏せますが、脆弱性の放置をユーザー個人の問題ではなくビジネス課題として位置付けることで、今回の対象範囲内では最長でも翌々営業日までに対応を完了できました。
情報の与え方による行動変化
対応を進める中で、ユーザーへの情報提供方法が行動に大きく影響することも分かりました。
当初は脆弱性の「Severity」や詳細情報を提示し、優先度を判断してもらう方針を採っていましたが、これは逆効果でした。
複数の “Critical” が存在すると、どれを優先すべきか判断に迷い、結果的に対応が遅れたり、管理部門への問い合わせが急増したりするケースもありました。
最終的には、「詳細を伝えるよりも明確な指示を出す方が効果的」という結論に至りました。
特に非技術職ユーザーにとっては、脆弱性の内容よりも「更新しなさい」というシンプルな指示が行動につながりやすく、“意識向上よりも実行率” を重視する方針が現実的でした。
また、ユーザー自身に任せたことによって新たな課題も確認できました。セキュリティ管理部門が集中管理しているソフトウェア、自動更新が設定されているソフトウェアなどユーザーが対応する必要があるものとないものが混在することで対応件数も多くなり、ユーザーがアップデートを行えないソフトウェアも報告されることになりました。
同様にアップデートできないケースとして
- ユーザーがローカル管理者権限を有していないために、他ユーザーとしてインストールされているソフトウェアの対応が行えない
- SBOMとしてソフトウェアの部品に脆弱性が確認できているが、ソフトウェア自体の更新版が存在しない
ことが確認できました。
※2の詳細はこちらでもご紹介しています。ぜひ参照ください。
まとめ
半年間の運用を経て、私たちはいくつかの重要な「運用ファクター」が成果を大きく左右することを実感しました。
特に、ユーザーとセキュリティ担当部門の責任分解と、ユーザーにいかに「面倒」と思わせないかが鍵となります。
「クライアント端末」という範囲では、脆弱性対応よりもEDR導入・メールセキュリティ・ユーザー教育など、直接的な脅威対策が優先されがちです。（筆者もそれを優先すべきだと考えます）
そのうえで、Microsoft Defender for Endpoint によってエンドポイントセキュリティを強化できる今、もし低コストで運用できる体制が整っているなら、脆弱性対応にも踏み込む価値があると感じました。
今回の取り組みを通じて得た知見をもとに、ツールの機能を最大限活かしながら、現場に根付く運用を作るという視点で、今後もより効率的かつ効果的な脆弱性管理を模索していきます。
