目次

変更監視ルールについて

変更監視 ルール言語は、 Workload Securityが監視する必要がある、システムコンポーネントおよび関連する属性を記述する宣言的XMLベースの言語です。この言語を使用して、システム内に多数存在するコンポーネントの中から監視の対象外とするものを指定することもできます。

ファイルまたはWindowsレジストリへの不正な変更のみを監視する場合は、カスタムテンプレートを作成する代わりにファイルおよびレジストリルールテンプレートを使用できます。これらのテンプレート使用の詳細については、「変更監視ルールの作成」を参照してください。

新しいカスタム変更監視ルールを作成するには、「変更監視ルールの作成」 (テンプレートの種類として [カスタム (XML)] を選択) の手順を開始してから、以下のセクションで説明されているように、変更監視ルール言語に従ってカスタムルールを作成します。

エンティティセット

変更監視ルールに含まれるシステムコンポーネントは、エンティティと呼ばれます。コンポーネントの各タイプは、エンティティのクラスです。たとえば、ファイル、レジストリキー、およびプロセスは、それぞれエンティティのクラスです。変更監視ルールの言語には、エンティティのクラスごとにエンティティのセット (エンティティセット) を記述するためのタグが用意されています。次の エンティティセット タイプをルールで使用できます。

  • DirectorySet: ディレクトリの整合性を検索するルール
  • FileSet: ファイルの整合性を検索するルール
  • GroupSet: ルールはグループの整合性を検索します
  • InstalledSoftwareSet: インストール済みソフトウェアの整合性を検索するルール
  • PortSet: リスニングポートの整合性を検索するルール
  • ProcessSet: プロセスの整合性を検索するルール
  • RegistryKeySet: ルールはレジストリキーを検索します
  • RegistryValueSet: ルールはレジストリ値を検索します
  • ServiceSet: サービスの整合性を検索するルール
  • UserSet: ルールはユーザの整合性を検索します
  • WQLSet: Windows Management Instrumentation WQLクエリステートメントの結果の整合性を監視するルール

1つの変更監視ルールに複数のエンティティセットを含めることができます。たとえば、複数のファイルとレジストリエントリを監視するルール1つで、アプリケーションを保護できます。

階層とワイルドカード

FileSetやRegistryKeySetなどの階層型のデータの種類を表すエンティティセットでは、セクションベースのパターン照合がサポートされます。

  • / (スラッシュ) : は階層のレベルに適用されるパターンのセクションを区切ります。
  • ** (2つの星) : 0個以上のセクションに一致する場合

次のワイルドカードがサポートされます。

  • ? (疑問符) : 1文字に一致します
  • * (1つの星) : ゼロ個以上の文字に一致する場合

エスケープ文字もサポートされています。

  • \ (バックスラッシュ) : が次の文字をエスケープします。

パターンは、「 / 」文字を使用してセクションに分割され、パターンの各セクションは、一致している限り、連続する階層レベルに適用されます。たとえば、パターン /a?c/123/*.java がパス /abc/123/test.javaに適用されている場合は、次のようになります。

  • a?c」は「abc」に一致します。
  • 123」は「123」に一致します。
  • *.java」は「test.java」に一致します。

パターンがパス /abc/123456/test.javaに適用されると、次のようになります。

  • a?c」は「abc」に一致します。
  • 123」は「123456」と一致しないため、一致は実行されません

**」表記パターンは0個以上のセクションに一致するため、 /abc/**/*.java は「abc/123/test.java」と「abc/123456/test.java」の両方に一致します。 「abc/test.java」および「abc/123/456/test.java」にも一致します。

構文とコンセプト

変更監視ルールの例では、 FileSet エンティティセットを使用します。トピックとコンポーネントは、すべてのエンティティセットに共通です。

変更監視の最小ルールは次のようになります。

<FileSet base="C:\Program Files\MySQL">
</FileSet>

base 属性は、ファイルセットのベースディレクトリを指定します。ルールに関するその他の情報はすべて、このディレクトリに関連しています。ルールにこれ以上追加しない場合、 base の下にあるすべてのファイル (サブディレクトリを含む) の変更が監視されます。

* 」および「 ? 」のワイルドカードは、「ベース」属性文字列で使用できますが、ベースの最後のパスコンポーネントでのみ使用できます。したがって、次の条件が有効です。

base="C:\program files\CompanyName * Web Server"

ただし、次は無効です。

