テストルールを使用してデータの取り込みを検証する

Google Security Operations のキュレーションされた検出機能には、各ルールセットに必要なデータが正しい形式であることを確認するための一連のテストルールセットが含まれています。

これらのテストルールは、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 データ取り込みを検証する

これらのルールは、ログデータが Google Security Operations のキュレーションされた検出機能の想定どおりに取り込まれているかどうかを検証するのに役立ちます。

続きのステップでは、以下のものを使用してデータをテストする方法について説明します。

  • Cloud Audit Metadata Testing ルール: このルールをトリガーするには、Google Security Operations にデータを送信する Compute Engine 仮想マシンに予想される一意のカスタム メタデータキーを追加します。

  • Cloud DNS Testing ルール: このルールをトリガーするには、インターネットにアクセスでき、ログを Google Security Operations に送信する任意の仮想マシン内でドメイン（chronicle.security）に対して DNS ルックアップを実行します。

  • SCC Managed Detection Testing ルール: これらのルールをトリガーするには、Google Cloud コンソールで複数のアクションを実行します。

  • Cloud Kubernetes Node Testing ルール: このルールをトリガーするには、Google Security Operations にログデータを送信するテスト プロジェクトを作成し、既存の Google Kubernetes Engine クラスタに一意のノードプールを作成します。

ステップ 1. テストルールを有効にする

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. [ルールと検出] > [ルールセット] をクリックします。
  4. [Managed Detection Testing] セクションを開きます。ページをスクロールしなければならない場合があります。
  5. リスト内の [GCP Managed Detection Testing] をクリックして、詳細ページを開きます。
  6. Windows Managed Detection Testing ルールのステータスとアラートをどちらも有効にします。

ステップ 2. Cloud Audit Metadata Testing ルールのデータを送信する

テストをトリガーするには、次の手順を行います。

  1. 組織内のプロジェクトを選択します。
  2. Compute Engine に移動し、プロジェクト内の仮想マシンを選択します。
  3. 仮想マシン内で [編集] をクリックし、[カスタム メタデータ] セクションで次の操作を行います。
    • [項目を追加] をクリックします。
    • 次の情報を入力します。
      • 鍵: GCTI_ALERT_VALIDATION_TEST_KEY
      • 値: works
    • [保存] をクリックします。

  4. アラートがトリガーされたことを確認する手順は次のとおりです。

    1. Google Security Operations にログインする
    2. [Curated Detections] ページを開き、[ダッシュボード] をクリックします。
    3. 検出リストで tst_GCP_Cloud_Audit_Metadata ルールがトリガーされたことを確認します。

ステップ 3. Cloud DNS Testing ルールのデータを送信する

次の手順は、Compute Engine 仮想マシンにアクセスできる、選択したプロジェクトの IAM ユーザーとして実行する必要があります。

テストをトリガーするには、次の手順を行います。

  1. 組織内のプロジェクトを選択します。
  2. Compute Engine に移動し、プロジェクト内の仮想マシンを選択します。
    • Linux 仮想マシンの場合は、SSH アクセスが可能なことを確認します。
    • Windows 仮想マシンの場合は、RDP にアクセスできることを確認します。
  3. [SSH（Linux）] または [RDP（Microsoft Windows）] をクリックして、仮想マシンにアクセスします。

  4. 次のいずれかの手順でテストデータを送信します。

    • 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

  5. アラートがトリガーされたことを確認する手順は次のとおりです。

    1. Google Security Operations にログインする
    2. [Curated Detections] ページを開き、[ダッシュボード] をクリックします。
    3. 検出リストで、tst_GCP_Cloud_DNS_Test_Rule ルールがトリガーされたことを確認します。

手順 4. Cloud Kubernetes Node Testing ルールのデータを送信する

次の手順は、Google Kubernetes Engine リソースにアクセスできる、選択したプロジェクトの IAM ユーザーとして実行する必要があります。リージョン クラスタとノードプールの作成の詳細については、シングルゾーンのノードプールを持つリージョン クラスタを作成するをご覧ください。

