Webアプリケーションの継続的な保護の問題。 研究者およびオペレーターからの眺め。 パート2

そこで、1週間前に始まったトピックを続けます。 前回、WAF開発者は 、Webアプリケーションの継続的な保護に関する見解を共有しました。 今日、このタスクがどのように解決されているかについて、ソーラーJSOCサイバー攻撃監視および対応センターでお話ししたいと思います。 カットの下では、WAFの戦闘操作がすべてです。どの作業方法が最も効果的であると考えられるか、顧客のWebサービスがどのように攻撃されるか、WAFがどのように満たされるか（そして満たされない場合もあります）。







ベンダーの選択と製品の導入に加えて、WAFに関連する最も重要な側面の1つは、その継続的な運用です。 同時に、Webアプリケーションファイアウォールを操作する古典的なアプローチは非常に条件付きであり、多くの重要な機能を備えています。



まず、WAFの場所とWAFが保護するリソースの種類により、署名の迅速な更新とその上へのパッチのインストールは、他の機器の場合よりもはるかに高い優先順位です。 ウェブサイトは常に突出しているため、特に新しく公開されたさまざまな脆弱性に対して脆弱です。 数日間の遅延は、深刻な損失と保護されたリソースのハッキングにつながる可能性があります。 ベンダーは署名を迅速に発行しますが、通常、それらをブロッキングモードで起動するプロセスにはいくつかの手順が必要です。 まず、障害の数を観察し、署名が機能したパケットを分析すると、トレーニング手順が成功します。 その後、別のモードに転送されます。 ただし、重大な脆弱性の場合、署名をすぐにブロックに変換するか、ベンダーの更新を待たずに署名を自分で記述する必要があります。



次に、WAFを使用すると、オンラインに近いモードでのインシデント対応、ポリシーとプロファイルの分析と運用の調整など、プロアクティブな活用が最前線になります。 これは、一部の障害がブロックされず、WAFによってのみ修正されるハイブリッド操作モードの場合に特に当てはまります。 これは、正当な要求をブロックするリスクを最小限に抑えるために行われます。



第三に、リリースサイクルが短縮されるため、動的コンテンツとプロファイリングの問題には、フルタイムモードで動作する運用スペシャリストの存在が必要です。

WAF操作

操作のタスクには何が含まれますか？ 私は4つの主な分野を特定しました：

1. 更新-エラーをカバーするパッチを含む追跡パッチ。 これは上記で述べたので、次に進みます。
2. プライベート署名の作成：
   
   
   • 新しい重要な署名の追跡、顧客との共同テスト、および公式アップデートがリリースされるまでの期間の対策の準備（カスタムアップデートを作成できない場合）。
   • アプリケーションのソースコードの脆弱性を解決するための補償手段として署名する：
     
     
     • 開発者に知られている脆弱性、その閉鎖にはソースコードの大規模な変更が必要です。
     • アプリケーションのソースコードの分析の結果として特定された脆弱性。
3. 要求のプロファイリング、サイトページ、アプリケーションへのアクセス。
4. 検証-保護されたリソース/アプリケーションの要求/応答パラメーターの検証と分析。

ただし、上記の項目のうち最初の項目のみが開発部門から自律的に実行できます。 他のすべての操作機能は、保護されたWebサイトまたはアプリケーションの開発者と密接にリンクされています。 同様に重要な役割は、収集されたプロファイルをテストし、要求ブロックモードを含む作成されたポリシーをテストすることです。



「come-configured-enabled-works」オプションは99％のケースで実行可能ではなく、動的に変化するコンテンツでは機能しないことは間違いないと思います。 例外は、静的な署名によるブロック要求を含め、WAFに到着するテスト更新を除外し、すぐに運用環境に「ロール」する顧客です。 つまり、WAFトレーニング機能、更新サイクル、RFCのパッチのインストール、特定の保護されたリソースのポリシーの作成について話していない場合、フルタイムの専門家やメンテナンスサービスはおそらく必要ありません。

WAFモード

最初のオプション：ブロッキングのみ-署名およびプロファイルによる。 ここでは2つのポイントを考慮する必要があります。1）正当なリクエストをブロックするリスクがかなり高い。 2）そして逆に、WAFは脆弱性とホールを悪用するリクエストをスキップできます。 大規模なスキャンでは、リクエストの99.9％がブロックされ、0.1％がパスすることがありますが、これは攻撃を成功させるのに十分です。 分析時に、0.1％が書き込まれ、ブロックに新しいカスタム署名が追加されます。



