中間のSOC。 保護対象、またはインフラストラクチャのインベントリを作成する方法を理解している

こんにちは。 「SOC for ...」というサイクルは、その動きと開発を続けています。 以前の記事で、インシデント監視および対応センターの内部キッチンの最初の層をカバーすることができたので、技術的な詳細とより微妙な問題についてもう少し深く掘り下げます。



セキュリティ管理に関する記事 や、SOCの自動化と人工知能の問題で 、アセット管理のトピックに間接的に何度か触れました。 明らかに、顧客のインフラストラクチャのインベントリがないと、監視センターはそれを保護できません。 同時に、詳細な説明を作成することは決して簡単な作業ではありません。 そして最も重要なこと-2、3か月後、それは再び関連しなくなりました：いくつかのホストが消え、他が現れ、新しいサービスやシステムが現れました。 ただし、インフラストラクチャの保護は継続的なプロセスであり、SOCは、顧客の資産に関する最新情報が取得されるまでその活動を遅くすることはできません。 Solar JSOCの仕事の質は、抽象的な約束ではなく、非常に具体的なSLAに支配されており、その違反にはさまざまな天体が続きます。 そのような状況で抜け出し、提供されるサービスの質を失うことのない方法は？







インシデント通知の比較例の1つを使用して、この問題に戻ることをお勧めします。

RATユーティリティAmmyAdminは、ホスト172.16.13.2で起動されました。

対

RATユーティリティAmmyAdminはホスト172.16.13.2で起動され、モスクワのクズネツク橋にあるオフィス、Ivanov Petr Mikhailovichのマシン、コミュニケーションセンターの副部長、MDCのフライトの機能処理、CBDのAWSとの作業、リモート管理者の作業は禁止されています。

これらの2つの通知の違いは、詳細な分析であると思われます。 最初のケースでは、通知はSIEMプラットフォームから自動的に受信されたように見えます。2番目のケースでは、オペレーターの作業とインシデントの強化が表示されます。 これはそうであり、そうではありません。 オペレーターがインシデントを分析して結論を​​出すには、これらの神秘的でほぼ同一のIPアドレスを顧客から隠している（または誰が）かを理解し、この情報をインシデントの分析に使用することが非常に重要です。



読者の約20％が次のように言うでしょう。「それでは、すべての企業がCMDBシステムを実装しています。これは、データをSIEMに接続するよりも簡単ですか？ コネクタを作成する必要さえありません。」 インテグレーターやベンダーの同僚をこの信念に任せましょう。 これを実現するのがどんなに悲しくても、CMDBからの情報は完全に無関係であるため、SIEMに接続したりエクスポートしたりするべきではありません。 そのため、袖をまくり上げて自分でやらなければなりません。 この質問を詳しく見て、IT部門の完全なサポートを期待せずに、秩序の注意を引くことなく 、インフラストラクチャの腸を理解する方法を理解してみましょう。

象を部分的に食べるか、インフラストラクチャの説明に没頭する

資産の目録を作成する動きでは、通常4つのマイルストーンを通過しようとします。



1.組織の最上位であるが詳細なネットワークマップを構築する



ここでは、顧客のIT部門が最初の主要な連絡先です（会社がネットワーク機器管理システムまたはファイアウォール管理を正しく実装および構成していない限り、これは例外です）。 ネットワーク機器、ネットワーク図などからの両方の記述情報が使用されます。



この段階の目標結果は、次の情報の識別により、すべての内部アドレスをネットワークゾーンに分割する機能です。

• 特定のIPアドレスであるサイト（ジオロケーション/ロケーション（該当する場合））。
• どのタイプのサイト（データセンター/本社/支店/販売拠点）に属しますか。
• 専用ネットワークセグメントのグローバルな目的は、ユーザー/企業Wi-Fi /ゲストWi-Fi /管理者/サーバーです。
• このネットワークセグメントのアプリケーションは、可能であれば、システムまたはビジネスアプリケーションに関連しています。

これは、 最初の重要な結論につながります。資産は、特定のホストに関する詳細なインベントリ情報の説明だけでなく、ネットワークセグメントを説明し、レポート/相関/イベント検索でこのデータを使用する機能でもあります。



SIEMでは次のようになります。







2.データセンターのメインサブシステムの説明



原則として、これらのマシンの識別の開始は、最初のビジネスインタビューに基づいて表示されます。 セキュリティ、IT、ネットワーク、およびアプリケーションの専門家とのコミュニケーションにより、最初の近似として、会社のインフラストラクチャがどのように構成され、どのリソース/システムが最も重要であるかを理解できます。 アドレス指定とネットワーク加入に関する情報を収集するのは簡単です。 さらに、ポイント質問のモードでは、必要な情報を取得することがすでに可能です。

