Security Center の Malicious Behavior Defense 機能は、ホスト上で疑わしいシステム動作を検出してブロックすることで保護します。既知の安全な操作を検出対象から除外するためのカスタム許可リストルールを作成することで、セキュリティ可視性を維持しつつ誤検知アラートを削減できます。本トピックでは、セキュリティアラートの分析方法と、特定の環境に適した効果的な許可リストルールの構成方法について説明します。
許可リストルールを使用する理由
許可リストルールには、検出カテゴリ全体を無効化するよりもいくつかの利点があります。
-
きめ細かい制御：アラート機能から除外する動作を微調整するためのカスタムフィルターを作成できます。
-
可視性の維持：許可リストに登録された動作も引き続きモニタリングされます。バックグラウンドで検出は実行されますが、アラートは抑制されます。これにより監査証跡が保持され、後でルールを再評価できます。
-
ビジネス継続性：正当な操作（O&M スクリプト、サービス間通信、開発ツールなど）がワークフローを妨げる誤ったアラームをトリガーすることを防止します。
許可リストルールを使用するタイミング：
-
Security Center が信頼できる内部ツールまたはスクリプトを悪意のあるものとしてフラグ付けしている場合
-
正当なサービス間ネットワーク接続が繰り返しアラートをトリガーしている場合
-
開発またはテスト活動（デバッグツール、テストフレームワークなど）がノイズを生成している場合
-
メンテナンスウィンドウ中に一時的な除外が必要な場合
許可リストルールを使用しないタイミング：
-
検出された動作が実際に不審であり、信頼できるソースからのものである場合（代わりにセキュリティ態勢の改善を検討してください）
-
検出タイプを完全に無効化したい場合（代わりに機能設定を使用してください。ただし、可視性が失われることに注意してください）
仕組み
許可リストルール機能は、Security Center の検出エンジンの上位にユーザー定義ポリシーレイヤーを提供します。以下が評価ワークフローです。
-
動作モニタリング：Security Center エージェントは、システムアクティビティ（プロセス作成、ネットワーク接続、ファイル操作、レジストリ変更）を継続的にモニタリングします。
-
ルールマッチング（評価順序）：
-
判断と実行：
-
動作が許可リストルールに一致する場合：操作は許可され、アラートは生成されません。バックグラウンドでの検出は引き続き実行され（監査証跡が保持されます）。
-
許可リストに一致せず、検出ルールに一致する場合：アラートが生成され、動作はブロックされます（保護モード設定に基づき、「モニターのみ」または「ブロック」）。
-
-
継続的最適化：新しいアラートに基づいてルールを洗練させ、時間の経過とともに検出精度を向上させます。
複数の許可リストルールが同じ動作に一致する場合、Security Center は一致するすべてのルールを適用します（最初に一致したルールのみではありません）。つまり、重複するルールは競合せず、各ルールが指定された条件に対して独立してアラートを抑制します。
アラートステータスフロー：
-
動作検出：Security Center エージェントがシステム動作（プロセス実行、ネットワーク接続など）を検出します。
-
許可リストルールの確認：エージェントは、その動作がユーザー定義の許可リストルールに一致するかどうかを確認します。
-
判断：
-
一致が見つかった場合：アラートは抑制されます（アラートは生成されません）。動作は許可され、コンプライアンスのために監査証跡が保持されます。
-
一致しない場合：その動作は組み込みの検出ルールに対してチェックされます。悪意のあるパターンに一致する場合、ステータス「アクティブ」のアラートが生成され、保護モード設定に基づいて動作がブロックまたはモニタリングされます。
-
前提条件
以下の要件を満たしていることを確認してください。
-
エディション要件：
-
サブスクリプション（推奨）：Security Center のAdvanced Edition、Enterprise Edition、またはUltimate Editionを購入済みである必要があります。購入後、サーバー保護エディションが購入したエディションレベルに設定されていることを確認してください。
説明サーバー保護エディションが購入したエディションよりも低いレベルに設定されている場合、Malicious Behavior Defense 機能は利用できません。システム設定 > 機能設定 に移動して、保護エディションが購入したエディションと一致していることを確認してください。
-
従量課金：Vulnerability Fixing、Security Configuration Assessment、またはContainer Intrusion Detection 機能を有効化し、保護レベルをMalicious Behavior Defense以上に設定する必要があります。
-
-
エージェント：Security Center エージェントが対象ホストにインストールされ、正常に実行中である必要があります。
-
アラート：Malicious Behavior Defense コンソールに少なくとも 1 件の誤検知アラートが存在している必要があります（アラート詳細からルールパラメーターを抽出するため）。
操作手順
ステップ 1：アラートを分析してルールタイプを選択する
効果的なルールを作成するには、まず誤検知アラートの詳細を分析します。
-
Security Center コンソールにログインします。[Security Center コンソール]。
-
左側のナビゲーションウィンドウで、 を選択します。コンソールの左上隅で、保護する資産があるリージョンを選択します：Chinese Mainland または Outside Chinese Mainland。
説明Agentic SOC サービスを有効化すると、ナビゲーション パスが次のように変更されます：。
-
セキュリティアラート ページの CWPP タブで、Precise Defense をクリックして、Malicious Behavior Defense 機能によって自動的にブロックされた脅威に関するすべてのアラートを表示します。
-
アラート詳細の主要フィールドに基づいて、最も適切なルールタイプを選択します。
|
推奨ルールタイプ |
主要アラートフィールド |
シナリオ |
|
Process Hash |
悪意のあるファイル MD5 |
MD5 ハッシュで識別される特定のファイルの実行を許可リストに登録します。 |
|
Command Line |
プロセスパス、コマンドライン |
特定のコマンドライン引数で実行される特定のプロセスを許可リストに登録します。 |
|
Process Network |
ネットワーク通信のプロセスパス、IP アドレス、ポート |
特定のプロセスが特定の IP アドレスおよびポートに開始するネットワーク接続を許可リストに登録します。 |
|
File Read and Write |
ファイルパス |
特定のプロセスが特定のファイルまたはディレクトリに対して実行する読み取りまたは書き込み操作を許可リストに登録します。 |
|
Operation on Registry |
レジストリパス、レジストリ値 |
特定のプロセスが特定のレジストリキーに対して実行する操作を許可リストに登録します。このルールタイプは Windows のみに適用されます。 |
|
Dynamic-link Library Loading |
ハイジャックされたプロセスパス、悪意のある so ファイルパス |
特定のプロセスによる特定のダイナミックリンクライブラリ（.so または .dll）のロードを許可リストに登録します。 |
|
File Renaming |
擬似ディレクトリファイル保護 |
特定のプロセスが実行するファイル名変更操作を許可リストに登録します。このルールタイプは Windows のみに適用されます。 |
ステップ 2：ルールを構成する
-
Security Center コンソール > 保護設定 > ホスト保護 > ホスト固有ルール管理 に移動します。ページの左上隅で、資産があるリージョンを選択します：Chinese Mainland または Outside Chinese Mainland。
-
悪意のある行動の防御 タブで、カスタム防衛ルール サブタブをクリックし、ホワイトリストルール作成 をクリックします。
-
ルールの作成 パネルで、以下のように基本設定を完了します。
-
ルール名：アラートに対応する内容に基づいて命名することを推奨します。例：
Process Startup Whitelist。 -
Rule Type：ステップ 1 の分析に基づいて適切なルールタイプを選択します。
-
Action: 許可リストに追加 を選択します。
-
-
選択したルールタイプのパラメーターを構成します。
説明ルール構文の詳細については、「付録：ルール構文」をご参照ください。
Process Hash
パラメーター
説明
Process MD5
アラート詳細の 悪意のあるファイル MD5 フィールドの値を入力します。例：
d2f295a89555579c39a0507e96XXXXXX。Command Line
パラメーター
説明
Process Path
アラート詳細の コマンドを実行するプロセス フィールドのパスを入力します。例：
*/pkill。Command Line
アラート詳細の 実行中のコマンド フィールドから特徴的な文字列を入力します。例：
*AliYunDun*。Process Network
パラメーター
説明
Process Path
アラート詳細の ネットワーク通信のプロセスパス フィールドのパスを入力します。例：
*/powershell.exe。Command Line
アラート詳細の ネットワーク通信のプロセスコマンド フィールドから特徴的な文字列を入力します。例：
*dAByAhADQAKAHsADQAkACXXXXXX*。IP アドレス
アラート詳細の IP アドレス フィールドの値を入力します。例：
45.117.XX.XX。Port
アラート詳細の ポート フィールドの値を入力します。例：
14XX。File Read and Write
パラメーター
説明
Process Path
アラート詳細の コマンドを実行するプロセス フィールドのパスを入力します。例：
*/java。Command Line
アラート詳細の 実行中のコマンド フィールドから特徴的な文字列を入力します。例：
*weaver*。File Path
アラート詳細の 読み取りおよび書き込みの対象ドキュメント フィールドのパスを入力します。例：
*/console_login.jspOperation on Registry
パラメーター
説明
Process Path
アラート詳細の コマンドを実行するプロセス フィールドのパスを入力します。例：
*/iexplore.exe。Command Line
アラート詳細の 実行中のコマンド フィールドから特徴的な文字列を入力します。例：
*iexplore.exe*。Registry Key
アラート詳細の レジストリパス フィールドから特徴的な文字列を入力します。例：
*currentversion*。Registry Value
アラート詳細の レジストリ値 フィールドから特徴的な文字列を入力します。例：
*svch0st.exe*。Dynamic-link Library Loading
パラメーター
説明
Process Path
アラート詳細の ハイジャックされたプロセスパス フィールドのパスを入力します。例：
*/python*。Command Line
アラート詳細の ハイジャックされたプロセスコマンド フィールドから特徴的な文字列を入力します。例：
*python*。File Path
アラート詳細の 悪意のある so ファイルパス フィールドのパスを入力します。例：
/usr/local/lib/kswapd0.so。File Renaming
パラメーター
説明
Process Path
アラート詳細の コマンドを実行するプロセス フィールドのパスを入力します。例：
*/cdgregedit.exe。Command Line
アラート詳細の 実行中のコマンド フィールドから特徴的な文字列を入力します。例：
*CDGRegedit.exe*。File Path
アラート詳細の 読み取りおよび書き込みの対象ドキュメント フィールドのパスを入力します。例：
c:/programdata/hipsdata/private/*。New File Path
アラート詳細の 読み取りおよび書き込みの対象ドキュメント フィールドのパスを入力します。例：
c:/programdata/hipsdata/private/*。 -
Select Asset パネルで、ルールを適用する資産を選択し、Complete をクリックします。
説明新しいカスタムルールはデフォルトで有効になります。ルールを編集して、適用するサーバーを管理できます。
ステップ 3：ルールの検証とトラブルシューティング
-
検証方法：ルールが適用されているホストをモニタリングして、同一の新しいアラートが生成されないことを確認します。
-
トラブルシューティング：ルールが有効にならず、アラートが引き続き生成される場合は、以下の手順でトラブルシューティングを行ってください。
-
資産範囲の確認：ルール一覧で、対象のホストがルールの範囲内にあることを確認します。
-
マッチング条件の検証：新しい
アラートの詳細とルールのパラメーターを慎重に比較します。パスやファイル名を含むすべての文字列が正確に一致していることを確認してください（大文字小文字の区別、スペースなど）。アラート詳細のフィールド値を直接ルール構成にコピーします。 -
テスト用にルールを簡略化：
プロセスパスのみを使用するなど、より広い条件でルールを作成して、その有効性をテストします。広い条件のルールが機能する場合、問題は元のルールの条件の組み合わせまたは特定のフィールド値にある可能性があります。問題を特定するために、条件を徐々に追加していきます。
-
付録：ルール構文
ルールフィールドでは、柔軟な動作マッチングのためにワイルドカードおよび論理演算子がサポートされています。
ワイルドカード
アスタリスク（*）はユニバーサルワイルドカードで、任意の文字シーケンス（ゼロ文字を含む）に一致します。
|
パターン |
一致対象 |
例 |
|
|
"keyword" を含む任意の文字列 |
|
|
|
"keyword" で始まる任意の文字列 |
|
|
|
"keyword" で終わる任意の文字列 |
|
|
|
任意の文字列（ユニバーサルマッチ） |
慎重に使用してください。ルールが過度に広くなる可能性があります |
論理演算子
複数の条件を組み合わせて、正確なマッチングを実現します。必要に応じて括弧を使用して式をグループ化します。
|
演算子 |
記号 |
動作 |
例 |
|
AND |
|
すべての条件が一致する必要がある |
|
|
OR |
|
少なくとも 1 つの条件が一致すればよい |
|
|
NOT |
|
パターンを除外 |
|
重要な構文ルール：
-
&!patternはサポートされています（AND NOT） - 例：*process*&!*debug* -
|!patternはサポートされていません - 代わりに!pattern1&!pattern2を使用してください -
セキュリティを弱める過度に広い除外ルールは避けてください
例：
|
シナリオ |
構文 |
説明 |
|
テストスクリプトを除く Python プロセスを許可 |
|
"python" を含み、"test" または "pytest" を含まない必要がある |
|
/usr/bin または /usr/local/bin からのプロセスを許可 |
|
いずれかのプレフィックスで始まるパスに一致 |
|
特定の構成を持つ Java プロセスを許可 |
|
コマンドラインに "prod" または "production" を含む Java プロセス |
ベストプラクティス：
-
シンプルなパターンから始め、必要に応じて複雑さを追加する
-
本番環境以外でまずルールをテストする
-
ルールロジックを文書化する（説明的なルール名を使用）
-
二重否定（
!(!pattern)）は避けて、明確になるように書き直す
用語集
|
用語 |
定義 |
関連用語 |
|
許可リストルール |
特定の動作をアラート機能から除外するユーザー定義ルール。業界標準用語（非推奨の「ホワイトリスト」に代わるもの）。 |
抑制ルール（AWS GuardDuty、Azure Sentinel）、ミュートルール（GCP Security Command Center） |
|
アラート |
Security Center によって検出された疑わしいまたは悪意のある動作を示すセキュリティ検出結果。 |
Finding（AWS/GCP における検出結果の用語） |
|
誤検知 |
正当な動作が悪意のあるものとして誤って識別され、アラートがトリガーされること。 |
誤警報、良性検出 |
|
Malicious Behavior Defense |
ホストの動作をモニタリングし、リアルタイムで疑わしいアクティビティをブロックする Security Center の機能。 |
脅威検出（業界用語）、動作分析 |
|
ルールマッチング |
キャプチャされた動作を構成済みのルール基準と比較して、許可リストルールが適用されるかどうかを判断するプロセス。ルール評価とは、どの検出ルールが発動するかを決定する内部エンジンロジックを指します。 |
ルール評価（内部エンジンの観点） |