インシデント管理：「あきらめることはできません」またはコンマを配置する技術

普及している市場ニッチが、情報セキュリティ取引の恐怖からマーケターをどのように引き付けているかに気付いていますか？ 彼らは、サイバー攻撃が発生した場合、企業はインシデントに対応するためのタスクに対処できないことを確信しています。 そしてもちろん、親切なウィザードが表示されます-面倒や意思決定の必要性から顧客を救うために一定量の準備ができているサービスプロバイダー。 このようなアプローチがウォレットだけでなく会社のセキュリティレベルにとっても危険である理由、サービスプロバイダーの関与がもたらす実際的なメリット、顧客の責任範囲に常に残すべきソリューションを説明します。







まず、用語を扱います。 インシデント管理に関しては、SOCとCSIRTの2つの略語がよく耳にされますが、マーケティングの操作を避けるためには、その重要性を理解することが重要です。

SOC（セキュリティオペレーションセンター）-情報セキュリティの運用タスク専用のユニット。 ほとんどの場合、SOCの機能について話すとき、人々はインシデントの監視と特定を意味します。 ただし、通常、SOCの責任には、インシデントの結果への対応と排除、ITインフラストラクチャを改善し、企業のセキュリティレベルを高めるための方法論的活動など、情報セキュリティプロセスに関連するタスクが含まれます。 同時に、SOCは多くの場合、さまざまなプロファイルの専門家を含む独立したフルタイムのユニットです。

CSIRT（サイバーセキュリティインシデント対応チーム）-新たなインシデントへの対応を担当するグループ/一時的に編成されたチームまたはユニット。 CSIRTには通常、情報セキュリティの専門家、SZIの管理者、およびフォレンジックのグループで構成される恒久的なバックボーンがあります。 ただし、各ケースのチームの最終的な構成は脅威ベクトルによって決定され、ITサービス、ビジネスシステムの所有者、さらにはPRサービスを備えた会社の経営陣（メディアのネガティブなバックグラウンドを平準化するため）で補うことができます。

その活動では、CSIRTはほとんどの場合、完全なインシデント管理サイクルを含むNIST標準によってガイドされているという事実にもかかわらず、現在、マーケティング空間の重点はより頻繁に対応活動に置かれており、この機能をSOCに否定し、これら2つの用語を対照しています。



SOCの概念はCSIRTに関連してより広範ですか？ 私の意見では、はい。 その活動において、SOCはインシデントに限定されず、組織のセキュリティレベルのサイバーインテリジェンスデータ、予測、分析に依存し、より広範なセキュリティタスクを含めることができます。



しかし、インシデント管理の手順とフェーズを記述する最も一般的なアプローチの1つとして、NIST標準に戻ります。 NIST SP 800-61標準の一般的な手順は次のとおりです。

1. 準備：
   
   
   • インシデントを処理するために必要な技術インフラストラクチャを作成する
   • インシデント検出ルールを作成する
2. インシデントの識別と分析：
   
   
   • 監視と識別
   • インシデント分析
   • 優先順位付け
   • アラート
3. ローカリゼーション、中和、および回復：
   
   
   • インシデントのローカリゼーション
   • インシデントサインの収集、保管、および文書化
   • 災害軽減
   • インシデント復旧
4. 系統的な活動：
   
   
   • インシデント概要
   • ナレッジベースフィル+脅威インテリジェンス
   • 組織的および技術的な対策

NIST標準はインシデントレスポンス専用であるという事実にもかかわらず、レスポンスの大部分は「インシデントの検出と分析」セクションで占められており、実際にはインシデントの監視と処理の古典的なタスクについて説明しています。 なぜそんなに注目されているのですか？ 質問に答えるために、これらの各ブロックを詳しく見てみましょう。

準備する

