ベストプラクティス
•新しいルールは、まずテスト環境でテストするか、少数のコンピューターでテストします。
•「任意のプロセスが開始されました」など、多くのアラートを生成するルールは設計しないでください。
•新しいルールを作成するときは、監視対象とその理由をドキュメント化します。
•新しいルールを作成するときに、ルールの重大度を定義します。<severity>タグが存在しない場合、ルールには警告の重大度が自動的に割り当てられますが、これは特定のルールに適合しない可能性があります。
•CurrentControlSetレジストリキーはオペレーティングシステムによって動的に評価され、ControlSet%number%を指す代わりのシンボリックリンクであるため、ESET Inspectはこのキーを使用しません。ルールの例でCurrentControlSet内のレジストリキー/値を照合する方法を参照してください。
•x64 Windows OSにおけるx86エミュレーションの仕組みにより、多くのレジストリキー/値は、Wow6432Node下に片割れを持ち、同様の機能があるため、この場所を監視する必要があります。同じ概念が%windir%\SysWOW64と%PROGRAMFILES(X86)%フォルダにも当てはまります。
•Windowsでのレジストリパスの実装方法を考慮すると、特定のレジストリ値を照合する最善の方法は、条件値endsを使用することです。
•Windows NTFSで代替データストリーム(ADS)を照合する最善の方法は、次の条件を使用することです。
<condition component="FileItem" property="Extension" condition="contains" value=":" />
「contains」コンパレーターはパフォーマンスをかなり重視します。可能であれば、代わりに「starts」または「ends」を使用してください。 |
•特別な値条件「isnotempty」を使用して、任意の値で検出をトリガーする必要があることを示すことができます(たとえば、特定のプロセスのネットワーク接続と一致させる場合などに便利です)。使用例:
<condition component="FileItem" property="FileNameWithoutExtension" condition="isnotempty" />
•レジストリハイブは、短縮名(特にHKCU for HKEY_CURRENT_USERとHKLM for HKEY_LOCAL_MACHINE)で照合されます。
•条件パスは、大文字と小文字を区別せずに一致します。
•ルールを作成するときに、誤検知(無関係なアラートが多すぎる)をフィルター処理する方法を計画します。一般に、最初の繰り返しでは、できるだけ一般的なもの(たとえば、このレジストリ値の変更)にし、その後(たとえば、一般的な規則で無関係な検出が多数生成される場合)フィルターを追加する必要があります。その後、フィルター(ESET LiveGridの発生数/レピュテーション、プロセス名など)を追加して、無関係な検出の数を減らすことができます。フィルターは、関連性のある検出や注目に値する検出を逃さないように、できるだけ具体的なフィルターにする必要があります。
•論理演算子(タグ<operator>)の短絡評価が実装されているため、ルール作成時にルール論理式の最適化を検討し、ルールマッチングのパフォーマンスを向上させることができます。実例 - 論理式(A|B) & CはC & (A|B)に書き換えることができ、Cが真でない場合、式の残りの部分は評価されません。