base="C:\* files\Microsoft Office"

エンティティセット内では、 include タグと exclude タグを使用してパターンマッチングを制御できます。これらのタグには、照合するパターンを指定する key 属性があります。キーのソースはエンティティセットによって異なります。たとえば、ファイルとディレクトリの場合はパスであり、ポートの場合は一意のプロトコル/IP/ポート番号のタプルです。

包含ルールまたは除外ルールに指定されたパスが構文的に無効な場合、エージェントは変更監視ルールのコンパイルの問題エージェントイベントを生成し、パラメータとしてルールIDとパス (展開後の) を指定します。ファイル名に2つのボリューム識別子を含めることはできないため、無効なパスの例は C:\test1\D:\test2 です。

includeタグ

include タグは基本的に許可リストです。これを使用すると、それに一致するエンティティ (またはその他のインクルードタグ) のみが含まれます。 include タグを追加することで、次のルールは C:\Program Files\MySQL フォルダおよびサブフォルダ内の \*.exe という名前のファイルに対する変更のみを監視します。

<FileSet base="C:\Program Files\MySQL">
<include key="**/*.exe"/>
</FileSet>

インクルードは組み合わせることができます。次のルールは、 C:\Program Files\MySQL フォルダおよびサブフォルダ内の \*.exe および \*.dll という名前のファイルに対する変更を監視します。

<FileSet base="C:\Program Files\MySQL">
<include key="**/*.exe"/>
<include key="**/*.dll"/>
</FileSet>

複数の条件を1つのインクルードブロックに結合することもできます。この場合、特定のエンティティを含めるには、すべての条件がtrueである必要があります。次の include タグでは、エンティティが .exe で終わり、 .exe で始まるエンティティを sample 必要があります。この要件はより簡潔に表現できますが、キーパターンがエンティティの他の機能と組み合わされるにつれて、この要件の有用性がより明確になります。

<include>
<key pattern="**/*.exe"/>
<key pattern="**/sample*"/>
</include>

次の構文は、同じ条件を他の方法で記述したものです。

<include key="**/*.exe">
<key pattern="**/sample*"/>
</include>

excludeタグ

exclude タグはブロックリストとして機能し、通常であれば返されるファイルをセットから削除します。次の (ありそうにない) 例では、一時ファイル以外のすべてが監視下に置かれます。

<FileSet base="C:\Program Files\MySQL">
<include key="**"/>
<exclude key="**/*.tmp"/>
</FileSet>

次のルールは、EXEおよびDLLのセットから MySQLInstanceConfig.exe を除外します。

<FileSet base="C:\Program Files\MySQL">
<include key="**/*.exe"/>
<include key="**/*.dll" />
<exclude key="**/MySQLInstanceConfig.exe"/>
</FileSet>

include タグと同様に、複数の条件を要求するように exclude タグを記述することができます。次の例は、複数条件の exclude タグを示しています。

<exclude>
<key pattern="**/MySQLInstanceConfig*" />
<key pattern="**/*.exe" />
</exclude>

大文字/小文字の区別

包含タグまたは除外タグのパターン一致で大文字と小文字を区別するかどうかは、 casesensitive 属性で制御できます。この属性には、次の3つの値を指定できます。

  • true
  • false
  • platform

この属性の初期設定値は platformです。これは、パターンの大文字と小文字の区別が、パターンが実行されているプラットフォームと一致することを意味します。次の例では、Windowsシステムでは Sample.txtsample.txt の両方が返されますが、Unixシステムでは Sample.txt のみが返されます。

<FileSet base="C:\Program Files\MySQL">
<include key="**/*Sample*"/>
</FileSet>

この例では、WindowsおよびUNIXでは Sample.txt のみが返されます。

<FileSet base="C:\Program Files\MySQL">
<include key="**/*Sample*" casesensitive="true"/>
</FileSet>

true の大文字と小文字を区別する設定は、ほとんどのオブジェクト名で大文字と小文字が区別されないWindowsなどのプラットフォームでは使用が制限されます。

エンティティ機能

一部のエンティティタイプでは、キー以外の特性に基づくエンティティの包含と除外もサポートされています。一連の特性は、エンティティの種類によって異なります。次の例には、すべての実行可能ファイルが含まれています。ファイル拡張子を使用した前の例のように、ファイル拡張子には依存しませんが、代わりにファイルの最初の数百バイトをチェックして、指定されたOSで実行可能かどうかを判断します。

