5月のイングランド銀行(Bank of England)の方針に続き、ECB(欧州中央銀行)も、AIを悪用したサイバー攻撃への対策として、組織にアクションプランの策定を義務付けています。。 しかし、求められているのは戦略文書ではなく、運用面での備えが整っていることの証明です。
7 Julyに、ECB銀行監督は約 110 の金融サービス企業に手紙を送りました。 指示：31st October 2026までにAI主導のサイバー攻撃に対する専用のアクション計画を提出してください 。 ECBがこの話題を取り上げていることに驚く人はいません。 驚くべきは、それがいかに具体的になったかです。 単なる戦略計画の策定ではもはや不十分で、運用権限の証拠が必要です。 これは、パッチ適用ペースにおいて必須の要件とされています。 かつては脆弱性の解消に3か月かけても妥当とされていたが、今では数時間以内の対応が求められています。 その責任は経営陣(マネジメントボード)にあります。 もはや、これは任意の選択肢ではありません。
その手紙は、IT部門ではなく、経営陣宛てに意図的に送られたものでした。 これに伴い、 25th June のESRBからは、AIモデルに起因するシステミックなサイバーリスクに関する警告が発せられており、同時に、監督当局は年次ITリスクアンケートの実施を延期しました。 その兆候は明らかです。この問題は今や取締役会レベルでの関心事となっています。
行動計画の基礎
必要な行動計画には、新たな規則集は必要ありません。 これは、DORAがすでに求めていることを具体化したものであり、スピードと検証可能性に対する要求が著しく高まっている点が異なります。 デジタル・オペレーショナル・レジリエンスに関する規則（EU）第 2022/2554 号は、17th January 2025より完全に適用されています。 これは、金融セクターのレジリエンスを、ICTリスクの管理、ICT関連インシデントへの対応と報告、デジタルレジリエンスの検証、サードパーティリスクの管理、および情報共有という5つの柱に集約したものです。
AIサイバー行動計画は、一から作り直すものではありません。 AIを活用した攻撃の圧力の下で、これら3つの柱を強化する必要があります。: ICT リスク管理（保護すべき対象を把握していますか？ （どれくらいの速さで対応できるでしょうか？）、レジリエンステスト（実際のストレス下でも私の仮定は成り立つでしょうか？）、およびサードパーティリスク（私はどの程度依存しており、誰に依存しているのでしょうか？）です。 すでにDORAを真剣に受け止めている方々にとっては、一から始める必要はありません。 これを単なる記録作業だと考えていた人たちは、今になってその不備がどこにあるかを実感することになるでしょう。
上司は実施状況をどのように評価するのでしょうか
当該の合同監督チームは、文書の文言そのものを精査することはありませんが、その背後にある実質的な内容については検討を行います。 堅実な計画と単なる意向表明とを区別する4つの要素は以下の通りです：
- 原則ではなく具体的な措置： 計画には、どのシステムが影響を受けるか、どのような順序で対応するか、そしてどの目標値が適用されるかを明記しなければなりません。 漠然とした改善の意思だけでは不十分です。
- 委員会だけでなく、具体的な人物を指名すること： 必要なのは、その計画を主導する責任者を任命することです。 単なる責任ではなく、真の権限を付与されています。
- 割り当てられたリソース： 予算と人員について、漠然とした約束ではなく、明確な取り組みが示されています。
4つ目の要素は、同時に決定的な問いでもあります。すなわち、ご自身の主張を証明できるでしょうか？ ここでいう「証明」とは、求められた際に3つの証拠を提示できることを意味します：
- パッチ適用のペースについて： この記事では、最近公開された重大な脆弱性について、公開から全車両へのパッチ適用が完了するまでに何時間または何日が経過したかを分析しています。 数値は、分布として、また時間軸に沿って、タイムスタンプを付して表示する必要があります。 丸めた平均値では、上司を納得させることはできません。 例えば、重大なCVEの 95％が 72 時間以内に修正されました。
- 資産の透明性について： 実際に発見されたインベントリとCMDBとの照合を行い、その差異を可視化するものです。 この資料では、公式のリストには掲載されていないエンドポイント、サーバー、クラウドワークロードがどれほど存在するか、また、こうした管理対象外や旧式のシステムをどのような方法で特定するかについて解説しています。 その不一致そのものが、最も説得力のある証拠なのです。
- 進捗状況について： これは、短期間（数分以内）で、単一のデータソースから生成できるレポートであり、日付が明記され、追跡可能なものです。 もしJSTが今日問い合わせてきた場合、その回答はすでに用意されているべきであり、まずさまざまなシステムから手作業で情報を集めてまとめる必要はないはずです。
共通点は、信頼できる情報源から得られた、タイムスタンプ付きの数値であり、いつでも再現可能であるということです。
実践においてどのような困難があるか
その要件は、言うまでもないことのように思えます。 多くの機関がこうした課題に苦戦する可能性が高いのは、意志の問題ではなく、長年にわたって形成されてきた構造の問題なのです。 5つのパターンが繰り返し現れます：
- 断片化したツール環境： 。資産管理、脆弱性管理、パッチ適用、およびレポート作成が、それぞれ別々のソリューションに分散しています。 上司からの質問は、そのたびにシステム間の垣根を越えたデータ収集作業へと変わってしまいます。
- 遅れをとっているCMDB： 構成データベースは、実際の状態ではなく、目標状態を反映しています。 現実とデータベースの間には、誰もリアルタイムで埋めることのできない隔たりがあります。
- 死角。 管理対象外のデバイス、シャドーIT、および旧式のシステムは、リストには表示されません。 それらはまさに、攻撃者が狙う侵入経路なのです。
- ITとセキュリティという別々の世界： 脆弱性を見つけた人が、それを修正するとは限らないのです。 引き継ぎのたびに、現在不足している時間が費やされてしまいます。
- メンテナンス期間への依存： AIが数時間でエクスプロイトを生成するようになった今、事後対応型の定期的なパッチ適用サイクルだけではもはや不十分です。
さらに、多くの組織では、依然として誰かが一晩かけて作成したスプレッドシートを用いて、上司向けの資料を手作業で作成しています。 この方法は再現性も堅牢性もなく、JSTから急な問い合わせがあった場合にも対応できません。
成功を収める組織とは、期限を単なる煩わしいコンプライアンス対応ではなく、かねてより必要とされていた自動化や業務改革を推進するためのきっかけとして捉える組織です。
今後数週間のロードマップ
「 31st October」までの短い期間において、重要なのは、その計画の運用面を支える基盤となるものです：
- 在庫の全容を把握してください。 管理対象外や旧式のシステムを含め、すべてのエンドポイント、サーバー、クラウドワークロードについて、包括的かつリアルタイムな全体像を把握できます。 その結果をCMDBと照合してください。なぜなら、その差異こそがリスクとなるからです。 自分が何を担当しているかを把握して初めて、優先順位をつけることができます。
- ペースを測定可能なものにしましょう。 重大な脆弱性の公表から全車両へのパッチ適用が完了するまでの時間を指標（パッチ適用までの平均時間）として定義し、その記録を開始してください。 測定をメンテナンス期間から切り離してください。そうしないと、対応能力ではなく、単にスケジュールだけを測定することになってしまいます。
- 証拠を準備してください。 単一のデータソースから、ボタンひとつで進捗状況を確認でき、タイムスタンプが付与され、JSTへの提出準備が整っていることを確認してください。 数分で作成できる報告書は、何日もかけてまとめた報告書よりも説得力があります。
- 説明責任を徹底する。 責任ある担当者を任命し、権限と予算を付与した上で、上司があなたを評価する際に用いるのと同じ指標に基づき、この議題を定例取締役会での議題として取り上げるようにしてください。
実際のプロセスとしては、まず透明性と指標を確立し、その上に自動化とエビデンスを構築し、最初からガバナンスを並行して進めていきます。 このパターンに従う組織は、 31st Octoberにおいて、計画に加え、さらに重要なこととして、それを裏付ける根拠を提示することになります。
計画から実証可能な現実へ
自律型ITのプラットフォームとして、Taniumは、資産情報、脆弱性、パッチ適用状況、および証拠情報を、共有され、常に最新の状態で維持されるデータ基盤に統合します。 これにより、軽量なエージェントが、断片化されたツールの環境に取って代わることになります。 その結果、すべてのエンドポイントにわたるリアルタイムの可視化、パッチ適用作業の自動化、そして自律的な対応が可能となります。 このようにして、信頼性の高い行動計画は、監督当局の精査に耐えうる、実証可能な運用上の現実となるのです。
締め切りが決まりました。 問題は、計画を提出できるかどうかではなく、その計画が十分に堅実なものかどうかです。
