先日話を伺った、売上高数十億ドル規模の企業のCISOが述べたある言葉が、私の心に強く残っています。彼らが最も重視していたセキュリティ能力は、新たな検知ツールやフレームワークではありませんでした。それは「スピード」だったのです。
彼らにとって、問題の特定、修正策の検証、そして変化への対応のスピードが最優先事項でした。対処すべき課題が山積していることから、時間が運用上の制約要因になりつつあることも示唆されています。
サイバーセキュリティの専門家フィル・ベナブルズ氏は最近、セキュリティ対策の成否は今後ますますスピード次第になると指摘した。
「スピードがすべてだ。特に、ディフェンダーが、アタッカーが適応するよりも速くOODA（観察、状況把握、判断、行動）ループを回せるかどうかが重要だ」。
とはいえ、これは単なる「AIがこの混乱を引き起こしている」という類の記事ではありません。より広い現実と向き合いましょう。200人のCISOと200人のエンジニアリングリーダー（CTOを含む）を対象とした当社の調査によると、76%の組織が毎週、あるいはそれ以上の頻度で大規模な更新を実施しており、39%は毎日更新を行っています。現代のエンジニアリングチームは、変更を継続的にデプロイしているのです。
しかし、セキュリティ検証はそのような頻度で行われていない。リリースごとにセキュリティ検証を行っているのはわずか21%に過ぎない。これは単なる不整合というレベルではなく、構造的な欠陥である。
ペースレイヤー
ベナブルズは、複雑なシステムがどのように進化するかを説明するために、スチュワート・ブランドの「ペース・レイヤーズ」という枠組みを引用している。
「速い層は斬新さと実験性をもたらし、遅い層は安定性と記憶をもたらす。」
ソフトウェアの提供は「高速層」であるのに対し、ガバナンスと検証は「低速層」にあたります。現代のソフトウェア環境では、これらの層の乖離がさらに拡大しつつあります。エンジニアリングチームは業務のスピードを加速させている一方で、セキュリティ検証は依然として四半期ごとや年次サイクルで行われています。
セキュリティの結果はシステムが変更された後に届くのだから、一体何の意味があるのだろうか？
この不一致がもたらす結果は避けられない。回答者の85％が、セキュリティ上の問題点が報告される頃には情報が古くなっていることが「少なくとも時々」あると回答しており、そのうちほぼ半数（48％）は、それが「非常に頻繁に」あるいは「常に」起こると答えている。
つまり、テスト結果が検証される頃には、その結果が示すシステムはすでに変化しているということです。事実上、チームはシステムの過去の状態に基づいてセキュリティ上の判断を下していることになります。わずかな変更であっても、システムのセキュリティ態勢は変化する可能性があります。新しいエンドポイントの追加、認証ロジックの微調整、あるいは依存関係の更新といったことが、まったく新しい攻撃経路を生み出す恐れがあります。ペネトレーションテストでは、もはや存在しないバージョンのシステムを検証していることが多々あるのです。
その結果、提案された修正や再テストによって、古いセキュリティ上の問題が何とか発見されることもあるでしょう。しかし、ソフトウェアが進化していくにつれ、チームはテストが提供したシグナルに対する信頼を失い始めます。なぜなら、そのシグナルは遅れて届くものだからです。
その結果は、映画『インセプション』の多重に重なり合った時間の仕組みに少し似ています。システムの各部分がそれぞれ全く異なる速度で動作するようになり、ある層で遅れて行われた行動は、別の層ですでに進行している事態にはほとんど影響を与えない可能性があります。
スピードを追求するあまり、深みを犠牲にしてはならない
セキュリティ体制の強化を目指す組織にとって、検証には論理的根拠、調査、エクスプロイト 、およびワークフローの分析が必要です。検証は徹底的なものでなければなりません（もちろん、それはご存じのことでしょう）。
「静的解析には限界があります。実行中のアプリケーションに対して問題を検証できなければ、それは単なる仮説に過ぎません」と、ペンテスト フィリップ・ドゥラソフ氏は語る。 Aikido SecurityのAIペネトレーションテスト責任者、フィリップ・ドゥラソフ氏は語る。
これこそが、有意義なセキュリティテストにはこれまで時間がかかってきた理由です。
つまり、課題はテストの数を増やすことではなく、はるかに高いペースで運用しながらも、本格的な攻撃テストの質を維持することにある。
しかし、定期的なテストには、脆弱性の検出深度において明らかな限界がある。我々の調査によると、回答者の51％が、論理的欠陥、不適切なアクセス制御、あるいは多段階の攻撃経路といった、より深層にある脆弱性は「常に」あるいは「頻繁に」見落とされていると考えている。
これは、セキュリティチームに専門知識が欠けているからではありません。むしろ、ペネトレーションテスターやレッドチームが、時間制限のあるテスト、システムの拡大、複雑さの増大、そしてシステム間の相互接続性といった、数多くの制約に直面しているからです。しかし、その根本にある「広さ対深さ」のジレンマは、実際には時間の問題なのです。
検証は、実質的な変更が行われた後に実施されなければならない
組織は、デリバリーのスピードとセキュリティ検証の間に生じているギャップの拡大に気づいていないわけではない。多くの組織が、年間を通じてペネトレーションテストの実施回数を増やしたり、継続的なスキャンを行ったり、手動による検証作業を短縮してより短いリリースサイクルに合わせたりすることで、このギャップを埋めようとしてきた。理論上は、こうしたアプローチによってスピードは向上する。しかし実際には、単にセキュリティ上のリスクが別の場所に移るだけであることが多い。
より望ましい変化は、検証をソフトウェアの実際の変更状況に合わせて調整することです。これは、すべてを絶えず、あるいは継続的にテストするように移行することを意味するのではなく、意味のある変更が発生した際に検証が即座に対応できるようにすることを意味します。 言い換えれば、実際にリスクをもたらす変更を検証するということです。課題は、既存のテスト手法のほとんどが、このレベルの迅速な対応を実現できない点にあります。従来のペネトレーションテストでは、スケジューリング、実行、レポート作成に数日あるいは数週間を要します。最も迅速なプロジェクトであっても、毎日、あるいは1日に何度も発生する変更に現実的に追いつくことはできません。これらの変更は単なる表面的なものではなく、API 、認証ロジックの変更、エージェントのワークフロー、あるいは新しいサードパーティ製サービスの統合といったものです。
セキュリティチームにとって、これが運用面で意味するのは、検証を単なる後付けの作業ではなく、デリバリー・パイプラインの一部として組み込む必要があるということです。その結果、システム全体を定期的にテストすることから、システムを段階的に検証することへと重点が移行することになります。
{{cta}}
スピードへの渇望
何十年もの間、組織は生産量の増加――より多くのコード、より多くの機能、より多くのアプリケーション――に注力してきた。より迅速に製品をリリースできるチームが競争上の優位性を獲得する。ベナブルズ氏は、この原則がセキュリティの分野にもますます当てはまってきていると主張している。
現代のソフトウェア開発のスピードを真に活かすためには、セキュリティ対策も同等のスピードで進化させなければなりません。問題を迅速に検知し、修正策を検証し、変化に対応できる組織は、攻撃者に対してだけでなく、同じ分野で事業を展開する競合他社に対しても優位に立つことができます。それができない組織は、自社のシステムについて時代遅れの前提に基づいて業務を行わざるを得なくなるでしょう。
システムの各層が異なる速度で動く場合、反応が遅すぎるセキュリティは、すでに不適切な時間軸で動作していることになる。これは映画『インセプション』の構図に似ており、ある層で遅れてとられた行動は、別の層ですでに進行している事態にはほとんど影響を与えない。
