ビュー:
変更監視ルール言語は、システムコンポーネントとそれに関連する属性を記述する宣言型のXMLベースの言語であり、Deep Securityによって監視されるべきものです。また、より大きなコンポーネントセット内で監視から除外すべきコンポーネントを指定する手段も提供します。
ヒント
ヒント
ファイルやWindowsレジストリの不正な変更をモニタするだけでよい場合は、カスタムルールを作成する代わりにファイルおよびレジストリルールテンプレートを使用できます。これらのテンプレートの使用方法について詳しくは、変更監視ルールの作成を参照してください。
新しいカスタム変更監視ルールを作成するには、変更監視ルールの作成の手順に従って開始し、テンプレートタイプとして[Custom (XML)]を選択します。その後、以下のセクションで説明されている変更監視ルール言語に従ってカスタムルールを作成します。

エンティティセット

変更監視ルールに含まれるシステムコンポーネントは「エンティティ」と呼ばれます。各コンポーネントの種類はエンティティのクラスです。例えば、ファイル、レジストリキー、プロセスはそれぞれエンティティのクラスです。変更監視ルール言語は、各エンティティクラスのエンティティセットを記述するためのタグを提供します。ルールで使用可能な[エンティティセット]タイプは次のとおりです:
  • DirectorySet: ルールはディレクトリの整合性をスキャンします
  • FileSet : ルールはファイルの整合性をスキャンします
  • GroupSet: ルールはグループの整合性をスキャンします
  • InstalledSoftwareSet: ルールはインストールされたソフトウェアの整合性をスキャンします
  • PortSet: ルールはリスニングポートの整合性をスキャンします
  • ProcessSet: ルールはプロセスの整合性をスキャンします
  • RegistryKeySet: ルールはレジストリキーをスキャンします
  • RegistryValueSet : ルールはレジストリ値をスキャンします
  • ServiceSet : ルールはサービスの整合性をスキャンします
  • UserSet: ルールはユーザの整合性をスキャンします
  • WQLSet : ルールはWindows Management Instrumentation WQLクエリステートメントの結果の整合性をモニタします
1つの変更監視ルールに複数のエンティティセットを含めることができます。たとえば、複数のファイルとレジストリエントリを監視するルール1つで、アプリケーションを保護できます。

階層とワイルドカード

FileSetやRegistryKeySetなどの階層型のデータの種類を表すエンティティセットでは、セクションベースのパターン照合がサポートされます。
  • / (スラッシュ) : 階層の各レベルに該当する箇所でパターンの各セクションを区切ります
  • ** (2 つのアスタリスク): ゼロ個以上のセクションと一致します
次のワイルドカードがサポートされます。
  • ? (クエスチョンマーク) : 1文字に一致
  • * (アスタリスク1つ) : 0文字以上の任意の文字に一致
次の「エスケープ」文字もサポートされます。
  • \ (バックスラッシュ) : 次の文字をエスケープします
「 / 」の文字でパターンをセクションに分割します。分割したセクションが一致するかぎり、パターンの各セクションが階層のそれぞれの下位レベルに適用されます。たとえば、パターンが:
/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」に一致しないため、そこから先はパターン照合は実行されない
「 ** 」の記号パターンは、ゼロ個以上のセクションと照合します。したがって、次のパターンの場合
/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」属性があります。キーのソースはエンティティセットによって異なります。例えば、ファイルとディレクトリの場合はそのパスであり、ポートの場合は一意のプロトコル/IP/ポート番号のタプルです。
注意
注意
含めるルールまたは除外ルールで指定されたパスが構文的に無効な場合、エージェントは「変更監視ルールコンパイル問題」エージェントイベントを生成し、ルールIDとパス (展開後) をパラメータとして提供します。無効なパスの例としては、 C:\test1\D:\test2 があります。ファイル名には2つのボリューム識別子を含めることはできません。

includeタグ

includeタグは本質的に許可リストです。これを使用すると、それに一致するエンティティ (または他のincludeタグ) だけが含まれます。includeタグを追加することで、次のルールは「C:\Program Files\MySQL」フォルダおよびサブフォルダ内の名前が「*.exe」のファイルの変更のみを監視するようになります。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
「Includes」を組み合わせることができます。次のルールは、「C:\Program Files\MySQL」フォルダとそのサブボリュームフォルダ内にある、「*.exe」と「*.dll」という名前の付いたファイルに対する変更を監視します。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
複数の条件を単一のインクルードブロックに組み合わせることも可能で、その場合、特定のエンティティが含まれるためには[all]条件が真でなければなりません。次の「include」タグでは、エンティティが含まれるためには「.exe」で終わり、「sample」で始まる必要があります。この要件はより簡潔に表現することもできますが、以下の「機能」セクションで説明するように、キーのパターンがエンティティの他の機能と組み合わされると、その有用性がより明確になります。
<include>
</include>
次の構文は、同じ条件を他の方法で記述したものです。
<include key="**/*.exe">
</include>

