変更監視 ルール言語は、 Workload Securityが監視する必要がある、システムコンポーネントおよび関連する属性を記述する宣言的XMLベースの言語です。この言語を使用して、システム内に多数存在するコンポーネントの中から監視の対象外とするものを指定することもできます。
ファイルやWindowsレジストリの不正な変更をモニタするだけでよい場合は、カスタムルールを作成する代わりにファイルおよびレジストリルールテンプレートを使用できます。これらのテンプレートの使用方法について詳しくは、変更監視ルールの作成を参照してください。
新しいカスタム変更監視ルールを作成するには、変更監視ルールの作成の手順から始め、テンプレートタイプとして[Custom (XML)]を選択し、次のセクションで説明されている変更監視ルール言語に従ってカスタムルールを作成します。
ここでは、次の項目について説明します。
エンティティセット
変更監視ルールに含まれるシステムコンポーネントは、エンティティと呼ばれます。各コンポーネントのタイプはエンティティのクラスです。例えば、ファイル、レジストリキー、プロセスはそれぞれエンティティのクラスです。変更監視ルール言語は、各エンティティクラスのエンティティセットを記述するためのタグを提供します。ルールで使用可能な[Entity Set]タイプは次のとおりです。
- DirectorySet: ディレクトリの整合性をスキャンするルール
- FileSet: ルールはファイルの整合性をスキャンします
- GroupSet: グループの整合性をスキャンするルール
- InstalledSoftwareSet: ルールはインストールされたソフトウェアの整合性をスキャンします
- PortSet: ルールはリスニングポートの整合性をスキャンします
- ProcessSet: ルールはプロセスの整合性をスキャンします
- RegistryKeySet: ルールはレジストリキーをスキャンします
- RegistryValueSet: ルールはレジストリ値をスキャンします
- ServiceSet: ルールはサービスの整合性をスキャンします
- UserSet: ルールはユーザの整合性をスキャンします
- WQLSet: Windows Management Instrumentation WQLクエリステートメントの結果の整合性を監視するルール
1つの変更監視ルールに複数のエンティティセットを含めることができます。たとえば、複数のファイルとレジストリエントリを監視するルール1つで、アプリケーションを保護できます。
階層とワイルドカード
FileSetやRegistryKeySetなどの階層型のデータの種類を表すエンティティセットでは、セクションベースのパターン照合がサポートされます。
/(スラッシュ) : 階層の各レベルに該当する箇所でパターンの各セクションを区切ります**(2 つのアスタリスク): ゼロ個以上のセクションと照合します
次のワイルドカードがサポートされます。
?(クエスチョンマーク) : 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に一致しないため、そこから先はパターン照合は実行されない
**表記パターンは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属性文字列で使用できますが、baseの最後のパスコンポーネントでのみ使用できます。したがって、次のものは有効です:
base="C:\program files\CompanyName * Web Server"
ただし、次の内容は無効です:
base="C:\* files\Microsoft Office"
Entity Set内では、
includeタグとexcludeタグを使用してパターンマッチングを制御できます。これらのタグには、マッチングするパターンを指定するkey属性があります。keyのソースはEntity Setによって異なります。例えば、ファイルやディレクトリの場合はそのパスであり、ポートの場合は一意のプロトコル/IP/ポート番号のタプルです。含むまたは除外するルールで指定されたパスが構文的に無効な場合、エージェントは変更監視ルールコンパイル問題エージェントイベントを生成し、ルールIDとパス (展開後)
をパラメータとして提供します。無効なパスの例として、
C:\test1\D:\test2があります。これは、ファイル名に2つのボリューム識別子を含めることはできないためです。includeタグ
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>
複数の条件を単一のincludeブロックに組み合わせることも可能で、その場合、特定のエンティティが含まれるためにはすべての条件が真でなければなりません。次の
includeタグは、エンティティが.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>
大文字/小文字の区別
include または exclude タグのパターン照合での大文字/小文字の区別は、
casesensitive 属性で制御できます。この属性には、3 つの許可される値があります:truefalseplatform
この属性のデフォルト値は
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のように、ほとんどのオブジェクト名に対して大文字/小文字の区別をしないプラットフォームに限られます。エンティティ機能
一部のエンティティタイプでは、キー以外の特性に基づくエンティティの包含と除外もサポートされています。一連の特性は、エンティティの種類によって異なります。次の例には、すべての実行可能ファイルが含まれています。ファイル拡張子を使用した前の例のように、ファイル拡張子には依存しませんが、代わりにファイルの最初の数百バイトをチェックして、指定された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"/>一部の機能属性は、エンティティの属性の値と単純に一致します。このような場合、
*や?を使用したワイルドカード一致がサポートされることがあります。個々のエンティティセットのヘルプページには、どの属性がこの方法で含めるまたは除外するルールに使用できるか、またワイルドカード一致や単純な文字列一致をサポートしているかが示されています。ワイルドカードの一致がサポートされている場合、属性の文字列値に対して一致が行われ、正規化が行われないことに注意することが重要です。
**や階層コンポーネントを分離するための/の使用など、エンティティキーの一致に利用可能な構造は適用されません。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を記述することができます。複数の基準を含めるまたは除外する方法はいくつかあり、それを
ANDとして表現することができます。最も簡単な方法は、単一の囲みタグ内に複数の基準を含めることです。次の例は、シンプルな複数基準の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" />
評価の順序
すべてのインクルードは、ルールに表示される順序に関係なく、最初に処理されます。オブジェクト名が少なくとも1つの
includeタグに一致する場合、それはexcludeタグに対してテストされます。少なくとも1つのexcludeタグに一致する場合、それは監視対象オブジェクトのセットから削除されます。エンティティ属性
特定のエンティティには、監視可能な一連の属性があります。エンティティセットに属性が指定されていない場合 (たとえば、attributesラッパータグが存在しない場合)、そのエンティティの属性のSTANDARDセットが想定されます。個々のエンティティセット については、短縮形の属性を参照してください。
特定のエンティティセットについて、変更監視の対象となるのはエンティティの特定の属性のみです。たとえば、ログファイルの内容に対する変更は、ほとんどの場合予期され、許可されます。ただし、権限または所有権の変更はレポートする必要があります。
Entity Setsの
attributesタグを使用すると、これを表現できます。attributesタグには、対象となる属性を列挙する一連のタグが含まれています。許可されるattributesタグのセットは、提供されるEntity Setによって異なります。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
|
エンティティセットの属性をモニタするためのセットです。これは、エンティティセットの「すべての可能な属性」とは異なります。例えば、すべての可能なハッシュアルゴリズムを含むのではなく、十分と見なされるものだけを含みます。各エンティティセットの「標準」属性のリストについては、個々のエンティティセットのセクションを参照してください。
|
|
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
|
環境変数のオーバーライド
WindowsOSで標準外の場所が使用されている場合、環境変数をオーバーライドします。例えば、Windowsホストファイルの変更を監視する[Microsoft Windows - 'Hosts' file modified]変更監視ルールは、
C:\WINDOWS\system32\drivers\etcディレクトリ内のファイルを探します。しかし、すべてのWindowsインストールがC:\WINDOWS\ディレクトリを使用するわけではないため、変更監視ルールはWINDIR環境変数を使用し、ディレクトリを%WINDIR%\system32\drivers\etcとして表します。- 環境変数を上書きしたい[コンピュータエディタとポリシーエディタ]を開きます。
- の順にクリックします。
- [環境変数のオーバーライドセクション]で[環境変数の表示]をクリックして[環境変数のオーバーライド]ページを表示します。
- メニューバーで[新規]をクリックし、新しい名前と値のペア (例: 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\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}\..">
<include key="*/Start Menu/Programs/Startup/*"/>
</FileSet>
ベストプラクティス
ルールは、重要なオブジェクトと属性のみを含むように作成する必要があります。これにより、オブジェクトの他の属性が変更されてもイベントが報告されないようにします。例えば、変更監視ポリシーでは、
/bin内のファイルの権限と所有権に制限を設けることができます。変更監視ルールでは、所有者、グループ、および権限をモニタする必要がありますが、lastModifiedやhash値などの他の属性はモニタしないようにします。変更監視ルールを使用して、不正プログラムや不審なアクティビティの検出、サービスの監視、NTFSデータストリームの使用状況の監視、および通常の場所以外のディレクトリ
(
/tmp や ${env.windir}\temp など) に置かれた実行可能ファイルの監視などを実施します。ルールに含めるオブジェクトは、できるだけ具体的に指定してください。含めるオブジェクトが少ないほど、ベースラインの作成にかかる時間が短くなり、変更の検索にかかる時間が短くなります。変更が予想されるオブジェクトを除外し、必要な属性のみを監視します。
ルールを作成するときは、次のことを行わないでください。
**/...を、/、C:\、またはHKLM\Softwareなどのディレクトリ階層の最上位で使用する。- どうしても必要な場合を除き、複数のコンテンツハッシュタイプを使用します。
- 参照先として、
HKEY_CURRENT_USER、${env.USERPROFILE}、または${env.HOME}などのユーザ固有の場所を指定すること。
エージェントは指定されたパターンに一致するために多くの項目を検索するため、変更監視ルールでこれらのステートメントを使用すると、パフォーマンスの問題が発生する可能性があります。
