「パッチパンデミック」で現場が阿鼻叫喚 フロンティアAI時代の脆弱性管理“新常識”：「リスクが低いから後回し」は通用しない（2/2 ページ）

[田渕聖人，＠IT]

脆弱性対応のドリームチームはこれだ

　脆弱性対応を高速化するだけでは限界がある。そこで重要になるのが、経営層から現場までが共通の認識を持って迅速に意思決定できる体制だ。

　経営層は事業継続を重視し、CISO（最高情報セキュリティ責任者）はリスク低減を求め、IT部門はシステムの安定運用を優先する。事業部門には業務停止を避けたい事情があり、法務や広報には別の判断基準がある。

　こうした立場の違いを平時から調整しておかなければ、緊急時の意思決定は遅れる。そこで藤井氏が提案するのが、経営層の下に部門横断の「SWATチーム」を構築する考え方だ。

　SWATチームには経営層やIT・セキュリティ部門、事業部門、リスク管理、法務、広報、海外子会社などを巻き込む。パッチ対応やインシデント対応、脆弱性評価、サイバーBCP（事業継続計画）、サードパーティー対応などについて、部門をまたいで迅速に判断できる体制を作る。

部門横断の「SWATチーム」のイメージ（提供：アクセンチュア）

　藤井氏は「緊急時に誰が判断するのかを、有事ではじめて考えるのでは遅い。また、自社が直接管理する対象そのものを減らすことも重要だ」と話す。

　オンプレミスでは、OSやミドルウェア、アプリケーションなど複数のレイヤーについて、自社で脆弱性を把握し、パッチや設定変更を管理する必要がある。一方、PaaSやSaaSを活用すれば、サービスによって範囲は異なるが、インフラやミドルウェアなど自社が直接管理する領域を縮小できる。

　「オンプレミスのままでは全てのレイヤーのパッチを自前で当てる必要があり、予算と労力を食いつぶす。PaaSやSaaSなどのクラウド環境に移行し、ベンダー側に責任分界点を移すことで自社の対応面積を劇的に縮小すべきだ」（藤井氏）

　ただし、クラウド移行によってセキュリティ責任が全てクラウド事業者に移るわけではない。サービスによって責任範囲は異なり、ID管理やアクセス権限、設定、データなど、利用企業側に残る責任もある。

　本質は「クラウドに移行すれば安全になる」ということではない。クラウドサービスを活用し、自社が直接管理する対象を減らすことで、限られた人材や予算をより重要な領域に振り向ける。クラウドシフトは、単なるIT基盤の近代化ではなく、セキュリティ運用の対象範囲を見直す手段としても捉える必要がある。

攻撃される前に「あえて」サービスを止める？

　どれだけ防御を強化しても、公式パッチが提供されないレガシーシステム、自社開発のソースコード、サポート終了製品（EoL）など、リスクを完全には取り除けない領域は残る。

　AIを活用したソースコード解析や修正案の作成は、こうした環境の改善を支援する手段になり得る。一方、AIが生成した修正をそのまま本番環境に適用できるとは限らない。業務への影響や修正の妥当性、安全性を人間が検証する必要があるからだ。

　仮想パッチやネットワーク隔離などの代替策を講じても、リスクを十分に低減できない場合もある。そこで重要になるのが、サイバーBCPの考え方を「攻撃後の復旧」だけに限定しないことだ。

　従来のサイバーBCPでは、サイバー攻撃によってシステムが停止・侵害された場合に、被害を抑え、事業を継続し、システムを復旧するための準備が重要になる。

　しかし重大な脆弱性を抱えたシステムについて「攻撃を受けてから対応する」という選択肢が現実的でない場合もある。そのとき必要になるのが、攻撃を受ける前に、あえてシステムやサービスを停止する判断だ。

従来のサイバーBCPと異なる、攻撃前の能動的停止を検討する（提供：アクセンチュア）

　重大な脆弱性が発見されたがパッチ適用まで時間がかかる場合に、対象システムへの外部アクセスを遮断する。あるいは、事業上許容できる範囲でサービスを一時停止し、安全性を確認した上で段階的に復旧する。

　ポイントは、こうした判断をインシデント発生後に初めて決定しないことだ。誰が停止を決めるのか。どの条件を満たした場合に停止するのか。どの業務を止め、どこまでなら継続できるのか。復旧の判断基準は何か。これらを経営層と事業部門の間で事前に合意し、実機やシミュレーションを使って訓練する。サイバーBCPを「攻撃後の復旧」だけでなく、攻撃前のリスク回避まで含む仕組みに拡張することが、攻撃の時間軸が短くなる時代には大切になるという。

AIの性能で勝負しない　押さえるべきはやはり「基本」

