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

この記事では、Splunk 検出ルールを特定し、比較し、Microsoft Sentinel 組み込みルールに移行する方法について説明します。

Splunk Observability のデプロイを移行する場合は、Splunk から Azure Monitor ログに移行する方法の詳細を確認してください。

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

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

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

検出ルールを移行するためのベスト プラクティスの詳細を参照してください。

Microsoft Sentinel に分析ルールを移行するには、次のようにします。

1. 移行するルールごとにテスト システムが配置されていることを確認します。

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

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

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

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

   • SIEM 移行エクスペリエンスを使用し、翻訳と移行を自動化します。

     詳細については、SIEM 移行エクスペリエンスを使用する方法に関するページを参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ルールの用語を比較する

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

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

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

一般的な検索コマンド

検索コマンド: KQL 例

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats コマンド: KQL 例

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats コマンド: KQL 例

T | summarize count() by price_range=bin(price, 10.0) 

トランザクション コマンド: SPL の例

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

トランザクション コマンド: KQL 例

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

row_window_session()を使用して、シリアル化された行セット内の列のセッション開始値を計算します。

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

イベント コマンド: SPL の例

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

イベント コマンド: KQL 例

join ステートメントを使用した例を次に示します。

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

make_list ステートメントを使用した例を次に示します。

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection コマンド: SPL の例

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection コマンド: KQL 例

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

一般的な eval コマンド

case(X,"Y",…) SPL の例

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) KQL 例

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) KQL 例

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) KQL 例

iif(gettype(X) =="long","TRUE","FALSE")

isint(X) KQL 例

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") の例

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) KQL 例

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) KQL 例

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) KQL 例

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) KQL 例

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) KQL 例

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) KQL 例

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() KQL 例

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y)

文字列としてフィールド値Xを返します。

• Xのが数値の場合は、Xは文字列の値に再フォーマットされます。
• Xがブール値の場合は、XはTRUEまたはFALSEに再フォーマットされます。
• Xが数値の場合、2 番目の引数Yは省略可能で、hex (Xを16 進数に変換)、commas (Xをコンマと小数点以下 2 桁の書式)、または duration (Xを秒単位の時刻形式から読み取り可能な時刻形式HH:MM:SSに変換) のいずれかを指定することができます。

tostring(X,Y) SPL の例

この例では、以下が返されます。

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) SPL の例

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

一般的な統計コマンド KQL 例

次のステップ

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