右キッチン

こんにちは、同僚。 そこで、セキュリティオペレーションセンターに関する3番目の記事が登場しました。



本日の出版物は、あらゆるSOCの最も重要な側面、つまり潜在的な情報セキュリティインシデントの識別と分析に関連するコンテンツを扱っています。 これはまず、SIEMシステムの相関ルールのアーキテクチャであり、関連するシート、トレンド、スクリプト、コネクタ設定です。 この記事では、SIEMシステムのコネクターを使用したイベントの処理から始まり、相関ルールでのこれらのイベントの使用とインシデントのさらなるライフサイクルで終わる、初期ログの処理方法全体について説明します。







前の記事で述べたように、SOCの中心はHPE ArcSight ESM SIEMシステムです。 この記事では、4年以上にわたる進化のためのこのプラットフォームの改善について説明し、設定の現在のバージョンについて説明します。



まず第一に、改善点は次のアクティビティを最適化することでした。

1. 新しいクライアントを接続し、コネクタを構成する時間を短縮します。
2. インフラストラクチャのコアアクティビティのプロファイリング。
3. 誤検知の数を減らします。
4. 記録された潜在的なインシデントについての情報内容と顧客アラートの完全性を高める。

すべてのSIEMには、ソースからのイベントを比較し、しきい値を蓄積することにより、固定された異常（潜在的なインシデント）をクライアントに通知できる一連の定義済みルールが「すぐに使用可能」です。 では、なぜこのシステムの高価な実装、その構成、およびインテグレーターと私たち自身のアナリストによるサポートが必要なのでしょうか？



この質問に答えるために、ソースからSIEMに分類されるイベントのライフサイクルがどのように構成されているか、ルールトリガーからインシデントの作成と顧客への通知までの方法を説明します。



イベントの主な処理は、SIEMシステムのコネクタで発生します。 処理には、フィルタリング、分類、優先順位付け、集約、および正規化が含まれます。 イベントには、たとえば、異なる情報を含む複数のイベントを組み合わせて、追加の前処理を行うこともできます。



例：arpスプーフィングを追跡するためのnetscreenジュニパーログには、IPアドレスとMACアドレスに関する情報が異なる行に含まれています。

iso.3.6.1.4.1.3224.17.1.3.1.2.274 = IpAddress：192.168.30.94

iso.3.6.1.4.1.3224.17.1.3.1.2.275 = IpAddress：172.16.9.231

iso.3.6.1.4.1.3224.17.1.3.1.2.276 = IpAddress：172.16.9.232

iso.3.6.1.4.1.3224.17.1.3.1.3.274 =六角ストリング：AC 22 0B 74 91 4C

iso.3.6.1.4.1.3224.17.1.3.1.3.275 =六角ストリング：20 CF 30 9A 17 11

iso.3.6.1.4.1.3224.17.1.3.1.3.276 =六角ストリング：80 C1 6E 93 A0 56

コネクタを作成するとき、すぐにマージして1つのイベントにすべての情報を表示できます。 この場合のキーフィールドマージはiso.3.6.1.4.1.3224.17.1.3.1。*。276です。



次に、前処理されたイベントはHPE ArcSightシステムのコアに送信され、そこで処理されます。 Solar JSOCの一環として、イベント処理のすべての段階を使用して、インシデントを監視し、エンドシステムに関する情報を取得する機能を拡張しました。

コネクタ設定

イベントの前処理の一部として、フィールドマッピング、追加の分類、およびコネクタ上のイベントのフィルタリングに関連する機能を最大限に活用しようとします。



残念ながら、1秒あたりの処理済みイベント（EPS）の数、および後続の計算と初期イベントの処理に関するSIEMシステムの機能は限られています。 Solar JSOCでは、1つのArcSightインストールに対して複数の顧客が存在し、それらからのイベントのフローは非常に多くなっています。 記録されたインシデントの合計範囲は100〜150に達します。これは、計算、シートの記入、インシデントの生成などに数百のルールを使用することを意味します。 同時に、システムの安定性とアクティブなチャンネルでのイベントの迅速な検索は非常に重要です。



