スポンサード記事: CVEの洪水に溺れ、答えに飢えていませんか? CTEMを試してみましょう

10年か20年前、取締役会の役員たちは「なぜサイバーセキュリティを気にする必要があるのか」と尋ねていました。5年前になると、「ソフトウェアの脆弱性にパッチを当てているか」と質問するようになりました。そして今、彼らはこう問い始めています。「私たちは本当に安全なのか」。最初は単純な「はい」か「いいえ」を求めているだけかもしれませんが、いずれ最も恐ろしい一言を、質問ではなく要求として口にするようになるでしょう。「それを証明してくれ」と。

従来型の脆弱性管理とパッチ適用では、その会話を乗り切ることはできません。だからこそ、比較的新しいアプローチである継続的脅威エクスポージャー管理(CTEM: Continuous Threat Exposure Management)が支持を広げているのです。

脆弱性管理の何が問題なのか

私たちはセキュリティ上の欠陥を共通脆弱性識別子(CVE)で定義し、共通脆弱性評価システム(CVSS)を割り当てることでその深刻度を互いに伝え合っています。

ここには3つの問題があります。CVEが洪水のように押し寄せていること、CVSSスコアが優先順位付けの役に立たないこと、そしてAIがこの状況をさらに悪化させようとしていることです。

CISOたちはCVEの波に溺れています。業界はこれまで数十年をかけ、脆弱性データを大量に生み出すツールと、それを消費するツールを作り続けてきました。しかし、自社の環境において攻撃者がどの脆弱性を悪用し得るかを教えてくれるツールはほとんど存在しません。

CVEの数は年々増え続けており、パッチを当てて放置するという従来型の脆弱性管理はますます立ち行かなくなっていると、Horizon3のプリンシパル・セキュリティ・ストラテジストであるDrew Vanover氏は指摘します。

「Microsoftが最近リリースしたパッチのことを考えてみてください」と同氏は言います。「1回のパッチサイクルで500件を超える修正がありました。これは理解の域を超えています。誰であれ、それらすべてを精査し、優先順位を付け、本当に安全と言える形で展開することなど不可能です」

毎年生成されるCVEの件数は急増を続けており、米国国立標準技術研究所(NIST)の国家脆弱性データベース(NVD)にさらなる負担をかけています。同データベースは何年も前から処理が滞っている状態です。NISTは今年4月にとうとう匙を投げ、事実上CVE破産を宣言しました。

米商務省は今年5月に発表した報告書の中で、2つ目の問題、つまり現行の深刻度指標が役に立たないという点を強調しています。同報告書はNVDの管理が不十分だと痛烈に批判しただけでなく、CVSSスコアの付与そのものをやめるべきだとも提言しました。これらのスコアは極めて主観的なものだというのがその理由です。

スコアはまた、その脆弱性がある組織のインフラの中で実際に何を行っているシステムに存在するかにも左右されます。あるサンドボックス化された1台のシステムしか関与していない製品において、緊急(クリティカル)評価は本当に重要でしょうか。あるいは、一見無害に見える3つの脆弱性を攻撃者が連鎖させることで、経営幹部が懸念すべき損害を引き起こす可能性はないでしょうか。

AIが脆弱性管理をさらに困難にする

これらの複雑な問題はただでさえ頭痛の種ですが、AIはそれを本格的な偏頭痛へと変えようとしています。ClaudeのMythosのような最先端のLLMは、すでにゼロデイ脆弱性を大量に発見し始めており、CVEの氾濫を予告しています。

AIは単に大量のバグを見つけるだけではありません。人間よりもはるかに速いスピードでエクスプロイトを作成し、武器化することもできます。だからこそ、組織が正しいバグに迅速にパッチを当てることが一段と重要になっているのです。Cloud Security Allianceは現在、攻撃者がAIを使ってより速く脆弱性を発見・悪用する(パッチがリリースされる前にすら悪用されるケースが増えている)一方で、組織側のパッチ適用にはより時間がかかるという、非対称な脆弱性サイクルが生まれていると説明しています。

CTEMとは何か

何かを変えなければなりません。Gartnerは2023年にこのことに気づき、CTEMを主要なサイバーセキュリティトレンドとして挙げました。これは脆弱性を適切に選別することで、状況を常に把握し続ける手法です。それを実現するには、セキュリティ上の欠陥が持つ技術的な意味合いだけでなく、それが自社のビジネスにとって実際に何を意味するのかを理解する必要があります。

Gartnerは、CTEMを構成する5つのステップを示しています。

● スコーピング(範囲設定) ビジネスへの影響が大きい資産を特定し、優先順位を付けます。

● ディスカバリー(発見) それらの資産が抱える弱点を詳しく分析し、どのようにエクスポージャー(露出)が生じているかを把握します。

● プライオリタイゼーション(優先順位付け) 実際のビジネスリスクに基づき、それらのエクスポージャーに順位を付けます。

● バリデーション(検証) 脆弱性を実際に試し、悪用可能かどうかを確認します。

● モビライゼーション(動員) 適切なインシデント対応計画のもとで修正します。

自動化された侵入テストが脆弱性管理にどう役立つか

このアプローチは、組織にとって本当に重要なセキュリティ上の欠陥を的確に捉えることを約束していますが、その分、従来型の脆弱性管理よりも複雑でもあります。そこには自動化が必要であり、それこそがHorizon3が提供するNodeZeroの役割です。

システムの範囲設定は、今日ではもはやコモディティ化した作業です。ディスカバリーも同様です。Horizon3はそれらをパートナー企業に任せることで、CTEMフレームワークのうち顧客がまだ容易には解決できない部分、すなわちビジネスへの影響度に基づく優先順位付けと動員に注力しています。

