ArcSight 検出ルールをMicrosoft Sentinelに移行する

この記事では、ArcSight 検出ルールを識別、比較、移行して分析ルールをMicrosoft Sentinelする方法について説明します。

ルールを特定して移行する

Microsoft Sentinelでは、機械学習分析を使用して、忠実性が高く実用的なインシデントが作成され、既存の検出の一部がMicrosoft Sentinelで冗長になる場合があります。 そのため、すべての検出と分析のルールを盲目的に移行しないでください。 既存の検出ルールを特定するときに、これらの考慮事項を確認します。

• ビジネスの優先順位と効率性を考慮して、ルールの移行を正当化するユース ケースを必ず選択してください。
• ルールの種類Microsoft Sentinel理解していることを確認します。
• ルールの用語を理解していることを確認します。
• 過去 6 か月から 12 か月間にアラートをトリガーしていないルールを確認し、まだ関連性があるかどうかを判断します。
• 日常的に無視する低レベルの脅威やアラートを排除します。
• 既存の機能を使用し、Microsoft Sentinelの組み込み分析ルールが現在のユース ケースに対応できるかどうかをチェックします。 Microsoft Sentinelは機械学習分析を使用して、忠実性が高く実用的なインシデントを生成するため、既存の検出の一部が不要になる可能性があります。
• 接続されているデータ ソースを確認し、データ接続方法を確認します。 データ収集の会話を見直して、検出する予定のユース ケース全体でデータの深さと幅を確保します。
• SOC Prime Threat Detection Marketplace などのコミュニティ リソースを調べて、ルールが使用可能かどうかをチェックします。
• Uncoder.io などのオンライン クエリ コンバーターがルールに対して機能するかどうかを検討します。
• ルールが使用できない場合、または変換できない場合は、KQL クエリを使用して手動で作成する必要があります。 ルール マッピングを確認して、新しいクエリを作成します。

検出ルールを移行するためのベスト プラクティスの詳細については、こちらをご覧ください。

分析ルールをMicrosoft Sentinelに移行するには:

1. 移行する各ルールに対してテスト システムが用意されていることを確認します。

   1. 完全なテスト シナリオやスクリプトなど、移行されたルールの検証プロセスを準備します。

   2. 移行されたルールをテストするためにチームに役立つリソースがあることを確認します。

   3. 必要なデータ ソースが接続されていることを確認し、 データ接続方法を確認します。

2. 検出がMicrosoft Sentinelの組み込みテンプレートとして使用できるかどうかを確認します。

   • 組み込みのルールで十分な場合は、組み込みのルール テンプレートを使用して、独自のワークスペースのルールを作成します。

     Microsoft Sentinelで、[Configuration > Analytics > Rule templates]\(ルール テンプレート\) タブに移動し、関連する各分析ルールを作成して更新します。

     詳細については、「 テンプレートからスケジュールされた分析ルールを作成する」を参照してください。

   • Microsoft Sentinelの組み込みルールでカバーされていない検出がある場合は、Uncoder.io などのオンライン クエリ コンバーターを試してクエリを KQL に変換してください。

     トリガー条件とルール アクションを特定し、KQL クエリを構築して確認します。

   • 組み込みのルールもオンライン ルール コンバーターでも十分な場合は、ルールを手動で作成する必要があります。 このような場合は、次の手順を使用してルールの作成を開始します。

     1. ルールで使用するデータ ソースを特定します。 クエリを実行するテーブルを識別するために、Microsoft Sentinelのデータ ソースとデータ テーブルの間にマッピング テーブルを作成します。

     2. ルールで使用するデータ内の属性、フィールド、またはエンティティを特定します。

     3. ルールの条件とロジックを特定します。 この段階では、KQL クエリを構築する方法のサンプルとしてルール テンプレートを使用できます。

        フィルター、相関ルール、アクティブ リスト、参照セット、ウォッチリスト、検出異常、集計などを検討します。 従来の SIEM によって提供される参照を使用して、 クエリ構文を最適にマップする方法を理解できます。

     4. トリガー条件とルール アクションを特定し、KQL クエリを構築して確認します。 クエリを確認するときは、KQL 最適化ガイダンス リソースを検討してください。

