KQL Basics Every SOC Analyst Should Know

Kusto Query Language (KQL) は、Microsoft Sentinel および Microsoft Defender における脅威ハンティングとアラートトリアージの中核です。SOC で働いている場合、KQL に習熟していることが、「ここで何が起きたのか？」に素早く答えられるアナリストと、ダッシュボードをクリックして回るだけのアナリストを分けます。これは完全な言語リファレンスではなく、シフト中に常に使用される実用的なサブセットです。

SOC における KQL の重要性

KQL は読み取り専用で、大規模なログデータセットを高速にクエリするために最適化されています。Sentinel、Defender for Endpoint、Azure Monitor、Log Analytics のすべてが対応しています。一度習得すれば、同じメンタルモデルで製品間を移動できます：テーブルを選択し、それをフィルタリングし、出力を整形する。すべての調査（フィッシングトリアージ、横方向の移動ハント、誤検知の調整）はクエリから始まります。

パイプがすべて

KQL クエリはパイプラインとして構築されます。テーブルから始めて、一連のオペレータを通じてデータを渡します。各オペレータは前の結果をフィルタリング、変換、または集計します：

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

これを上から下へ文のように読みます：SecurityEvent ログから始まり、ログイン失敗のみを保持し（4625）、過去 1 日に制限し、アカウント/コンピュータごとに失敗数をカウントしてからソートします。この直線的な可読性は、アドホックハンティング向けに SQL より KQL の最大の強みです。

覚えておくべきコアオペレータ

• where — プライマリフィルタです。データ量を削減して、高コストの操作の前に頻繁に使用します。
• project — 特定の列を選択して名前を変更し、出力に必要のないノイズを削除します。
• extend — 既存の列を削除せずに計算列を追加します。文字列の解析または条件フラグに便利です。
• summarize — count()、sum()、dcount()、または make_set() を使用してデータを集計します。ほぼ常に by と組み合わせます。
• join — テーブル間でデータを関連付けます。例えば、サインインログをデバイスインベントリとリンクして、管理されていないデバイスのログインを検出します。
• render — 結果をタイムチャートまたは棒グラフとしてクエリエディタで直接視覚化します。スパイク検出に便利です。

適切な時間フィルタリング

パイプラインの早い段階で TimeGenerated（またはテーブルの同等のタイムスタンプ列）をフィルタリングしてください。KQL エンジンは時間範囲フィルタの周りで大幅に最適化され、| where TimeGenerated > ago(7d) を下部ではなく上部に配置することで、秒単位で返されるクエリと、ビジー状態のテナントでタイムアウトするクエリの違いになります。

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"
| where UserPrincipalName has "@yourdomain.com"

文字列マッチング：has vs contains vs ==

よくある間違いは、すべてに contains をデフォルトとすることです。has は単語全体にマッチし、用語インデックスを使用するため、大きなテーブルで劇的に高速です。contains は、単語内のサブストリングマッチが必要な場合（部分的なドメインフラグメントなど）にのみ使用し、EventID や IPAddress などの構造化フィールドには == を使用してください。この習慣ひとつで、DeviceNetworkEvents や CommonSecurityLog のような高ボリュームテーブル全体でのハントが著しく高速化します。

DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

再利用可能な検出ロジックの構築

クエリが有用であることが証明されたら、let で関数にラップするか、Sentinel Analytics Rule としてスケジュール実行で保存します。閾値（ログイン失敗数など）をパラメータ化し、同じロジックがテナント全体で拡張されるか、最初から書き直さずにチューニングできるようにします。これは、1 回限りのハンティングクエリが SOC を自動的にページアウトする常続的な検出にどのように発展するかです。

よくある落とし穴

• TimeGenerated フィルタを忘れて、遅く、高コストなフルテーブルスキャンを引き起こします。
• where の前に summarize を使用して、エンジンがフィルタリングされていないデータを集計するように強制します。
• テーブル結合時の列名の不一致 — 常に getschema で最初にスキーマを確認してください。
• contains を過度に使用し、インデックスメリットをスキップして大規模ハントを遅くします。

KQL は、ネストされたサブクエリではなくパイプラインで考えるアナリストに報いています。すべての調査を狭い時間窓と特定のテーブルで開始し、必要に応じてのみ拡大します。

これが堅固な基盤を提供した場合、Korra Studio のブルーチームとデジタルフォレンジックスセグメントを探索して、より実践的な SOC クエリウォークスルーと検出構築演習を確認してください。