JSOC：インシデントの準備方法

同僚、こんにちは。



次の記事のリリースで少し遅れました。 それにもかかわらず、彼女は準備ができており、私たちの新しいアナリストと著者-Alexei Pavlov- avpavlovによる記事を提示したいと思います。



この記事では、セキュリティオペレーションセンターの「ライフ」の最も重要な側面、つまり情報セキュリティに対する新たな脅威の特定と運用分析について検討します。 ルールの設定方法、およびアウトソーシングJSOC監視および対応センターでのインシデントの識別と登録について説明します。







以前の記事でJSOCの仕組みについて説明しました。



JSOC：若いロシアMSSPの経験



JSOC：セキュリティオペレーションセンターの可用性を測定する方法



彼らは、とりわけ、JSOCの中核はHP ArcSight ESM SIEMシステムであると述べました。 この記事では、誤検知イベントの数、新しいシステムとSISの運用上の接続を減らすために実装された設定と改善の説明に集中し、お客様の潜在的なインシデントを分析するプロセスの速度と透明性を高めます。



すべてのSIEMには、ソースからのイベントを比較することにより、クライアントに脅威を通知できる事前定義された相関ルールのセットが「すぐに使用可能」になっています。 では、なぜ、このシステムの高価なセットアップと、インテグレーターおよび当社のアナリストによるサポートが必要なのでしょうか？



この質問に答えるには、ソースからJSOCに分類されるイベントのライフサイクルがどのように構成されているか、ルールトリガーからインシデントの作成までの方法を伝える必要があります。



イベントの主な処理は、SIEMシステムのコネクタで発生します。 処理には、フィルタリング、分類、優先順位付け、集約、および正規化が含まれます。 次に、CEF形式（Common Event Format）のイベントがHP ArcSightシステムのコアに送信され、そこで相関と視覚化が行われます。 これらは、SIEMの標準的なイベントメカニズムです。 JSOCの一環として、インシデントを監視し、エンドシステムに関する情報を取得する機能を拡張するために、それらを最終決定しました。

フィルタリングと分類

SIEMの主な機能の1つは、コネクタで発生するイベントのフィルタリングと分類です。 平均的なSIEMシステムでは、6000〜8000 EPS（1秒あたりのイベント）は通常のイベントフローと見なされますが、50〜80のソースからのイベントタイプの数は数千になります。 このような大量の情報を処理しやすいように、イベントカテゴリが考案されました。



さまざまなベンダーの機器やシステムでは、同じイベントが異なる方法で呼ばれることが多いことに注意してください。 たとえば、TCP接続内のセッションの開始は、Juniperでは「Built inbound TCP connection」、Juniperでは「セッション作成」、Checkpointには接続の成功に応じて「accept」または「block」という2つのイベントがあります。 「新しいベンダーの」相関ルールの変更を避けるために、デバイスが登場したときに、実行されるアクションを決定するイベントのカテゴリが導入されました。



例：Juniper Firewallイベント-「セッション開始」



カテゴリの意味：/情報-メッセージタイプ-情報



カテゴリデバイスタイプ：ファイアウォール-ファイアウォールからのイベント



カテゴリの動作：/アクセス/開始-セッションを開く



カテゴリー結果：/成功-成功



したがって、相関ルールですべてのデバイスからの成功したアクセスイベントを追跡する必要がある場合は、単にカテゴリ動作：/アクセス/開始、カテゴリデバイスタイプ：ファイアウォール、カテゴリ結果：/成功を指定します。



JSOC内の標準的な分類に加えて、インシデントを生成するルールへの可能な変更を最小限にするために、追加の分類を実装しました。 これらのルールはさまざまなお客様に有効であり、そのうちの1つのパラメーターを変更すると、すべてのユーザーにとってソリューションが一時的および/または完全に機能しなくなる可能性があります。







図 1.例としてINC_Password Change Neededルールを使用したイベントの分類



例として、ルール「INC_Password Change Needed」を引用しましょう。 その主なタスクは、有効期限が切れたパスワードを持つアカウントでシステムで認証が行われたかどうかを通知することです。 期間は企業ルールに従って計算され、顧客によって異なります。 このルールは、さまざまなソースからのすべての認証イベントを含むJSOC分類「デバイスイベントカテゴリは/ JSOC / Authentication /」を使用し、標準分類「HP Arcsight-Category Outcome = / Success」-成功した接続イベントを使用します。

基本ルールとプロファイルルール