excludeタグ

除外タグはブロックリストとして機能し、通常は返されるファイルをセットから削除します。次の (ありそうもない) 例では、一時ファイル以外のすべてのファイルが監視対象になります。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
次のルールは、EXEとDLLのファイルセットから「MySQLInstanceConfig.exe」を除外します。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
「include」タグと同様、複数の条件を指定する「exclude」タグを記述することができます。次の例は、複数の条件を指定する「exclude」タグを示しています。
<exclude>
</exclude>

大文字/小文字の区別

includeまたはexcludeタグのパターン照合での大文字/小文字の区別は、「casesensitive」属性で制御できます。この属性には3つの許可された値があります。
  • true
  • false
  • プラットフォーム
この属性のデフォルト値は「platform」であり、これはパターンの大文字小文字の区別が実行されているプラットフォームに一致することを意味します。次の例では、Windowsシステムでは「Sample.txt」と「sample.txt」の両方が返されますが、Unixシステムでは「Sample.txt」のみが返されます。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
次の例では、Windowsの場合もUNIXの場合も「Sample.txt」のみが返されます。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
注意
注意
大文字/小文字の区別を「true」に設定するのは、Windowsのように、ほとんどのオブジェクト名に対して大文字/小文字の区別をしないプラットフォームに限られます。

エンティティ機能

「キー」以外の機能に基づくエンティティの包含と除外も、一部のエンティティタイプでサポートされています。機能のセットはエンティティタイプによって異なります。次の例では、すべての実行可能ファイルが含まれます。これは、以前のファイル拡張子を使用した例のようにファイル拡張子に依存するのではなく、ファイルの最初の数百バイトをチェックして、指定されたOSで実行可能かどうかを判断します。
<FileSet base="C:\Program Files\MySQL">
</FileSet>
フィーチャ属性は「include」または「exclude」タグに表示される必要があります。複数の条件を含むincludeまたはexcludeの一部として使用するには、囲むincludeまたはexcludeタグの属性として指定する必要があります。次の例では、名前に「MySQL」という文字列が含まれており、実行可能なすべてのファイルを含めます:
<include executable="true">
</include>
上記の例は、次のようにもっと簡潔に記述することができます。
<include key="**/*MySQL*" executable="true"/>
いくつかの機能属性は、エンティティの属性の値に対する単純な一致です。このような場合、ワイルドカード一致「 * 」および「 ? 」がサポートされることがあります。個々のエンティティセットのヘルプページには、この方法で含めるまたは除外するルールに使用できる属性と、それらがワイルドカード一致または単純な文字列一致をサポートするかどうかが示されています。
注意
注意
ワイルドカードマッチがサポートされている場合、マッチは属性の文字列値に対して行われ、正規化は行われないことに注意することが重要です。 "** "や階層コンポーネントを区切るための" / "の使用など、エンティティキーのマッチに利用できる構成は適用されません。Windowsでパス名をマッチさせるには、テストされる属性の値に現れる文字である" \ "を使用する必要がありますが、Unixシステムではパス値に" / "を使用するため、Unixパスに対するマッチには" / "を使用する必要があります。
次のルールは、「state」属性を使用した機能照合の例です。
<ServiceSet>
</ServiceSet>
注意
注意
state照合ではワイルドカードはサポートされません。
次の例は、バイナリのパスの末尾が「\notepad.exe」となっているプロセスを照合します。
<ProcessSet>
</ProcessSet>
次の例は、コマンドラインが「/sbin/」から始まるプロセスを照合します。
<ProcessSet>
</ProcessSet>
注意
注意
ワイルドカードを使用する際は注意してください。ワイルドカード式「 ** 」は、「base」以下のすべてのサブディレクトリ内のすべてのファイルを対象とします。このような式のベースラインを作成するには、多くの時間とリソースがかかる可能性があります。

ANDとOR

複数の条件を指定するincludeとexclude、および複数のincludeとexcludeを使用して、論理ANDと論理ORを記述することができます。
複数の基準を含めるまたは除外する方法はいくつかあり、ANDを表現することができます。最も簡単な方法は、単一の囲みタグ内に複数の基準を含めることです。次の例は、単純な複数基準のANDを示しています:
<include>
</include>
また、囲みタグの属性に条件を記述すると、その条件は、複数の条件を指定する要件の一部として囲まれた条件でグループ化されます。次の例は、この方法で書き直された以前の複数条件「include」を示しています。
<include key="**/*.exe">
</include>
最後の例は、複数の条件をincludeまたはexcludeタグの属性に記述したものですが、これもANDとして扱われます。
<include executable="true" key="**/*MySQL*" />
ORは、複数のincludeまたはexcludeタグを含めることで簡単に表現されます。次のコードは、拡張子が「.exe」または「.dll」のファイルを含めます:
<include key="**/*.dll" />
<include key="**/*.exe" />