3. 関連する各ユース ケースでルールをテストします。 期待される結果が得られない場合は、KQL を確認し、もう一度テストすることができます。

4. 問題がなければ、移行されたルールを検討できます。 必要に応じて、ルール アクションのプレイブックを作成します。 詳細については、「Microsoft Sentinelのプレイブックを使用して脅威対応を自動化する」を参照してください。

分析ルールの詳細については、以下を参照してください。

• Microsoft Sentinelのスケジュールされた分析ルール。 アラートのグループ化を使用して、特定の期間内に発生するアラートをグループ化することでアラートの疲労を軽減します。
• SOC エンジニアが調査中に追跡する証拠の一部としてエンティティを定義できるように、Microsoft Sentinelのエンティティにデータ フィールドをマップします。 また、エンティティ マッピングにより、SOC アナリストは、時間と労力を削減できる直感的な 調査グラフ を利用できます。
• イベント、アラート、およびインシデント プレビュー ウィンドウの特定のインシデントに関連付けられているブックマークを表示するために証拠を使用する方法の例として、UEBA データを使用してインシデントを調査します。
• Kusto 照会言語 (KQL)。これを使用して、Log Analytics データベースに読み取り専用要求を送信してデータを処理し、結果を返すことができます。 KQL は、Microsoft Defender for Endpointや Application Insights などの他の Microsoft サービスでも使用されます。

ルールの用語を比較する

この表は、ArcSight と比較してMicrosoft Sentinelルールの概念を明確にするのに役立ちます。

	ArcSight	Microsoft Sentinel
規則の種類	• フィルタールール • 参加ルール • アクティブリストルール • その他	• スケジュールされたクエリ •融合 • Microsoft セキュリティ • Machine Learning (ML) Behavior Analytics
基準	ルール条件で定義する	KQL で定義する
トリガー条件	• アクションを定義する • 集計で定義する (イベント集計の場合)	しきい値: クエリ結果の数
操作	• イベント フィールドの設定 • 通知の送信 • 新しいケースを作成する • アクティブリストに追加 • その他	• アラートまたはインシデントを作成する • Logic Apps との統合

ルール サンプルのマップと比較

これらのサンプルを使用して、ArcSight のルールを比較し、さまざまなシナリオでMicrosoft Sentinelにマップします。

Rule	説明	サンプル検出ルール (ArcSight)	KQL クエリのサンプル	リソース
フィルター (AND)	AND条件を含むサンプル ルール。 イベントはすべての条件に一致する必要があります。	フィルター (AND) の例	フィルター (AND) の例	文字列フィルター: • 文字列演算子 数値フィルター: • 数値演算子 Datetime フィルター: • 前 • Datetime • 間 • 今すぐ 解析： • 解析 • 抽出 • parse_json • parse_csv • parse_path • parse_url
フィルター (OR)	OR条件を含むサンプル ルール。 イベントは、任意の条件と一致できます。	フィルター (OR) の例	フィルター (OR) の例	• 文字列演算子 • の
入れ子になったフィルター	入れ子になったフィルター条件を持つサンプル ルール。 ルールには、フィルター条件も含まれる MatchesFilter ステートメントが含まれます。	入れ子になったフィルターの例	入れ子になったフィルターの例	• サンプル KQL 関数 • サンプル パラメーター関数 • 参加 • 場所
アクティブなリスト (ルックアップ)	InActiveList ステートメントを使用するサンプル参照規則。	アクティブ リスト (ルックアップ) の例	アクティブ リスト (ルックアップ) の例	• ウォッチリストは、アクティブなリスト機能と同等です。 ウォッチリストの詳細については 、こちらをご覧ください。 • ルックアップを実装するその他の方法
相関関係 (一致)	Matching Event ステートメントを使用して、一連の基本イベントに対して条件を定義するサンプル ルール。	相関関係 (照合) の例	相関関係 (照合) の例	join 演算子: • 参加 • 時間枠で参加 • シャッフル • ブロードキャスト • 共用体 define ステートメント: • let 集計: • make_set • make_list • make_bag • bag_pack
相関関係 (時間枠)	Matching Event ステートメントを使用して一連の基本イベントに対して条件を定義し、Wait timeフィルター条件を使用するサンプル ルール。	相関関係 (時間枠) の例	相関関係 (時間枠) の例	• 参加 • Microsoft Sentinelルールと join ステートメント

