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 で、[構成] > [分析] > [ルール テンプレート] タブにアクセスし、関連する各分析ルールを作成および更新します。

     詳細については、「難しい設定なしで脅威を検出する」を参照してください。

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

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

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

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

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

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

        フィルター、相関関係ルール、アクティブ リスト、参照セット、ウォッチリスト、検出の異常、集計などを検討してください。 レガシ SIEM から提供されている参照を使用して、クエリ構文を最適にマップする方法を理解することができます。

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

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

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

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

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

ルールの用語を比較する

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

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

ルール サンプルをマップおよび比較する

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

ルール	説明	サンプル検出ルール (ArcSight)	サンプル KQL クエリ	リソース
フィルター (AND)	AND 条件を含むサンプル ルール。 イベントはすべての条件に一致する必要があります。	フィルター (AND) の例	フィルター (AND) の例	文字列フィルター: • 文字列演算子 数値フィルター: • 数値演算子 日付時刻フィルター: • ago • Datetime • between • now 解析: • parse • extract • parse_json • parse_csv • parse_path • parse_url
フィルター (OR)	OR 条件を含むサンプル ルール。 イベントは、条件のいずれかに一致します。	フィルター (OR) の例	フィルター (OR) の例	• 文字列演算子 • in
入れ子になったフィルター	入れ子になったフィルター条件を含むサンプル ルール。 ルールに MatchesFilter ステートメントが含まれ、そこにさらにフィルター条件が含まれます。	入れ子になったフィルターの例	入れ子になったフィルターの例	• サンプル KQL 関数 • サンプル パラメーター関数 • join • where
アクティブ リスト (ルックアップ)	InActiveList ステートメントを使用するサンプル ルックアップ ルール。	アクティブ リスト (ルックアップ) の例	アクティブ リスト (ルックアップ) の例	• ウォッチリストは、アクティブ リスト機能に相当します。 ウォッチリストの詳細情報。 • ルックアップを実装するその他の方法
関連付け (照合)	Matching Event ステートメントを使用して、一連の基本イベントに照らして条件を定義するサンプル ルール。	関連付け (照合) の例	関連付け (照合) の例	join 演算子: • join • 時間枠を使用する join • shuffle • broadcast • union 定義ステートメント: • let 集約: • make_set • make_list • make_bag • pack
関連付け (時間枠)	Matching Event ステートメントを使用して一連の基本イベントに照らして条件を定義し、Wait time フィルター条件を使用するサンプル ルール。	関連付け (時間枠) の例	関連付け (時間枠) の例	• join • 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

このルールでは、Account フィールドを持つ Cyber-Ark Exception Accounts ウォッチリストが 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 ルールを次に示します (10 分以内に 3 つ一致)。

集計の例: KQL

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

次の手順

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

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