テストルールをトリガーするには、次の手順を行います。

  1. 組織内に chronicle-kube-test-project という名前のプロジェクトを作成します。このプロジェクトはテスト専用です。
  2. Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
    [Google Kubernetes Engine] ページに移動
  3. [作成] をクリックして、プロジェクトに新しいリージョン クラスタを作成します。組織の要件に従ってクラスタを構成します。
  4. [ノードプールを追加] をクリックします。
  5. ノードプールに kube-node-validation という名前を付け、プールサイズをゾーンあたり 1 ノードに調整します。
  6. テストリソースを削除します。
    1. kube-node-validation ノードプールを作成したら、ノードプールを削除します。
    2. chronicle-kube-test-project テスト プロジェクトを削除します。

  7. Google Security Operations にログインします。

  8. [Curated Detections] ページを開き、[ダッシュボード] をクリックします。

  9. 検出リストで、tst_GCP_Kubernetes_Node ルールがトリガーされたことを確認します。

  10. 検出リストで、tst_GCP_Kubernetes_CreateNodePool ルールがトリガーされたことを確認します。

ステップ 5. SCC Managed Detection Testing ルールのデータを送信する

次のセクションの手順では、Security Command Center の検出結果と関連データが、想定どおりの形式で正しく取り込まれることを確認します。

[Managed Detection Testing] カテゴリの [SCC Managed Detection Testing] ルールセットで、CDIR SCC Enhanced ルールセットで必要なデータが Google Security Operations に送信されていること、形式が正しいことを確認できます。

各テストルールでは、受信したデータが、ルールで想定されている形式であることを検証します。Google Cloud 環境でアクションを実行して、Google Security Operations のアラートを生成するデータを送信します。

Google Cloud サービスでのロギングの構成、Security Command Center Premium の検出結果の収集、Security Command Center の検出結果の Google Security Operations への送信に必要なこのドキュメントの次のセクションを完了してください。

このセクションで説明する Security Command Center のアラートの詳細については、Security Command Center のドキュメントの脅威の調査と対処をご覧ください。

CDIR SCC 永続性テストルールをトリガーする

Google Security Operations でこのアラートをトリガーするデータを送信するには、次の手順を行います。

  1. Google Cloud コンソールで新しい VM インスタンスを作成し、編集者権限で Compute Engine のデフォルト サービス アカウントを一時的に割り当てます。これはテストの完了後に削除します。

  2. 新しいインスタンスが利用可能になったら、[アクセス スコープ] を [すべての API への完全アクセス権を許可] に割り当てます。

  3. 次の情報を使用して、新しいサービス アカウントを作成します。

    • [サービス アカウント名] を scc-test に設定します。
    • [サービス アカウント ID] を scc-test に設定します。
    • 必要に応じて、サービス アカウントの説明を入力します。

    サービス アカウントの作成方法の詳細については、サービス アカウントを作成するのドキュメントをご覧ください。

  4. 前の手順で作成したテスト インスタンスに 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 アラートが起動します。

  5. Google Security Operations にログインし、[アラートと IOC] ページを開きます。

  6. [Test SCC Alert: IAM Anomalous Grant given to test account] というタイトルの Google Security Operations のアラートが表示されます。

  7. Google Cloud コンソールを開き、次の操作を行います。

    • IAM と管理コンソールから scc-test テスト アカウントのアクセス権を削除します。
    • サービス アカウント ポータルを使用してサービス アカウントを削除します。
    • 作成した VM インスタンスを削除します。

CDIR SCC マルウェア テストルールをトリガーする

Google Security Operations でこのアラートをトリガーするデータを送信するには、次の手順を行います。

  1. Google Cloud コンソールで、curl コマンドがインストールされている VM インスタンスに SSH を使用して接続します。

  2. 次のコマンドを実行します。

      curl etd-malware-trigger.goog

    このコマンドを実行すると、Malware: Bad Domain Security Command Center のアラートがトリガーされます。

  3. Google Security Operations にログインし、[アラートと IOC] ページを開きます。

  4. [Test SCC Alert: Malware Bad Domain] というタイトルの Google Security Operations アラートが表示されていることを確認します。

CDIR SCC 防御回避テストルールをトリガーする

