変更監視ルール言語は、 Server & Workload Protectionで監視する必要があるシステムコンポーネントおよび関連する属性を記述するXMLベースの宣言型言語です。また、大規模なコンポーネントセット内のどのコンポーネントを監視から除外するかを指定する手段も提供します。
ヒントファイルまたはWindowsレジストリに対する不正な変更を監視する必要がある場合は、カスタムテンプレートを作成する代わりに、ファイルルールテンプレートとレジストリルールテンプレートを使用できます。これらのテンプレートの使用の詳細については、を参照してください。変更監視ルールの作成。
|
新しいカスタム変更監視ルールを作成するには、の手順を実行します。変更監視ルールの作成(テンプレートの種類として [カスタム (XML)] を選択)、変更監視ルールの言語に従ってカスタムルールを作成します。以下のセクションで説明します。
エンティティセット
変更監視ルールに含まれるシステムコンポーネントを「エンティティ」と呼びます。コンポーネントの各タイプは、エンティティのクラスです。たとえば、ファイル、レジストリキー、およびプロセスは、それぞれエンティティのクラスです。変更監視ルールの言語には、エンティティのクラスごとにエンティティのセット
(エンティティセット) を記述するためのタグが用意されています。ルールでは、次の [エンティティセット] タイプを使用できます。
- ディレクトリセット: ルールはディレクトリの整合性を検索します
- ファイルセット: ルールはファイルの整合性を検索します
- グループセット: ルールはグループの整合性を検索します
- インストール済みソフトウェアセット: ルールは、インストールされているソフトウェアの整合性を検索します。
- ポートセット: ルールは待機ポートの整合性を検索します
- プロセスセット: ルールはプロセスの整合性を検索します
- レジストリキーセット: ルールはレジストリキーを検索します
- RegistryValueSet : ルールはレジストリ値を検索します
- サービスセット: ルールはサービスの整合性を検索します
- ユーザセット: ルールはユーザの整合性を検索します
- WQLセット: ルールは、結果の整合性を監視します。 Windows Management Instrumentation WQLクエリステートメント
1つの変更ルールに複数のエンティティセットを含めることができます。これにより、たとえば、複数のファイルとレジストリエントリを監視する単一のルールでアプリケーションを保護できます。
階層とワイルドカード
FileSetやRegistryKeySetなどの階層型のデータの種類を表すエンティティセットでは、セクションベースのパターン照合がサポートされます。
/
(スラッシュ) : 階層のレベルに適用するパターンのセクションを区切ります。**
(星2つ) : 0個以上のセクションに一致
次のワイルドカードがサポートされます。
?
(クエスチョンマーク) : 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" と一致しないため、これ以上の一致は実行されません。
「
**
」表記パターンは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の最後のパスコンポーネントでのみ使用できます。したがって、これは有効です。 <codeblock>base="C:\program files\CompanyName * Web Server" </codeblock> but this is not: <codeblock>base="C:\* files\Microsoft Office"</codeblock> |
エンティティセット内では、「include」および「exclude」タグを使用してパターンマッチングを制御できます。これらのタグには、照合するパターンを指定する「key」属性があります。キーのソースはエンティティセットによって異なります。たとえば、ファイルとディレクトリの場合はパスであり、ポートの場合は一意のプロトコル/IP/ポート番号のタプルです。
注意包含ルールまたは除外ルールに指定されたパスが構文的に無効な場合、Agentは「整合性監視ルールのコンパイルの問題」Agentイベントを生成し、パラメータとしてルールIDとパス
(展開後の) を指定します。無効なパスの例は次のとおりです。
C:\test1\D:\test2 ファイル名に2つのボリューム識別子を含めることはできないためです。 |
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」で先頭が「sample」のエンティティを含める必要があります。この要件はより簡潔に表すこともできますが、以下の「機能」で説明するように、キーパターンをエンティティの他の機能と組み合わせると、その有用性がより明確になります。
<include> <key pattern="**/*.exe"/> <key pattern="**/sample*"/> </include>
次の構文は、同じ条件を他の方法で記述したものです。
<include key="**/*.exe"> <key pattern="**/sample*"/> </include>
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つの値を指定できます。
- [true]
- [false]
- [プラットフォーム]
この属性の初期設定値は「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」タグ内に指定する必要があります。複数条件の包含または除外の一部として使用するには、包含タグまたは除外タグの属性として指定する必要があります。次の例には、名前に文字列「MySQL」を含み、かつ実行可能なすべてのファイルが含まれます。
<include executable="true"> <key pattern="**/*MySQL*"/> </include>
上記の例は、次のようにもっと簡潔に記述することができます。
<include key="**/*MySQL*" executable="true"/>
一部の機能属性は、エンティティのいずれかの属性の値と単純に一致します。このような場合、ワイルドカードは「」を使用して一致します。
*
"と" ?
がサポートされている場合があります。エンティティセットこの方法で包含ルールまたは除外ルールで使用できる属性、およびワイルドカード一致または単純な文字列一致のどちらをサポートするかを示します。
注意ワイルドカードによる一致areサポートされている場合、一致は属性の文字列値に対するものであり、正規化は実行されないことに注意してください。 "などのエンティティキーの一致に使用できる構文
** "および"の使用/ " を使用して階層コンポーネントを区切ることはできません。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を表すには、いくつかの方法があります。最も簡単な方法は、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は、複数の包含タグまたは除外タグを含めることで簡単に表されます。次のコードには、拡張子が「.exe」または「.dll」のファイルが含まれます。
<include key="**/*.dll" /> <include key="**/*.exe" />
評価の順序
ルール内での出現順序に関係なく、すべての「include」が最初に処理されます。オブジェクト名が少なくとも1つの「include」タグと一致する場合、そのオブジェクトは「exclude」タグと照合されます。少なくとも1つの「除外」タグと一致する場合、監視対象オブジェクトのセットから削除されます。
エンティティ属性
特定のエンティティには、監視可能な一連の属性があります。エンティティセットに属性が指定されていない場合 (つまり attributes ラッパータグが存在しない場合)、そのエンティティの属性の標準セットが想定されます。
(個々のエンティティセット.)
ただし、特定のエンティティセットについて、変更監視の対象となる可能性があるのはエンティティの特定の属性のみです。たとえば、ログファイルの内容に対する変更は、ほとんどの場合予期され、許可されます。ただし、権限または所有権の変更はレポートする必要があります。
エンティティセットの「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
|
エンティティセットを監視する属性のセット。これは、エンティティセットの「すべての可能な属性」とは異なります。たとえば、すべてのハッシュアルゴリズムが含まれるわけではなく、十分と見なされるものだけが含まれます。各エンティティセットの「標準」属性のリストについては、各エンティティセットのセクションを参照してください。エンティティセット。
|
コンテンツ
|
これは、ファイルの内容のハッシュまたはハッシュのセットの省略形です。初期設定はSHA-1です。
|
onChange属性
変更をリアルタイムで監視するようにEntitySetを設定できます。 EntitySetのonChange属性がtrue (初期設定値) に設定されている場合、EntitySetから返されるエンティティの変更がリアルタイムで監視されます。変更が検出されると、エンティティは即座にベースラインと比較されて変動が確認されます。
EntitySetの onChange 属性が false に設定されている場合は、ベースラインが作成されたとき、またはスケジュールされたタスクによってトリガされたとき、または
Server & Workload Protectionによってオンデマンドでトリガされたときにのみ実行されます。
次の例では、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」ファイルが変更されました] 変更監視ルールは、C:\\WINDOWS\\system32\\drivers\\etcフォルダでそのファイルを検索します。ただし、すべてのWindowsインストールでC:\\WINDOWSディレクトリが使用されるわけではないため、変更監視ルールではWINDIR環境変数を使用し、ディレクトリを\
%WINDIR%\\system32\\drivers\\etc\ として表します。
注意環境変数は、仮想マシンでAgentレスの変更監視を実行するときに、主に仮想アプライアンスによって使用されます。これは、特定の仮想マシンのオペレーティングシステムが標準のディレクトリの場所を使用しているかどうかを仮想アプライアンスが認識できないためです。
|
- 環境変数を上書きする [コンピュータエディタとポリシーエディタ] を開きます。
- クリック 。
- で[環境変数のオーバーライド] セクションをクリックします。環境変数の表示を表示します。環境変数のオーバーライドにアクセスします。
- メニューバーの New をクリックし、新しい名前と値のペア (WINDIR、D:\\Windowsなど) を入力して OKをクリックします。
レジストリ値
レジストリ値は、エンティティセットで使用される基本値に含めることができます。 ${} で囲みます。レジストリ値へのパスの先頭には「reg.」が付きます。次の例では、FileSetのベースディレクトリを、レジストリ値「HKLM\\Software\\
トレンドマイクロ\\ Deep Security Agent\\InstallationFolder」に格納されているパスに設定します。
<FileSet base="${reg.HKLM\Software\Trend Micro\Deep Security Agent\InstallationFolder}"/>
参照されているレジストリ値の値は、新しいルールまたは変更されたルールがAgentによって受信されると読み取られます。 Agentは起動時にすべてのルールを確認し、参照されているレジストリ値が変更された場合は、影響を受けるルールのベースラインを再構築します。
参照されているレジストリ値が見つからない場合、その値を参照しているEntitySetは検索も監視もされませんが、残りの設定が使用されます。変数が存在しないことを通知するアラートが生成されます。エージェントは、エージェントイベント8012を使用して、無効な環境変数の展開を報告します。変更監視ルールのIDとレジストリ値のパスは、イベントのパラメータとして指定されます。
注意ワイルドカードは、ベース名の最後の階層コンポーネントでのみ使用できます。たとえば、「
base="HKLM\Software\ATI* " は有効で、"HKLM\\Software\\ATI" と "HKLM\\Software\\ATI Technologies" の両方が検出されます。ただし、base="HKLM\*\Software\ATI* は無効です。 |
「..」の使用
親ディレクトリを参照するための「..」規則は、Agentの現在のすべてのバージョンでサポートされています。 Agentは、「..」参照を解決し、Windowsのショートネームをロングネームに変換することにより、FileSetおよびDirectorySet要素のベースディレクトリ名の正規化を試みます。たとえば、一部の新しいバージョンのWindowsでは、次のファイルセットのベースディレクトリが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:\
またはHKLM\Software
"。 - 必要がないのに、データのハッシュの種類を複数使用すること。
- 次のようなユーザ固有の場所をレファレンス/参照情報します。
HKEY_CURRENT_USER
,${env.USERPROFILE}
、または${env.HOME}
。
変更監視ルールにこれらのステートメントが含まれていると、指定されたパターンに一致するようにエージェントが多数の項目を検索するため、パフォーマンスの問題が発生します。