ソフトウェアは継続的に変化しますが、セキュリティ検証はそうではありません。このため、銀行のような規制産業では、エンジニアリングがより速く動けないからではなく、検証が追いつかないためにリリースサイクルが遅くなるというギャップが生じています。
全体的に、業界はスナップショットテストだけでは不十分であると同意しています。200人のCISOと200人のエンジニアリングリーダーを対象とした当社の調査では、79%が定期的なペンテストの間に問題が見過ごされることを懸念しており、85%が少なくとも時には発見が古くなっていると回答しています。しかし、継続的なペンテストが実際にどのようにそれに取って代わるかについては、誰も（少なくとも今のところ）合意できていません。
継続的なペンテストとは何を意味するのでしょうか？
最近のRedditスレッドで、誰かが一見簡単な質問をしました。
「年次監査の代わりに、実際に継続的なペンテストを実施している人はいますか？」
「継続的なペンテスト」が実際に何を意味するのかについて、誰も合意できませんでした。あるスレッドだけでも、継続的なペンテストは「高度な自動スキャン」から、より定期的に行われる完全な手動テストまで、意味が揺れ動きました。その他の定義には、長々とした規制対応や、変更に焦点を当てたリリースごとのテストが含まれていました。また、真の継続的な製品として宣伝しながら、実際には全く異なるものを提供した企業に明らかに痛い目に遭わされた不満を持つコメントも多数ありました。
これに入る前に、本稿で用いるペンテストの定義について合意しましょう。リリースごとに脆弱性スキャンを実行することはペンテストではありません。真の攻撃的テストには、アプリケーションの動作に関する推論、認証されたワークフローの探索、攻撃パスの連鎖、実際の攻撃によるエクスプロイト可能性の検証が必要です。継続的なペンテストは、テスト自体が意味のあるものである場合にのみ意味をなします。
人間によるペンテストのスケーリングが限界に達する場所
正しい直感は、継続的なペンテストが変更に追随すべきだということです。何かが変更されたら、それを検証します。これはしばしば「デルタテスト」と呼ばれます。
しかし、上記のスレッドが指摘するように、すべての変更がテストを必要とするわけではなく、どの変更が重要か、それに応じてどのように価格を設定するか、オンデマンドで利用可能な人材をどのように最適に活用するか、そして単にノイズをテストしているだけではないことをどのように保証するかを決定するのは難しい場合があります。
ペンテスターやレッドチームは、ペンテストツールにはない創造性と判断力を持っていますが、彼らが直面する状況はますます厳しくなっています。その制限要因は彼らの能力の質ではなく、その思考を大規模に、そして攻撃対象領域が変化する速度で適用できない点にあります。
彼らは時間に制約され、システムをテストするたびにそのコンテキストを再構築する必要があります。これは、各ペンテストに必要な計画、調整、報告を考慮に入れていない場合でも同様です。
これがポイントです。人間の調整のみに依存するこのようなモデルは、現在のデプロイ速度には対応できません。継続的なAIペンテストが、この課題を解決する助けとなります。
しかし、AIを使用する場合でも、考慮すべき点があります。継続的とは、常にすべてをテストすることを意味しません。それは膨大なリソースの無駄になります。できるからといって、すべきとは限りません。継続的なAIペンテストは、変更が攻撃対象領域やセキュリティ体制に意味のある影響を与えるかどうかを判断し、影響がある場合にのみテストを開始できます。
カバレッジと深度のトレードオフ
経験豊富なテスターにとって最大のジレンマの1つは、広範なカバレッジと深度のどちらに重点を置くかを決定することです。広範な攻撃対象領域を迅速にカバーしようとすると、一般的な脆弱性クラスと既知の攻撃パターンに焦点を当てます。これにより多くの問題を発見できるかもしれませんが、より深刻な問題が潜んでいる可能性のある他の相互作用を深く掘り下げる時間は少なくなります。逆に、複雑な攻撃パスやアプリケーション全体にわたる連鎖的な動作に焦点を当てて深く掘り下げると、必然的にシステム全体のカバー範囲は狭くなります。
現代のシステムは、より大規模で相互接続性が高く、更新頻度も高いため、この問題をさらに複雑にしています。
そのため、ロジックの欠陥、アクセス制御の不備、多段階のエクスプロイトチェーンといったより深い脆弱性は、一貫して発見することが非常に困難です。私たちの調査では、セキュリティおよびエンジニアリングリーダーの半数以上が、従来のペンテストではより深いロジックの欠陥や多段階の脆弱性が見過ごされがちであると述べています。
これはペンテスターのスキルセットに対する批判ではなく、彼らが活動する上での制約を反映したものです。
しかし、これは同じ結論を裏付けています。継続的な検証は、単に頻繁にテストすることだけではなく、その過程で適切なカバレッジを確保することでもあります。
継続的なペンテストは攻撃対象領域のドリフトに対応できるため、経験豊富な攻撃チームはクラウンジュエルに集中できます。
継続的なペンテストにおけるアーキテクチャの問題
多くのツールは自動化されたペンテストと攻撃の生成に焦点を当てています。継続的なペンテストにおける真の課題は、変化するアプリケーションに対して継続的に攻撃テストを実行できるシステムを構築することです。
まず第一に、アーキテクチャは十分なシステムコンテキストを可能にする必要があります。これは、アプリケーションアーキテクチャ、API、ソースコード、およびインフラ構成に対する可視性を意味し、現実的な攻撃パスを探索できるようにするためです。ツールが公開されたエンドポイントしか認識しない場合、内部サービス通信を介する攻撃パスを見逃してしまいます。
第二に、システムはいつテストを実行すべきかを理解する必要があります。これは、攻撃対象領域に実際に影響を与える変更を検出し、その変更があった場合にテストをトリガーすることを意味します。これがなければ、「継続的」なテストは常に実行されてリソースを浪費するか、リスクをもたらす変更を見逃すスケジュールされたスキャンに逆戻りしてしまいます。
第三に、現代のアプリケーションは、ロール、エンドポイント、サービス間で数千もの相互作用を含んでいます。これらのパスは、一度に1つずつではなく、並行して探索される必要があります。順次テストするシステムでは、次のデプロイまでに現代のアプリケーションの検証を完了することはできず、重要なコンポーネントがテストされないままになります。
第四に、発見された結果は実際のエクスプロイトを通じて検証される必要があります。これにより、結果が実際に到達可能で再現可能な脆弱性を反映していることを確認できます。チームはすでに多くの誤検知に対処しており、これ以上は必要ありません。
第五に、システムはループを閉じる必要があります。脆弱性が同様に迅速に修正および検証できる場合にのみ、継続的な発見は意味を持ちます。これは、修正ガイダンスの生成、適用後の修正の検証、および問題が実際に解決されたことを確認するためのシステムの再テストを意味します。
そして最後に、システムは厳格な実行境界を強制し、テストが範囲内に留まり、無関係なシステムに影響を与えないことを保証する必要があります（AIペンテストエージェントが範囲外に出ないようにする方法に関する記事をご覧ください）。
上記のいずれの点も欠けていれば、継続的なペンテストは単なる自動スキャンとほとんど変わりません。
モデルの変化
業界はペンテストが進化する必要があるかどうかについて混乱していません。しかし、新しいモデルが何であるかについてはやや不明確な点があります。このためらいは理解できます。従来のペンテストは依然として機能しますが、常に変化するソフトウェア向けには設計されていませんでした。
スキャナーをより頻繁に実行しても問題は解決しないことを私たちは知っています。より多くのペンテストをスケジュールしても同様です。検証はソフトウェアが変化するのと同じ頻度で変化する必要があります。
しかし、変更があったときに適切なものをテストし、実際の攻撃作業に期待される深度を維持し、評価の間に攻撃対象領域が静かにドリフトしないようにする必要があります。
そのような状況になれば、レッドチームは彼らの専門知識を必要とする作業、すなわち複雑な攻撃パス、システム全体の弱点、そしてクラウンジュエルに集中できます。
継続的なペンテストは、攻撃チームに取って代わるものではなく、これまで得られなかったカバレッジを提供します。
継続的なペンテストが実際にどのように機能するか、ご覧になりませんか？
Aikido Infiniteは、アプリケーションへのすべての重要な変更をテストし、実際の攻撃パスを探索し、エクスプロイトの可能性を検証し、コードが本番環境に到達する前に修正を検証します。
継続的なペンテストが実際にどのように機能するかを確認するには、5分でペンテストを開始するか、ウォークスルーを予約してください。