Google Security Operations でこのアラートをトリガーするデータを送信するには、次の手順を行います。

  1. 組織レベルでアクセスできるアカウントを使用して Google Cloud コンソールにサインインし、VPC Service Control 境界を変更します。

  2. Google Cloud コンソールで、[VPC Service Controls] ページに移動します。

    [VPC Service Controls] に移動

  3. [+新しい境界] をクリックして、[詳細] ページで次のフィールドを構成します。

    • 境界のタイトル: scc_test_perimeter.
    • [境界タイプ] を [標準の境界（デフォルト）] に設定します。
    • [構成タイプ] を [適用] にします。

  4. 左側のナビゲーションで、[3 制限付きサービス] を選択します。

  5. [制限するサービスの指定] ダイアログで [Google Compute Engine API] を選択し、[Google Compute Engine API を追加] をクリックします。

  6. 左側のナビゲーションで、[境界を作成] をクリックします。

  7. 境界を変更するには、[VPC サービス境界] ページに移動します。このページへのアクセス方法について詳しくは、サービス境界の一覧と説明をご覧ください。

  8. [scc_test_perimeter]、[境界を編集] の順に選択します。

  9. [制限付きサービス] で [削除] アイコンをクリックして、Google Compute Engine API サービスを削除します。これにより、SCC の Defense Evasion: Modify VPC Service Control Perimeter のアラートがトリガーされます。

  10. Google Security Operations にログインし、[アラートと IOC] ページを開きます。

  11. [Test SCC Alert: Modify VPC Service Control Test Alert] というタイトルの Google Security Operations アラートが表示されていることを確認します。

CDIR SCC 引き出しテストルールをトリガーする

Google Security Operations でこのアラートをトリガーするデータを送信するには、次の手順を行います。

  1. Google Cloud コンソールで Google Cloud プロジェクトに移動し、BigQuery を開きます。

    BigQuery に移動

  2. 次のデータを含む CSV ファイルを作成し、ホーム ディレクトリに保存します。

    column1, column2, column3
