クラウドフレア、AIハーネスを活用しWAFを強化

実験は、WAFがすでにブロックした攻撃ペイロードから始まりました。固定されたテストケースを繰り返し再生するのではなく、モデルの呼び出しは、前の試行からの応答に基づいて、エンコーディング、配置、または配信に対する変更を提案しました。モデルは、クラウドフレアのWAFルール、ソースコード、または内部のセキュリティシグナルにアクセスできなかったため、テストは彼らにとって効果的にブラックボックスでした。

Pythonハーネスは、クラウドフレアがモデルに委任したくない部分を処理しました。HTTPリクエストの構築と再生、シナリオ状態の維持、制限の適用、応答の収集を行いました。1つのモデル呼び出しが次の変異を提案し、別のモデルがその結果の応答をレビューしました。これにより、モデルがリクエスト実行を直接制御することなく、その後の試行が適応できました。

SSRFテストの1つは、そのフィードバックループがどのように機能したかを示しています。テスターは、クラウドメタデータアドレスの表現と配置を繰り返し変更し、10進数、8進数、その他の形式を試しました。最終的に、10進数表現を使用したリクエストがブロックされました。次の試行では、モデルは同じリクエスト形状を保持したが、アドレスの末尾にドットを付けた表現に切り替えました。今回は、クライアントがWAFブロックではなくリダイレクトに遭遇しました。クラウドフレアは、攻撃が成功した証拠としてではなく、調査のために結果を保存しました。

この区別は、大規模な運用において重要でした。1,107の記録された変異試行のうち、607がトリアージ後の結果セットを生成しました。558のリクエストはWAFによってブロックされ、49の発見はさらに補修作業が必要とされました。49の発見のうち48は、コマンドインジェクションまたはサーバーサイドリクエストフォージェリ（SSRF）に関連していました。

人間によるレビューは、最終的な検証ステップでした。レビュアーは、リクエストが実際にターゲットに到達したか、依然として悪意があるか、明確にブロックされていないか、WAFの責任範囲内か、安全に再現できるかを確認しました。生き残ったケースは、ルール、正規化、またはその他の緩和策の変更候補として再生され、評価されました。

この作業は、クラウドフレアのマネージドルールセットに3つの変更をもたらしました。新しい検出、SSRF - 宿主を隠蔽したホストとSSRF - 制限されたプロトコル、および既存のSSRF - クラウドルールの改善です。

同じハーネスパターンは、セキュリティエンジニアリングの他の分野にも見られます。クラウドフレアの脆弱性発見ハーネスは、脆弱性発見と独立した検証を分離しています。Google Mandiantのエージェンティック脆弱性発見ハーネスは、ソースコード分析、仮説生成、検証を通じて専門化されたエージェントをチェーン化し、発見が人間のレビュアーに到達する前に行っています。

他のシステムは、異なる用語を使用していますが、類似した発見と検証のパターンに従っています。OpenAIのCodex Securityは、リポジトリの脅威モデルを構築し、脆弱性を検索し、隔離された環境で候補を再現し、人間のレビューのために修正を提案します。GoogleのPageBreakは、AI生成の脆弱性仮説が実際に悪用できるかどうかを検証することに焦点を当てており、部分的に、信頼性のあるが検証されていない発見に圧倒されるのを防ぐためです。

これらのシステムを通じて、共通のテーマはモデルを囲むハーネスです。実行を制限し、状態を保持し、発見を検証し、確率的な探索を、既存のセキュリティワークフローが使用できる証拠に変換します。