<FileSet base="C:\Program Files\MySQL">
<include key="**" executable="true"/>
</FileSet>

対象物属性は、 include タグまたは exclude タグで指定する必要があります。複数条件の包含または除外の一部としてこれらを使用するには、それらを囲む include または exclude タグの属性として指定する必要があります。次の例では、名前に文字列 "MySQL" を含み、かつ実行可能であるすべてのファイルが含まれます。

<include executable="true">
<key pattern="**/*MySQL*"/>
</include>

上記の例は、次のようにもっと簡潔に記述することができます。

<include key="**/*MySQL*" executable="true"/>

機能属性によっては、単にエンティティのいずれかの属性の値を照合するだけのものもあります。このような場合、「*」および「?」を使用したワイルドカード照合がサポートされることがあります。この方法でinclude/excludeルールに使用できる属性について、およびワイルドカード照合と単純な文字列照合のどちらがそれらの属性でサポートされるかについては、各エンティティセットのヘルプ画面を参照してください。

ワイルドカード一致がサポートされている場合、一致は属性の文字列値に対して行われ、正規化は行われないことに注意してください。 「**」などのエンティティキーの一致に使用できる構文や、階層コンポーネントを分離するための「/」の使用は適用されません。 Windowsでパス名を照合するには、テスト対象の属性の値に「\」を使用する必要があります。UNIXシステムではパス値に「/」を使用するため、Unixパスとの照合には「/」を使用する必要があります。 。

次に、 state 属性を使用した機能一致の例を示します。

<ServiceSet>
<include state="running"/>
</ServiceSet>

state照合ではワイルドカードはサポートされません。

次の例は、バイナリのパスが "\notepad.exe" で終わるすべてのプロセスに一致します。

<ProcessSet>
<include path="*\notepad.exe"/>
</ProcessSet>

次の例は、コマンドラインが "/sbin/"で始まるすべてのプロセスに一致します。

<ProcessSet>
<include commandLine="/sbin/*"/>
</ProcessSet>

ワイルドカードを使用する場合は注意してください。 「**」などのワイルドカード表現は、 baseの下のすべてのサブディレクトリ内のすべてのファイルを検索します。このような式のベースラインを作成するには、多くの時間とリソースが必要です。

ANDおよびOR演算子

複数条件の包含と除外、および複数の包含と除外を使用して、論理 ANDOR を表すことができます。

複数の条件の包含または除外を使用して ANDを表現する方法はいくつかあります。最も簡単な方法は、1つの囲みタグ内に複数の条件を含めることです。次の例は、単純な複数条件 AND-ing を示しています。

<include>
<key pattern="**/*MySQL\*" />
<key pattern="**/*.exe"/>
</include>

また、includeタグの属性として表される条件は、複数条件の要件の一部として囲まれた条件とともにグループ化されます。次の例は、以前の複数条件インクルードが書き換えられたことを示しています。

<include key="**/*.exe">
<key pattern="**/*MySQL*" />
</include>

最後に、複数の条件が包含または除外の属性として表されている場合、それらは ANDとして扱われます。

<include executable="true" key="**/*MySQL*" />

OR は、複数の包含タグまたは除外タグを含めることで簡単に表されます。次のコードでは、拡張子が .exe または .dllの場合、ファイルがインクルードされます。

<include key="**/*.dll" />
<include key="**/*.exe" />

評価の順序

ルールでの出現順序に関係なく、すべてのインクルードが最初に処理されます。オブジェクト名が少なくとも1つの include タグと一致する場合、そのオブジェクトは exclude タグに対してテストされます。少なくとも1つの exclude タグと一致する場合、監視対象オブジェクトのセットから削除されます。

エンティティ属性

特定のエンティティには、監視可能な一連の属性があります。エンティティセットに属性が指定されていない場合 (たとえば、attributesラッパータグが存在しない場合)、そのエンティティの属性のSTANDARDセットが想定されます。個々のエンティティセット については、「短縮形の属性」を参照してください。

特定のエンティティセットについて、変更監視の対象となるのはエンティティの特定の属性のみです。たとえば、ログファイルの内容に対する変更は、ほとんどの場合予期され、許可されます。ただし、権限または所有権の変更はレポートする必要があります。

エンティティセットの attributes タグを使用すると、これを表現できます。 attributes タグには、対象の属性を列挙する一連のタグが含まれます。許可される attributes タグのセットは、タグが提供されるエンティティセットによって異なります。