評価の順序

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

エンティティ属性

特定のエンティティには監視可能な属性のセットがあります。エンティティセットに属性が指定されていない場合 (つまり、属性ラッパータグが存在しない場合)、そのエンティティの標準属性セットが適用されます。(個々のエンティティセットの省略属性セクションを参照してください。)
ただし、特定のエンティティセットに対して、変更監視の対象となるのはエンティティの特定の属性のみです。例えば、ログファイルの内容の変更はほとんどの場合予想され、許可されます。しかし、権限や所有権の変更は報告されるべきです。
Entity Setsの"attributes"タグを使用すると、これを表現できます。"attributes"タグには、関心のある属性を列挙する一連のタグが含まれています。許可される"attribute"タグのセットは、提供されるEntity Setによって異なります。
注意
注意
「attributes」タグが存在しても属性が指定されていない場合、ルールで定義されたエンティティが存在するかどうかだけが監視されます。
次の例は、「C:\Program Files\MySQL」ディレクトリ内でファイル名に「SQL」の文字列を含む実行ファイルについて、「last modified」、「permissions」、および「owner」の各属性に関する変更を監視します。
<FileSet base="C:\Program Files\MySQL" >
</FileSet>
次の例は、「C:\Program Files\MySQL」内のログファイルの「permissions」と「owner」の属性を監視します。
<FileSet base="C:\Program Files\MySQL" >
</FileSet>
次の例は、属性のSTANDARDセットを監視します。(下記の略語属性を参照)
<FileSet base="C:\Program Files\MySQL" >
</FileSet>
次の例では、属性は監視されません。エンティティの存在のみが変更の追跡対象となります。
<FileSet base="C:\Program Files\MySQL" >
</FileSet>

簡略記法属性

省略属性は、単一の上位レベル属性を使用して一連の属性を指定する方法を提供します。通常の属性と同様に、許可される値のセットは、それらが提供されるエンティティセットに基づいて異なります。
簡略記法属性が役に立つのは、属性のセットが自然にグループ化されている場合、属性のセットをすべて列挙することが煩雑な場合、および上位レベルの属性で表された属性のセットが時間とともにまたはシステム構成によって変わる可能性がある場合などです。各ケースの例を以下に示します。
属性
説明
STANDARD
エンティティセットのモニタ対象属性のセット。これはエンティティセットの「すべての可能な属性」とは異なります。例えば、すべての可能なハッシュアルゴリズムを含むのではなく、十分と見なされるものだけを含みます。各エンティティセットの「標準」属性のリストについては、個々のエンティティセットのセクションを参照してください。
CONTENTS
ファイルの内容のハッシュまたはハッシュのセットを表す簡略記法属性です。SHA-1に初期設定されています。

onChange属性

EntitySetは、リアルタイムでの変更をモニタするように設定できます。EntitySetのonChange属性がtrue (デフォルト値) に設定されている場合、EntitySetによって返されるエンティティはリアルタイムで変更がモニタされます。変更が検出されると、エンティティは直ちにそのベースラインと比較され、変動が確認されます。EntitySetのonChange属性がfalseに設定されている場合、ベースラインが構築されるとき、または予約タスクやDeep Security Managerによってオンデマンドでトリガーされるときにのみ実行されます。
次の例では、MySQLバイナリをリアルタイムで監視します。
<FileSet base="C:\Program Files\MySQL" onChange="true">
</FileSet>

環境変数

環境変数はエンティティセットで使用される基本値に含めることができます。これらは "${}" で囲まれます。変数名自体は "env." で始まります。
次の例は、FileSetのベースディレクトリを、PROGRAMFILES環境変数に格納されたパスに設定します。
<FileSet base="${env.PROGRAMFILES}"/>
注意
注意
参照された環境変数の値は、エージェントの起動時にDeep Security Agentによって読み取られ、保存されます。環境変数の値が変更された場合、その変更を登録するためにエージェントを再起動する必要があります。
参照されている環境変数が見つからない場合、それを参照しているエンティティセットはスキャンまたは監視されませんが、残りの設定は使用されます。変数が存在しないことを示すアラートがトリガーされます。エージェントは、エージェントイベント「変更監視ルールコンパイル問題」を使用して無効な環境変数を報告します。変更監視ルールのIDと環境変数名がイベントのパラメータとして提供されます。
変更監視で使用される初期設定の環境変数を次に示します。
名前
Value
ALLUSERSPROFILE
C:\ProgramData
COMMONPROGRAMFILES
C:\Program Files\Common Files
PROGRAMFILES
C:\Program Files
SYSTEMDRIVE
C:
SYSTEMROOT
C:\Windows
WINDIR
C:\Windows

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