システムのコアに分類される特定のタイプのイベントを処理するために、特別なプロファイリングと基本的なルールがJSOCに導入されました。 さまざまなアクティビティのプロファイルルールは、最も重要な役割の1つです。 これらは、アクティブリストに記録されたプライマリデータを形成し、その後、平均、最大、および変動のインジケーターの計算に使用されます。 このようなルールには、認証、リソースへのアクセス、毎日のトラフィック、主要システムへのアクセス用のIPアドレスのホワイトリストなどのデータが含まれます。通常のアクティビティプロファイルが完了したら、通常のアクティビティからの逸脱を記録するルールを作成できます。



基本的なルールを別の段落として取り上げたいと思います。 不足している情報をイベントに追加する-ファイアウォールからのイベントのユーザー名、人事システムからのアカウント所有者情報、CMDBからのホストの追加説明-JSOCに実装され、インシデントを分析し、1つのイベントで必要なすべての情報を取得するプロセスを高速化します。



基本的なルールの使用の顕著な例は、「CISCO_VPN_User Session Started」です。 このルールにより、VPNを介して接続している従業員のIPアドレスをユーザー名に関連付けることができます（この情報は、Cisco ASAからのさまざまなイベントにあります）。







図 2.基本的なルール設定の例

相関ルールを作成および構成する

異常なアクティビティを記録するには、いくつかのオプションがあります。

1. ソースからの特定のイベント用
2. 特定の期間にわたるソースからのいくつかの連続したイベント。
3. 特定の期間に1つのタイプのイベントのしきい値に達すると、
4. 参照（または平均）値からのインジケーターの偏差。

各オプションをさらに詳しく分析しましょう。



相関ルールを使用する最も簡単な方法は、ソースからの単一イベントの発生時にトリガーすることです。 これは、構成済みのSPIと組み合わせてSIEMシステムを使用する場合に効果的です。



監視対象サーバーで重要なサービスが停止すると、INC_Critical Service Stoppedルールがトリガーされます。 このイベントは、悪意のあるユーザーまたはマルウェアのアクティビティを示している可能性があります。 しかし、企業に対するほとんどの標的型攻撃と内部インシデントは、単一のイベントで特定することはできません。







図 3.ソースからの単一のイベントでトリガーするルールの例



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



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







図 4.複数のソースから一連のイベントをトリガーするルールの例







図 5.インシデント「外部からのリソースへの不正アクセス」に関するイベントのマッチングの例



ルールを構成する3番目の方法は、さまざまなスキャン、ブルートフォース、流行、およびDDoSの検出に最適です。



多数のログイン試行の失敗は、ブルートフォース攻撃を示している可能性があります。 BF_INC_SSH_Dictionary攻撃ルールは、Unixシステムで20回のログイン試行の失敗を追跡するように構成されています。







図 6. 1つのタイプの特定の数のイベントに対してトリガーするルールの例



異常な活動を記録する最も複雑で同時に効果的かつ普遍的な方法は、プロファイルの使用です。



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







図 7.平均を超えるルールをトリガーする例



JSOCを開発して、相関ルールを作成するための次の推奨事項の基礎となる特定の教訓を学びました。

1. プロファイリングを使用する必要があります。 1人のクライアントにとっては、ホストでTORを使用することは完全に正常な場合があり、別のクライアントにとっては、従業員を解雇する直接的な方法です。 一部の人は、インフラストラクチャ全体で作業できる信頼できる管理者のみにVPNアクセスを許可し、他の人は従業員の半分にアクセスできますが、ステーションでのみ作業します。 しかし同時に、会社の従業員の大多数は毎日同じシナリオで作業しているため、プロファイルを作成するのは簡単です。したがって、異常は簡単に登録できます。 したがって、JSOCでは統一されたルールを使用しますが、それらのパラメーター、リスト、フィルターはクライアントごとに個別です。
2. 複雑なルールは機能しません。誤検知の数を最小限に抑えるためにルールをトリガーするための条件を10個積み上げると、トリガーの可能性は低くなり、重要な何かを見落とすリスクが高くなります。
3. SIEMはそのタスクのみを解決する必要があります。 これらの目的に特化したソリューションが存在する場合、その上にすべてをドロップしようとする必要はありません。 たとえば、外部IPアドレスが1分以内に外部リソースへの接続を1000以上試行しようとした場合に機能するルールを構成します。 不要な作業でSIEMをロードすることなく、IPSでこのルールを設定する方がはるかに簡単です。

同時に、注意したいのは、SIEMシステムがどれほど適切に構成されていても、False Positiveイベントは常に存在するということです。 そうでない場合、SIEMは死んでいます。 そのため、実際のインシデントを特定できる資格のあるモニタリングエンジニアを配置することが重要です。 スペシャリストは、情報セキュリティに関する一連の知識、起こりうる攻撃のプロファイルを持ち、イベントを分析するための最終的なシステムを知っている必要があります。

おわりに

最後の言葉として、社内でSOCを組織するための推奨事項を要約したいと思います。

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