　フロンティア時代のサイバー攻撃を考える際、「AI対AI」という構図を想像しがちだ。しかし現時点で重要なのは、完全自律型AI同士が人間の関与なしに戦う世界ではないと藤井氏は指摘する。

　「現実には、AIを使う人間の攻撃者と、AIを使う人間の防御者との戦いと捉えた方が適切だ。開発現場では、『Claude Code』などのコーディングエージェントを活用したコード解析も可能になっている。AIを使って継続的にコードを検査し、開発プロセスにセキュリティチェックを組み込むことも選択肢になる」（藤井氏）

　ビルドやテストを実施するCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインに大規模言語モデル（LLM）を活用したコード解析を組み込み、本番リリース前に問題を検出するDevSecOpsの高度化も考えられる。

　ただし、ソースコードの欠陥を検出する静的解析（SAST）で問題が見つかったとしても、それが直ちに実環境での攻撃成立や事業インパクトにつながるとは限らない。アプリケーションの構成や認証、ネットワーク、権限、他システムとの接続などによって、実際の攻撃可能性は変わる。

　そのため動的アプリケーション・セキュリティ・テスト（DAST）やAIを活用したペネトレーションテスト、レッドチーム演習などを組み合わせ、「実際の攻撃経路をたどって到達できるか」まで多角的に検証することが重要になる。

　ここで防御側が持つ武器が「情報」だ。

　攻撃者が外部から取得できるのは、公開情報や外部から観測可能なサービス、設定など、限定された情報である。一方、防御側は自社の資産情報、ネットワーク構成、認証・アクセスログ、EDRなどの監視情報、アプリケーションの設計情報など、外部からは取得できない内部情報を持っている。

　もちろん、全ての企業がこうした情報を完全に整理できているわけではない。だからこそ、前述した資産の可視化が重要になる。自社環境の情報をAIから参照可能な形で統合できれば、防御側は外部から得られる断片的な情報しか持たない攻撃者に対して、より多くのコンテキストを持って判断できる。

　AIの性能だけで防御力が決まるわけではない。AIにどれだけ正確な自社環境の情報を与えられるかもまた、フロンティアAI時代のセキュリティを左右する重要な要素だ。

AIを入れる前にITをシンプルにする

　フロンティアAI時代のセキュリティ対策は一朝一夕では完成しない。藤井氏は以下のように時間軸を分けて進める必要があると提言する。

時間軸	実行期間	重点取り組み
即時	0〜1カ月	IT資産の可視化、パッチバックログの把握・解消、緊急対応体制の整備、責任分界点の確認
短期	1〜6カ月	継続的な脆弱性管理への移行、攻撃対象領域の縮小、アプリ・クラウド環境の診断と修正、サイバーBCPの整備
中長期	6カ月〜2年	AIを活用したセキュリティ運用、AI Red Teaming、DevSecOpsの標準化、サプライチェーンリスク管理
抜本的変革	2年〜	IT・セキュリティアーキテクチャの刷新、AI駆動型運用モデルの導入、リスクモデルとガバナンスの改革

　足元の脆弱性対応を止めることはできない。しかし、それだけにリソースを使い続ければ、将来も同じ問題を繰り返すことになる。そこでクラウドサービスの活用やシステムの標準化などによって、自社が直接管理する範囲を縮小し、運用負荷を減らす。その上で、捻出した人材や予算を、攻撃経路の分析やAIを活用した継続的なセキュリティ改善へ振り向ける。こうした循環を作ることが重要になる。

　最終的に問われるのは、AIの性能だけではない。複雑なレガシー環境、拠点や子会社ごとに異なるルール、不透明なネットワーク接続、重複したセキュリティ製品――。こうした複雑性を残したままAIを導入しても、AIが参照すべき情報そのものが不正確であれば、期待する効果は得られない。

　藤井氏は最後に、こうした環境の問題を次のように指摘した。

　「壊れたサーバの構成や接続先を聞いても『昔からつながっていて分からない』という複雑で混沌とした環境では、最新のAI製品を入れても防御にムラができる。ポリシーやガイドラインをグローバルで徹底的に標準化し、IT環境そのものをAIが守りやすい形へと作り変えることこそが、AIが真価を発揮し、人間も守りやすくなる最強のレジリエンスにつながる」（藤井氏）

　フロンティアAIが変えるのは、攻撃の手法だけではない。これまでのセキュリティは「重大な脆弱性を見つけ、パッチを当て、アラートを処理する」という個別対応の積み重ねだった。

　これからは、自社環境全体を把握し、攻撃経路を分析し、必要なら攻撃を受ける前にシステムを止める。そしてAIにルーティン作業を任せながら、人間は事業リスクとセキュリティの最終判断を担う。

　AIを導入することより、AIが判断できるほどシンプルで正確な環境を作れるかどうか。それが、フロンティアAI時代におけるサイバーレジリエンスの新たな前提になるだろう。