attributes タグが存在してもエントリが含まれていない場合は、ルールで定義されたエンティティの存在のみが監視されます。

次の例では、 C:\Program Files\MySQL 内の名前に SQL が含まれる実行可能ファイルの last modified permissionsおよび owner 属性の変更を監視します。

<FileSet base="C:\Program Files\MySQL" >
<include key="**/*SQL*" executable="true"/>
<attributes>
<lastModified/>
<permissions/>
<owner/>
</attributes>
</FileSet>

次の例では、 C:\Program Files\MySQL内のログファイルの permissions および owner 属性を監視します。

<FileSet base="C:\Program Files\MySQL" >
<attributes>
<permissions/>
<owner/>
</attributes>   
<include key="**/*.log" />
</FileSet>

次の例では、属性のSTANDARDセットが監視されます。 短縮形の属性を参照してください。

<FileSet base="C:\Program Files\MySQL" >
<include key="**/*.log" />
</FileSet>

次の例では、監視対象の属性はありません。エンティティの存在のみ変更が追跡されます。

<FileSet base="C:\Program Files\MySQL" >
<attributes/>
<include key="**/*.log" />
</FileSet>

簡略記法属性

短縮形の属性を使用すると、1つの上位レベルの属性を使用して属性のグループを指定できます。通常の属性と同様に、許可される値のセットは、その値が提供されるエンティティセットによって異なります。

簡略記法属性が役に立つのは、属性のセットが自然にグループ化されている場合、属性のセットをすべて列挙することが煩雑な場合、および上位レベルの属性で表された属性のセットが時間とともにまたはシステム構成によって変わる可能性がある場合などです。各ケースの例を以下に示します。

属性 説明
STANDARD エンティティセットを監視する属性のセット。これは、エンティティセットの「想定されるすべての属性」とは異なります。たとえば、想定されるすべてのハッシュアルゴリズムが含まれることはなく、必要とみなされる属性だけが含まれます。各エンティティセットの「STANDARD」属性のリストについては、個々のエンティティセットのセクションを参照してください。
CONTENTS ファイルの内容のハッシュまたはハッシュのセットを表す簡略記法属性です。SHA-1に初期設定されています。

onChange属性

変更をリアルタイムで監視するようにEntitySetを設定できます。 EntitySetの onChange 属性が true (初期設定値) に設定されている場合、EntitySetから返されるエンティティの変更がリアルタイムで監視されます。変更が検出されると、エンティティは即座にベースラインと比較されて変動が確認されます。 EntitySetの onChange 属性が falseに設定されている場合は、ベースラインが作成されたとき、またはスケジュールされたタスクによってトリガされたとき、またはWorkload Securityによってオンデマンドでトリガされたときにのみ実行されます。

次の例では、MySQLバイナリをリアルタイムで監視します。

<FileSet base="C:\Program Files\MySQL" onChange="true">
<include key="**/*.exe"/>
<include key="**/*.dll" />
</FileSet>

環境変数

環境変数は、エンティティセットで使用される基本値に含めることができます。これらは "${}"で囲まれます。変数名自体の先頭に env.が付きます。

次の例では、FileSetのベースディレクトリを PROGRAMFILES 環境変数に格納されているパスに設定します。

<FileSet base="${env.PROGRAMFILES}"/>

参照される環境変数の値は、エージェント読み取られ、保存されます。環境変数の値が変更されると、変更内容を登録するためにAgentが再起動されます。

参照先の環境変数が見つからない場合、それを参照するエンティティセットは検索も監視もされませんが、残りの設定が使用されます。変数が存在しないことを示すアラートがトリガーされます。エージェントが、エージェントイベントを使用して無効な環境変数をレポートし変更監視。変更監視ルールのIDと環境変数名がパラメータとしてイベントに指定されます。

変更監視で使用される初期設定の環境変数を次に示します。

名前
ALLUSERSPROFILE C:\ProgramData
COMMONPROGRAMFILES C:\Program Files\Common Files
PROGRAMFILES C:\Program Files
SYSTEMDRIVE C:
SYSTEMROOT C:\Windows
WINDIR C:\Windows

環境変数のオーバーライド