data1, data2, data3
data4, data5, data6
data7, data8, data9

  3. 左側のナビゲーションで、[データセットを作成] を選択します。

  4. 次の構成を設定してから、[データセットを作成] をクリックします。

    • [データセット ID] を scc_test_dataset に設定します。
    • [ロケーション タイプ] を [マルチリージョン] に設定します。
    • テーブルの有効期限を有効にする: このオプションは選択しないでください。

    新しいデータセット パラメータ

    データセットの作成方法について詳しくは、BigQuery ドキュメントのデータセットの作成をご覧ください。

  5. 左側のナビゲーションで、scc_test_dataset の右側にある アイコンをクリックし、[テーブルを作成] を選択します。

  6. テーブルを作成し、次の構成を設定します。

    • テーブルの作成元: [アップロード] に設定します。
    • ファイルを選択: ホーム ディレクトリを参照し、前に作成した CSV ファイルを選択します。
    • ファイル形式: CSV に設定します。
    • データセット: css_test_dataset に設定します。
    • テーブルタイプ: [ネイティブ テーブル] に設定します。

  7. 他のすべてのフィールドのデフォルト構成を受け入れ、[Create Table] をクリックします。

    テーブル パラメータ

    テーブルの作成方法について詳しくは、BigQuery ドキュメントのテーブルの作成と使用をご覧ください。

  8. リソースリストで css_test_dataset テーブルを選択し、[クエリ] をクリックして [新しいタブ] を選択します。

    新規クエリを作成する

  9. 次のクエリを実行します。

    SELECT * FROM TABLE_NAME LIMIT 1000`

    TABLE_NAME は、完全修飾のテーブル名に置き換えます。

  10. クエリが実行されたら、[Save Results] をクリックしてから、[CSV in Google Drive] を選択します。これにより、Exfiltration: BigQuery Exfiltration to Google Drive の Security Command Center アラートがトリガーされます。Security Command Center の検出結果が Google Security Operations に送信され、Google Security Operations のアラートがトリガーされるはずです。

    クエリ結果を保存する

  11. Google Security Operations にログインし、[アラートと IOC] ページを開きます。

  12. [Test SCC Alert: BigQuery Exfiltration to Google Drive] というタイトルの Google Security Operations アラートが表示されていることを確認します。

ステップ 6. テストルールを無効にする

終了したら、GCP Managed Detection Testing ルールを無効にします。

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. GCP Managed Detection Testing ルールのステータスとアラートをどちらも無効にします。

クラウドの脅威のカテゴリの AWS データ取り込みを検証する

AWS Managed Detection Testing テストルールを使用して、AWS データが Google Security Operations に取り込まれていることを確認できます。これらのテストルールは、AWS データが取り込まれており、想定どおりの形式であることを確認するのに役立ちます。AWS データの取り込みを設定したら、テストルールをトリガーするアクションを AWS で実行します。

  • Detection Engine でこれらのルールを有効にするユーザーには、curatedRuleSetDeployments.batchUpdate IAM 権限が必要です。
  • AWS データを送信する手順を実行するユーザーには、選択したアカウントの EC2 インスタンスのタグを編集するための AWS IAM 権限が必要です。EC2 インスタンスのタグ付けの詳細については、AWS ドキュメントの Amazon EC2 リソースにタグ付けするをご覧ください。

AWS Managed Detection Testing のテストルールを有効にする

  1. Google Security Operations で、[検出] > [ルールと検出] をクリックして、[キュレーションされた検出機能] ページを開きます。
  2. [Managed Detection Testing] > [AWS Managed Detection Testing] を選択します。
  3. Broad ルールと Precise ルールでステータスとアラートの両方を有効にしました。

AWS のタグ アクションによってテストルールがトリガーされることを確認する

次の手順を実行して、AWS のタグ アクションがルールセットをトリガーすることを確認します。

ステップ 1. AWS でログイベントを生成します。

  1. AWS 環境内のアカウントを選択します。
  2. EC2 ダッシュボードに移動し、アカウント内のインスタンスを選択します。
  3. EC2 インスタンス内で、[Actions] をクリックしてから、[Instance Settings] をクリックし、[Manage Tags] セクションで次の操作を行います。
    1. [新しいタグを追加する] をクリックします。
    2. 次の情報を入力します。
    3. キー: GCTI_ALERT_VALIDATION_TEST_KEY
    4. 値: works
    5. [保存] をクリックします。

詳細については、EC2 インスタンス タグを追加または削除するをご覧ください。

ステップ 2. テストアラートがトリガーされたことを確認する

前の手順でタスクを実行した後、AWS CloudTrail Test Rule のルールがトリガーされたことを確認します。これは、CloudTrail ログが想定どおりに記録され、Google Security Operations に送信されたことを示します。次の手順を行なってアラートを確認します。

  1. Google Security Operations で、[検出] > [ルールと検出] をクリックして、[キュレーションされた検出機能] ページを開きます。
  2. [ダッシュボード] をクリックします。
  3. 検出のリストで、tst_AWS_Cloud_Trail_Tag のルールがトリガーされたことを確認します。

AWS GuardDuty のサンプル検出結果がテストルールをトリガーすることを確認する

GuardDuty のアラートが環境で意図したとおりに機能するように、GuardDuty のサンプル検出結果を Google Security Operations に送信できます。

ステップ 1. GuardDuty のサンプル検出結果データを生成します。

  1. AWS コンソールのホームに移動します。
  2. [セキュリティ、ID、コンプライアンス] で [GuardDuty] を開きます。
  3. GuardDuty の [設定] に移動します。
  4. [サンプル検出結果を生成する] をクリックします。

サンプル GuardDuty の検出結果を生成する方法については、GuardDuty でのサンプル検出結果の生成をご覧ください。

ステップ 2. テストアラートがトリガーされたことを確認します。

  1. Google Security Operations で、[検出] > [ルールと検出] をクリックして、[キュレーションされた検出機能] ページを開きます。
  2. [ダッシュボード] をクリックします。
  3. 検出リストで、AWS CloudTrail Test Rule がトリガーされたことを確認します。

AWS Managed Detection Testing のルールセットを無効にする

  1. Google Security Operations で、[検出] > [ルールと検出] をクリックして、[キュレーションされた検出機能] ページを開きます。
  2. [Managed Detection Testing] のルール> [AWs Managed Detection Testing] のルールを選択します。
  3. Broad ルールと Precise ルールのステータスとアラートをどちらも無効にします。

Linux 脅威のカテゴリのデータ取り込みを検証する

Linux Managed Detection Testing ルールは、Google Security Operations のキュレーションされた検出に対して、Linux システムのロギングが正しく機能していることを確認します。このテストでは、Linux 環境で Bash プロンプトを使用してさまざまなコマンドを実行します。このテストは、Linux Bash プロンプトにアクセスできるユーザーが実行できます。

ステップ 1. テストルールを有効にする

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. [ルールと検出] > [ルールセット] をクリックします。
  4. [Managed Detection Testing] セクションを開きます。ページをスクロールしなければならない場合があります。
  5. リスト内の [Linux Managed Detection Testing] をクリックして、詳細ページを開きます。
  6. Linux Managed Detection Testing ルールのステータスとアラートをどちらも有効にします。

ステップ 2. Linux デバイスからテストデータを送信する

Linux Managed Detection Testing テストルールをトリガーするには、次の手順を行います。

  1. データを Google Security Operations に送信する Linux デバイスにアクセスします。
  2. 任意のユーザーとして新しい Linux Bash プロンプト コマンドライン インターフェースを開きます。

  3. 次のコマンドを入力して Enter キーを押します。

    /bin/echo hello_chronicle_world!

Linux シェルの組み込みの echo コマンドではなく、echo バイナリを使用する必要があります。

  1. 次のコマンドを入力して Enter キーを押します。

    sudo useradd test_chronicle_account

  2. 前の手順で作成したテスト アカウントを削除します。次のコマンドを実行します。

    sudo userdel test_chronicle_account

  3. 次のコマンドを入力して Enter キーを押します。

    su

  4. パスワードの入力を求められたら、ランダムな文字列を入力します。su: Authentication failure メッセージが表示されます。

  5. Bash ウィンドウを閉じます。

ステップ 3. Google Security Operations でアラートがトリガーされたことを検証する

コマンドによって、Google Security Operations で *tst_linux_echo、tst_linux_echo、tst_linux_echo の各ルールがトリガーされたことを確認します。これは、Linux ログが想定どおりに書き込まれて送信されることを示します。Google Security Operations でアラートを確認するには、次の手順を行います。

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. [ダッシュボード] をクリックします。

  4. 検出リストで、tst_linux_echo、tst_linux_failed_su_login、tst_linux_test_account_creation の各ルールがトリガーされたことを確認します。

手順 4. テストルールを無効にする

終了したら、Linux Managed Detection Testing ルールを無効にします。

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. Linux Managed Detection Testing ルールのステータスとアラートをどちらも無効にます。

Windows 脅威のカテゴリのデータ取り込みを検証する

Windows Echo のテストルールにより、Microsoft Windows のロギングが Google Security Operations のキュレーションされた検出に対して正しく機能していることを検証します。このテストでは、Microsoft Windows 環境でコマンド プロンプトを使用して、予想される一意の文字列で echo コマンドを実行します。

Windows コマンド プロンプトにアクセスできる任意のユーザーとしてログインした状態でテストを行うことができます。

ステップ 1. テストルールを有効にする

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. [Managed Detection Testing] セクションを開きます。ページをスクロールしなければならない場合があります。
  4. リスト内の [Windows Managed Detection Testing] をクリックして、詳細ページを開きます。
  5. Windows Managed Detection Testing のルールのステータスとアラートをどちらも有効にします。

ステップ 2. Windows デバイスからテストデータを送信する

Windows Echo Test Rule をトリガーするには、次の手順を行います。

  1. Google Security Operations に送信するデータを生成するデバイスにアクセスします。
  2. 任意のユーザーとして新しい Microsoft Windows Command Prompt ウィンドウを開きます。

  3. 大文字と小文字を区別しない次のコマンドを入力して、Enter キーを押します。

    cmd.exe /c "echo hello_chronicle_world!"

  4. Command Prompt ウィンドウを閉じます。

ステップ 3. アラートがトリガーされたことを検証する

コマンドによって Google Security Operations で tst_Windows_Echo ルールがトリガーされたことを確認します。これは、Microsoft Windows のロギングが想定どおりにデータを送信していることを示しています。Google Security Operations でアラートを確認するには、次の手順を行います。

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. [ダッシュボード] をクリックします。

  4. 検出リストで tst_Windows_Echo ルールがトリガーされたことを確認します。

手順 4. テストルールを無効にする

終了したら、Windows Managed Detection Testing ルールを無効にします。

  1. Google Security Operations にログインします。
  2. [キュレーションされた検出機能] ページを開きます。
  3. Windows Managed Detection Testing ルールのステータスとアラートをどちらも無効にします。