テストルールを使用してデータの取り込みを検証する
Chronicle のキュレーションされた検出機能には、各ルールセットに必要なデータが正しい形式であることを確認するための一連のテストルールセットが含まれています。
これらのテストルールは、Managed Detection Testing カテゴリの下にあります。各ルールセットでは、テストデバイスで受信したデータが、指定したカテゴリのルールで想定されている形式であることを検証します。
| ルールセット名 | 説明 |
|---|---|
| GCP Managed Detection Testing | クラウドの脅威のカテゴリでサポートされているデバイスから Google Cloud データが正常に取り込まれることを検証します。 詳細については、クラウドの脅威のカテゴリの Google Cloud データ取り込みを検証するをご覧ください。 |
| AWS Managed Detection Testing | クラウドの脅威のカテゴリでサポートされているデバイスから AWS データが正常に取り込まれることを検証します。 詳細については、クラウドの脅威のカテゴリの AWS データ取り込みを検証するをご覧ください。 |
| Linux Managed Detection Testing | Linux 脅威のカテゴリでサポートされているデバイスからデータが取り込まれることを検証します。 詳細については、Linux 脅威のカテゴリのデータ取り込みを検証するをご覧ください。 |
| Windows Managed Detection Testing | Windows 脅威のカテゴリでサポートされているデバイスからデータが取り込まれることを検証します。 詳細については、Windows 脅威のカテゴリのデータ取り込みを検証するをご覧ください。 |
このドキュメントの手順に沿って受信データが正しく取り込まれており、正しい形式であることをテストして検証します。
クラウド脅威のカテゴリの Google Cloud データ取り込みを検証する
これらのルールは、ログデータが Chronicle のキュレーションされた検出機能の想定どおりに取り込まれているかどうかを検証するのに役立ちます。
続きのステップでは、以下のものを使用してデータをテストする方法について説明します。
Cloud Audit Metadata Testing ルール: このルールをトリガーするには、Chronicle にデータを送信する Compute Engine 仮想マシンに予想される一意のカスタム メタデータキーを追加します。
Cloud DNS Testing ルール: このルールをトリガーするには、インターネットにアクセスでき、ログを Chronicle に送信する任意の仮想マシン内でドメイン（
chronicle.security）に対して DNS ルックアップを実行します。SCC Managed Detection Testing ルール: これらのルールをトリガーするには、Google Cloud コンソールで複数のアクションを実行します。
Cloud Kubernetes Node Testing ルール: このルールをトリガーするには、Chronicle にログデータを送信するテスト プロジェクトを作成し、既存の Google Kubernetes Engine クラスタに一意のノードプールを作成します。
ステップ 1. テストルールを有効にする
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- [ルールと検出] > [ルールセット] をクリックします。
- [Managed Detection Testing] セクションを開きます。ページをスクロールしなければならない場合があります。
- リスト内の [GCP Managed Detection Testing] をクリックして、詳細ページを開きます。
- Windows Managed Detection Testing ルールのステータスとアラートをどちらも有効にします。
ステップ 2. Cloud Audit Metadata Testing ルールのデータを送信する
テストをトリガーするには、次の手順を行います。
- 組織内のプロジェクトを選択します。
- Compute Engine に移動し、プロジェクト内の仮想マシンを選択します。
- 仮想マシン内で [編集] をクリックし、[カスタム メタデータ] セクションで次の操作を行います。
- [項目を追加] をクリックします。
- 次の情報を入力します。
- 鍵:
GCTI_ALERT_VALIDATION_TEST_KEY - 値:
works
- 鍵:
- [保存] をクリックします。
アラートがトリガーされたことを確認する手順は次のとおりです。
- Chronicle にログインする
- [Curated Detections] ページを開き、[ダッシュボード] をクリックします。
- 検出リストで tst_GCP_Cloud_Audit_Metadata ルールがトリガーされたことを確認します。
ステップ 3. Cloud DNS Testing ルールのデータを送信する
次の手順は、Compute Engine 仮想マシンにアクセスできる、選択したプロジェクトの IAM ユーザーとして実行する必要があります。
テストをトリガーするには、次の手順を行います。
- 組織内のプロジェクトを選択します。
- Compute Engine に移動し、プロジェクト内の仮想マシンを選択します。
- Linux 仮想マシンの場合は、SSH アクセスが可能なことを確認します。
- Windows 仮想マシンの場合は、RDP にアクセスできることを確認します。
- [SSH（Linux）] または [RDP（Microsoft Windows）] をクリックして、仮想マシンにアクセスします。
次のいずれかの手順でテストデータを送信します。
Linux 仮想マシン: SSH を使用して仮想マシンにアクセスして、
nslookup chronicle.securityまたはhost chronicle.securityのいずれかのコマンドを実行します。コマンドが失敗した場合は、次のいずれかのコマンドを使用して仮想マシンに
dnsutilsをインストールします。sudo apt-get install dnsutils（Debian / Ubuntu 版）dnf install bind-utils（RedHat / CentOS の場合）yum install bind-utils
Microsoft Windows 仮想マシン: RDP を使用して仮想マシンにアクセスしたら、インストールされている任意のブラウザに移動し、次の URL を参照します: https://chronicle.security
アラートがトリガーされたことを確認する手順は次のとおりです。
- Chronicle にログインする
- [Curated Detections] ページを開き、[ダッシュボード] をクリックします。
- 検出リストで、tst_GCP_Cloud_DNS_Test_Rule ルールがトリガーされたことを確認します。
手順 4. Cloud Kubernetes Node Testing ルールのデータを送信する
次の手順は、Google Kubernetes Engine リソースにアクセスできる、選択したプロジェクトの IAM ユーザーとして実行する必要があります。リージョン クラスタとノードプールの作成の詳細については、シングルゾーンのノードプールを持つリージョン クラスタを作成するをご覧ください。
テストルールをトリガーするには、次の手順を行います。
- 組織内に
chronicle-kube-test-projectという名前のプロジェクトを作成します。このプロジェクトはテスト専用です。 - Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
[Google Kubernetes Engine] ページに移動 - [作成] をクリックして、プロジェクトに新しいリージョン クラスタを作成します。組織の要件に従ってクラスタを構成します。
- [add_boxノードプールを追加] をクリックします。
- ノードプールに
kube-node-validationという名前を付け、プールサイズをリージョンごとに 1 ノードに調整します。 - テストリソースを削除します。
kube-node-validationノードプールを作成したら、ノードプールを削除します。chronicle-kube-test-projectテスト プロジェクトを削除します。
[Curated Detections] ページを開き、[ダッシュボード] をクリックします。
検出リストで、tst_GCP_Kubernetes_Node ルールがトリガーされたことを確認します。
検出リストで、tst_GCP_Kubernetes_CreateNodePool ルールがトリガーされたことを確認します。
ステップ 5. SCC Managed Detection Testing ルールのデータを送信する
次のセクションの手順では、Security Command Center の検出結果と関連データが、想定どおりの形式で正しく取り込まれることを確認します。
Managed Detection Testing カテゴリの SCC Managed Detection Testing ルールセットで、CDIR SCC Enhanced ルールセットで必要なデータが Chronicle に送信されていること、形式が正しいことを確認できます。
各テストルールでは、受信したデータが、ルールで想定されている形式であることを検証します。Google Cloud 環境でアクションを実行して、Chronicle アラートを生成するデータを送信します。
Google Cloud サービスでのロギングの構成、Security Command Center Premium の検出結果の収集、Security Command Center の検出結果の Chronicle への送信に必要なこのドキュメントの次のセクションを完了してください。
このセクションで説明する Security Command Center のアラートの詳細については、Security Command Center のドキュメントの脅威の調査と対処をご覧ください。
CDIR SCC 永続性テストルールをトリガーする
Chronicle でこのアラートをトリガーするデータを送信するには、次の手順を行います。
Google Cloud コンソールで新しい VM インスタンスを作成し、編集者権限で Compute Engine のデフォルト サービス アカウントを一時的に割り当てます。これはテストの完了後に削除します。
新しいインスタンスが利用可能になったら、[アクセス スコープ] を [すべての API への完全アクセス権を許可] に割り当てます。
次の情報を使用して、新しいサービス アカウントを作成します。
- [サービス アカウント名] を
scc-testに設定します。 - [サービス アカウント ID] を
scc-testに設定します。 - 必要に応じて、サービス アカウントの説明を入力します。
サービス アカウントの作成方法の詳細については、サービス アカウントを作成するのドキュメントをご覧ください。
- [サービス アカウント名] を
前の手順で作成したテスト インスタンスに SSH を使用して接続し、次の
gcloudコマンドを実行します。gcloud projects add-iam-policy-binding PROJECT_NAME --member="serviceAccount:scc-test@PROJECT_NAME.iam.gserviceaccount.com" --role="roles/owner`"PROJECT_NAMEは、Compute Engine インスタンスが実行され、scc-testアカウントが作成されたプロジェクトの名前で置き換えます。永続性: IAM 異常付与の Security Command Center アラートが起動します。
Chronicle にサインインし、[Alerts & IOCs] ページを開きます。
Test SCC Alert: IAM Anomalous Grant given to test account というタイトルの Chronicle アラートが表示されます。
Google Cloud コンソールを開き、次の操作を行います。
- IAM と管理コンソールから
scc-testテスト アカウントのアクセス権を削除します。 - サービス アカウント ポータルを使用してサービス アカウントを削除します。
- 作成した VM インスタンスを削除します。
- IAM と管理コンソールから
CDIR SCC マルウェア テストルールをトリガーする
Chronicle でこのアラートをトリガーするデータを送信するには、次の手順を行います。
Google Cloud コンソールで、
curlコマンドがインストールされている VM インスタンスに SSH を使用して接続します。次のコマンドを実行します。
curl etd-malware-trigger.googこのコマンドを実行すると、Malware: Bad Domain Security Command Center のアラートがトリガーされます。
Chronicle にサインインし、[Alerts & IOCs] ページを開きます。
Test SCC Alert: Malware Bad Domain というタイトルの Chronicle アラートが表示されていることを確認します。
CDIR SCC 防御回避テストルールをトリガーする
Chronicle でこのアラートをトリガーするデータを送信するには、次の手順を行います。
組織レベルでアクセスできるアカウントを使用して Google Cloud コンソールにサインインし、VPC Service Control 境界を変更します。
Google Cloud コンソールで、[VPC Service Controls] ページに移動します。
[+新しい境界] をクリックして、[詳細] ページで次のフィールドを構成します。
- 境界のタイトル:
scc_test_perimeter. - [境界タイプ] を [標準の境界（デフォルト）] に設定します。
- [構成タイプ] を [適用] にします。
- 境界のタイトル:
左側のナビゲーションで、[3 制限付きサービス] を選択します。
[制限するサービスの指定] ダイアログで [Google Compute Engine API] を選択し、[Google Compute Engine API を追加] をクリックします。
左側のナビゲーションで、[境界を作成] をクリックします。
境界を変更するには、[VPC サービス境界] ページに移動します。このページへのアクセス方法について詳しくは、サービス境界の一覧と説明をご覧ください。
[
scc_test_perimeter]、[境界を編集] の順に選択します。[制限付きサービス] で [削除] アイコンをクリックして、Google Compute Engine API サービスを削除します。これにより、SCC の Defense Evasion: Modify VPC Service Control Perimeter のアラートがトリガーされます。
Chronicle にサインインし、[Alerts & IOCs] ページを開きます。
Test SCC Alert: Modify VPC Service Control Test Alert というタイトルの Chronicle アラートが表示されていることを確認します。
CDIR SCC 引き出しテストルールをトリガーする
Chronicle でこのアラートをトリガーするデータを送信するには、次の手順を行います。
Google Cloud コンソールで Google Cloud プロジェクトに移動し、BigQuery を開きます。
次のデータを含む CSV ファイルを作成し、ホーム ディレクトリに保存します。
column1, column2, column3 data1, data2, data3 data4, data5, data6 data7, data8, data9左側のナビゲーションで、[データセットを作成] を選択します。
次の構成を設定してから、[データセットを作成] をクリックします。
- [データセット ID] を
scc_test_datasetに設定します。 - [ロケーション タイプ] を [マルチリージョン] に設定します。
- テーブルの有効期限を有効にする: このオプションは選択しないでください。
データセットの作成方法について詳しくは、BigQuery ドキュメントのデータセットの作成をご覧ください。
- [データセット ID] を
左側のナビゲーションで、
scc_test_datasetの右側にある more_vert アイコンをクリックし、[テーブルを作成] を選択します。テーブルを作成し、次の構成を設定します。
- テーブルの作成元: [アップロード] に設定します。
- ファイルを選択: ホーム ディレクトリを参照し、前に作成した CSV ファイルを選択します。
- ファイル形式: CSV に設定します。
- データセット:
css_test_datasetに設定します。 - テーブルタイプ: [ネイティブ テーブル] に設定します。
他のすべてのフィールドのデフォルト構成を受け入れ、[Create Table] をクリックします。
テーブルの作成方法について詳しくは、BigQuery ドキュメントのテーブルの作成と使用をご覧ください。
リソースリストで
css_test_datasetテーブルを選択し、[クエリ] をクリックして [新しいタブ] を選択します。
次のクエリを実行します。
SELECT * FROM TABLE_NAME LIMIT 1000`TABLE_NAMEは、完全修飾のテーブル名に置き換えます。クエリが実行されたら、[Save Results] をクリックしてから、[CSV in Google Drive] を選択します。これにより、Exfiltration: BigQuery Exfiltration to Google Drive の Security Command Center アラートがトリガーされます。Security Command Center の検出結果が Chronicle に送信され、Chronicle アラートがトリガーされるはずです。
Chronicle にサインインし、[Alerts & IOCs] ページを開きます。
Test SCC Alert: BigQuery Exfiltration to Google Drive というタイトルの Chronicle アラートが表示されていることを確認します。
ステップ 6. テストルールを無効にする
終了したら、GCP Managed Detection Testing ルールを無効にします。
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- GCP Managed Detection Testing ルールのステータスとアラートをどちらも無効にします。
クラウドの脅威のカテゴリの AWS データ取り込みを検証する
AWS Managed Detection Testing テストルールを使用して、AWS データが Chronicle に取り込まれていることを確認できます。これらのテストルールは、AWS データが取り込まれており、想定どおりの形式であることを確認するのに役立ちます。AWS データの取り込みを設定したら、テストルールをトリガーするアクションを AWS で実行します。
- Detection Engine でこれらのルールを有効にするユーザーには、
curatedRuleSetDeployments.batchUpdateIAM 権限が必要です。 - AWS データを送信する手順を実行するユーザーには、選択したアカウントの EC2 インスタンスのタグを編集するための AWS IAM 権限が必要です。EC2 インスタンスのタグ付けの詳細については、AWS ドキュメントの Amazon EC2 リソースにタグ付けするをご覧ください。
AWS Managed Detection Testing テストルールを有効にする
- Chronicle で、[検出] > [ルールと検出] をクリックして、[キュレーションされた検出機能] ページを開きます。
- [Managed Detection Testing] > [AWS Managed Detection Testing] を選択します。
- Broad ルールと Precise ルールでステータスとアラートの両方を有効にしました。
AWS のタグ アクションによってテストルールがトリガーされることを確認する
次の手順を実行して、AWS のタグ アクションがルールセットをトリガーすることを確認します。
ステップ 1. AWS でログイベントを生成します。
- AWS 環境内のアカウントを選択します。
- EC2 ダッシュボードに移動し、アカウント内のインスタンスを選択します。
- EC2 インスタンス内で、[Actions] をクリックしてから、[Instance Settings] をクリックし、[Manage Tags] セクションで次の操作を行います。
- [新しいタグを追加する] をクリックします。
- 次の情報を入力します。
- キー:
GCTI_ALERT_VALIDATION_TEST_KEY - 値:
works - [保存] をクリックします。
詳細については、EC2 インスタンス タグを追加または削除するをご覧ください。
ステップ 2. テストアラートがトリガーされたことを確認する
前の手順でタスクを実行した後、AWS CloudTrail Test Rule のルールがトリガーされたことを確認します。これは、CloudTrail ログが想定どおりに記録され、Chronicle に送信されたことを示します。次の手順を行なってアラートを確認します。
- Chronicle で、[検出] > [ルールと検出] をクリックして、[キュレーションされた検出機能] ページを開きます。
- [ダッシュボード] をクリックします。
- 検出のリストで、tst_AWS_Cloud_Trail_Tag のルールがトリガーされたことを確認します。
AWS GuardDuty のサンプル検出結果がテストルールをトリガーすることを確認する
GuardDuty アラートが環境で意図したとおりに機能するように、GuardDuty のサンプル検出結果を Chronicle に送信できます。
ステップ 1. GuardDuty のサンプル検出結果データを生成します。
- AWS コンソールのホームに移動します。
- [セキュリティ、ID、コンプライアンス] で [GuardDuty] を開きます。
- GuardDuty の [設定] に移動します。
- [サンプル検出結果を生成する] をクリックします。
サンプル GuardDuty の検出結果を生成する方法については、GuardDuty でのサンプル検出結果の生成をご覧ください。
ステップ 2. テストアラートがトリガーされたことを確認する。
- Chronicle で、[検出] > [ルールと検出機能] をクリックして、[キュレーションされた検出機能] ページを開きます。
- [ダッシュボード] をクリックします。
- 検出リストで、AWS CloudTrail Test Rule がトリガーされたことを確認します。
AWS Managed Detection Testing のルールセットを無効にする
- Chronicle で、[検出] > [ルールと検出機能] をクリックして、[キュレーションされた検出機能] ページを開きます。
- [Managed Detection Testing] のルール> [AWs Managed Detection Testing] のルールを選択します。
- Broad ルールと Precise ルールのステータスとアラートをどちらも無効にします。
Linux 脅威のカテゴリのデータ取り込みを検証する
Linux Managed Detection Testing ルールでは、Linux システムのロギングが、Chronicle のキュレーテッド検出に対して正しく機能していることを確認します。テストでは、Linux 環境で Bash プロンプトを使用してさまざまなコマンドを実行します。このテストは、Linux Bash プロンプトにアクセスできるすべてのユーザーが実行できます。
ステップ 1. テストルールを有効にする
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- [ルールと検出] > [ルールセット] をクリックします。
- [Managed Detection Testing] セクションを開きます。ページをスクロールしなければならない場合があります。
- リスト内の [Linux Managed Detection Testing] をクリックして、詳細ページを開きます。
- Linux Managed Detection Testing ルールのステータスとアラートをどちらも有効にします。
ステップ 2. Linux デバイスからテストデータを送信する
Linux Managed Detection Testing テストルールをトリガーするには、次の手順を行います。
- データを Chronicle に送信する Linux デバイスにアクセスします。
- 任意のユーザーとして新しい Linux Bash プロンプト コマンドライン インターフェースを開きます。
次のコマンドを入力して Enter キーを押します。
/bin/echo hello_chronicle_world!
Linux シェルの組み込みの echo コマンドではなく、echo バイナリを使用する必要があります。
次のコマンドを入力して Enter キーを押します。
sudo useradd test_chronicle_account前の手順で作成したテスト アカウントを削除します。次のコマンドを実行します。
sudo userdel test_chronicle_account次のコマンドを入力して Enter キーを押します。
suパスワードの入力を求められたら、ランダムな文字列を入力します。
su: Authentication failureメッセージが表示されます。Bash ウィンドウを閉じます。
ステップ 3. Chronicle でアラートがトリガーされたことを検証する
コマンドによって、Chronicle で *tst_linux_echo、tst_linux_failed_su_login、tst_linux_test_account_creation の各ルールがトリガーされたことを確認します。これは、Linux ログが想定どおりに書き込まれ、送信されていることを示します。Chronicle でアラートを確認するには、次の手順を行います。
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- [ダッシュボード] をクリックします。
検出リストで、tst_linux_echo、tst_linux_failed_su_login、tst_linux_test_account_creation の各ルールがトリガーされたことを確認します。
ステップ 4. テストルールを無効にする
終了したら、Linux Managed Detection Testing ルールを無効にします。
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- Linux Managed Detection Testing ルールのステータスとアラートをどちらも無効にます。
Windows 脅威のカテゴリのデータ取り込みを検証する
Windows Echo のテストルールにより、Microsoft Windows のロギングが Chronicle のキュレートされた検出に対して正しく機能していることを検証します。このテストでは、Microsoft Windows 環境でコマンド プロンプトを使用して、予想される一意の文字列で echo コマンドを実行します。
Windows コマンド プロンプトにアクセスできる任意のユーザーとしてログインした状態でテストを行うことができます。
ステップ 1. テストルールを有効にする
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- [Managed Detection Testing] セクションを開きます。ページをスクロールしなければならない場合があります。
- リスト内の [Windows Managed Detection Testing] をクリックして、詳細ページを開きます。
- Windows Managed Detection Testing のルールのステータスとアラートをどちらも有効にします。
ステップ 2. Windows デバイスからテストデータを送信する
Windows Echo Test Rule をトリガーするには、次の手順を行います。
- Chronicle に送信されるデータを生成するデバイスにアクセスします。
- 任意のユーザーとして新しい Microsoft Windows Command Prompt ウィンドウを開きます。
大文字と小文字を区別しない次のコマンドを入力して、Enter キーを押します。
cmd.exe /c "echo hello_chronicle_world!"Command Prompt ウィンドウを閉じます。
ステップ 3. アラートがトリガーされたことを検証する
コマンドによって Chronicle で tst_Windows_Echo のルールがトリガーされたことを確認します。 これは、Microsoft Windows のロギングが期待どおりにデータを送信していることを示します。 Chronicle でアラートを確認するには、次の手順を行います。
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- [ダッシュボード] をクリックします。
検出リストで tst_Windows_Echo ルールがトリガーされたことを確認します。
ステップ 4. テストルールを無効にする
終了したら、Windows Managed Detection Testing ルールを無効にします。
- Chronicle にログインします。
- [キュレーションされた検出機能] ページを開きます。
- Windows Managed Detection Testing ルールのステータスとアラートをどちらも無効にします。