ブルーチーム企業のハッカーからの警告
確かにAIは役立つ、すでに役立っているのだからと言って、AIならセキュリティ問題を解決してくれると夢見るのはやめましょう。防御側と攻撃側の両者が生成AIを使えるからといって、防御側が攻撃側に「追いつける」と考えるのは幻想にすぎません。
私はレッドチームの視点からこの問題に取り組んでいます。長年、攻撃者の思考で物事を考えてきました。現在はブルーチームの企業で働き、実際のシステムを守ろうとしています。そして私にとって明らかなのは以下の点です：
AIにより攻撃者は今まで以上に攻撃を仕掛けてくるでしょう。そして防御側は依然としてなすすべがありません。
それがボトルネック、計画の欠陥です。AI支援によるパッチ適用では、何千ものアセット、チーム、承認プロセスにまたがってガムテープでつなぎ合わせたような、脆弱な15年前のコードベースは修正できません。2015年に我々の足を引っ張った問題が今も残っています。そして今、それらは攻撃者が武器にしようとしているのです。
Respond faster with Sumo Logic Dojo AI
Cut through the noise, detect threats faster, and resolve issues before they disrupt your operations.
AIは、レガシーな技術的負債からあなたを救いません。
セキュリティの世界では今、脆弱性管理にAIを投入し、デフォルトで安全なソフトウェアを提供できるようになる、という輝かしい希望があります。
しかし、現実の企業環境はこのような状態です。
- サポート終了となったシステムがまだ現役で稼働しています。
- OSアップデートのたびに壊れる脆弱な統合システム。
- 6年間未更新のファームウェア。
- パッチ適用不可能な Windows XP を実行している OT ネットワーク。
技術負債を「AIで解決」することはできません。
セキュリティとは可観測性です。可観測性とはセキュリティです。見えないものは守れません。そして修正できないものは、ダッシュボードをいくつ持っていようと、決して安全とは言えないのです。
特に古いシステムにおいて、これは根本的にアーキテクチャの問題です。これは設計上の失敗であり、今や大規模に是正する必要があります。クラウド以前の時代に作られた脆いソフトウェアに、AIが奇跡の修正プログラムを書いてくれるわけではありません。
Infrastructure as Code（IaC）とKubernetes：万能薬ではない
では、 infrastructure as code、Kubernetes、 コンテナなどの最新のスタックについて説明します。こここそが、私たちが正しく理解すべきところですよね？
まあね。
そうです、IaCとK8sは一貫性のある迅速かつ安全なパッチ適用の可能性を与えてくれます。ただし、「正しく使っていればこそ」という話であり、現実はどうなっていると思う？
ほとんどの組織は、そうではありません。
2年前のブログ記事からコピーされたYAMLを使って、いまだに手動で設定されているKubernetesクラスタの多さに驚くことでしょう。IaCテンプレートは他のコードと同様に劣化します。そして劣化した時、それらは新たな負担となります。
- RBACコントロールなしで作成されたクラスターもあります。
- パッチ未適用のベースレイヤーに基づく画像。
- ヘルムチャートに埋め込まれたシークレット。
- Terraformの状態ファイルはパブリックバケットにあります。
私たちは、使い捨て（エフェメラル）で再デプロイ可能なインフラという約束された恩恵を手にしながら、それを単なる別の『固定された（静的な）データセンター』として扱ってしまっている。それは大きな『機会損失』であり、起こるべくして起こるセキュリティの惨事だ。
AIにKubernetes環境のパッチ適用を任せたいなら、まずクリーンでバージョン管理され、きちんと保守されたIaCベースラインが必要です。そして実際にそれを使うチームが必要です。それは当然のことではありません。
現代の道具は古い習慣からあなたを救ってはくれない。問題が起きたとき、その影響範囲をむしろ大きくしてしまうだけです。
チームの入れ替わりとともにアーキテクチャも失われてしまいました。
もう一つの残酷な真実を忘れてはいけません。レイオフやチームの入れ替わりが加速しているのです。
ここ数年、チームの離職や人員削減がニュースの見出しを賑わせています。人員削減によるものか、チーム構造の変更や新たな役割への異動によるものか、いずれにせよ組織は内部構造を「実際に理解していた」人材を失いました。なぜこの統合があの方法で機能したのかを知っていた人たちのことです。忘れ去られたライブラリへのカスタムパッチを覚えていた人たち。2週間のチケットサイクルを必要とせず、4つのサービスにまたがる壊れた認証フローを追跡できた人たちなのです。
もう、彼らはいません。
そして彼らと共に、あの彼らの間で共有されていた知識も一緒に消え去ったのです。文書化されていなかったからです。代替不可能だった。それはSlackのスレッドや戦術会議室、そして人間の記憶の中にも存在していたのです。
今では、誰も完全に理解していないシステムにパッチを当てようとして、なぜ何週間もかかるのか不思議に思っている状況です。それは技術的な失敗ではなく、組織的な失敗です。
AIには修復可能です。プロンプトを使っただけで、組織に蓄積された記憶を取り戻すことはできません。
セキュリティ業界の静かなる妥協
そして現実を見ましょう：これは私たちにも責任があります。
多くのセキュリティ企業—特に大手企業—は、システムを保護するという本来の使命よりも、製品化と利益を優先してきました。私たちはプラットフォームやダッシュボード、アラートを構築してきました。しかし、根本的な問題—パッチ適用とアーキテクチャの脆弱性—は解決されていません。なぜなら、それらはデモで効果的に見せられないからです。
「技術的負債を1年かけて解消しました。」というような派手なインターフェイスはありません。
「4,000台のエンドポイントでパッチ適用プロセスを20%高速化しました。」これではRSAでブースは取れないのです。
でもそこが戦いの場です。
システムの脆弱性を知ってから、実際に 修正する までのギャップこそが本当の戦争であり、決して華やかなものではありません。
では、ここからが本当の行動喚起です。
私たちの最大の弱点は運用であり、情報ではないという不都合な真実と向き合う必要があります。
全てを知り、全てを見抜き、全てに警告を発せたとしても、パッチを当てるのが遅かったために侵害されてしまうのです。
どうすればいいのでしょうか？
- 「修正不可能な」という認識を断ち切りましょう。重要でありながら更新できないものは、置き換え、隔離、または削除する必要があります。パッチ適用＝ダウンタイム＝ビジネスリスクとなるシステム構築をやめるのです。
- ツールよりも組織図を修正せよ。セキュリティ、運用、開発、コンプライアンスチーム間の縦割り構造が対応時間を悪化させています。AIでは解決できない。解決するのはコミュニケーションです。
- デフォルトで安全なソフトウェアを要求せよ。ベンダーに対し、パッチ適用可能でモジュール化された自動更新コンポーネントの提供を迫ります。彼らの言い訳を許すのはやめましょう。
- 本当に重要な部分を自動化せよ。ダッシュボードの増設ではなく、パッチ検証・展開・再起動を自動化します。AIがシェルスクリプトを書くなら、パッチ適用用のスクリプトを書かせるのです。
- 障害を想定した設計システムを構築せよ。パッチ適用が遅れることを前提とします。封じ込め、セグメンテーション、ロールバックをアーキテクチャ自体に組み込むのです。
- リスクを低減したチームを評価し、単に管理策を追加しただけでは評価しない。 1万台のエンドポイントにパッチを適用し、ネガティブなニュースにならずに済むことのほうが、きらびやかなAI機能の追加よりも大きな成果です。
結び
攻撃者は常に速度で優位に立ってきました。AIはその状況をさらに悪化させました。攻撃者がリアルタイムでポリモーフィックエクスプロイトを生成している一方で、防御側はいまだ変更管理を通じてのパッチ適用に四苦八苦しています。
これはツールの問題ではなく、脅威インテリジェンスの問題でもありません。これは、セキュリティにおける最も古い問題です―問題を発見した後に、それをどう直すか―を、私たちがまだ解決していないという事実についてです。
このAIの波を乗り切るためには、パッチを運用J等の負担ではなく、 戦略的 優先事項として扱う必要があります。 そして、今すぐそれを実行するのです。
なぜなら、攻撃者は待っていませんから。常に我々の先を行こうとするのです。
では、実際に何をすべきか？ 最初のステップは、効果的なセキュリティプログラムの導入、適切なログ記録、そしてSumo LogicのようなクラウドSIEMソリューションの導入です。しかし、この問題を根本的に解決するには、あなたのような賢い人材が問題解決に取り組み、できればコミュニティに貢献することが必要です。別のブログ記事でいくつかの解決策を提示していますが、おそらく気に入らないでしょう。
