この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。
こんにちは。パーソルプロセス＆テクノロジーの三浦です。
今回はAzure Sentinelのインシデント分析ルールとその作成方法について説明します。
はじめに
Azure Sentinelとは、オンプレからクラウドまで幅広く監視を行うことができるオールインワンな監視サービスです。AzureやOffice365、オンプレサーバなどからログを収集し、脅威の検出、インシデントの調査、自動対処などを行うことができます。詳しくはこちらの記事をご参照ください。
分析ルールとは、集められたログの中から不審なものはどれかという定義を行い、脅威の検出を行うものです。Azure Sentinel には多数の分析ルールのテンプレートが用意されており、それらによって脅威を検出し、攻撃から守ることができます。
今回は分析ルールとはどのようなものであるか、そしてどのようにして分析ルールを作成するかの手順を説明します。
分析ルールとは
まずAzure Sentinelにおいて、分析ルールがどのように定義されているかを見ていきます。分析ルールを見るには、Azure Sentinel の分析ブレードを開きます。
インシデントの分析ルールにはいくつか種類がありますが、今回はスケジュール済みクエリルールについて説明します。スケジュール済みクエリルールとは、ログテーブルからKustoクエリ言語(KQL)で定義された不審な動きを表すログを抽出してインシデントを検出するものです。
Kustoクエリ言語はテーブルからレコードを抽出するクエリ言語の一種です。基本的な文法はSQLと類似していますが、パイプライン「|」でクエリを区切ることが特徴です。以下に代表的なKQLの文法を示します。
1,<テーブル名> | where <カラム名>== <値> 指定した値と等しいカラムを持つレコードを抽出する
例: OfficeActivity | where UserType == “DcAdmin”
2,<テーブル名> | project <カラム名1> ,<カラム名2> 指定したカラム名のみ表示する
例: OfficeActivity | project Operation , UserType
3,<テーブル名> | summrize Count = count() by <カラム名> 指定したカラムの数を集計する。whereと併用される。
例: OfficeActivity | where UserType == “DcAdmin” | summarize Count = count() by UserType
具体的な分析ルールを見ていきます。規則のテンプレートの中から、今回は「Office policy tampering(Officeポリシーの改ざん)」というルールを選択し、右の「ルールの作成」をクリックします。
ルールの作成をクリックすると、このようにルールに関する詳細ページが表示されます。最初に表示される全般タブには、名前、説明、方針、重大度などが記述されています。方針は検出する攻撃の種類をプルダウンメニューから選択できます。重大度はインシデントの重大度を高、中、低、情報提供の四段階から選択できます。
ルールのロジックを設定タブには、インシデントの具体的な定義が記述されています。具体的には、ルールのクエリ、クエリのスケジュール設定、アラートの閾値などが記述されています。クエリに関しては、「現在のデータでテストする」をクリックすると、現在のログテーブルでそのクエリを実行した結果が表示されます。
エリのスケジュール設定では、クエリの実行頻度およびどれだけの過去のデータを参照するかを指定できます。また、アラートの閾値では、クエリによって取り出されたレコードの数の閾値を指定できます。基本的には閾値を0にし、1つ以上レコードが取り出された場合アラートを出す設定にすることが多いです。
インシデントの設定タブでは、アラートのグループ化などの設定を行うことができます。
自動応答タブでは、インシデント発生時の自動対応を設定することができます。例えば、Teamsにメッセージを送信するlogicAppsを作成し、それを登録することで、インシデント発生時にTeamsにメッセージを送信する自動応答を設定することができます。
最後に確認と作成タブでの右下の作成ボタンをクリックすると、分析ルールが作成されます。
分析ルールの作成
分析ルールの作成方法について説明します。今回は1時間以内に10以上のユーザが削除されたことを検出する分析ルールを作成します。
上部の作成ボタンをクリックし、プルダウンメニューから「スケジュール済みクエリルール」を選択してクリックします。
全般タブで名前、説明、方針、重大度、状態を定義します。名前は「Delete many users in 1 hour」とします。説明にも内容に準じた説明を書きます。方針は「Persistence」と「Privilege Escalation」を選択し、重大度を中、状態を有効にしておきます。
ルールのロジックを設定タブで、インシデントの具体的な定義を行います。ルールのクエリには、Azure AD の監査ログ(AuditLog)からユーザが削除されたことを示すレコードを取り出すクエリを記述します。
クエリは1時間ごとに実行し、1時間で10より大きい結果件数だった場合にインシデントとして検出する設定にします。
インシデントの設定タブはデフォルトのままにします。
自動応答はとくに設定しないこととします。
最後に確認を行い、作成ボタンをクリックすると、分析ルールが作成されます。
インシデントを発生させる
先ほど定義した分析ルールに基づいてインシデントが発生するかどうかを確認します。
実際に10個のユーザを用意し、一気に削除します。すると、Azure AD の監査ログに以下のようなログが残ります。アクティビティが”Delete user”になっているレコードが10個あるのがわかります。
1時間待つと、インシデントがAzure Sentinelの概要ブレードの画面上に表示されます。
インシデントの名前をクリックすると、インシデントの詳細画面が表示されます。この画面で、担当者の割り当てなどの対処を行うことができます。
おわりに
今回は、Azure Sentinelの分析ルールについて説明をしました。ほかにもAzure Sentinelには自動応答など様々な機能があります。以下の記事なども参考にしてみてください。
(この記事が参考になった人の数：1)
読み込み中...