• このホストにデプロイされているサービスとアプリケーションの種類。
• ITに応じてどの重要度クラスに割り当てられますか？
• システムの機能的役割は何ですか（予定）。

この段階では、通常、さまざまな集中管理システムからのアンロードが役立ちます。

• 仮想化システム。 多くの場合、仮想マシンの作成に関するコメントは、それらの機能的な役割を説明しています。
• Active Directoryおよびその他のディレクトリ。 少なくとも、ドメイン構造はシステムの機能的な目的に関する回答を非常に頻繁に提供します。
  
  
  
  
  
  
• さまざまなSZI（通常はアンチウイルス）には大量のインベントリ情報があります。
  
  
  
  
  
  
• または、プラットフォーム固有のアドレス指定などで主要なシステムをリストする大きなExcelファイルのみ

2番目の重要な結論は、これから続きます。完全に異なるソースから資産に関する情報を「取得」し、構成されたシナリオと監視ロジックに従ってこの情報をSIEMに追加できる必要があります。



3.情報セキュリティに関する重要なホストと資産の説明



顧客が「痛みのポイント」と最も重要なシステムを指定すると、これらのシステムがどのように関連しているか、そこに保存されているデータ、およびそれらに関連する情報セキュリティリスクを理解するために、責任者との対話に入ります。 また、追加のパラメーターによってそれらを評価し、その後、臨界レベルを高めるいくつかのシステム係数に割り当てます。 私たちが注意を払うものは次のとおりです。

• このシステムは、攻撃の収益化の面でどれほど危険です。 例としては、CBDのAWS、銀行の決済センターマシン、財務機関のマシン、および他社のクライアントバンクがあります。
• このシステムは、その上のデータを侵害するという点でどれほど重要ですか。 例としては、管理報告システム、企業秘密を含む情報を保存するフォルダーなどがあります。
• このシステムは、インフラストラクチャへの攻撃を開発するためのハッキングにどの程度使用できますか？ 例としては、中央ネットワーク機器、アンチウイルス、AD、およびセキュリティスキャナーサーバーがあります（これらを使用すると、攻撃者はどこからでもアクセスできることがよくあります）。
• このホストの重要度が高いもう1つの理由は、お客様から言われています。

例の説明：







3番目の重要な結論 ：SOCは、各資産およびシステムに入力された各サブネットに対して、ホストの目的、機能、および重要性に関する独自の説明を追加できる必要があります。 彼らが言うように、「すべてのマーカーは味と色が異なります」とITで良いことは情報セキュリティで必ずしも必要ではありません。



4.ホスト/資産に関する情報の充実



最後に、情報セキュリティシステムまたはセキュリティスキャナーからのデータでホスト/資産情報を充実させようとします。

• ハードウェアの仕様（プロセッサ、メモリ、ディスクなど）。
• OSおよびインストールされているすべてのパッチに関する情報（および、幸運な場合は、それらに関連する脆弱性がある場合でも）。
• バージョン管理付きのインストール済みソフトウェアのリスト。
• スキャン時に実行中のプロセスのリスト。
• 多くの追加情報（MD5ライブラリなど）。

この情報は調査に非常に役立つ可能性がありますが、私たちの意見では、ホストインシデント自体の重要性を特定して評価することは重要ではありません。

問題を理解する

一見したとしても、インフラストラクチャを記述するプロセスはかなり複雑に見えますが、実際にはこれらは表面にある困難にすぎません。 いつものように、中にはたくさんの石の水中熊手があります。 それらについて議論し、可能な解決策を共有してみましょう。



一意のアセット識別子を選択する



質問は平凡で明白なように思われます。 何でも選択します：少なくともIPアドレス（複数のインターフェイスがある場合、メインのインターフェイスを割り当てます）、少なくともドメイン名、少なくともシリアル番号。 しかし、人生では、すべてがそれほど単純ではありません。



ハードウェアまたはソフトウェアの識別子はどれも、その一意性とデバイスとの直接接続のために非常に優れています。 問題は1つだけです。ログを操作し、ログに基づいてインシデントを識別しますが、それらには一意の識別子がありません。 したがって、ネットワークで発生していることを資産に正しく接続する方法は（ほとんど）ありません。



DNS名は、その一意性の観点からも優れています（使用しないことを好む企業を無視します）。 しかし、残念なことに、問題は完全に類似しています。ログの大部分には、このDNS名に関する情報が含まれていません。 したがって、インシデントを資産と一致させることも問題のままです。



オプションが残っていないように思えますが、IPアドレスを操作する必要があります。 それは私たちが対処しなければならない大多数のジャーナルに現れており、サーバーセグメントの場合、デバイスを決定するためのほぼ保証された基準です。