徐々に、上記の条件を満たすために、処理の一部をコネクタレベルに移動できることがわかりました。



たとえば、ネットワーク機器を含むさまざまなシステムで認証イベントを統一するために事前永続化ルールを使用する代わりに、コネクタのマップファイルレベルでカテゴリを導入します。



Ciscoルーターのマップファイルは次のようになります。

event.eventClassId、set.event.deviceAction、set.categoryOutcome、set.event.categoryDe​​viceGroup

SEC_LOGIN：LOGIN_SUCCESS、ログイン、成功、/ JSOC /認証

SEC_LOGIN：LOGIN_FAILURE、ログイン、失敗、/ JSOC /認証

SYS：ログアウト、ログアウト、成功、/ JSOC /認証

DNSサーバーからのイベントのフローは通常最も高いものの1つであるため、インフラストラクチャをスキャンするために外部サーバーによるグレーアドレスの解決の試行を正規表現を使用して追跡することは非常に困難なタスクになります。 ArcSightは、DNSを使用した1500 EPSのストリームで「気分が悪くなる」ため、正規表現もマップファイルに配置され、カテゴリが割り当てられます。



代わりに







書く：







残りは、マップファイル内の正規表現によって取り出されます。



イベントフィルタリングの使用の顕著な例は、DNSサーバーにも関連付けられています。 HPE ArcSight SmartConnectorコネクタサーバーでは、ホスト名をWindowsコネクタおよびネットワーク機器のアドレスに解決できます。 したがって、コネクタサーバーからのDNSクエリの数は非常に多くなる可能性があり、これらすべてのイベントはインシデントを識別するために明らかに必要ではないため、ESMの負荷を減らすために正常にフィルタリングできます。





分類を使用する2番目の、さらに重要な理由は、多くの場合、さまざまなデバイス、システム、およびアプリケーションソフトウェアを使用することです。



たとえば、ロシアの企業ではあまり人気のないNetScreenに接続する必要がある場合は、たとえば、以下に関するすべてのルールでSolar JSOCに許可イベントを追加できます。

• プロキシをバイパスしてインターネットに直接アクセスします。
• さまざまなレピュテーションデータベースのバージョンに応じた、潜在的に危険なホストへのアクセス。
• アプリケーション層プロトコルなどのスキャン。

また、分類または既成のフィルターを使用できます。 Solar JSOCは、異なる場合に両方の方法を使用します。 この場合、Firewall_Passフィルターを使用します。









上記の例からわかるように、要件に合っている場合は標準のArcSightカテゴリを使用します。

コンテンツ相関ルール

Solar JSOCの一部として、「ベースプロファイリングインシデントルール」バンドルが正常に機能すると結論付けています。 それぞれのタイプを順番に詳しく見ていきましょう。

基本的なルール

基本的なルールは、欠落している情報をイベントに追加するために使用されます-ユーザー名、人事システムからのアカウント所有者情報、CMDBからのホストの追加説明。 これはすべてSolar JSOCに実装されており、インシデントをより迅速に分析し、限られたイベントプールで必要なすべての情報を取得するのに役立ちます。 これは、最初の行が常に20分間SLAによって割り当てられた重大なインシデントに対応し、同時に非常に高品質で完全な分析を行う機会を持つように行われました。

プロファイルルール

さまざまなアクティビティのプロファイルルールは、最も重要な役割の1つです。 これらは、アクティブリストに記録され、その後次の状況で使用されるプライマリデータを形成します。

1. アクティビティのクイックレトロスペクティブ検索。
   
   
   
   これらのプロファイリングルールには、たとえば、Profile_IA_Internet Access（Proxy）が含まれます。 このルールは、プロキシサーバーを介したサイトへのすべての紹介をリストに書き込みます。 このシートには次のフィールドが含まれています。
   
   
   
   
   
   
   
   ただし、シートには300万件のレコードの制限があるため、毎日夜間にストレージスペースが1桁多い傾向にデータを入力します。
   
   
   
   このシートは、標準的なインシデント調査と、1年までの長期間にわたる侵害の指標の遡及的検証の両方で使用されます。
   
   
   
   
