Cloudflareの脅威インジケーターをリアルタイムのWAFルールに変える

脅威指標がシステムに侵入するとすぐに、ルールがトラフィックのブロックを開始します。このアクションは非常にきれいに見えます。ペースが速く、フィードバックも早く、レポートも美しいです。しかし、これが実際に運用されると、本当の困難は、インジケーターをルールに変えることではなく、このルールをトラフィック、誤検知、ロールバックに耐えられるようにすることです。

『Cloudflare の脅威インジケーターをリアルタイム WAF ルールに変える』を読んだとき、私の頭に浮かんだのは「インテリジェンス アクセスの自動化」という派手な言葉ではなく、いくつかの非常に実用的な図でした。IP が赤色でマークされ、10 分後に傍受されました。 ASN は高リスクとマークされ、その結果、共有出口全体が関与しました。存続期間の短い攻撃サンプルがルール ベースに入ったばかりで、攻撃トラフィックは遮断され、古いルールが引き続き有効になったままになっていました。ここでのリアルタイムとは、単に速度を意味するのではなく、ルールのライフサイクル、データの信頼性、処理の責任を同じウィンドウ内に圧縮します。

ルールは、取り消すことができれば高速に実行できます

脅威指標が WAF に侵入した場合、最初に忍耐力を失うのは通常、攻撃者ではなく、勤務中の担当者です。なぜなら、ルールが発効すると、その後に続くのは抽象的な「セキュリティの向上」ではなく、具体的な事故による傷害、異議申し立て、ロールバック、監査となるからです。 IP レベルのインジケーターは委任するのが最も簡単です。攻撃は単一点であり、生存時間は短く、回復コストは低いです。 ASN、ネットワーク セグメント、TLS フィンガープリント、リクエストの組み合わせなどの指標は、より慎重になります。より広い範囲をカバーし、攻撃時の副作用がより困難になります。

この機能の本当に価値のある部分は、ルールが一度書き込まれて完了するのではなく、TTL、ソース、ヒット範囲、および元に戻す条件とともに表示されることです。これらのフィールドがないと、リアルタイム ルールはすぐに期限切れの禁止レコードの束に変質してしまいます。今日攻撃をブロックすると、明日からは通常のユーザーのブロックが開始されます。制作現場で最もよくある嫌な臭いは、ルールベースがますます厚くなり、残っているのは有効な判断ではなく、歴史的な感情だけであることです。

インジケーターレイヤーとアクションレイヤーの間にバッファーを残す必要があります。

もちろん、脅威指標をブロック ルールに直接変換するのが最も早いですが、このステップはインテリジェンス エラーをオンライン事故に増幅させる最も簡単なステップでもあります。より安定したアプローチは、通常、インジケーターとアクションの間にバッファー層を残し、同じ信号が最初に観察、チャレンジ、および速度制限を通過できるようにしてから、実際にブロックするかどうかを決定することです。このバッファ層が失われると、インジケーターの更新が速くなるほど、ルールが誤って破損する可能性が高くなります。

実際に実装する場合、ルールはフラットなオン/オフ スイッチではなく、アクションの激しさを表現できる一連の状態にすることが最善です。最初に記録し、次にチャレンジ、次に電流を制限し、最後にインターセプトに入るということです。この利点は簡単で、証拠が強力になるにつれてルールを段階的に強化し、証拠が弱くなった場合はすぐに格下げすることができます。セキュリティ チームにとっては、すべてのルールを一度に入力するよりも信頼性を維持できます。ビジネス側にとっては、何が起こったのかを知るために顧客サービスチケットが山積みになるまで待つのではなく、少なくとも異常な変動が最初に現れたときにそれを確認することができます。

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

この構造は単純そうに見えますが、実は非常に重要です。 confidence が低い場合、最初に挑戦することは、直接の傍受というよりも工学的な判断に似ています。 ttl は、古い情報が残らないように、有効期限が切れると自動的に期限切れになります。 scope は、偶発的な損傷エリアが無限に拡大しないように、経路または交通セグメントに縮小されます。

レビューがなければ、ルールは長くなるだけで、ゴミの山のように見えます。

リアルタイム WAF の最大の恐怖は、ヒット率が低いことではなく、ヒット後に何が起こったのか誰も分からないことです。ルールがリリースされた後は、ブロックされた実際の攻撃の数、誤って強制終了された通常のリクエストの数、ヒット後に新しいバイパス方法があったかどうかという 3 つのことを振り返ることができなければなりません。これら 3 つを結び付けることによってのみ、ルールは運用可能で保守可能であると見なされます。どれも欠けてしまうと、最終的には「とにかく先にブロックする」という慣性行動になってしまいます。

これは、脅威インジケーターの自動化において最も過小評価されている部分でもあります。指標のソースは多数あり、インテリジェンスの更新は頻繁に行われる可能性がありますが、安定したフィードバック ループがなければ、ルールは常に前進するだけになります。真に成熟したシステムは、各ルールのヒット率、ロールバック数、手動リリースの数、関連するアラーム、ビジネス損失を記録します。この時点で、ルールは単なるセキュリティ構成ではなくなり、証拠チェーンを伴う廃棄記録になります。

このツールのセットは、すでに廃棄機能を備えているチームにのみ適しています

脅威インジケーターをリアルタイムで WAF ルールに変換することは、すべてのシナリオに適しているわけではありません。トラフィックが少なく、攻撃対象領域が狭く、手動による勤務が十分に速いシステムの場合、静的なルールと手動更新に依存し続けることの方が面倒なことがよくあります。この機能を本当に必要としているのは、通常、トラフィックが多く、攻撃密度が高く、ルールが頻繁に変更され、すでにログ、レビュー、職務プロセスを備えているチームです。

このタイプのシステムが実装されると、その価値は単に「より速く停止する」だけではありません。さらに重要なのは、安全廃棄を 1 回限りの手動判断から、取り消し可能、レビュー可能、段階的に評価できる実行チェーンに変えることです。これを行う際のCloudflareのようなプラットフォームの利点は、より多くの脅威信号を取得できることだけでなく、信号をルール層にプッシュし、ルール層を監視、ロールバック、監査に接続する機能があることです。このチェーンがなければ、リアルタイムではエラーの発生が速くなるだけです。このチェーンを使用すると、ルールを実際に本番環境に導入できるようになります。