フィルター (AND) の例: ArcSight

ArcSight で条件を AND するフィルター ルールの例を次に示します。

フィルター (AND) の例: KQL

KQL で条件を AND するフィルター 規則を次に示します。

SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)

この規則では、Azure監視エージェント (AMA) がWindows セキュリティ イベントを収集することを前提としています。 したがって、規則では、Microsoft Sentinel SecurityEvent テーブルが使用されます。

次のベスト プラクティスを検討してください。

• クエリを最適化するには、可能な場合は大文字と小文字を区別しない演算子 ( =~) を避けます。
• 値の大文字と小文字が区別されない場合は、 == を使用します。
• 最も多くのデータをフィルター処理する where ステートメントから始めてフィルターを並べ替える。

フィルター (OR) の例: ArcSight

ArcSight で条件を OR するフィルター ルールの例を次に示します。

フィルター (OR) の例: KQL

KQL で OR 条件を使用してフィルター規則を記述する方法を次に示します。

最初のオプションとして、 in ステートメントを使用します。

SecurityEvent
| where SubjectUserName in
 ("Adm1","ServiceAccount1","AutomationServices")

2 番目のオプションとして、 or ステートメントを使用します。

SecurityEvent
| where SubjectUserName == "Adm1" or 
SubjectUserName == "ServiceAccount1" or 
SubjectUserName == "AutomationServices"

どちらのオプションもパフォーマンスは同じですが、読みやすい最初のオプションをお勧めします。

入れ子になったフィルターの例: ArcSight

ArcSight の入れ子になったフィルター 規則の例を次に示します。

/All Filters/Soc Filters/Exclude Valid Users フィルターの規則を次に示します。

入れ子になったフィルターの例: KQL

KQL で OR 条件を使用してフィルター規則を記述する方法を次に示します。

最初のオプションとして、 where ステートメントで直接フィルターを使用します。

SecurityEvent
| where EventID == 4728 
| where isnotempty(SubjectDomainName) or 
isnotempty(TargetDomainName) 
| where SubjectUserName !~ "AutoMatedService"

2 番目のオプションとして、KQL 関数を使用します。

1. 次のクエリを、 ExcludeValidUsers エイリアスを使用して KQL 関数として保存します。

       SecurityEvent
       | where EventID == 4728
       | where isnotempty(SubjectDomainName)
       | where SubjectUserName =~ "AutoMatedService"
       | project SubjectUserName
   

2. 次のクエリを使用して、 ExcludeValidUsers エイリアスをフィルター処理します。

       SecurityEvent    
       | where EventID == 4728
       | where isnotempty(SubjectDomainName) or 
       isnotempty(TargetDomainName)
       | where SubjectUserName !in (ExcludeValidUsers)
   

3 番目のオプションとして、パラメーター関数を使用します。

1. 名前とエイリアスとして ExcludeValidUsers を持つパラメーター関数を作成します。

2. 関数のパラメーターを定義します。 例:

       Tbl: (TimeGenerated:datetime, Computer:string, 
       EventID:string, SubjectDomainName:string, 
       TargetDomainName:string, SubjectUserName:string)
   

3. parameter関数には、次のクエリがあります。

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

4. 次のクエリを実行して、パラメーター関数を呼び出します。

       let Events = (
       SecurityEvent 
       | where EventID == 4728
       );
       ExcludeValidUsers(Events)
   

4 番目のオプションとして、 join 関数を使用します。