2. プロファイルの作成と修正。
   
   
   
   たとえば、重要なホストの認証またはネットワークプロファイル。 このようなプロファイルの収集には1〜2週間かかります。その後、プロファイルがアンロードされてクライアントに送信されます。 プロファイルの調整と修正が行われた後、インシデントルールが設定されます。 指定されたパラメーターに従ってプロファイルに該当しないアクティビティが出現すると、このルールがトリガーされ、インシデントが最初の行で解析され、クライアントに通知されます。
   
   
   
   ステータスを変更するために、構成ファイルを使用します。
   
   
   
   
   
   
   
   ステータスがInProgressの場合、プロファイルが収集され、ステータスがFinishedの場合、インシデントルールが機能し始めます。
   
   
   
   
3. 平均、最大、変動指標の計算。
   
   
   
   「ウイルス活動の異常な統計」というルールは、この原則に基づいています。 クライアントのインフラストラクチャのウイルス感染に関する一定期間の統計を考慮し、攻撃が標的となる悪意のあるアクションを示す可能性があるため、いずれかの日が急増した場合、異常をクライアントに通知します。
   
   

インシデントルール

Solar JSOCでは、次の種類の異常アクティビティログを使用します。

1. ソースからの単一のイベント。
2. 選択した期間の1つまたは複数のソースからの複数の連続したイベントの場合。
3. 特定の期間の別のイベントの開始ではなく、1つの開始時。
4. 1つのタイプのイベントのしきい値に達すると。
5. 基準値または平均値からの統計指標の偏差による。
6. 別に、侵害の指標のチェックがあります。

各オプションについて詳しく見てみましょう。



相関ルールを使用する最も簡単な方法は、ソースから単一のイベントが発生したときに起動することです。 これは、構成済みのSPIと組み合わせてSIEMシステムを使用する場合に効果的です。 多くの企業はこのように制限されています。



最も単純なインシデントの1つは、ホスト上の重要なファイルの変更です。









ルールは、無条件に/ etc / hostsファイル、およびアクティブリストで指定され、クライアントと合意したすべての重要なファイルを検索します。



期間にわたる複数のイベントの相関ルールの一貫したトリガーは、インフラストラクチャセキュリティに理想的に適合します。



1つのアカウントでワークステーションにログインしてから、別のアカウント（またはVPNと情報システムを使用した同じシナリオ）でターゲットシステムにログオンすると、これらのアカウントの盗難の可能性が示されます。 このような潜在的な脅威は、特に管理者の日常業務（ドメイン：a.andronov、データベース：oracle_admin）で一般的であり、多数の誤検知を引き起こすため、ホワイトリストの作成と追加のプロファイリングが必要です。



次に、VPNプールから不正なネットワークセグメントへのアクセスをトリガーする例を示します。





次に、ウイルス検出イベントと、その除去/修復/検疫のイベントのその後の不在を検出するように構成された3番目のタイプのインシデントルールの例を示します。









ルールを構成する4番目の方法は、さまざまなスキャン、ブルートフォース、流行などを識別するのに最適です。



すべてのシステムに共通するブルートフォースルールは、上記のすべての方法の真髄です。 ソースを設定するときは、常に分類にマップファイルを使用するため、それらは失敗ログオンフィルターに該当し、シートに書き込まれ、カウントされる基本的なルールがあり、構成シートはさまざまな顧客のしきい値を設定するために個別に使用されます。クリティカルおよび非クリティカルユーザー。 1人のユーザーの最初の行が同じタイプのインシデントでいっぱいにならないように、例外と停止リストも提供されます。







平均的な指標からの偏差は、DDoS攻撃、ウイルスの発生、企業ネットワークからの情報漏えい、およびその他の多くを検出するシナリオで使用されます。



例としては、相関ルールINC_AV_Virus Anomaly Activityがあります。これは、特定の期間における平均的なウイルス対策応答率（プロファイルに基づいて計算）の超過を監視します。







妥協の指標の検証に関しては、それらの点に関して全範囲の作業が行われているため、それらは別の段落として強調されるべきです：

