ブルーチーム企業のハッカーからの警告
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ベースラインが必要です。そして、それを実際に使うチームも必要です。それは当たり前のことではありません。
最新のツールを使っても、古い習慣からは逃れられません。問題が起きたとき、その影響範囲をむしろ大きくしてしまうだけです。
チームの入れ替わりとともにアーキテクチャも失われてしまいました。
もう一つの残酷な真実を忘れてはいけません。レイオフやチームの入れ替わりが加速しているのです。
ここ数年、チームの入れ替わりやレイオフがニュースの見出しになっています。人員削減やチーム構造の変更、新しい役割への異動によって、組織は 内部アーキテクチャーを 実際に理解していた人材を失っています。この統合がなぜそのように機能するのかを知っている人たちです。忘れ去られたライブラリーのカスタムパッチを覚えていたのは誰ですか？4つのサービスにまたがる壊れた認証フローを、2週間もかかるチケットサイクルなしで追跡できた人たちです。
もう、いません。
そんな彼らとともにあった、部族的な知識は？それもなくなりました。文書化されていなかったのです。代替はありませんでした。それはSlackのスレッドや戦略会議室、そして人間の記憶の中に存在していました。
今では、誰も完全に理解していないシステムにパッチを当てようとして、なぜ何週間もかかるのか不思議に思っている状況です。それはエンジニアリングの失敗ではありません。それは組織的なものです。
AIでは解決できません。プロンプトを使っただけで、組織に蓄積された記憶を取り戻すことはできません。
セキュリティ業界の静かなる妥協
そして現実を見ましょう：これは私たちにも責任があります。
多くのセキュリティ企業、特に大手は、システムの安全確保という実際の使命よりも、製品化と利益を優先してきました。私たちはプラットフォーム、ダッシュボード、アラートを構築してきました。しかし、根本的な問題であるパッチ適用とアーキテクチャの脆弱性は、デモ映えしないために解決されていません。
「技術的負債を1年かけて解消しました。」というような派手なインターフェイスはありません。
「4,000台のエンドポイントでパッチ適用プロセスを20%高速化しました。」これではRSAでブースは取れないのです。
でもそこが戦いの場です。
システムの脆弱性を知ってから、実際に 修正する までのギャップこそが本当の戦争であり、決して華やかなものではありません。
では、ここからが本当の行動喚起です。
私たちの最大の弱点は運用であり、情報ではないという不都合な真実と向き合う必要があります。
全てを知り、全てを見抜き、全てに警告を発せたとしても、パッチを当てるのが遅かったために侵害されてしまうのです。
どうすればいいのでしょうか？
- 「パッチ不可能」という物語に終止符を。 それが重要で更新できない場合は、交換、隔離、または削除する必要があります。パッチ適用＝ダウンタイム＝ビジネスリスクとなるようなシステム構築はやめましょう。
- ツールの前に組織図を修正しましょう。 セキュリティ、運用、開発、コンプライアンスの各チーム間のサイロ化により、レスポンスタイムが低下しています。AIでは解決できません。コミュニケーションが解決します。
- デフォルトで安全なソフトウェアを求めよう。 ベンダーに、パッチが適用可能で、モジュール化され、自動更新されるコンポーネントをリリースするよう求めます。もう、言い訳は受け付けません。
- 実際に重要な部分を自動化します。 ダッシュボードを増やすのではなく、パッチの検証、ロールアウト、再起動を自動化しましょう。AIがシェルスクリプトを書くのであれば、パッチを当てるスクリプトにしましょう。
- 失敗を念頭に置いたシステム設計 パッチは遅れがちだと想定しておきましょう。封じ込め、セグメンテーション、ロールバックをアーキテクチャ自体に組み込みます。
- 単に管理策を追加するだけでなく、リスクを削減したチームを評価しましょう。 1万台のエンドポイントにパッチを適用し、ネガティブなニュースにならずに済むことのほうが、きらびやかなAI機能の追加よりも大きな成果です。
結び
アタッカーは常にスピードで優位に立ってきました。AIによってその差はさらに広がりました。攻撃者がリアルタイムでポリモーフィックエクスプロイトを生成している一方で、防御側はいまだ変更管理を通じてのパッチ適用に四苦八苦しています。
ツールの話ではありません。問題は脅威インテリジェンスではないのです。これは、セキュリティにおける最も古い問題です――問題を発見した後に、それをどう直すか――を、私たちがまだ解決していないという事実についてです。
このAIの波を乗り切るためには、パッチを運用J等の負担ではなく、 戦略的 優先事項として扱う必要があります。そして、私たちは今すぐ取り組む必要があります。
なぜなら、攻撃者は待っていませんから。彼らは決して、待ちませんでした。
では、実際に何をすればいいのでしょうか？最初のステップは、効果的なセキュリティプログラムを実装し、適切なログ基盤を整え、Sumo Logic のようなクラウド SIEM ソリューションを導入することです。しかし、この問題を本当に解決するには、あなたのような優秀な人材が課題解決に取り組み、できればコミュニティへの貢献も必要です。別のブログでいくつか答えを準備していますが、おそらく気に入ってはいただけないでしょう。
