脆弱性管理が回らないのはなぜか｜ツールを入れる前に決める4つのこと

「脆弱性の情報は毎週のように届くのですが、そのたびに担当者がその場で判断していて、正直まわっていません」——Microsoft 365を導入済みの企業から、そうした相談をいただくことがあります。

Defenderも動いていて、管理画面には脆弱性が並んでいる。それでも対応が属人的なまま、という状態はよく見かけます。

この記事では、脆弱性管理を仕組みとして回すための考え方を整理します。製品の設定手順ではなく、着手する前に決めておくことに絞ります。

この記事でわかること

• 脆弱性管理が属人的なまま止まる理由

• 把握・判断・適用・報告の4工程と、ツールが支援する範囲

• 一覧に出ていても評価されていないものへの備え

※製品の機能・名称・対応範囲は変更されることがあります。実際の検討時には、公式ドキュメントで最新の情報を確認してください。

ツールを入れても回らないのはなぜか

よくあるのは、こういう状態です。Defenderが脆弱性を検出して、深刻度つきで一覧に出している。それでも、その先が進まない。

理由は、把握と判断が別の仕事だからです。

把握は、条件さえ決めれば機械が繰り返せます。どの端末に何が入っていて、どの脆弱性が該当するか。ツールが最も力を発揮するところです。

判断は違います。自社の業務とリスクを突き合わせる仕事だからです。

近年のツールは、判断も支援してくれます。脅威の情報や、その資産がどれだけ外部に晒されているかをもとに、優先度を提示してくれる。ここは年々賢くなっています。

ただ、その業務を止めてよいのか。いつまでに当てるのか。当てないと決めた場合、誰が責任を持つのか。 このあたりは、自社にしか決められません。

基準が決まっていなければ、情報が届くたびに担当者が一人で業務影響を想像し、関係部署に聞いて回ることになります。属人的になるのは、担当者の問題ではありません。基準が決まっていないという、設計の問題です。

ここまでは導入済みの場合の話ですが、その手前で止まる形もあります。ツールを入れるとき、期待が大きいほど、最初から対象範囲を広げたくなります。ただ範囲を広げると、そのぶん決めることが増えます。この機器の管理者は誰か。何に使われているのか。どういう状態を検知させたいのか。判断の基準は誰が持つのか。ひとつずつ確認しているうちに検討が長引き、導入そのものが止まってしまう。

回らないのも、始まらないのも、原因は同じです。決めるべきことが決まっていない。違いは、それが導入のあとに出るか、前に出るかだけです。

だから、工程を分けて、どこを自分たちで決めるのかをはっきりさせる。そして、全部を一度に対象にしようとしない。この2つが出発点になります。

4つの工程と、ツールが支援する範囲

脆弱性管理を、把握・判断・適用・報告の4つに分けます。

1. 把握

何が、どの資産に、どれだけあるかを知る工程です。ここには、性質の違う2つの作業が含まれます。

ひとつは脆弱性の把握で、Microsoft Defender の脆弱性の管理が担います。もうひとつは不足している更新の評価で、Azure上のサーバについては Azure Update Manager が、更新プログラムの評価と適用を担います。

この2つは別のものです。Azure Update Managerは更新の過不足を見るサービスであって、脆弱性を検知する製品ではありません。混ぜて理解していると、どちらかに穴が空きます。

2. 判断

どれを、いつまでに、どうするかを決める工程です。

ツールは優先度づけを支援します。しかし決めるのは自社です。業務を止められるか、期限をいつにするか、当てない判断を誰が負うか。

もっとも詰まりやすく、もっとも設計されていないのがこの工程です。次の章で扱います。

3. 適用

実際に当てる工程です。

Intune が Windows Update や、管理対象アプリの更新・再配布を担います。Azure上のサーバは Azure Update Manager です。

Defenderで見つけた脆弱性を、Intune側の対応タスクとして引き渡す連携もあります。ただし、依頼を作成しただけで自動的に修復されるわけではありません。 その先は管理者の作業です。

そして、当てられない対象が必ず残ります。これは後ほど扱います。

4. 報告

誰に、何を、どの頻度で出すかです。

ツールでレポートは出せます。ただ、何を報告すべきかは決めておく必要があります。出せる数字をそのまま出しても、受け取る側は判断できません。

表の3列目が、この記事で言いたいことです。ツールの比較ではなく、どこを自分たちで決めるのかの整理として使ってください。

判断の工程で決める4つのこと

1. 優先度の基準