2番目のオプション：通知のみ。 この場合、署名がトリガーされたという事実に基づいて、包括的な調査を実施し、データを他のソース、たとえばSQLインジェクションを使用する場合のデータベースと相関させる必要があります。 WAF応答の膨大な量を考えると、それらをすべて手動で分析することはほとんど不可能です。



そのため、3番目のオプションが最もよく使用されます-ハイブリッド。



この場合、静的シグニチャの応答の分析が実行され、誤検知が存在しないか、最小限の数である場合、それらはブロッキングモードに転送されます。



並行して、アナリストは、異常をさらに特定するために、サイトとユーザーのアクティビティをプロファイリングします。 ここで、サイトプロファイルに基づいて作成されたポリシーをブロックモードに移行することは、重大な分析と開発との対話なしでは不可能であることに注意してください。 そうでない場合、正当なリクエストをブロックする恐れがあり、顧客の評判が失われます。



同時に、動的なコンテンツと、顧客の活動に関連する新たに発生する状況の両方により、ポリシー、カスタム署名、および例外のリストの改良は終わりません。これは継続的なプロセスです。



以下は、いずれかのクライアントの署名グループを設定する例です。 サービスの一環として、WAFとWebサーバーログ（IIS）をSolar JSOC SIEMシステムに接続しました。 例外を作成する必要がある場合、重要な署名はブロックモードになり、ログに記録されてトレーニングリストに追加されます。







コンテンツ設定：







無効なリクエストヘッダーはまだブロックされていませんが、トレーニングが進行中であり、そのようなリクエストはログに記録されます。







どちらのオプションを選択する場合でも、操作をトリガーしたリクエストとアプリケーションへの未送信リクエストの両方を分析する必要があることを覚えておくことが重要です。 さらに、WAFに強制的に失敗したログを記録させることは負荷の観点から非常に時間がかかるため、アプリケーション自体またはWebサーバーのログを確認することをお勧めします。

カスタム署名

Web Application Firewallを使用する上で最も重要な側面の1つは、カスタム署名の作成です。 これはいくつかの場合に必要です：新しい脆弱性の出現、追加の分析を必要とする異常の登録、およびアプリケーションの長期認証統計の収集。



シェルショックなどの深刻な脆弱性が発生した場合、ポリシーの運用上の改善が必要です。 通常、WAF運用サービスは1〜2時間以内に実装できますが、ベンダーは数日かかる場合があります。 このような状況での先延ばしは、攻撃者がほぼ瞬時に働き、すべての白いインターネットアドレスで脆弱性をスキャンするため、この脆弱性を悪用する恐れがあります。



手動分析を使用して異常を識別する例は、送受信される大量のトラフィックに関する統計の収集です。 一般的なケースでは、セッションの大部分はインシデントを示していませんが、一般的な統計を表示すると、本当に重要なポジティブを見つけることができます。 同様に、非標準の拡張子でファイルのダウンロードを監視する-一般に、このような添付ファイルをブロックすることは実用的ではありませんが、サンドボックスを使用するなど、それらを分析することをお勧めします。

動的コンテンツを操作する

絶えず変化するコンテンツを使用した作業の正しいサイクルは、私には思えますが、次のようになります。

1. 生成されたポリシーは、バトルサーバーからテスト環境にアップロードされます。
2. 更新されたコンテンツのテスト中に、現在のWAFポリシーとの互換性が同時にテストされ、必要に応じて調整されます。
3. 理想的なスキームでは、アプリケーションまたはサービスの更新はパイロットグループ（地域）でテストされます。 この時点で、WAFポリシーはブロッキングモードになり、フィールドでテストされます。 ポリシー構成の調整と微調整も実行されます。
4. さらに、更新とポリシーは顧客のすべての顧客にグローバルに適用され、次の更新まで参照になります。

理想的な世界では、実稼働前の環境、機能テスト、ストレステストが約2週間続きます。 しかし、人生は時々物事を異なるように置きます。 約30％のケースでは、更新プログラムがすぐに生産的なサーバーに展開されたときに、顧客向けのアプリケーションとWebサイトの開発を減らすモードで作業する必要があります。 この場合、WAFポリシーを新しい労働条件に迅速に調整する必要があります。 これを行うために、プロファイリングは短期間（半日から1日）開始されます。 トラフィック量が多いため、多くの場合、これで十分です。 この時間が経過すると、「事前にプロファイルされた」更新されたポリシーはブロックモードになります。



どちらの方法でも、ブロッキングモードへの移行中は、オペレーティングサービスからの追加の注意が必要です。 これは、ブロックされた要求を手動で分析するために行われます。これは、インテリジェントなトレーニングおよびプロファイリングシステムが誤検知なしに完全に機能することはできないためです。