しかし、ユーザーホストを識別するために使用しようとすると、事態はさらに複雑になります。 多くの場合、ユーザーネットワークまたはその一部では、DHCPに直面し、セグメント内でホストIPアドレスをランダムに発行します。 これにより、インシデントを処理するロジック全体が破壊されます。イベントが発生した時点で、IPアドレスは1台のマシンを参照でき、アナリストが解析または顧客のITサービスによって接続された時点で、このIPアドレスはすでに完全に異なるホストに属している可能性があります



さらに魅力的なケースがあります。 たとえば、RDP認証を使用したWindowsロギングを見てください。















その結果、イベントのタイプに応じて、識別子はホストまたはIPになります。 また、この問題は一般に、イベントの解析レベルでより適切に解決されます。



ほとんどの場合、次のホスト定義スキームを使用します。 イベントを処理するとき、いくつかの条件が順次チェックされ、最初のゼロ以外の値が選択されます（上記の例の解析に関する問題は、解析レベルで解決されます:)）。

• ネットワークは静的にアドレス指定され、このIPの資産はSIEMで設定されます（識別子=資産名）。
• アクティブなDHCPリースでは、ログからIPで取得するときにHostNameに情報があります（識別子=ドメインなしのホスト名）。
• ログにHostNameがあります（識別子=ホスト名、ドメインなし）。
• ログにIPアドレスがあります（識別子= IPアドレス）。

このプロセスは、着信イベントごとに実行され、すべての例外リスト、プロファイルなどを確認するために使用されます。



ここで重要なのは、会社のすべてのホストの資産を取得して最新の状態に保つことは決して機能しないことです。 いずれにしても、ゲストネットワーク、VPNアドレスプール、テスト環境、およびインターネットがあります。 すべてが絶えず変化しているため、これらのネットワークでアセットを開始することはできません。 ただし、同時に、アクティビティのソースを正しく判断し、同じホストのアラートを生成しないことが重要です。アラートは異なる形式でログに記録されます（たとえば、nb-hostname.domain.local、nb-hostname、10.10.10.10（ただし、nb -DHCPのホスト名））。



イベントの強化における関連インベントリ情報の使用



インシデントの分析について話すとき、ホスト上の更新/ソフトウェア/脆弱性などの存在に関する最新のデータを操作することが非常に重要です。



原則として、定期的なスキャン（および、それに応じて、資産に関する情報の更新）は、せいぜい1か月に1回行われます。 インフラストラクチャ全体をスキャンすることは実際には非現実的であり、これはある時点で見落とされがちなインシデント処理の別の非常に重要な詳細を生成します：2つのインベントリスキャンの間、ホストの状態は必要に応じて頻繁に変化し、同時に元に戻る状態。 たとえば、悪意のあるメール、感染したWebサイトへの紹介、侵害の兆候の検出などを含むインシデントでは、その特定の瞬間にウイルス対策がアクティブであったかどうかを理解することが非常に重要です。



この問題は次の2つの方法で解決します。

• ソフトウェアまたはホストの切断/変更状態に対する個別のアラート。
• ホストごとにステータスをアップロードするか、ホストログを使用して現在のステータスを更新します。

この情報は、対応するインシデントに自動的に追加されます。







資産情報を最新の状態に保ちます。



既に述べたように、インフラストラクチャの説明にどれほど慎重であっても、まもなく廃止されます。 わずか1〜2か月で、顧客のネットワークは変化し始めます。新しいサービスまたはホストが表示され、古いサービスまたはホストが消え、システムの一部が目的を変更します。



現在のコンテキストを維持するためにSolar JSOCで使用するいくつかのアプローチを以下に示します。

1. 疑わしい事件の発生時のオンデマンド資産に関する情報の補充。 インシデントの分析の結果、資産（IPアドレス）がネットワークモデルに含まれていないことが判明した場合、通知時にホストに関する情報をお客様に求めます。 これは、資産とサブネットの両方に関する情報の入力に適用されます。
2. 潜在的な新しいホストの定期的なインベントリ。 ここにはいくつかのオプションがあります：
   
   
   • ドメイン、アンチウイルスなどからホストをアンロードし、現在の状態と比較します。 これは、特定のOrganizationUnit、マスクによるホスト名などを登録できる条件下で、最も単純な相関ルールを使用して行われます。 -あなたが見たいものに応じて。
     
     
     
     
     
     
   • 一部のネットワークセグメントのスイッチでIP-MAC準拠のアップロードを行います。
     
     
     
     
     
     
   • ホストネットワークアクティビティを追跡します。
     
     
     
     
     
     
     
     上記のプロセスへの「配信」のために、指定されたレポートに長い間表示されておらず、おそらく存在しないホストに関する情報を取得します。 たとえば、「従業員を解雇するプロセスに従って」、ホスト/ KMを「OU =無効」に移動することについてアラート/レポートを作成できます。
     
     
     
     
     
     
   
   
   