Windowsオペレーティングシステムで標準以外の場所が使用されている場合は、環境変数をオーバーライドします。たとえば、Windowsのhostsファイルに対する変更を監視する Microsoft Windows - 'Hosts' file modified 変更監視ルールは、 C:\WINDOWS\system32\drivers\etc ディレクトリでそのファイルを検索します。ただし、すべてのWindowsインストールで C:\WINDOWS\ ディレクトリが使用されるわけではないため、変更監視ルールでは環境変数 WINDIR を使用し、ディレクトリを %WINDIR%\system32\drivers\etcとして表します。

  1. コンピュータまたはポリシーエディタ を開き、環境変数をオーバーライドします。
  2. [設定]→[詳細] をクリックします。
  3. 環境変数 オーバーライド セクションで、 環境変数 をクリックして、 環境変数 オーバーライド ページをオーバーライドするように表示します。
  4. メニューバーの [ New ] をクリックし、新しい名前と値のペア (WINDIR と D:\Windows など) を入力して、[ OK] をクリックします。

レジストリ値

レジストリ値は、エンティティセットで使用される基本値に含めることができます。これらは ${}で囲まれます。レジストリ値自体へのパスの先頭に「 reg. 」が付きます。

次の例では、FileSetのベースディレクトリを HKLM\Software\Trend Micro\Deep Security Agent\InstallationFolder レジストリ値に格納されているパスに設定します。

<FileSet base="${reg.HKLM\Software\Trend Micro\Deep Security Agent\InstallationFolder}"/>

参照されているレジストリ値の値は、新しいルールまたは変更されたルールをエージェントが受信したときに読み取られます。また、エージェントは起動時にすべてのルールを確認し、参照されているレジストリ値が変更された場合は、影響を受けるルールのベースラインを再構築します。

参照されているレジストリ値が見つからない場合、その値を参照しているEntitySetは検索も監視もされませんが、残りの設定が使用されます。変数が存在しないことを通知するアラートが生成されます。エージェントは、エージェントイベント8012を使用して、無効な環境変数の展開を報告します。変更監視ルールのIDとレジストリ値のパスは、イベントのパラメータとして指定されます。

ワイルドカードは、ベース名の最後の階層コンポーネントでのみ使用できます。たとえば、「base="HKLM\Software\ATI*」は有効で、 HKLM\Software\ATIHKLM\Software\ATI Technologiesの両方を検索します。ただし、 base="HKLM\*\Software\ATI* は無効です。

ドットドットの使用

親ディレクトリを参照するための .. 規則は、現在のすべてのバージョンのAgentでサポートされています。エージェントは、 .. 参照を解決し、Windowsのショートネームをロングネームに変換することにより、FileSetおよびDirectorySet要素のベースディレクトリ名の正規化を試みます。たとえば、一部の新しいバージョンのWindowsでは、次のファイルセットのベースディレクトリが C:\Usersになります。以前のバージョンのWindowsでは、 C:\Documents and Settingsでした。

<FileSet base="${env.USERPROFILE}\..">
<include key="*/Start Menu/Programs/Startup/*"/>
</FileSet>

ベストプラクティス

重要なオブジェクトと属性のみを含めるようにルールを作成する必要があります。これにより、オブジェクトの他の属性が変更されてもイベントがレポートされなくなります。たとえば、変更監視ポリシーによって、 /bin内のファイルの権限と所有権が制限される場合があります。変更監視ルールでは、所有者、グループ、および権限を監視しますが、 lastModifiedhash の値などの他の属性は監視しないようにします。

変更監視ルールを使用して不正プログラムや不審なアクティビティの検出、サービスの監視、NTFSデータストリームの使用の監視、および /tmp${env.windir}\tempなどの通常とは異なる場所にある実行可能ファイルの監視を行う場合は、

ルールに含めるオブジェクトは、できるだけ具体的に指定してください。含めるオブジェクトが少ないほど、ベースラインの作成にかかる時間が短くなり、変更の検索にかかる時間が短くなります。変更が予想されるオブジェクトを除外し、必要な属性のみを監視します。

ルールを作成するときは、次のことを行わないでください。

  • / C:\HKLM\Softwareなど、階層の最上位から **/... を使用する。
  • どうしても必要な場合を除き、複数のコンテンツハッシュタイプを使用します。
  • HKEY_CURRENT_USER ${env.USERPROFILE}${env.HOME}などのユーザ固有の場所の参照。

エージェントは指定されたパターンに一致するために多くの項目を検索するため、変更監視ルールでこれらのステートメントを使用すると、パフォーマンスの問題が発生する可能性があります。