web-dev-qa-db-ja.com

企業ネットワークの平均的なインシデント対応プロセスには何が入りますか？

私はセキュリティのよりプロセス指向でポリシー指向の側面をブラッシュアップしようとしており、インシデント対応に興味があります。ほとんどのセキュリティ担当企業には、企業ネットワーク内のセキュリティインシデントへの対処方法を管理する、ある種の基本的なセキュリティインシデント対応プロセスがあることを理解しています。

標準的なインシデント対応プロセスの一部として考慮する必要のある要素は何ですか？証拠の法医学的完全性など、焦点を当てるべき特定の分野はありますか？これは、組織やインシデントの種類によって大きく異なるようなものですか、それとも共通の要素がたくさんありますか？

corporate-policyincident-response
3
Polynomial

プロセスの基本セットには、次の高レベルのカテゴリを含める必要があります。

  • 脅威分析-これにはすべてのタイプの脅威を含める必要があります。自然災害、テロ攻撃、外国のスパイ活動など。起こりうる事件を理解し、それに備えるために、毎年見直す必要があります。これらの脅威はインシデントにマッピングする必要があり、これらのマッピングはインシデント対応手順の開発に役立てる必要があります。これが重要な準備段階です。

  • インシデントの分類-分類は中央で所有する必要があり、ビジネスの責任である必要があります。この分類には、エスカレーション要件とともに、影響と可能性のしきい値を含める必要があります。これは、インシデントへの対応方法、緊急性、および解決の期待の種類を判断するのに役立ちます。

  • 運用手順-コミュニケーションとエスカレーションの手順は、ビジネスユニットごとに形式化して文書化する必要があります。これらには、指名された個人またはチーム、サービスレベル、応答時間、およびチームと組織の内外の通信プロトコルを含める必要があります。関係するチームはインシデントの分類によって異なりますが、各チームは、コミュニケーション、測定、整合性、および復元力の標準要件を満たすための運用手順を必要とします。

  • インシデント後のレビュー-インシデント後のレビューは、すべてのインシデントに対して形式化され、必須である必要があります。これには、組織がインシデントの増分、長期、および無形のコストを理解するのに役立つ完全な影響評価を含める必要があります。

  • 最終的な見切り-見切りには、改善を行うことができるように、インシデントの解決時間とアクティビティの記録、および期待される結果との比較を含める必要があります。

質問の文言から、あなたは操作手順のセクションに最も興味があると思うので、ここでレベルを下げます：

運用手順には、次のような項目が含まれます。

  • インシデントの開始から少なくとも終了まで、インシデントチームによって記録されたすべての情報の保持。それ以降は、保持は企業または規制の要件に従います。
  • すべてのログローテーションを保留にする-通常のログローテーションサイクルに従う代わりに、定義された量（1時間、1日、またはそれ以上）のログが調査チームに提供されます。
  • どんな事件もは刑事事件である可能性があるので、最初はどのように見えても（例として、地殻変動-ニュージーランドの地震によって引き起こされた混乱の間に発生したハードウェアの日和見的盗難）データの記録は可能な限り完全であり、Write-Once、Read-Manyのストレージに記録する必要があります可能であれば、法医学規則を適用する必要があります。
  • 迅速に修復して通常どおりのビジネスに戻すためのアクティビティ、およびインシデントの根本原因を完全に調査するためのアクティビティの特定。
  • 内部インシデントと外部インシデントの処理方法は大きく異なる場合があります（たとえば、重要なデータを盗んだ従業員は解雇されてサイトを離れるだけで、競合他社が産業スパイを実行しているという証拠が警察に渡される場合や、静かに隠されている-これらの決定はビジネス上の成果をもたらすため、最高リスク責任者または同等のレベルで話し合う必要があります）

すべてのアイテムまたはアクティビティはコストオプションであるため、これらすべてが実行されることはめったにありません。大規模なインシデントに苦しんでいる企業は、インシデントが続くたびにお金を失う可能性があるため、最初に行うのは通常、データまたはアクティビティのフォレンジック記録です。ドライバーは、最初に通常の操作手順に戻り、その後、事後に調査を行う可能性があります。

Computer Security Incident Responseの詳細については、 このIETFドキュメント および このCERTドキュメント を確認してください。

7
Rory Alsop

あなたの質問への答えは簡単ではありません。SO/ IECTR 18044：2004やその他のベストプラクティスに依存することをお勧めします。個人的には、リスクレベル（クリティカル、高、中、低）を分類するためのカテゴリをいくつか作成し、ほとんどを特定しました。予期されるイベント、予期されるイベントは、次のように簡単に定義できます。

  • セキュリティの原則（機密、整合性、可用性）に一致するすべてのイベントは、より具体的なもの（信頼性、説明責任、否認防止など）に拡張できます。
  • 次に、内部と外部に従ってそれらを分類します（攻撃者が従業員または匿名の場合）

これで、各イベントの作成場所（ターゲット）ごとに、論理的または実際の場所になります。その後、計画に詳細を提供します。

最後に、プロジェクトのトップマネジメントからサポートを受けてください!!!

[1] http://blog.iso27001standard.com/tag/incident-response/

[2] http://www.iso.org/iso/catalogue_detail.htm?csnumber=35396

0
Akam