Kusto クエリ言語 (KQL) は、データの分析を行って Analytics、Workbooks を作成し、Microsoft Sentinel と Microsoft Defender XDR でハンティング（アラートに頼らず、自分からログを調べて“潜んでいる脅威”を見つけに行く活動。目的：アラートになっていない不審な動きを探す）を実行するために使用されるクエリ言語。
Microsoft Sentinel の検知ルール（Analytics Rule）は、KQL（Kusto Query Language） で書かれています。
これは、Sentinel が Azure Monitor / Log Analytics 上で動いているためです。
環境
個人で検証用のログを置くにも費用が必要となる可能性があります。
マイクロソフトで提供している下記環境を利用することで Kusto Query Language（KQL）を実際に動かしながら確認を進められます。
🔷 検知ルールの正体＝KQLクエリ
Microsoft Sentinelの分析ルール（Analytics Rule） は、内部的には
「Log Analytics に蓄積されたログを KQL で定期的に検索し、条件に一致したらアラートを生成する仕組み」です。
🔶 イメージ図
ログ（Azure AD、Defender、Firewallなど）
↓
Log Analytics ワークスペース
↓
KQLクエリで検索（例：5分おき）
↓
一致 → アラート生成（Alert）
↓
必要に応じてインシデント化（Incident）・Playbook自動化
🔷 例：不審なログイン検知ルール（KQL）
以下は「同じユーザーが短時間に複数の場所からログインしたら検知する」例です。
SigninLogs
| summarize Countries = make_set(LocationDetails.countryOrRegion), Count = count()
by UserPrincipalName, bin(TimeGenerated, 15m)
| where array_length(Countries) > 1
👆このクエリの意味：
- SigninLogs：Azure ADのサインインログを対象
- summarize … by UserPrincipalName：ユーザーごとに15分単位で集計
- where array_length(Countries) > 1：複数の国から同時アクセスがあればアラート
このKQLを「Analytics Rule」に設定し、
“15分ごとに実行・結果が1件以上ならアラート” というように構成します。
🔶 ルールの構成要素（KQL以外の設定もあります）
| 区分 | 内容 | 例 |
|---|---|---|
| 1. 検知ロジック（KQL） | ログから異常を抽出するクエリ | `SigninLogs |
| 2. 実行頻度 | クエリを走らせる周期 | 5分 / 1時間 / 1日など |
| 3. 対象期間（Lookback period） | クエリが検索するログ範囲 | 例：過去1時間分 |
| 4. 結果のしきい値 | 何件以上ならアラートを上げるか | 例：5件以上ならアラート |
| 5. エンリッチメント | アラートに追加情報（ユーザー名、IP、国）を付与 | |
| 6. 自動応答（Playbook） | ServiceNow起票やTeams通知などの自動化 |
🔧 よく使われるログテーブルと用途
| テーブル名 | 代表的な検知例 |
|---|---|
SigninLogs | 不審なログイン、異常な国からのアクセス |
SecurityEvent | Windowsログオン失敗、特権昇格 |
DeviceProcessEvents | 不審なプロセス実行、PowerShell利用 |
DeviceNetworkEvents | 不審な外部通信、C2通信検知 |
CommonSecurityLog | FirewallやProxyログからの攻撃通信 |
ThreatIntelligenceIndicator | IOC（脅威インテリジェンス）との照合検知 |
🧩 Sentinel では3タイプのルールが存在
| タイプ | 内容 |
|---|---|
| Scheduled rule（スケジュール実行） | KQLクエリを一定間隔で実行（最も一般的） |
| Microsoft security rule | Defender製品などMicrosoftネイティブアラートをSentinelで取り込み |
| Fusion rule | 機械学習ベースで複数の信号を相関し自動検出（KQL不要） |
あなたが今日の「検知ルールチューニング会議」で扱うのは、
ほとんどがこの Scheduled（KQLベース）ルール です。
💡 まとめ
| 項目 | 内容 |
|---|---|
| 言語 | KQL（Kusto Query Language） |
| 目的 | ログを定期的に検索し、異常・攻撃を検知 |
| 出力 | アラート → インシデント → 自動化（Playbook） |
| 主な作業 | クエリ調整・誤検知除外・新規ルール作成 |
| 関連機能 | Analytics Rule, Log Analytics, Playbook, Threat Intelligence |
Kusto クエリ言語ステートメントの構造を理解する
表形式の式ステートメントの構文には、表形式クエリ演算子間の表形式のデータ フローがあります。 データ ソースから始まり、その後、パイプ (|) 区切り記号を使用してバインドされた一連のデータ変換演算子を通過します。
たとえば、次のクエリにはステートメントが 1 つありますが、それは表形式ステートメントです。 そのステートメントは、SecurityEvent というテーブルで始まります。 EventID 列の値によって、データ (行) がフィルター処理され、その後、アカウント別の件数 () を示す新しい列が作成されて結果が要約されます。 次に、準備フェーズで、結果は 10 行に制限されます。
重要
結果がパイプ “|” を通過する方法を理解することが不可欠です。 パイプの左側にあるすべてが処理され、パイプの右側に渡されます。
コメント