あなたはSOCについてほとんど知らないかもしれませんが、インシデントの特定とそれらへの対応という2つのことだけがその作業で重要であることは、直感的に明らかです。同時に、私たちが複雑な内部詐欺や専門家グループの活動の兆候を扱っているときにあなたが状況を取らない場合、応答は、原則として、非常に単純な技術的手段（ウイルス組織またはソフトウェアの削除、アクセスまたはアカウントのブロック）と組織的手段で構成されます（ユーザーからの情報の明確化、またはモニタリングにアクセスできないソースの分析結果の検証と充実）。ただし、いくつかの理由により、顧客対応プロセスは近年大幅に変化し始めており、これにはSOC側での変更が必要でした。さらに、「すべてではない」が重要である応答と正確さについて話しているので、完全性とアクションの速度の両方-内部または外部のSOCがこのプロセスの新しい要件を考慮しない場合、インシデントを正常に処理できない可能性が高くなります。
これで、「フルサイクル」サービスとしての応答をより快適に受け取ることができる多くのお客様がいます。この場合、企業の防御に対する攻撃をブロックし、ITサービスの責任の領域での応答プロセスに同行します。たとえば、ブロックの正当化を支援します。理論的にはビジネスプロセスの問題につながる可能性があります。また、アカウントのブロック、ホストの分離など、部分的に実行する必要がある作業についてアドバイスします。
しかし、大多数は依然として自分たちで技術的な対応を行うことを好み、インシデントのタイムリーな検出、誤検知の分析とフィルタリング、およびインシデントに対応する優先アクションに関する推奨事項を分析情報に提供することを求めています。
このプロセスに以前関与していて、顧客側で結果を担当したのは誰ですか？原則として、対応作業を部門の他のタスクと組み合わせた1人または2人の情報セキュリティスペシャリストは、攻撃分析に関する深いニッチな専門知識を必ずしも持っていませんでした（前の段落からわかるように、これは必須ではありませんでした）。それでも、リスク、脅威、そして何が起こっているのかを理解するのは、常に情報セキュリティの専門家です。
最近では、情報セキュリティとITサービスの間で、お客様側の対応の完全性と適時性に対する責任がますます分散されています。その理由は次のとおりです。
まず、インシデントの数とインシデントの疑いが大幅に増加しました。以前の通知の平均数が1か月あたり100〜200で測定されていた場合、現在では数倍に増加しています。問題の一部は、現在一般的に流行している用語「デジタル化」または「デジタル変換」と呼ばれるものによって引き起こされる一定の（常に固定されているわけではない）変化による企業インフラストラクチャーのエントロピーの増加です。副次作用として、ユーザーアクションがより多様になり、技術的な解決策がそれらを動作の異常として分類する可能性が高くなり、その結果、セキュリティ担当者が攻撃者と間違える可能性があります。これらは、最初のタイプの誤検知です。
第2に、もちろん、サイバー犯罪者の活動も絶えず増加しています（つまり、攻撃の数が増加しています）。これは、私たち、他の業界関係者、および顧客自身によって指摘されています。その結果、SOCは常に巧妙な攻撃検出シナリオを常に発明し、それらを顧客に確実に接続する必要があります。これはもちろん、操作の数の増加、顧客のアクションの非決定性の増加、およびインシデントに関する情報に外部コンテキストを含める必要があります（ワークステーションはそのワークステーションであり、リモートアクセスツールを使用することは社内で慣例であり、そうである場合、どのワークステーションが誰であるか）。それらは何のために使用できるかなどです。
実際、これは、対応プロセスをスピードアップするために、ますます多くの企業が情報セキュリティではなくIT部門との直接のやり取りに外部SOCを転送しようとしているという事実につながります。そして、これは非常に論理的です。ソフトウェアの削除またはアカウントのロックアウトを必要とするインシデントは、ITに直接向けられ、ホストのネットワーク分離を必要とします-ネットワーク部門+ヘルプデスクなど。会社に独自の監視センターがある場合、SIEMシステムからITにトリガーを転送することがしばしば義務付けられます。
ただし、プロセスの変更は、プロセスを遅くするリスク、当事者への不完全な情報のリスク、そして最終的には効率の低下のリスクです。幸いなことに、ほとんどの企業はこれを理解しているため、（そして場合によっては法的要件により、特にGosSOPKAセンターの作成に関して）実際の対応レベル（ITおよび情報セキュリティ部門からの推奨の完全性、品質、タイミング）を確認する要求が高まっています。会社。
ただし、監査を実施する前に、結果を達成するためのツールを人々に提供する必要があります。つまり、SOCは、各インシデントの分析結果をITの明確なルーティングに適合させる必要があります。試行錯誤により、お客様に送信するインシデント情報の要件のリストを作成しました。
インシデントの分析のこれらの結果では、技術的対応に責任のある従業員を明確に識別する必要があります。
落とし穴とは何か：責任者を正しく特定するためには、インシデントの場所を正確に特定する必要があります-特定の部門、ホストの重要度、業務提携、インシデントのタイプ。これには、在庫段階で顧客のインフラストラクチャに非常に深く没頭することが必要です（そして、非常に重要なことに、このデータを常に更新します）。
インシデントの重要度を判断するには、同じ情報が必要です。たとえば、銀行は、マガダンの支店にある車のウイルス感染に対して、よりゆっくりと、地元の情報セキュリティ専門家の助けを借りて対応する準備ができています。 KBRのローカルAWSについて話している場合、インシデントは、リスクを調整するための顧客のCISOと、ホストを即座に分離するためのサイト上のコミュニケーションセンターの専門家を含む、即時の対応と関与を必要とします。
原則として、eコマースセグメントのWebアプリケーションへの攻撃に対応するには、セキュリティ担当者だけでなく、その実装に関連するリスクをより正確に特定できるアプリケーションスペシャリストも関与し、同じホスト上のデータベースから注文に関する情報をアンロードする必要があります。それどころか、申請者（潜在的な攻撃者の1人）やITスペシャリストさえも関与すべきではありませんが、情報セキュリティに加えて、経済的セキュリティサービスの参加が必要になることがよくあります。
これらすべてのシナリオ-私たちがいつ、どの段階で、どのような目的で関与するか-は事前に解決し、お客様と合意する必要があります。 SOCは情報セキュリティについてよく知っていますが、顧客は自分のビジネスをよく理解しており、どのリスクが彼にとって最も重要であるかを理解しているため、スクリプトは一緒に開発されます。
これは、脅威とそのリスクの説明、および対応に関する推奨事項の説明の詳細レベルにも適用されます。さらに、理想的には、必要なアクションのシーケンスを必須イベントと補助イベントのツリーに分割する必要があります。たとえば、SOCがエンドホストでのリモート管理ツールの起動を記録しているが、監査レベルが攻撃者によるバックドアの潜在的な起動とユーザーアクティビティを区別するのに十分でない場合、最初の必須のポイントは、このアクティビティを開始したかどうかを調べる専門家とユーザーとの通信です。答えが「はい」の場合、これは定期的な活動か、最大で情報セキュリティポリシーの違反です。否定的な場合、それはハッカー攻撃の一部である可能性があり、完全に異なる応答作業が必要です。
応答結果の確認には、推奨事項の実装の事実（SIEMまたはその他のツールのログを使用）と、インシデントが今後再発しないという事実の両方の技術的な制御の可能性が含まれているはず
です。ホストでRATを実行する例を続けましょう。たとえば、最初のブランチである情報セキュリティポリシーに違反したユーザーアクティビティに行きました。この場合、ITサービスはホスト上のRATを削除するようにアドバイスされます。削除スクリプトの制御された起動、またはホストでのユーティリティの不在/存在のチェックに加えて、インベントリツールは、再トリガーされたときに古いインシデントとリンクする必要があります。これは、違反が繰り返されるだけでなく、応答による推奨の低品質の実装についても通知します。
最後に、インシデントのコンテキストまたはデルタ近傍が重要です。キルチェーンで収集できる同様のまたは関連する可能性のあるインシデントがあったかどうかに関係なく、最後の時間間隔中にこのマシン/アカウントに正確に何が起こったかが非常に重要です。この情報により、プロバイダーのセキュリティチームまたはインシデントレスポンスチームをインシデントに直ちに関与させる必要があるかどうかをすばやく判断できます。
各SOCは、これらの課題に対する独自の答えを探しており、さまざまなツールを使用してこれらのタスクを実行できます。主なことは、原則としてそれを実行するように制御することです。軽微なインシデントでは、対応の遅延とためらいがごくわずかになり、重大なインシデントでは、規制されていないプロセスは機能しません。そして、それはあたかも有罪者がいないかのようです。