web-dev-qa-db-ja.com

ITとビジネスの統合のためのWAFプロセスの作成

クライアントから、WAFプロセスを支援するよう依頼されました。現在、いくつかの重要なWebアプリケーションがいくつかのWAFによって保護されています。 WAFを調整して、本番環境で使用する準備ができました。会社はかなり大きく、拡大しています。したがって、私は会社のIT部門をビジネス側に統合するプロセスを作成することにより、Webアプリケーションのセキュリティの管理性に取り組みたいと考えています。同時に、これまでのところ、私が作成しようとしている3つの異なるプロセスを1つにまとめたいと思っています。

プロセス1

XSSの試みがWAFによって検出されて警告されたとしましょう。運用セキュリティが単にそのIPからのトラフィックをブロックしてブロックすることは望ましくありません。この決定は、OpSecではなく、ビジネスの権限に該当するはずです。 WAFが実装されたのはそれほど昔ではないので、デフォルトでは気に入らないものはすべてブロックすることにしぶしぶ思います。現時点では、この目的のための専用データベースがないため、スプレッドシートトラッカーを作成する必要があります。

これをどのように行うかを定義するプロセスは、潜在的に次のように単純である可能性があります。

 1. Operational Security is notified of an alert against one of their
    assets.
 2. Operational Security immediately checks their Security Information
    Event Management for signs of compromise.
 3. If there is a sign of compromise, an high-priority Security Incident
    is raised and the IP is blocked.
 4. If there is no sign of compromise, the IP is not blocked, but a
    low-priority incident is raised and forwarded onto the service owner
    of the web application being attacked.
 5. Business makes a decision whether this should blocked or not based
    on certain information such as “has this IP been seen before?”
 6. Security Management logs all the activity on their Tracker.

プロセス2

保護のためにアプリケーションがWAFに追加されたとき、またはアプリケーションがWAFの保護から削除されたときのために、別のプロセスを準備する必要があります。このプロセスだけでも簡単です。 Security Managementはすべてのアクティビティをトラッカーに記録します。

プロセス3

最後に、おそらくもう少し複雑なプロセスでは、WAFによってすでに保護されているアプリケーションへの重要な変更（追加/削除されたページ/パラメーターなど）を追跡する必要があります。これはWAFのアラートの処理に影響します。これまでのところ、私は次のようなものを考えました：

 1. If a project is to change any of the application’s contents, they
    should notify and liaise with Security Management
 2. Security Management sends a Questionnaire for the project to fill in.
 3. Project forwards the filled Questionnaire to Security Management.
 4. Security Management can then tune the WAFs to reflect these changes.
 5. Security Management continues to monitor the application for say,
    one week and if so, the changes are consolidated.
 6. Should any issues occur, Security Management is to liaise with the
    project to address the problem.
 7. Security Management logs all the activity on their Tracker.

質問：

  1. これらの3つのプロセスは（不適切に）適切ですか、それとも全体のステップ/プロセスが不足していますか？
  2. これらすべての問題に対処する1つのプロセスが本当に良いのですか、それとも3つ（またはそれ以上）の別々のプロセスとして保持する必要がありますか？
  3. 誰かがトラッカーやアンケートのテンプレートに出くわしたり、それらをどのようにレイアウトするべきかについて提案がありますか？これまでのところ、1つのトラッカーワークブックに加えて、サブプロセスごとに1つずつ、3つの異なるタブを備えた1つのアンケートを用意することを考えていました。
  4. これを行うより良い方法はありますか？
  5. 最後に、IPをブロックするかどうかを決定するためのビジネスの根拠はどのようにすべきですか？
web-applicationcorporate-policywafoperationsopsec
13
Lex

1.これらの3つのプロセスが適切であるか、それとも全体のステップ/プロセスがないか？

SSL暗号化トラフィックを検査する必要がありますか？ WAFがネットワークのどこに配置されているかに応じて、WAFがトラフィックを表示する方法に関して、証明書のプロビジョニングと更新を処理するプロセスが必要になる場合があります。

私はそれをこれらの領域に分けます：

  • 潜在的なインシデントへの対応

    • 検出されたイベントの調査/フォレンジック
    • イベントへの応答
      • 真のインシデントへの正しいアプローチを決定する-あなたのプロセス1
      • 誤検知のケースを減らす

  • 変更の管理

    • 新しいアプリ
    • 古いアプリへの大きな変更
    • 古いアプリへの小さな変更

  • 全体的な健康管理

    • トラブルシューティング
    • アップグレード
    • 事業継続性

