変更監視ルールの言語

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

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

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

エンティティセット

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

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

階層とワイルドカード

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

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

次の「エスケープ」文字もサポートされます。

「/」の文字でパターンをセクションに分割します。分割したセクションが一致するかぎり、パターンの各セクションが階層のそれぞれの下位レベルに適用されます。たとえば、次のようなパターンがあります。

/a?c/123/*.java

これが次のパスに適用された場合

/abc/123/test.java

次のように判定されます。

このパターンが次のパスに適用された場合

/abc/123456/test.java

次のように判定されます。

「**」の記号パターンは、ゼロ個以上のセクションと照合します。したがって、次のパターンの場合

/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」属性の文字列に使用できますが、使用できるのはパスの最後のセクションだけです。したがって、次の記述は有効です。

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

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つの値をとります。

この属性の初期設定は「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のパス名を照合するには、「\」の使用が必要です。これは、チェックの対象となる属性の値にこの文字が含まれているためです。これに対し、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

複数の条件を指定する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 (初期設定値) に設定すると、エンティティセットによって返されるエンティティは、変更がリアルタイムで監視されます。変更が検出されると、すぐにそのエンティティがベースラインと比較されます。エンティティセットのonChange属性がfalseに設定されている場合は、ベースラインが作成されたとき、または予約タスクから、あるいは必要に応じて Managerで開始されたときにのみ実行されます。

次の例では、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が再起動されます。

参照先の環境変数が見つからない場合、その環境変数を参照しているエンティティセットは検索も監視もされませんが、それ以外の構成は使用されます。変数が存在しないことを示すアラートがトリガされます。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のhostsファイルに対する変更を監視する変更監視ルール「Microsoft Windows - 'Hosts' file modified」は、C:\WINDOWS\system32\drivers\etcフォルダ内のファイルを検索します。ただし、すべてのWindows環境に「C:\WINDOWS\」ディレクトリがあるわけではないため、変更監視ルールではWINDIR環境変数を使用して、このディレクトリを%WINDIR%\system32\drivers\etcと表記します。

環境変数は、主に、仮想マシンでAgentレスによる変更監視を実行するときにVirtual Applianceによって使用されます。これは、Virtual Applianceでは、特定の仮想マシンのOSが標準のディレクトリロケーションを使用しているかどうかを確認できないためです。
  1. 環境変数をオーバーライドするコンピュータまたはポリシーエディタを開きます。
  2. [設定]→[詳細] をクリックします。
  3. [環境変数のオーバーライド] セクションで、[環境変数の表示] をクリックして [環境変数のオーバーライド] ページを表示します。
  4. メニューバーで [新規] をクリックして新しい名前と値のペア (たとえばWINDIRとD:\Windows) を入力し、[OK] をクリックします。

レジストリ値

レジストリ値は、エンティティセットで使用されるベース値に含めることができます。レジストリ値は「${}」で囲みます。レジストリ値のパスの先頭には「reg.」が付けられます。次の例は、FileSetのベースディレクトリを、「HKLM\Software\Trend Micro\ Agent\InstallationFolder」レジストリ値に格納されたパスに設定します。

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

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

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

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

「..」の使用

親ディレクトリへの参照を示す「..」符号は、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」など) に置かれた実行可能ファイルの監視などを実施します。

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

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

これらのいずれかが変更監視ルールに記述されていると、 Agentでは指定されたパターンに照合させるために多数の項目を検索してしまうため、パフォーマンスが低下します。