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

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」属性には、FileSetのベースディレクトリを指定します。ルールに関するすべての項目は、このディレクトリを基準とした相対ディレクトリに保存されます。上記のルールを変更しなければ、「base」以下のすべてのもの (サブディレクトリも含む) について変更が監視されます。

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

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

しかしこれはそうではありません：

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

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

includeまたはexcludeルールに記述したパスの構文が無効な場合、Agentによって「変更監視ルールのコンパイルの問題」のイベントが生成され、ルールIDと展開後のパスがイベントのパラメータとして提供されます。C:\test1\D:\test2は無効なパスの例ですが、これは、ファイル名に2つのボリュームIDを含めることができないためです。

includeタグ

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

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

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

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

1つのincludeブロック内に複数の条件を含めることもできます。この場合、あるエンティティが対象となるためにはすべての条件に一致する必要があります。次の「include」タグは、「sample」で始まり「.exe」で終わる名前のエンティティを含めます。この条件はもっと簡潔に記述することもできますが、後述の「機能」のセクションで説明するように、「key」パターンはエンティティの他の機能と組み合わされるため、この構文の方が汎用性があります。

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

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

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

excludeタグ

除外タグはブロックリストとして機能し、それ以外の場合に返されるファイルをセットから削除します。次の例は、実際にはありえませんが、tempファイル以外のすべてのファイルを監視対象にします。

<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>

大文字/小文字の区別

include/excludeタグのパターン照合での大文字/小文字の区別は、「casesensitive」属性で制御できます。この属性は次の3つの値をとります。

true
false
platform

この属性の初期設定は「platform」です。これは、パターンの大文字/小文字の区別を実行中のプラットフォームの大文字/小文字の区別と照合します。次の例の場合、Windowsシステムでは「Sample.txt」と「sample.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のように、ほとんどのオブジェクト名に対して大文字/小文字の区別をしないプラットフォームに限られます。

エンティティ機能

エンティティの種類によっては、「key」以外の機能に基づいてエンティティをファイルセットに含めたり、除外したりすることができます。エンティティの種類によって、機能のセットは異なります。次の例は、すべての実行可能ファイルを含めます。ファイル拡張子を使用した前述の例のようにファイル拡張子には依存せず、ファイルの最初の数百バイトをチェックして、そのOSで実行可能なファイルかどうかを判定します。

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

機能属性は「include」または「exclude」タグに指定する必要があります。複数の条件を指定するinclude/excludeの一部として機能属性を使用するには、include/excludeの囲みタグの属性として指定する必要があります。次の例は、ファイル名に「MySQL」の文字列を含むすべての実行可能ファイルを含めます。

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

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

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

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

ワイルドカード照合がサポートされる場合は、属性の文字列の値についての照合になりますが、正規化は行われないので注意が必要です。「**」や「/」などのエンティティキーの一致で使用可能なコンストラクトは、階層コンポーネントを分離するためには適用されません。Windowsでパス名を一致させるには、「\" since that is the character which appears in the value of the attribute being tested, whereas Unix systems will use "/" in path values so matches against Unix paths need to use "/」を使用する必要があります。

次のルールは、「state」属性を使用した機能照合の例です。

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

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

次の例は、バイナリのパスの末尾が「\notepad.exe」となっているプロセスを照合します。

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

次の例は、コマンドラインが「/sbin/」から始まるプロセスを照合します。

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

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

ANDとOR

複数の条件を指定するinclude/excludeタグと複数のinclude/excludeタグを使用して、論理ANDと論理ORを記述することができます。

複数の条件を指定するincludeまたはexcludeを使用してANDを記述するにはいくつかの方法があります。最も簡単な方法は、複数の条件を1種類の囲みタグで囲む方法です。次の例は、複数の条件を指定する簡単なAND構文です。

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

また、囲みタグの属性に条件を記述すると、その条件は、複数の条件を指定する要件の一部として囲まれた条件でグループ化されます。次の例は、上記の複数の条件を指定する「include」タグをこのように書き直したものです。

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

最後の例は、複数の条件をinclude/excludeタグの属性に記述したものですが、これもANDとして扱われます。

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

ORは、複数のinclude/excludeタグに条件を含めるだけで記述できます。次のコードは、ファイル名に「.exe」または「.dll」を含むファイルを返します。

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

評価の順序

ルール内での出現順序にかかわらず、まず、すべての「include」が処理されます。オブジェクト名がいずれかの「include」タグに合致すると、「exclude」タグと照合チェックされます。オブジェクト名がいずれかの「exclude」タグと合致すると、監視対象オブジェクトのセットから除外されます。

エンティティ属性

各エンティティには、監視対象となる属性のセットがあります。エンティティセットに属性が指定されていない (属性のラッパータグがない) 場合は、そのエンティティのSTANDARDセットの属性が使用されます(各エンティティセットについては、「簡略記法属性」セクションを参照してください)。

ただし、エンティティセットによっては、エンティティの特定の属性のみが変更監視の対象となります。たとえば、ログファイルの内容の変更は、通常、変更されることが前提として許可されています。しかし、アクセス許可や所有権の変更はレポートの対象にする必要があります。

