シグナルシリーズ第3回 : エッジでのシグナル

本シリーズの第1回では、Fastly Next-Gen WAF のカスタムシグナルの活用方法について、悪質または望ましくない動作が疑われるトラフィックのブロックに関する例を挙げてご紹介しました。また、第2回では、システムシグナルを利用することで、セキュリティチームや DevOps チームがカスタム設定無しに Web アプリケーションや API を保護できることを説明しました。

本シリーズの第1回</u>では、Fastly の Next-Gen WAF カスタムシグナルで実現できることを、悪意または不正が疑われる動作のブロックに関する2つの活用例を用いてご紹介しました。第2回</u>では、セキュリティおよび DevOps チームがカスタム設定なしに Web アプリケーションと API の保護を行うことができるシステムシグナルを取り上げました。

シグナルシリーズの第3回では、既知の攻撃者の特定とレスポンスの追跡という、さらなる2つのユースケースと、これらの領域でセキュリティ体制を強化するのにシグナルがどう役立つかを見ていきます。また、Fastly のエッジに一部のセキュリティ判断を移行することで、カスタムレスポンスコードを使用したダウンストリームのシステムを強化する方法についても確認しましょう。

既知の攻撃者の特定

Web 脅威対策の重要性がさまざまな機会で語られているのには、正当な理由があります。コードのインジェクション攻撃、顧客データの流出、API の悪用は、常に Web でのサービス提供を脅かす存在だからです。 

しかし視点を変えてみると、ここには脅威モデリングの際にあまり省みられないもうひとつの側面があります。それは、チームに大きな負荷のかかるノイズやアラート疲れを軽減することです。実際の脅威ではなく誤検出を追いかけているとき、セキュリティチームは有効性の低いオペレーションを行っていることになります。 

ESG</u> のレポートによると、セキュリティリーダーの23%が、大量のセキュリティアラートに対処することが彼らの組織の最大の課題であると考えています。サイバーセキュリティのアラート疲れへのひとつの対策として、WAF を使用して既知の攻撃者の特定を自動化することが挙げられます。トラフィックやリクエストを「正常」とマークするメタデータでタグ付けすることで、チームに精神的な余裕が生まれ、脅威対策における効率を最大化できます。Fastly の Next-Gen WAF を使用することで、このトラフィックのカテゴリーに特定のシグナルundefinedを追加することが可能です。これは、HTTP リクエストの IP アドレスあるいはその他の特徴的な識別子を使用して行われます。 

以下は、IP アドレスのリストundefinedに基づいて、よく使用されるスキャナを特定するためのカスタムシグナルを追加するサイトルールを設定する方法です。ひとたびリストが作成されたら、サイトルール自体はきわめてシンプルです。UI での基本的なステップを簡単に確認しましょう。まず、ルール自体に使用するリストを作成します。この例では、特定すべき IP アドレスのリストは分かっています。

上記のスクリーンショットでは、既知の脆弱性スキャナを表す3件の架空の IP アドレスが追加されています。リストが作成されたら、このトラフィックのカテゴリーにシグナルをアタッチできます。これは、以下のような新たなリクエストルールを作成することで実行できます。

このルールにより、この特定のリストにある IP アドレスからのトラフィックを許可し、そのリクエストに今後の参照のために known-scanner のシグナルをタグ付けします。このルールがないと、Fastly の Next-Gen WAF はこのトラフィックに対して攻撃検出を実行し、スキャナの作業をブロックして、セキュリティチームへの不要なアラートを発生させることになります。また、このリクエストにアタッチされた known-scannerundefined のシグナルにより、スキャナの想定アクティビティの確認と可視化を行えます。 

次に紹介するのは、受信ペイロードだけでなく、そのリクエストがダウンストリームのアプリケーションに与えた (もしくは与えなかった) 影響を確認して攻撃を追跡するという、より複雑な方法です。

レスポンスの追跡

Web セキュリティの脅威モデリングへの基本的なアプローチは、ありがちな攻撃者の単純化された想定に基づいていることが多いようです。第一に、彼らは言わずもがな黒いパーカーに身を包み、第二に、ただひとつの精巧なペイロードを所有していて、これがもしアプリケーション (URL) の急所に送信されれば、システムに大打撃を与えるでしょう。ここでは、データ流出やサービス妨害攻撃、その他の悪用に見舞われる可能性が考えられます。

このストーリーはさらにこう続きます。もしundefined私たちに (悪意ある HTTP リクエストとして表現される) この攻撃を捕らえる万全の策があり、損害を受ける前に阻止できさえすれば、Web セキュリティに携わる身として本望であると。 

この思考のプロセスが、Web アプリケーションセキュリティの保護における一般的な第1のレイヤーです。この思考の行き着く先は、既知の脅威やシグネチャーに基づくモデルです。企業が最終的に、従来型の WAF でよく見られるような、何百もの (もしかしたら何千もの) ルールに帰結するのも不思議はありません。どうすれば、これを改善できるのでしょうか？ 