インシデントを識別するタスクは、インシデントを識別するためのルールに基づく脅威モデルと侵入者モデルの作成と「着陸」から始まります。 さまざまな情報保護ツール、ITインフラストラクチャコンポーネント、アプリケーションシステム、Technical System Element（ACS）およびその他の情報リソースからの情報セキュリティイベント（ログ）を分析することにより、インシデントを検出することができます。 もちろん、スクリプト、レポートを使用してこれを手動で行うこともできますが、情報セキュリティインシデントを効果的にリアルタイムで検出するには、依然として特別なソリューションが必要です。



SIEMシステムはここで助けになりますが、その操作は、「生の」ログの分析と、ソースの接続からインシデントルールの作成までの各段階での探求に劣りません。 難しさは、異なるソースからのイベントの外観が統一されている必要があり、システムまたはハードウェアのクラス/メーカーに関係なく、イベントの主要パラメーターをSIEMの同じイベントフィールドにマッピングする必要があるという事実に関連しています。



インシデントを検出するためのルール、侵害の指標のリスト、サイバー脅威の傾向は、SIEMのいわゆる「コンテンツ」を形成します。 ネットワークおよびユーザーアクティビティのプロファイルを収集し、さまざまな種類のイベントの統計を収集し、一般的な情報セキュリティインシデントを識別するタスクを実行する必要があります。 インシデントを検出するためのルールをトリガーするロジックでは、特定の企業の特定のインフラストラクチャとビジネスプロセスを考慮する必要があります。 会社の標準インフラストラクチャおよびビジネスプロセスが行われていないため、SIEMシステムの統一されたコンテンツは存在できません。 したがって、会社のITインフラストラクチャのすべての変更は、セキュリティ機器の設定と調整、およびSIEMの両方にタイムリーに反映される必要があります。 システムがサービスの提供の開始時に1回のみ設定された場合、または年に1回更新された場合、これにより軍事事件を検出し、誤検知を数回正常にフィルタリングする機会が減少します。



したがって、セキュリティ機能の設定、ソースのSIEMシステムへの接続、およびSIEMコンテンツの適合は、インシデントに対応するための主要なタスクであり、それなしでは先へ進むことはできません。 結局、インシデントがタイムリーに記録されておらず、識別と分析の段階を経ていない場合、もはや対応について話しているのではなく、その結果でのみ作業することができます。

インシデントの検出と分析

監視サービスは、24時間年中無休でリアルタイムモードでインシデントを処理する必要があります。 このルールは、安全の基本と同様に、血で書かれています。重大なサイバー攻撃の約半分は、金曜日に夜間に開始されます（たとえば、WannaCryランサムウェアウイルスの場合）。 最初の1時間以内に保護対策を講じなかった場合、すでに遅すぎる可能性があります。 この場合、記録されたすべてのインシデントを、NIST規格で説明されている次のステップに転送するだけです。 ローカライズの段階までは非現実的です。その理由は次のとおりです。

1. 何が起こっているかに関する追加情報を取得したり、誤検知を除外したりすることは、インシデントのローカライズではなく、分析の段階で簡単かつ正確です。 これにより、インシデント対応プロセスの次の段階で参照されるインシデントの数を最小限に抑えることができます。インシデント対応マネージャー、対応チーム、ITシステム、およびSIS管理者など、上位レベルの専門家が考慮に入れる必要があります。 誤検知を含むすべての些細な問題をCISOレベルにエスカレートしないようにプロセスを構築する方が論理的です。
2. インシデントの対応と「抑制」には、常にビジネスリスクが伴います。 インシデントへの対応には、不審なアクセスをブロックし、ホストを隔離し、リーダーシップレベルにエスカレートする作業が含まれる場合があります。 誤検知が発生した場合、これらの各ステップはインフラストラクチャ要素の可用性に直接影響し、インシデント管理チームは、複数ページのレポートとメモを使用して、自身のエスカレーションを長期間「強制的に終了」します。