エンティティセットの「attributes」タグには、こうしたことを記述できます。「attributes」タグには、監視対象とする属性を列挙したタグのセットを指定します。許可される「attribute」タグのセットの内容は、指定するエンティティセットによって異なります。

「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属性

変更をリアルタイムで監視するように、エンティティセットを設定できます。エンティティセットのonChange属性をtrue (初期設定値) に設定すると、エンティティセットによって返されるエンティティは、変更がリアルタイムで監視されます。変更が検出されると、すぐにそのエンティティがベースラインと比較されます。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が再起動されます。

参照先の環境変数が見つからない場合、その環境変数を参照しているエンティティセットは検索も監視もされませんが、それ以外の構成は使用されます。変数が存在しないことを示すアラートがトリガされます。Agentイベント「変更監視ルールのコンパイルの問題」を使用して、Agentが不正な環境変数を報告します。変更監視ルールのIDと環境変数名が、イベントのパラメータとして返されます。

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

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

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

Windows OSで非標準的なロケーションを使用するときに環境変数をオーバーライドします。たとえば、Windowsホストファイルの変更を監視する Microsoft Windows - 'ホストのファイル変更変更監視ルールは、そのファイルをC:\WINDOWS\ system32 \ drivers \ etcフォルダ内に検索します。ただし、すべてのWindowsインストールでC:\WINDOWS\ディレクトリが使用されるわけではありません。したがって、変更監視ルールはWINDIR環境変数を使用し、このディレクトリを %WINDIR%\ system32 \ drivers \ etcとして表します。

環境変数は、主に、仮想マシンでAgentレスによる変更監視を実行するときにVirtual Applianceによって使用されます。これは、Virtual Applianceでは、特定の仮想マシンのOSが標準のディレクトリロケーションを使用しているかどうかを確認できないためです。

コンピュータまたはポリシーエディタ を開き、環境変数をオーバーライドします。
[設定]→[詳細] をクリックします。
環境変数オーバーライドセクションで、 環境変数 をクリックして、 環境変数オーバーライド ページをオーバーライドするように表示します。
メニューバーで[ 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}"/>

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

参照先のレジストリ値が見つからない場合、その環境変数を参照しているエンティティセットは検索も監視もされませんが、それ以外の構成は使用されます。変数が存在しないことを通知するアラートが発令されます。Agentは、イベント8012を使用して環境変数の不正な変更を報告します。変更監視ルールのIDとレジストリ値のパスが、パラメータとしてイベントに提供されます。

ワイルドカードは、ベース名の構造体の最後のコンポーネントにのみ使用できます。たとえば、 "base = "HKLM \ Software \ ATI*"は有効で、「HKLM \ Software \ ATI」と「HKLM \ Software \ ATI Technologies」の両方が検索されますが、, base = "HKLM\*\Software \ ATI* is無効です。

「..」の使用

親ディレクトリへの参照を示す「..」符号は、Agentの現在のすべてのバージョンでサポートされるようになりました。Agentは、FileSetとDirectorySet要素のベースディレクトリ名の正規化を行いますが、このとき、「..」参照を解決し、Windowsの短い名前を長い名前に変換します。たとえば、一部の新しいバージョンのWindowsでは、次のFileSetのベースディレクトリはC:\Usersになります。それ以前のバージョンのWindowsの場合は、C:\Documents and Settingsになります。

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

ベストプラクティス

ルールは、重要なオブジェクトと属性のみを含めるように記述してください。こうすることで、オブジェクトの他の属性が変更されても、イベントは報告されなくなります。たとえば、変更監視ポリシーで「/bin」ディレクトリ内のファイルのアクセス権と所有権を制限することもできます。変更監視ルールは所有者、グループ、およびアクセス権を監視しますが、lastModifiedやハッシュ値などの属性は監視しません。

変更監視ルールを使用して不正プログラムや不審な活動を検出し、サービスを監視し、NTFSデータストリームの使用を監視し、「/tmp」や「${env.windir}\temp」などの異常な場所で実行可能ファイルを監視する場合に使用します。

ルールに含めるオブジェクトを指定する場合は、必ず、できるだけ詳細に指定してください。ルールに含めるオブジェクトが少ないほど、短期間でベースラインを作成でき、変更の検索にかかる時間も短くなります。変更される可能性のあるオブジェクトは除外し、監視する属性は必要なものだけに絞ります。

ルールを作成するときは、次のことは避けてください。

「/」、「C:\", or "HKLM \ Software」など階層の最上位から「**/...`」を使用します。
必要がないのに、データのハッシュの種類を複数使用すること。
HKEY_CURRENT_USER, ${env.USERPROFILE}、 ${env.HOME}など、ユーザ固有の場所をレファレンス/参照情報ます。

エージェントが指定されたパターンに一致するように多数の項目を検索するため、変更監視ルールにこれらの文があるとパフォーマンスの問題が発生します。

このページのトピック

変更監視ルールについて

エンティティセット