カスタムシグナルがあれば、私たちはこのロジックを推定し、さらに詳細を検討できます。Fastly の Next-Gen WAF では、リクエストとレスポンスの両方undefinedが、攻撃や異常シグナルをリクエスト/レスポンスのペアに追加するかどうかの決定に使用されます。例えば、いくつかのシステムシグナル (強制ブラウジングundefinedなど) は、リクエストをシグナルにタグ付けする前に、リクエストとundefinedレスポンスの知識に依存します。

これにより「撃ち放し (fire-and-forget) 」型の攻撃からの保護が拡張され、より高度な攻撃に対する可視性とインサイトを得られるようになります。もし攻撃者がどのように認証のエンドポイントの弱点を探っているかを判断できたらどうでしょうか？認証 API は攻撃しやすい標的です。初期設定において、適切に機能するため広く露出させておく必要があるからです。認証の失敗 (このケースでは HTTP 302) を追跡するためのカスタムシグナルは、クレデンシャルスタッフィング攻撃を示す可能性のある過度のログイン失敗を通知することができます。以下に示すのは、これに対するサイトルールの作成の基本テンプレートです。

以前の例では、認証の失敗を AuthFailure シグナルでタグ付けしています。何らかの問題がすでに起こっているかどうかは不明ですが、想定外の失敗があまりに多いときには、攻撃が進行中であることを示している可能性があります。このタイプの先行インジケータは、認証を処理するアプリケーションの別の場所に、さらなるセキュリティコントロールを追加するよう警告していることがあります。もしくは、組織的攻撃の可能性を示唆しているかもしれません。カスタムダッシュボードにおいて、シグナルは以下のようにグラフ化されます。

今回の例では、過去1時間におけるこのシグナルのインシデントを追跡するためのダッシュボードを試作しました。10:30から10:45の間のシグナルアクティビティが通常より集中していることがお分かりいただけるかと思います。特に通常のベースラインがもっとずっと低いようであれば、攻撃が試みられていることを示している可能性があります。

エッジへの保護の拡張

レスポンスの追跡は重要ですが、ブロッキングやレート制限などの強化アクションはどうでしょうか？もし、これらのアクションをアップストリームで実施したい場合には、どうすればよいのでしょうか？この時点では、その機を逸してしまったようにも見えます。なぜなら、エージェントはすでに処理を完了しており、レスポンスはクライアントへ送り返されているからです。 

実は、まさにここでセキュリティの境界をエッジに拡張することが力を発揮します。レスポンスのシグナルは、カスタムレスポンスコード</u>を使用してエッジへ返送することができ、Next-Gen WAF により生成された追加的なインテリジェンスは Fastly の配信 (Varnish) や Compute 環境でさらなる強化アクションを生むことができます。Varnish のお客様にとって、これは beresp.status 変数</u>にロジックを追加するのと同じくらい簡単なことです。Compute のお客様は、レスポンスの関連変数 (言語に依拠する可能性がある) に基づいて同様の処理が行うことができます。

beresp.status には、オリジンから受け取ったレスポンスの HTTP ステータスコードが含まれます。例えば、もしサイトルールが401エラーではなく550エラーを返してきた場合、この段階でのエッジセキュリティの判断にはブロッキング、エッジレート制限、もしくはクライアントのターピットが含まれる可能性があり、このすべてが攻撃者の動きを遅らせ、攻撃の際にトラフィックとロードをオリジンから分離する効果があります。ルールをブロックに変更するためにルールを更新し、以下のようにレスポンスコードを変更することで、追加的な保護を実施できます。

Next-Gen WAF でルールが変更されると、さらなるセキュリティロジックを Varnish に追加し、beresp.statu の値が550となった場合にアクションを取ることができます。エッジでのセキュリティ強化のメリットは、アプリケーションへの脅威の規模が拡大し、高度化が進むほどに拡張します。 

Fastly の Next-Gen WAF は、環境全体にわたる複数の場所にセキュリティ判断を分配することができます。エッジ、アプリケーション内 (コアのデプロイメント)、もしくはスタンドアロンのリバースプロキシ (Cloud WAF) など、より多くの場所でセキュリティの判断と保護を実施できます。 

今後について

今回は、カスタムシグナルにおける追加のユースケースのいくつかを見てきました。これらのアイデアが、皆さんの組織でお役に立てば幸いです。さらなるアイデアやユースケースに興味がおありの方は、担当のテクニカルアカウントマネジャーまでご連絡ください。Fastly ブログの次回更新もぜひご覧いただければと思います。ご期待ください！

Fastly Next-Gen WAF の利用にご興味のあるお客様は、ぜひお問い合わせ</u>ください。