2.これらすべての問題に対処する1つのプロセスが本当に良いですか、それとも3つ（またはそれ以上）の別々のプロセスとして保持する必要がありますか？

これは通常、プロセスを文書化する方法に大きく関係しています。単純に膨大なインフラストラクチャと組織で作業する人として、私は常に書類、プロセス、ドキュメントの階層内で作業しています。そして、そのような世界で提供する可能性のあるものはすべて、既存のモデルに適合すると優れています。奇妙にすると、人々はそれを理解したり使用したりしなくなります。

現在は小さめですが、大きくなることを期待している成長している組織の場合-私の大きな警告は、最初のブレイクアウトは組織または分野に関連している必要があり、各プロセスはそれを引き起こすトリガーによってグループ化されることです。したがって、理想的には、人々と同じくらい明確に分離されたチャンクで終わることになります。

私の経験では、運用担当者と開発者は非常に異なる遺伝子プールであり、ほとんど別の種として数えられています。彼らは同じような言葉を使うかもしれませんが、それらが単一のツール、プロトコル、またはアイデアにどのように取り組むかは、根本的に異なる場合があります。このため、私の最初の内訳はそこにあります：

1-運用ガイド-運用チームが利用でき、できればファイアウォールなどの既存のプロセスに組み込まれています。

  • wAFによってインシデントが検出された場合の対処

    • 既知の可能性の高いケース
    • 不明なプロセス（どこから始めればよいかわからない場合の対処方法）
    • 開発者へのハンドオフが含まれます-誤検知のバグレポートはどこに書きますか？問題の調査を支援する開発者が必要な場合はどうしますか？等.

  • 責任範囲のガイドライン

  • リスクを管理するためのガイドラインと、いつ、どこでリスクの承認を得るか

2-WAFメンテナンスガイド-チームがこのコンポーネントをメンテナンスするためのガイドです。 WAFはおもしろい-境界制御担当者（ファイアウォールの一団）かもしれないし、Webサーバーのサポートかもしれないし、他の何かかもしれない。アーキテクチャと組織に依存

3-ソフトウェアの導入と保守-WAFで保護されたサーバーの場合-WAFで保護されたサイトにソフトウェアを導入する方法、WAFインシデントのデバッグを支援する方法.

基本的に、WAFまたはWebサーバーで作業している人々が通常見る場所にそれらをリンクできる範囲でプロセスを分離します。

3.トラッカーやアンケートのテンプレートに出くわしたことはありますか？これまでのところ、1つのトラッカーワークブックに加えて、サブプロセスごとに1つずつ、3つの異なるタブを備えた1つのアンケートを用意することを考えていました。

共有できるわけではありません。私はこれのほとんどに企業の保護されたフォーマットを使用しています。

4.これを行うより良い方法はありますか？

さらに、ここで作成するものはすべて生きたドキュメントであることを認識してください。今日はXSS攻撃かもしれませんが、明日は何か違うかもしれません。ナレッジストアを構築するプロセス、可能な場合は自動化、および明確に伝達する方法（危機的状況と危機的状況の両方）を作成したいと考えています。

5.最後に、IPをブロックするかどうかを決定するためのビジネスの根拠はどのようにすべきですか？

WAFはIPよりもはるかに多くブロックします。具体的にIPを探す場合、フォレスト内の個々のツリーをブロックしようとしていると思います。具体的には、IPブロッキングについては、WAFを使用しているすべての組織がファイアウォールも使用していると思います。IPブロッキングは、ファイアウォールタイプの同じプロセスと一貫した方法で管理されます。

リスク全体で、全体的に-理想的には、リスクの性質に関係なく一貫した構造が存在する必要があります-既知の悪意のある攻撃者の動作のブロック、既知の攻撃プロファイルの脆弱性のブロックなど-かなり高いエンティティが存在する必要がありますリスクを評価することがその職務であるレベル。トレードオフは次のように要約されます。

  • システムおよびビジネス全体のセキュリティが、弱点を残したままにするリスク（現在許可しているものを許可する）

  • 防御を強化する際のビジネスオペレーションのリスク-脅威をブロックするときに何ができませんか？

  • それを行う/行わないためのコスト

決定を下す人は通常、組織内で説明責任を負うことができる高レベルの人です。多くの場合、ISO-情報セキュリティ担当者です。しかし、IT側だけでなく、ビジネスを見るのに十分な高さのある人。可能性としては、いくつかのものが一般的なガイドラインにまとめられる可能性があります-したがって、この人はIPごとにIPを実行しません-彼はいくつかのルールを設定します-IP攻撃がいくつかのメトリックよりも大きい場合、確実にブロックします...など。

7
bethlakshmi