ツールが出す優先度は出発点です。そこに、その資産が自社で何に使われているかを重ねます。同じ深刻度でも、外部に公開しているサーバと、閉じたネットワークの検証機では意味が違います。スコアの高い順に並べても、着手の順番にはなりません。

2. 期限

深刻度ごとに、いつまでに適用するかを決めます。期限がないと、優先度をつけても動きません。

具体的な日数は自社で決めるものです。業界の基準や取引先からの要求がある場合は、そちらに合わせます。

3. 誰が決めるか

情報システム部門だけでは決められないものがあります。業務システムは、止められる時間を業務部門と決める必要があります。

決める人が決まっていないと、重要なものほど止まります。 影響が大きいものほど、情シスの一存では動かせないからです。

4. 適用しない判断を、どう残すか

ここが最も抜けます。

すぐに当てられないもの、当てないと決めたものを記録します。最低限、理由・責任者・見直し日の3つを残します。この3つがないものは、記録ではなく放置です。

記録がないと、同じ脆弱性を毎月検討し直し、毎月同じ結論に達して、また残ります。

例外を「残していい」と決めることが、仕組みを回す条件です。すべてをゼロにする前提で設計すると、現実と合わなくなった時点で、仕組みごと使われなくなります。

ここでもうひとつ、責任者を決めただけでは足りない、という話があります。

管理対象に含めたものの、その機器の管理者が業務側の担当者で、インフラ側の判断材料を持っていない。毎回アラートは届くけれど、何を見て何をすべきかが分からない。結果として、すべてが「確認済・保留」のまま積み上がっていきます。業務アプリケーションが載ったサーバで、よく見かける状態です。

そして放置が続くと、ツールを入れた意義のほうを問われます。

対処は、何を確認し、何を判断すべきかのガイドを用意して配ることです。責任者を割り当てる作業と、その人が判断できる状態にする作業は、別物だと考えておきます。

ツールだけでは一律にカバーできない範囲

まず、前提を更新しておきます。Defender の脆弱性の管理は、対応範囲が広がっています。サードパーティ製のソフトウェアも評価の対象になりますし、認証済みのネットワークスキャンを使えば、ルーターやスイッチ、ファイアウォールなども評価できます。デバイス検出では、プリンターやカメラのような機器も見つかります。「機器はツールの対象外」という前提は、もう正しくありません。

本当に注意すべきなのは、別のところです。

危ないのは、対象外だと分かっているものではありません。一覧には出ているのに、脆弱性の評価がされていないものです。

対象外だと分かっていれば、台帳で管理する、ベンダーに確認するといった別の手段を考えられます。問題は、画面に出ているので対応済みに見えてしまうことです。

具体的には、こうした範囲が残ります。

• 脆弱性の情報が十分に紐づかず、評価の対象にならないソフトウェア（インベントリには表示されていても）

• ベンダーが独自に管理していて、こちらの判断では当てられないミドルウェア

• 長期間接続されていない端末、持ち出したまま戻らない端末

• 管理の対象になっていないセグメントのネットワーク機器

• ファームウェアの更新がベンダー作業に依存する機器

確認の方法はひとつです。ソフトウェアインベントリに出ている対象と、脆弱性の評価がされている対象を突き合わせる。 その差分が、別の手段で見るべき範囲です。

そしてもうひとつ、管理の対象にするときに確認しておきたいのが、保守契約です。

ミドルウェアやファームウェアの更新が必要だとアラートに出ていても、どこに依頼すればよいのか分からない。保守ベンダーに確認すると、保守の対象外で有償対応になる。こうした話は珍しくありません。

その環境を持ち続け、使い続けるのであれば、塩漬けのまま置いておくことはリスクです。ただし、一概に最新化が正解とも言い切れません。費用がかかる問題だからです。

つまりこれは、前章で書いた「適用しない判断」そのものになります。当てない理由と、責任者と、見直しの時期を残す。管理の対象に含めるタイミングは、その整理をする良い機会でもあります。

すべてを同じ仕組みに載せる必要はありません。載っていないものがどれなのか、分かっていることが重要です。

まとめ

脆弱性管理が回らないのは、ツールが足りないからではなく、判断の基準が決まっていないからです。

把握・判断・適用・報告の4つに分け、ツールが支援する範囲と、自社で決める範囲を分ける。判断で決めるのは、優先度の基準、期限、決める人、そして適用しない判断の残し方です。そして、一覧に出ていても評価されていないものがある、という前提を置いておく。

まずは、直近1か月に届いた脆弱性情報を3件挙げて、それぞれ「誰が、いつ、何を基準に判断したか」を書き出してみてください。書けないものが、仕組みにすべき部分です。