WindowsOSで標準以外の場所が使用されている場合、環境変数をオーバーライドします。例えば、Windowsホストファイルの変更を監視する[Microsoft Windows - 'Hosts' file modified]変更監視ルールは、そのファイルをC:\WINDOWS\system32\drivers\etcフォルダで探します。しかし、すべてのWindowsインストールがC:\WINDOWS\ディレクトリを使用するわけではないため、変更監視ルールはWINDIR環境変数を使用し、ディレクトリを%WINDIR%\system32\drivers\etcとして表します。
注意
注意
環境変数は、Virtual Applianceが仮想マシンでAgentレス変更監視を実行する際に主に使用されます。これは、特定の仮想マシン上のOSが標準ディレクトリの場所を使用しているかどうかをVirtual Applianceが知る方法がないためです。
  1. 環境変数を上書きしたい[コンピュータエディタとポリシーエディタ]を開きます。
  2. [設定]→[詳細]をクリックします。
  3. [環境変数のオーバーライド]セクションで、[環境変数の表示]をクリックして[環境変数のオーバーライド]ページを表示します。
  4. メニューバーで [新規] をクリックして新しい名前と値のペア (たとえば 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は起動時にすべてのルールをチェックし、参照先のレジストリ値が変更されていた場合は、影響を受けるルールのベースラインを再構築します。
参照されたレジストリ値が見つからない場合、それを参照しているEntitySetsはスキャンまたは監視されませんが、残りの構成は使用されます。変数が存在しないことを通知するアラートが発生します。エージェントは、エージェントイベント8012を使用して無効な環境変数展開を報告します。変更監視ルールのIDとレジストリ値のパスがイベントのパラメータとして提供されます。
注意
注意
ワイルドカードはベース名の最後の階層コンポーネントにのみ使用できます。例えば、base="HKLM\Software\ATI*"は有効で、「HKLM\Software\ATI」と「HKLM\Software\ATI Technologies」の両方が見つかりますが、base="HKLM\*\Software\ATI*は無効です。

「..」の使用

親ディレクトリを参照するための「..」の規則は、すべての現在のバージョンのエージェントでサポートされています。エージェントは、「..」の参照を解決し、Windowsの短い名前を長い名前に変換することによって、FileSetおよびDirectorySet要素の基底ディレクトリ名を正規化しようとします。例えば、Windowsの新しいバージョンのいくつかでは、次のFileSetの基底ディレクトリはC:\Usersになります。Windowsの以前のバージョンでは、C:\Documents and Settingsになります。
<FileSet base="${env.USERPROFILE}\..">
</FileSet>

ベストプラクティス

ルールは重要なオブジェクトと属性のみを含むように記述する必要があります。これにより、オブジェクトの他の属性が変更されてもイベントが報告されないようにします。例えば、変更監視ポリシーは /bin 内のファイルの権限と所有権に制限を設けることがあります。変更監視ルールは所有者、グループ、および権限をモニタする必要がありますが、lastModifiedやハッシュ値などの他の属性はモニタしないようにします。
変更監視ルールを使用して、不正プログラムや不審なアクティビティの検出、サービスの監視、NTFSデータストリームの使用状況の監視、および通常の場所以外のディレクトリ (「 /tmp 」や「 ${env.windir}\temp 」など) に置かれた実行可能ファイルの監視などを実施します。
ルールに含めるオブジェクトを指定する際は、できるだけ具体的にしてください。含めるオブジェクトが少ないほど、ベースラインの作成にかかる時間が短くなり、変更のスキャンにかかる時間も短くなります。変更が予想されるオブジェクトは除外し、関心のある属性のみをモニタしてください。
ルールを作成する際は、以下を行わないでください:
  • 「 **/... 」を、「 / 」、「C:\」、または「 HKLM\Software 」などのディレクトリ階層の最上位で使用すること。
  • 必要がないのに、データのハッシュの種類を複数使用すること。
  • 参照先として、 HKEY_CURRENT_USER 、 ${env.USERPROFILE} 、または ${env.HOME} などのユーザ固有の場所を指定すること。
これらのいずれかが変更監視ルールに記述されていると、Deep Security Agentは指定されたパターンに照合させるために多数の項目を検索するため、パフォーマンスが低下します。