デプロイの容易さと継続的検証の効果にも、組織側が驚くこととなりました。
多くのセキュリティチームは、データ不足に悩んでいるわけではありません。むしろ悩んでいるのは、確信の持てなさです。
脆弱性スキャナーや年次のペネトレーションテスト、コンプライアンス評価は、何千件もの検出結果を生み出すことがあります。それでも、「実際にどのリスクが重要なのか」というシンプルな問いに答えられないケースが少なくありません。
18拠点で事業を展開するあるグローバル投資会社にとって、この問いはますます重要性を増していました。少人数のセキュリティエンジニアリングチームは、拡大し続ける環境を守りながら、インフラプロジェクトやID管理、ユーザーサポートなど、現代の企業を保護するうえで欠かせない無数の業務を同時にこなさなければなりませんでした。
このチームが苦しんでいたのは検出結果を生み出すことではなく、どの検出結果が本当のリスクを表しているのか、修復対応がきちんと機能しているのか、そして本来もっと早く発見されるべきだった脆弱性で経営陣を驚かせることがないようにするにはどうすればよいか、を見極めることでした。
この課題への取り組みが、時点ベースのテストから継続的検証への移行につながりました。
成果の概要
- 同一スコープの内部ペネトレーションテスト（ペンテスト）における影響件数を251件から0件に削減
- 侵害された認証情報の件数を52件から0件に削減
- 侵害されたホスト数を67件から0件に削減
- クラックされたActive Directoryパスワードの件数を40件から0件に削減
- 段階的な展開戦略により、18拠点全体に継続的検証を拡大
- 少人数のセキュリティチームでも、大きな運用負荷をかけずに継続的なリスク検証を実現
影響
このチームは、完璧な結果を期待していたわけではありません。どんな環境にも弱点は存在するものであり、経験豊富なセキュリティ担当者であれば、内部ペンテストの結果が「クリーン」で返ってくるとは考えないものです。
チームが驚いたのは、攻撃者がひとたび足場を築いてしまえば、それらの弱点をいかに効果的に連鎖させられるかという点でした。
この会社が初期に実施した内部ペンテストの一つでは、85件の弱点が特定されました。この数字自体は、多くのセキュリティチームにとって特に目を引くものではなかったかもしれません。本当の懸念は弱点そのものではなく、それらの弱点が何を可能にしてしまうかにありました。
NodeZero®の分析により、これらの弱点がドメイン侵害、機密データの漏えい、ランサムウェアへの露出、ホスト侵害、ドメインユーザーの侵害、認証情報の侵害を含む251件もの影響につながる可能性があることが判明しました。
この違いが重要な理由は、攻撃者が弱点を単独で悪用することはないからです。攻撃者は弱点や設定ミス、認証情報を組み合わせて連鎖させ、目的を達成します。単体では優先度が低く見える検出結果でも、他の弱点と組み合わさることで、はるかに深刻な事態へとつながる経路の一部になり得るのです。
図1. 初期の内部ペンテストでは85件の弱点が特定され、それらがドメイン侵害、ランサムウェアへの露出、機密データの漏えい、ホスト侵害を含む251件の影響につながりました。
この組織のシニアセキュリティエンジニアは次のように説明しています。「NodeZeroの影響セクションは、まさに現実のシナリオで何が起こり得るかを示す純然たる証拠です」
理論上のリスクから実証された影響へと視点が移ったことで、チームの修復対応への取り組み方も変わりました。弱点を特定するだけの議論から、それがもたらしうるビジネスへの影響を理解するための議論へと転換したのです。
背景
多くの組織と同様、この会社もすでにセキュリティテストへの投資を行っていました。課題は別のツールを見つけることではなく、インフラプロジェクトやID管理、ユーザーサポートなど、すでに数え切れないほどの業務を抱える少人数のセキュリティチームにこれ以上の負担をかけることなく、事業全体に拡張できる手法を見つけることでした。
シニアセキュリティエンジニアは次のように述べています。「NodeZeroが占める割合は、私の業務全体のせいぜい5%程度です。私は無数の案件、無数のプロジェクト、無数の責務に追われていますから」
この現実があったからこそ、運用のシンプルさは単なる利便性ではなく、必須要件となりました。
このチームには、効果的に稼働させ続けるために大規模なインフラと継続的なメンテナンスを必要とするセキュリティテストプラットフォームを使ってきた経験がありました。複数の優先事項をやりくりする少人数のチームにとって、こうした運用負荷は無視できないものでした。NodeZeroはこれとは異なるモデルを提供しました。このプラットフォームは導入がシンプルで運用も容易であり、複雑なハードウェアインフラの管理にリソースを割くことなく、チームはすぐにテストを開始できました。
この導入のしやすさが特に重要な意味を持ったのは、チームが単なる概念実証（PoC）の実施には関心がなく、事業とともに拡張できる持続可能なプログラムを構築したいと考えていたためです。
こちらをクリックすると、この組織が直面した障害とその対策について、続きをお読みいただけます。
成果を検証することの必要性
目的は、あらゆる弱点をゼロにすることでは決してありませんでした。最も重要なリスクをめぐる不確実性をなくすことこそが目的だったのです。
これこそが、活動量を測定することと成果を検証することの違いです。