3. 最後に、最も複雑ですが非常に重要なプロセスは、顧客の責任ある専門家からの変更、新しいサブシステム、または古いサブシステムのスケーリングに関する情報の「手動」収集です。 Solar JSOCでは、契約サービスマネージャーがこれを行い、多くの場合、この作業は上記の自動化よりもはるかに多くの結果をもたらします。

ゲームはろうそくの価値はありませんが、結果は労働ですか？

この記事の最後の読者、実務家の誰も考えていませんでした。なぜ、このクレイジーなデザインをすべて考慮し、資産モデルを考慮して更新する必要があるのでしょうか？ たぶん、インシデントの事実に関して各ホストに手動で対処する方が簡単で「安い」ので、エンドカスタマーはそのような徹底的なインベントリを必要としませんか？



いくつかの例を挙げて、資産モデルがSOCオペレーターのアクティビティの一部を簡素化および自動化し、日常業務を支援する方法を示します。



過剰をフィルタリングする機能



「正しい」SIEMシステムにより、資産モデルを自動的に使用して、潜在的なインシデントを例外にフィルタリングできます。 これにより、オペレーターが「ごみ」の分析に費やす時間を大幅に削減できます。



たとえば、最初のネットワークモデルを記入する前に、お客様からスクリプトトリガーに関する主要情報の収集を開始することがよくあります。これは、C＆Cサーバーおよび悪意のあるサイトへの呼び出しを検出するルールを非常に迅速に開始できるためです。

これは、顧客のネットワーク全体がマルウェアで溢れていることを意味するのでしょうか、それとも逆に、C＆Cサーバーのレピュテーションデータベースが非常に多くの誤検出をもたらすのでしょうか 原則として、どちらもどちらでもありません。 ゲストWiFiは顧客の会社の支店で機能し、そのすべてのユーザーセッションはメインのクライアントネットワークと同じインターネットアクセスインフラストラクチャを使用するため、監視の範囲に含まれます。



ゲストのWi-Fiを使用しただけの外部の人の電話はどれほど安全ですか？ SOCオペレーターはそのようなインシデントを処理する必要がありますか？ ほとんどありません。 したがって、このシナリオからWi-Fiネットワークをフィルタリングすることは、非常に合理的で望ましい手順です。



または、別の例：通常、セキュリティポリシーレベルの会社では、リモート管理ツールの使用に制限があります。 しかし、リモートマシン、出張者、またはリモートのPOSのサービスを担当するヘルプデスクの従業員は、日常業務でこのツールに頼らざるを得ないことがよくあります。 SOCは、疑わしいインシデントを手動で処理するよりも、ヘルプデスクの従業員の場所を特定し、そのようなイベントを無視する方が簡単ではありませんか？



特定の資産に応じてインシデントの重要度と優先度を改善する



私の意見では、状況は追加のコメントを必要としません。 銀行のCBDのワークステーションまたはエネルギーセクターのメインセグメントとテクノロジーセグメントのジャンクションで発生したインシデントは、ユーザーセグメントでのハッキングツールの起動を修正するよりも、常にはるかに重要かつ優先されます。 そして、そのような事件はより速く検出され、処理されるべきです。



近年の実践から、攻撃者は若いSOCのインシデントの弱い優先順位付けを利用することを学んだことがわかります。 攻撃の最終段階の1つとして、いわゆる「インシデントストーム」を使用して、インフラストラクチャのさまざまな部分でインシデントの疑いを何十も作成してから、ターゲットリソースをキャプチャしたり、情報を危険にさらしたりします。 多数のインシデントを順番に処理するSOCオペレーターは、手遅れになるまで、真に重要な適切な手段を講じる時間がありません。 適切な優先順位付けにより、最も重要なインシデントに集中し、攻撃の結果を防ぐことができます。



変に見える能力



オペレータがインシデントの分析の開始時に持っている資産および状況に関する情報が多いほど、意思決定が迅速に行われ、より正確になります。 そしてもちろん、小さな異常に基づいて捕らえられた実際の複雑な攻撃は、SOCで効果的に特定され、分解される可能性が高くなります。



まあ、一般的に、誰が情報を所有しているのか、彼は世界を所有しています。 これについては、資産管理のテーマへのダイブを終了したいと思います。 残りのすべての実用的な質問とそうではない質問について-コメントへようこそ。 そして、....シリーズのSOCで再び会うまで。