以下に、お客様との開発サイクルの2つの顕著な例を示します。



最初のケース-顧客は週に1つのリリースを発行します。 同時に、顧客と請負業者とのやり取りでは、詳細なリリースノートが提供されないため、ポリシーの調整が必要かどうかを理解できます。 唯一のオプションは、WAFポリシーを調整するための短い運用サイクルで「ホット」に動作することです。







他のクライアントでは、サイトの一部が新製品、プロモーションなどの配置の一部として1日に数回変更されます。 サイトのコンテンツのこの部分で収集されたプロファイルにプロファイリングとブロックを含めることはできません。 したがって、異常監視モードで作業し、カスタム署名を作成しています。

SIEMとのWAF統合：どのように、何が必要ですか？

会社が独自または外部委託のセキュリティオペレーションセンターを使用している場合、WAFをSIEMシステムに接続すると、Web攻撃を含むすべての種類のインシデントをSIEMシステムから迅速に通知および分析できます。



SIEMシステムでインシデントを記録してさらに調査するには、次のソースを接続する必要があります。

• 直接WAF自体。
• Webサーバーのログ。 前述のように、WAFへのすべてのリクエストのロギングを有効にすると、過度の負荷が発生する可能性があるため、IISまたはApacheでのロギングを有効にする方が簡単です。
• 要求追跡用のWAF保護アプリケーションログ。
• クエリ追跡用のデータベースログ。

Webサーバーまたはアプリケーションのログを収集する際の重要なポイントは、情報収集の完全性だけでなく、遡及的な分析でもあります。 SIEMシステムは、大量のデータを保存するために強化されており、要求に応じて正規表現を使用するなど、数か月の深さで遡及的に迅速に検索できます。 これは、WAFとSIEMの統合を支持するもう1つの強力な議論です。



WAFを接続するときは、インシデント調査でどのフィールド、ヘッダー、メタデータが役立つかを理解する必要があります。 例として、F5 ASMをArcSightに接続することを検討してください。







必須フィールドのうち、強調表示する価値があるものは次のとおりです。



イベントがコミットされた日付と時刻

署名の名前は、たとえば、「無効な要求の長さ」です。

攻撃の種類-たとえば、「セッションハイジャック」

要求されたURL：

