検証がループを完結させる

攻撃対象領域を発見するだけでは仕事は半分にすぎません。

多くの組織は、リスク低減は修復によって成し遂げられると考えています。

それは無理もない思い込みです。脆弱性が特定され、パッチが適用され、スキャナーの再チェックで問題なしと出れば、チケットはクローズされます。ワークフローは完了し、指標は改善し、問題は解決したものとみなされます。

しかし問題は、攻撃者は修復ワークフローなど気にしていないということです。攻撃者が気にするのは結果だけです。

スキャナーがもはやその脆弱性を報告しなくなったとしても、攻撃者が同じ攻撃経路や過剰な権限、あるいはそもそも対処されなかった別の弱点を通じて同じ目的を達成できるのであれば、そうした修復活動には意味がありません。

多くのセキュリティプログラムは「作業が完了したかどうか」を測定していますが、「実際にリスクが低減したかどうか」までは必ずしも測定していません。

チームを窮地に追い込む思い込み

サイバーセキュリティ業界は、平均修復時間、パッチ適用率、SLA達成率、チケットクローズ率の測定については非常に得意になりました。これらの指標には価値がありますが、どれも攻撃者が投げかけている問いには答えていません。

「それでも侵入できるか?」

実際のところ、そこにこそ思い込みの落とし穴があります。修復活動とリスク低減はしばしば同一のものとして扱われますが、両者はまったく異なる結果を測定しています。一方は作業が実施されたかどうかを測定し、もう一方は攻撃を可能にしていた条件が今も存在しているかどうかを測定するものです。

当社が最近実施した調査では、セキュリティリーダーおよび実務者750名から一貫したパターンが浮かび上がりました。パッチ適用後にリスクが実際に修復されたことをテストで確認していると回答したCISOは、わずか30%にとどまりました。それに対し、パッチ適用後に脆弱性スキャナーで再スキャンするだけという組織は半数近くに上りました。

セキュリティチームは日々懸命に働き、脆弱性を修復し、対策を導入し、チケットをクローズしています。問題は検証にあります。パッチによって脆弱性は取り除かれ、再スキャンによってパッチが適用されたことは確認できても、そのどちらも攻撃者がもはや成功できないことの証明にはなりません。

セキュリティチームが評価されるべきなのは、作業を完了したことではなく、リスクを低減したことです。そして、リスクが実際に低減したかどうかを知る唯一の方法は、それを検証することです。

検証が議論を変える

ほとんどのセキュリティチームは、脆弱性を見つけること自体には苦労していません。苦労しているのは、自分たちの修復対応が実際に効果を上げたことを検証することです。

それこそが、18拠点で事業を展開するあるグローバル投資会社が直面していた課題でした。同社はすでに脆弱性データ、セキュリティ評価、修復ワークフローを備えていました。足りなかったのは確信でした。どの弱点が実際のリスクを表しているのか、修復策によって本当に攻撃対象領域が縮小しているのか、そして本来もっと早く発見できたはずの問題に不意打ちされることをどう避けるのか——同社はそれを理解したいと考えていました。

初期の内部侵入テスト(ペンテスト)では85件の弱点が発見されました。この数字自体は、それほど衝撃的なものではありませんでした。真のリスクが明らかになったのは、これらの欠陥が組み合わさることで251件もの被害——ドメイン侵害、認証情報の窃取、ホスト侵害、ランサムウェアへの露出、機密データの漏えい——を引き起こし得ることが判明した時でした。弱点そのものは話の一部にすぎません。真のリスクが表面化したのは、攻撃者が実際に行うのと同じ手口でそれらの弱点が連鎖させられた時だったのです。

多くの組織はそこで手を止めてしまいますが、このチームは再テストを実施しました。その決断によって、議論は「修復活動」から「測定可能なリスク低減」へと変わりました。同じ範囲で行った追跡ペンテストでは、被害件数が251件からゼロへと減少していたことが示されました。窃取された認証情報は52件からゼロに、侵害されたホストは67件からゼロに、解読されたActive Directoryのパスワードは40件からゼロにまで減少していたのです。

それこそが検証の姿です。

クローズされたチケットではなく、攻撃者が狙っていた結果がもはや達成不可能であることを示す具体的な証拠こそが重要なのです。

検証がなかなか実現しない理由

当社の調査では、2026年に向けた最大のサイバーセキュリティ上の課題として「修復の検証」を挙げた実務者が22%、「測定可能なリスク低減の証明」を挙げた実務者が21%に上りました。両者はいずれも、予算の制約や人材不足を上回る順位でした。

このギャップが解消されないのは、確認作業が修復そのものよりも難しいからです。パッチを適用するのは、単発の行為にすぎません。しかし、攻撃者がもはや同じ目的を達成できないことを証明するのは、それよりもずっと困難です。それには、スキャンレポートに脆弱性が表示されなくなったからといって攻撃経路が消えたと単に思い込むのではなく、実際にテストしてその攻撃経路が消滅したことを検証する作業が必要になります。

そこで多くの組織は、代替指標に頼ってしまいます。脆弱性スキャナーが「該当バージョンはもう存在しない」と報告する、チケットがクローズされる、ダッシュボード上の指標が改善して見える——といった具合です。これらのシグナルは有用ではあるものの、あくまで「活動」を示す指標にすぎません。「攻撃対象領域が実際に縮小した」ことの証明にはならないのです。

このギャップが重要な理由は、攻撃者が成功を測る基準は「バージョン番号が変わったことの確認」ではなく「目的の達成」だからです。防御側にも同じ基準が必要です。

それこそが、修復と検証の違いです。

成熟したセキュリティプログラムがやっていること

最も大きな進歩を遂げている組織は、必ずしも最も多くの脆弱性を発見している組織ではありません。自分たちの対応がリスクを実際に低減したかどうかを証明することに、徹底してこだわっている組織です。

この視点の転換は、議論そのものを変えます。「パッチは当てたか?」ではなく、「攻撃者はそれでも同じ目的を達成できるか?」を問うようになるのです。

成功をチケットのクローズ件数で測るのではなく、攻撃者が狙う結果がまだ実現可能かどうかで測るようになります。

この考え方は、当社の「Pentest Wednesday™」に関する数多くの事例からも見て取れます。金融サービス業界の組織は、修復効果が時間の経過とともに維持されているという確信を経営層が持てるよう、継続的な検証を業務プロセスに組み込みました。製造業や防衛産業基盤の組織も、環境が変化する中で攻撃経路が閉じたままであることを確認するため、繰り返しテストを活用しました。

これらに共通するのは、業界や技術ではなく、修復した後も歩みを止めない姿勢です。

• 攻撃対象領域を検証する。
• 攻撃対象領域を修復する。
• 攻撃対象領域が解消されたことを検証する。
• これを繰り返す。

成熟した組織は、ネットワークが変化する中でも修復の効果が維持されていることを経営層が信頼できるよう、継続的な検証を業務プロセスに組み込んでいます。

未来は検証にあり

サイバーセキュリティ業界は、再び急速な変化の時期を迎えています。AIによって、優先順位付け、修復、報告、分析のスピードが加速しています。セキュリティチームはこれまで以上に速く脆弱性を発見し、検出結果を処理し、多くのワークフローを自動化できるようになるでしょう。

攻撃対象領域を検証し、それを修復することは不可欠ですが、そのどちらもループを完結させるものではありません。ループを完結させるのは検証です。確信だけでは攻撃者を止めることはできませんが、繰り返し行われる検証はそれを可能にします。

デモを予約する