通常、エンジニアの最前線は24時間年中無休の監視サービスで働いており、SIEMシステムによって記録された潜在的なインシデントの処理に直接関与しています。 そのようなインシデントの数は1日に数千に達する可能性があります（これもローカライズ段階まで？）が、幸いなことに、それらのほとんどはよく知られているパターンに適合します。 したがって、処理の速度を上げるために、必要なアクションを段階的に説明するスクリプトと指示を使用できます。



これは、アナリストの2行目と3行目の負荷を軽減できる実証済みのプラクティスです。既存のスクリプトに適合しないインシデントのみが送信されます。 そうしないと、2番目と3番目の監視ラインでのインシデントのエスカレーションが80％に達するか、1番目のラインに高い専門知識と長いトレーニング期間を持つ高価な専門家を配置する必要があります。



したがって、第一線の従業員に加えて、スクリプトと指示を作成し、第一線の専門家を訓練し、SIEMでコンテンツを作成し、ソースを接続し、操作性を維持し、SIEMをクラスシステムIRP、CMDBなどと統合するアナリストとアーキテクトが必要です。



重要な監視タスクは、SIEMシステムでさまざまなレピュテーションベース、APTレポート、ニュースレター、およびサブスクリプションを検索、処理、および実装することです。これらは最終的に侵害の指標（IoC）に変わります。 インフラストラクチャ上の攻撃者による隠れた攻撃、ウイルス対策ベンダーによって検出されないマルウェアなどを特定することができるのは、それらのおかげです。 ただし、イベントソースをSIEMシステムに接続するように、脅威に関するこのすべての情報を最初に追加するには、いくつかのタスクを解決する必要があります。

• インジケーターの追加の自動化
• 適用性と関連性の評価
• 情報の陳腐化の優先順位付けと会計
• そして最も重要なことは、どの保護手段から情報を取得してこれらの指標を検証できるかを理解することです。 ネットワークのものですべてが非常に簡単な場合-ファイアウォールとプロキシをチェックし、ホストのものではより困難です-ハッシュを比較するもの、すべてのホストで実行中のプロセス、レジストリブランチ、ハードドライブに書き込まれたファイルをチェックする方法は？

上記では、インシデント対応プロセスを構築する企業が直面しなければならないインシデントを監視および分析するプロセスの側面の一部のみに触れました。 私の意見では、これはプロセス全体で最も重要なタスクですが、情報セキュリティインシデントがすでに記録および分析されている作業ブロックに進みましょう。

ローカリゼーション、中和、回復

一部の情報セキュリティの専門家によると、このブロックは、監視チームとインシデント対応チームの違いを決定するものです。 NISTが何を入れているかを詳しく見てみましょう。

インシデントのローカリゼーション

NISTによると、インシデントローカリゼーションプロセスの主なタスクは、戦略を開発することです。つまり、企業のインフラストラクチャ内でのインシデントの拡散を防ぐための対策を決定することです。 これらの対策の複雑さには、ネットワークレベルでのインシデントに関与するホストの隔離、情報保護ツールの動作モードの切り替え、さらにインシデントの被害を最小限に抑えるための企業のビジネスプロセスの停止など、さまざまなアクションが含まれます。 実際、戦略はプレイブックであり、インシデントのタイプに応じたアクションのマトリックスで構成されています。



これらのアクションの実装は、IT技術サポート、システム（ビジネスシステムを含む）の所有者と管理者、サードパーティの請負業者、情報セキュリティサービスの義務のシフトの責任分野に関連する場合があります。 アクションは、EDRコンポーネントによって手動で実行でき、コマンドで使用される自己記述スクリプトも実行できます。



この段階で行われた決定は企業のビジネスプロセスに直接影響を与える可能性があるため、ほとんどの場合に特定の戦略を適用する決定は内部情報セキュリティマネージャーのタスク（多くの場合、ビジネスシステムの所有者が関与）であり、 このタスクを外部委託することはできません会社の インシデントのローカライズにおける情報セキュリティサービスプロバイダーの役割は、顧客が選択した戦略の運用アプリケーションに限定されます。