/login?_*********=/sitebuilder/****/myaccount/login/*******form
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要求メソッドはGET、POSTなどです。

リクエストの送信元のアドレス

リクエストが来たアドレス

接続プロトコル

サイト応答コード

署名が機能したポリシーの名前。

このポリシーが適用された日時



ArcSightカスタム文字列フィールドには4096文字という制限がありますが、リクエスト全体を「マッピング」しました。その分析は、調査に役立つことがよくあります。







さまざまなシナリオで構成された潜在的なインシデントを監視する最初のラインのスペシャリスト：

1. 外部ホストからの異常な数の異なるWAFトリガーシグニチャは、潜在的な脆弱性スキャンです。
2. 1つの外部ホストから数日間連続して署名すると、遅いスキャンになります。
3. さまざまなホストから短時間でシグネチャのしきい値をトリガー-分散スキャン/ DDoSアプリケーションレベル。
4. 重大な脆弱性の悪用を試みました。 このシナリオの場合、当社のスペシャリストはお客様と一緒に、WAFログだけでなく、同じアドレスからWebサイトへの成功したリクエストも分析します。 さらに、分析の結果と必要に応じて、WAFポリシーが最終決定されます。

第一線の専門家がWAF運用サービスに通知した後、後者はSZIインターフェースに接続し、攻撃に対抗するためにリアルタイムでポリシーを「調整」する機会があります。 SIEMシステムに接続すると、潜在的なインシデントの迅速な通知を設定できるだけでなく、攻撃に関する情報を他のシステムからの情報で強化したり、イベントチェーンに従って複雑な相関関係を作成したりできます。 たとえば、攻撃の成功を理解するために、Webアプリケーションファイアウォールからの情報をSQLデータベースまたはローカルWebサーバーログのクエリと関連付けることができます。



インシデント処理へのアプローチ：







たとえば、顧客の1人では、オンラインストアが重要なビジネスコンポーネントです。 すべての既存のビジネスプロセスは、顧客と注文処理のロジックに「結び付けられ」ます。 ロイヤルティプログラムとして、会社は仮想ポイントを使用して、パーシャルを含む店舗での計算に使用できます。 支払い方法を選択する段階で購入する場合、クライアントはフィールドにポイント数を入力する機会があり、実際のお金の代わりに使用されます。



顧客は疑わしい取引を制御する必要があります-特定の期間に多すぎる償却済みボーナスまたはボーナス付きの取引。 別のテーブル（ArcSightのアクティブリスト）は、要約統計を収集するためのツールとして使用されます。 このシートからの毎日の荷降ろしはアナリストに送られ、現在の相関応答に該当しない異常を調査します。



次のアップロードのいずれかでレコードが見つかりました。

 modify_order_bonus ":"{\"bonusAvailable\":18.0,\"bonus\":-20000}" reason: success
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この異常を分析すると、クライアントの1人が、Webサイトのロジックを欺くために引き落とす必要のあるボーナスのさまざまなバリエーションを含むPOSTリクエストを使用しようとしたことがわかりました。 そして、彼は彼の方法を得ました！ 負の値を送信するとき、システムは利用可能なボーナスの数を償却のボーナスの数と比較し、数学的不等式を実行するときにプロセスを承認しました。



しかし、これがすべてではありません。情報がWebサイトから送信された特殊なシステムで注文をさらに処理する際に、借方記入に必要なボーナスの値はモジュロで取られました。 したがって、アカウントに18ポイントがある場合、クライアントは2万ルーブルの割引を正常に受け取りました。



リクエスト構造が正しく、リクエストの数が疑わしくなかったため、Webアプリケーションファイアウォールは異常を検出しませんでした。 その後の統計の収集と、生きているアナリストの目を通してのイベントの表示によってのみ、クライアントの主要なビジネスアプリケーションでの不正行為の成功を特定することができました。



これから次の結論を引き出すことができます：ポイントオフ、お金などの重要なアプリケーションへの重要な要求は、WAFのカスタムポリシー設定を使用するか、アプリケーションログとSIEMシステムでのさらなる分析を接続することによって記録する必要があります。

アプリケーション環境の保護

すべてのハッカーがアプリケーションを「額に」攻撃するわけではありません。 場合によっては、企業のインフラストラクチャに侵入し、内部からアプリケーションまたはそのベースを攻撃して直接変更する方がはるかに簡単です。 さらに、アプリケーションへのアクセス権を持つものを含む内部攻撃者が存在し、彼らはそれ以上に制御する必要はありません。



この問題をWAFで解決することは不可能であり、これはSIEMシステムで機能します。 主要なアプリケーションを保護するケースは包括的に解決されており、通常、SIEMに接続されるソースには次のものが含まれます。

• アプリケーションサーバー、データベース、補助システム、ターミナルサーバーのオペレーティングシステムのログ。
• アプリケーションセグメントを他のセグメントから分離するファイアウォールのログ。
• WAFをログに記録します。
• アプリケーションログ（フロントエンド、バックエンド）。
• Webサーバーのログ。
• 少なくとも認証レベルで、データベース自体へのリクエストのレベルで、アプリケーションデータベースのログ。
• VPNは、請負業者がリモート接続を介してアプリケーションを操作する場合に記録します。

次に、現在のリスクの分析と、潜在的な攻撃、不正な操作、アプリケーションの違反のベクトル：

• アプリケーションで請負業者の仕事を監視します。
• 特権従業員の仕事の監視。
• アプリケーションに対する外部攻撃の検出。

上記で定義されたベクトルに基づいて、接続に必要なソースとコントロールポイントは、SIEMシステムで構成された相関ルールの形式で決定されます。



インシデント検出ルールの構成には、通常3つのブロックが含まれます。

• ユーザーアクションの制御-アプリケーション/データベースへのアクセス、特権ユーザーを含むすべてのタイプのユーザーの操作。
• キーテーブル、ファイル、レジストリブランチ、環境設定、実行中のサービスおよびプロセスの整合性を監視します。
• 異常の識別-統計に基づいてプロファイルを収集し、さらにそれからの逸脱を監視します。

アプリケーション環境でインシデントを検出するためのルールの大部分は、基本的なロジックではほとんど変わりません。カスタマイズは、アクティブリストの構成を変更することで行われます。 プロファイリングルールにも同じことが当てはまります。



ほとんどの場合、アプリケーション自体の操作に関連するコンテンツは個別に作成され、システム調査、所有者と開発者とのインタビュー、ボトルネックを見つけるためのさらなる分析が含まれます。



この記事を要約すると、主要なアプリケーションとサイトのセキュリティは外部の直接的な脅威に部分的にしか関係しておらず、潜在的な攻撃と不正な操作の幅広いベクトルを常に考慮する価値があることを強調したいと思います。