let events = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) 
or isnotempty(TargetDomainName)
);
let ExcludeValidUsers = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
| where SubjectUserName =~ "AutoMatedService"
);
events
| join kind=leftanti ExcludeValidUsers on 
$left.SubjectUserName == $right.SubjectUserName

考慮 事項：

• わかりやすくするため、 where ステートメント (最初のオプション) で直接フィルターを使用することをお勧めします。 パフォーマンスを最適化するには、 join (4 番目のオプション) を使用しないでください。
• クエリを最適化するには、可能な限り、 =~ を回避し、大文字と小文字を区別しない演算子を !~ します。 値の大文字と小文字が区別されない場合は、 == 演算子と != 演算子を使用します。

アクティブ リスト (ルックアップ) の例: ArcSight

ArcSight のアクティブなリスト (ルックアップ) ルールを次に示します。

アクティブ リスト (ルックアップ) の例: KQL

この規則では、Cyber-Ark 例外アカウントウォッチリストが[アカウント] フィールドを持つMicrosoft Sentinelに存在することを前提としています。

let Activelist=(
_GetWatchlist('Cyber-Ark Exception Accounts')
| project Account );
CommonSecurityLog
| where DestinationUserName in (Activelist)
| where DeviceVendor == "Cyber-Ark"
| where DeviceAction == "Get File Request"
| where DeviceCustomNumber1 != ""
| project DeviceAction, DestinationUserName, 
TimeGenerated,SourceHostName, 
SourceUserName, DeviceEventClassID

フィルターを注文するには、最も多くのデータをフィルター処理する where ステートメントから始めます。

相関 (照合) の例: ArcSight

Matching Event ステートメントを使用して、一連の基本イベントに対して条件を定義する ArcSight ルールの例を次に示します。

相関関係 (一致) の例: KQL

let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2 
on $left.TargetUserName==$right.TargetUserName

ベスト プラクティス:

• クエリを最適化するには、小さいテーブルが join 関数の左側にあることを確認します。
• テーブルの左側が比較的小さい (最大 100 K レコード) 場合は、パフォーマンスを向上させるために hint.strategy=broadcast を追加します。

関連付け (時間枠) の例: ArcSight

Matching Event ステートメントを使用して一連の基本イベントに対して条件を定義し、Wait timeフィルター条件を使用する ArcSight ルールの例を次に示します。

関連付け (時間枠) の例: KQL

let waittime = 10m;
let lookback = 1d;
let event1 = (
SecurityEvent
| where TimeGenerated > ago(waittime+lookback)
| where EventID == 4728
| project event1_time = TimeGenerated, 
event1_ID = EventID, event1_Activity= Activity, 
event1_Host = Computer, TargetUserName, 
event1_UPN=UserPrincipalName, 
AccountUsedToAdd = SubjectUserName 
);
let event2 = (
SecurityEvent
| where TimeGenerated > ago(waittime)
| where EventID == 4729
| project event2_time = TimeGenerated, 
event2_ID = EventID, event2_Activity= Activity, 
event2_Host= Computer, TargetUserName, 
event2_UPN=UserPrincipalName,
 AccountUsedToRemove = SubjectUserName 
);
 event1
| join kind=inner event2 on TargetUserName
| where event2_time - event1_time < lookback
| where tolong(event2_time - event1_time ) >=0
| project delta_time = event2_time - event1_time,
 event1_time, event2_time,
 event1_ID,event2_ID,event1_Activity,
 event2_Activity, TargetUserName, AccountUsedToAdd,
 AccountUsedToRemove,event1_Host,event2_Host, 
 event1_UPN,event2_UPN

集計の例: ArcSight

集計設定を含む ArcSight ルールの例を次に示します。3 つは 10 分以内に一致します。

集計の例: KQL

SecurityEvent
| summarize Count = count() by SubjectUserName, 
SubjectDomainName
| where Count >3

次の手順

この記事では、ArcSight から Microsoft Sentinel に移行ルールをマップする方法について説明しました。

SOAR オートメーションを移行する