インシデントサインの収集、保管、文書化

インシデントを封じ込めるための運用措置が講じられたら、徹底的な調査を実施して、範囲を評価するためにすべての情報を収集する必要があります。 このタスクは2つのサブタスクに分かれています。

• 追加の入力を監視チームに転送し、インシデントに関連する情報セキュリティイベントの追加ソースをイベント収集および分析システムに接続します。
• フォレンジックチームを接続して、ハードドライブイメージを分析し、メモリダンプ、マルウェアサンプル、およびこの事件でサイバー犯罪者が使用したツールを分析します。

また、事件調査の枠組み内ですべてのユニットの活動を調整するために、人を任命する必要があります。 この専門家は、調査に関与したすべてのスタッフの権限と連絡先を持っている必要があります。 請負業者の従業員はこの役割を実行できますか？ 可能性が高いはい。 この役割を専門家または顧客の情報セキュリティサービスの責任者に任せる方が論理的です。

災害軽減

さまざまな部門からインシデントの全体像を受け取ったコーディネーターは、インシデントの結果を排除するための手段を開発します。 この手順には以下が含まれます。

• マルウェア/侵入者の存在の痕跡と侵害の検出されたインジケータの削除。
• 感染したホストの「リロード」とユーザーパスワードの変更。
• 最新の更新プログラムをインストールし、攻撃で使用される重大な脆弱性を排除するための補償手段を開発します。
• GISのセキュリティプロファイルを変更します。
• 関連するユニットによって実行されるアクションの完全性と、侵入者によるシステムの再妥協の欠如を監視します。

対策を作成する場合、コーディネーターは、特定のシステム、情報セキュリティシステムの管理者、フォレンジックグループ、およびISインシデントモニタリングサービスを担当する専門ユニットに相談することをお勧めします。 ただし、特定の対策の適用に関する最終決定は、インシデント分析グループのコーディネーターによって行われます。

インシデント復旧

このセクションでは、NISTがIT部門とビジネスシステムオペレーションサービスのタスクについて実際に話しています。 すべての作業は、会社のITシステムおよびビジネスプロセスのパフォーマンスの復元と検証に限定されます。 ほとんどの企業はこれらの問題の解決に直面しているため、情報セキュリティインシデントの結果ではないとしても、少なくとも最も安定したフォールトトレラントシステムのインストールでさえ定期的に発生する障害の後は、この点に留まるのは意味がありません。

整然とした活動

インシデント対応手法の4番目のセクションは、バグの処理と会社のセキュリティテクノロジの改善に専念します。



原則として、知識ベースとTIを埋めるインシデントレポートの準備については、フォレンジックチームが監視サービスと連携して責任を負います。 ローカライズ戦略がこのインシデントの時点で開発されなかった場合、その記述はこのブロックに含まれます。



バグに取り組む上で非常に重要な点は、将来同様のインシデントを防ぐ戦略を開発することであることは明らかです。

• ITインフラストラクチャと既存のGISのアーキテクチャを変更します。
• 新しい情報セキュリティツールの導入。
• パッチ管理および情報セキュリティインシデントの監視プロセスの導入（ない場合）。
• 会社のビジネスプロセスの修正。
• 情報セキュリティ部門の追加スタッフ。
• 情報セキュリティ従業員の権限の変更。

サービスプロバイダーの役割

したがって、インシデントレスポンスのさまざまな段階でのサービスプロバイダーの参加の可能性は、マトリックスの形式で表すことができます。







インシデント管理へのツールとアプローチの選択は、情報セキュリティの最も難しいタスクの1つです。 サービスプロバイダーの約束を信頼し、すべての機能を提供する誘惑は素晴らしいものになりますが、経済的およびプロセス効率の両方の利益のために、状況の適切な評価と、内部リソースと外部リソースの使用のバランスをとることをお勧めします。