1. 指標の遡及的検証;
2. インジケータは、将来の検出のために特別なシートに入力されます。
3. 時間がたつと、侵害の指標の関連性が見直されます。

最初の段落には、ウェブサイトの訪問、プロセスの開始、インフラストラクチャで起動された実行可能ファイルのmd5合計、特殊なセキュリティツールまたは一部から受け取ったウイルス対策ベンダー。



2番目と3番目の段落は密接に関連しています。 この場合、レビューは、量、頻度、および作戦が軍事的であったことの確認に応じて実施されます。 多数の誤検知と戦闘不足の場合、インジケータは一定時間後に削除されます。



Solar JSOCを開発して、サービスの提供の基礎となる特定の教訓を学びました。

1. カスタマーインタラクションとフィードバックは、セキュリティオペレーションセンターの運用における重要な要素です。 これにより、顧客内のプロセスをよりよく理解できます。つまり、さまざまなインシデントルールの例外リストを作成し、誤検知の数を数回減らすことができます。 あるクライアントではホストでTORを使用することは完全に正常な場合があり、別のクライアントでは従業員を解雇する直接的な方法です。 一部の人は、インフラストラクチャ全体で作業できる信頼できる管理者のみにVPNアクセスを許可し、他の人は従業員の半分にアクセスできますが、彼らはステーションでのみ作業します。
   
   
   
   
2. プロファイルのコレクション。 会社の従業員の大多数は毎日同じシナリオで働いています。 プロファイルするのは簡単です。したがって、異常は簡単に特定できます。 したがって、Solar JSOCでは統一されたルールを使用しますが、それらのパラメーター、リスト、フィルターはクライアントごとに個別です。
   
   
   
   
3. 複雑なルールは機能しません 。 相関ルールに関係する明確化条件と開始イベントの数が多いほど、そのようなシナリオがすべての顧客に対して箱から外れる可能性が低くなります。 例外のレベルで行うには、普遍的なルールと「微調整」を行う必要があります。
   
   
   
   
4. SIEMはそのタスクのみを解決する必要があります。 SIEMシステムにZabbixタスクまたはDDoS検出ソリューションを強制的に解決させる必要はありません。 後者は、システムのリソースを「食い尽くす」だけでなく、このDDoSを防ぐのに役立ちません。
   
   同時に、SIEMシステムをどのように適切に構成しても、誤検出イベントが常に存在することに注意してください。 そうでない場合、SIEMは死んでいます。 しかし、誤検知も異なります。 夜間にトップマネージャーのパスワードをリセットすることは、自宅で仕事をするという予期せぬ決定とパスワードを思い出せないこと、および攻撃者の行動の両方によって説明できます。 しかし、最新技術で誤検知が発生し、現在、通常の例外としてインシデントルールに追加されていない状況があります。 そのため、実際のインシデントを特定できる資格のあるモニタリングエンジニアを配置することが重要です。 専門家は、情報セキュリティに関する一連の知識を持ち、起こりうる攻撃のベクトルを予測し、イベントを分析するための最終的なシステムを知っている必要があります。

おわりに

結論として、私は会社で自分のSOCを組織するための推奨事項を要約したいと思います。

1. SOCの最も重要な要素はSIEMシステムです。選択の問題はサイクルの最初の記事で説明しましたが、最も重要な点はビジネスおよびインフラストラクチャ機能の要件へのカスタマイズです。
   
   
   
   
2. 相関ルールを作成してさまざまな攻撃シナリオと攻撃者の活動を検出する作業は、絶え間ない脅威の発展に関連して終わることのない膨大な作業層です。 そのため、社内スタッフに資格のあるアナリストが必要です。
   
   
   
   
3. 監視エンジニアの最初の行は、情報セキュリティ部門に基づいて形成される必要があります。 スペシャリストは、誤検知と実際のインシデントを区別し、イベントの基本的な分析を実施できる必要があります。 これには、情報セキュリティの分野のスキルと、考えられる攻撃ベクトルの理解が必要です。

この記事では、インシデントの登録、最初の行による処理、誤検知のフィルタリング基準、クライアントへの通知および追加調査の実施の問題に対処しませんでした。 これは、シリーズの次の記事の主題になります。