NodeZeroは組織のインフラ全体にわたって侵入テストを実行し、防御担当者が追跡できる証拠とともに、悪用可能な攻撃経路を記録します。その出力結果は、いわば籾殻からふるい分けられた麦のようなもので、セキュリティチームや開発者が集中して取り組むべき、絞り込まれたエクスポージャーのリストです。

ここで印象的なのは、連鎖的な攻撃の挙動です。NodeZeroは弱点を探り、それを悪用し、そこで見つけた結果に基づいて次の手に転じます。つまり、実際の攻撃者が攻撃を状況に応じて調整し、システム間を横方向に移動していくのと同じように、環境に適応しながら攻撃を拡張していくのです。

このアプローチは、汎用的なLLMではなく、決定論的な機械学習エキスパートシステムに基づいていると、Vanover氏は説明します。「良い例えは医療の世界を考えることです」と同氏は言います。「一般的なLLMを何にでも対応させようとするのは、いわば総合診療医のようなものです。彼らは広く浅く知ってはいますが、専門家ではありません。そして、そこからハルシネーション(幻覚)や当て推量、見落としが生まれてしまうのです」

同社が生成AIを使うのは、特定のタスクに限られます。例えば、2ペタバイトのS3ブロブを解析して機密データを探したり、価値の高い認証情報を特定したりする用途で、その際もデータはAWS Bedrockを介して顧客の境界内にとどまります。同社が行わないのは、顧客のシステム内で野放しの不正なエージェントを次々と生み出すようなことです。

Vanover氏は、ここでの価値は、システムを支える重要なセキュリティ上のバグを実際に叩き潰したことを証明できる点にあると言います。「私たちが何かを悪用できると言うなら、それは実際にやってみせたからです。プラットフォーム上でその証拠をお見せします」と同氏は述べています。

次のステップは、対処後のエクスプロイトを再テストすることでループを閉じることです。NodeZeroがもはやその攻撃経路をたどれなくなった時点で、チームはチケットをクローズできます。これは「修正済み」というものを検証可能な形で定義するものであり、CFOにも読めるリスク指標へと変換できるものです。

Horizon3はまた、CTEMに関わる重い作業をすべて一手に引き受ける単一の製品によって、顧客が抱えるツールの乱立問題を解決したいと考えています。エンタープライズ向けCTEMプログラムにありがちな失敗は、複数のベンダーが積み重なり、その間の引き継ぎの隙間が、まさにこのフレームワークが排除しようとしていた死角そのものを生み出してしまうことです。すべてを1つのサービスの下に置けば、そうした問題は解消されます。

自動化された侵入テストは安全なのか

CISOの中には、自律型の侵入テストシステムを本番環境で自由に動かすことに神経質になる人もいるでしょう。稼働中のプロセスを壊しかねないもののように聞こえるからです。それなら、デジタルツインを相手にテストすればいいのではないでしょうか。

本番環境でのテストこそが、バグを見つける最も安全な方法だとVanover氏は反論します。なぜなら、特に短い開発スプリントと自動化されたコード変更に駆動されるアジャイルな世界では、環境は頻繁に変化するからです。ユーザーがパスワードを変更したり、チームが機能の一部をプッシュしたりすれば、デジタルツインのシステムはもはや現実を反映しなくなります。

そこでHorizon3は、代わりに強固な本番環境向けガードレールに注力しています。

「システムを実際に人質に取ってみせなくても、それが可能だと証明することはできます」とVanover氏は言います。「システムに侵入し、リモートアクセスツールをインストールし、ファイルを作成し、そのファイルを暗号化し、そして削除する。それができれば、私はあなたのシステムを人質に取れることをすでに証明したことになります」

同氏によれば、Horizon3はこれまで顧客組織全体で32万件以上の本番環境テストを実施してきたといいます。その中には、自社システム内で何が動き回っているかに特に神経を尖らせている組織、例えばNSAや、世界最大級の医療記録処理事業者、さらには大手医療プロバイダー数社も含まれています。

CTEMはどこから始めればよいのか

GartnerのCTEMフレームワークは強力ですが、CISOにとっては気後れするものかもしれません。Vanover氏は、まず1つのことを選び、それをしっかりやり遂げることから始めるようアドバイスしています。

「1年でCTEMを実装できる組織などありません。それは失敗のもとです」と同氏は言います。「分解して考えてください。まずは手を付けやすいところを探すのです」。古くなっているかもしれない資産インベントリを盲目的に信頼するのではなく、実際にどのシステムに到達可能なのかを確認するところから始めるのも一つの手でしょう。

適用したパッチの件数といった指標では、取締役会をもう長くは満足させられません。だからこそ、CTEMを取り入れようという競争が始まっているのです。そうした指標は、悪用可能な攻撃対象領域がどれだけ残っているかを示してはくれません。CTEMのループを回す目的は、報告の軸を「活動量」から「成果」へと移し、取締役会に対して、悪用可能な経路の減少と被害範囲の縮小を実際に示せるようにすることにあります。

新たなゴールは、セキュリティ対策に費用を払ったという事実ではなく、その対策が実際に機能したということを証明することなのです。

CTEMを実際に運用に乗せたいが、どこから手を付ければよいか分からないという方は、Horizon3によるこちらのホワイトペーパーをご覧ください

翻訳元: https://www.theregister.com/security/2026/09/03/sponsored-drowning-in-cves-and-thirsty-for-answers-try-ctem/5293906

本記事は theregister.com の記事を翻訳・要約したものです。