Рекомендації
•Спочатку тестуйте нові правила в тестовому середовищі або для меншого набору комп’ютерів.
•Рекомендуємо не створювати правила, які призводять до появи великої кількості попереджень (наприклад, any process was started).
•Під час створення нового правила задокументуйте, що й чому відстежується.
•Окрім того, визначте рівень критичності правила. Якщо тег <severity> відсутній, для правила автоматично призначається рівень серйозності Попередження, який може не відповідати певному правилу.
•ESET Inspect не використовує розділ реєстру CurrentControlSet, оскільки він є альтернативним символьним посилання, яке динамічно оцінюється операційною системою і вказує на ControlSet%number%. Дізнайтеся, як зіставити розділи/значення реєстру в CurrentControlSet, у розділі Приклади правил.
•В ОС Windows x64 працює емуляція x86, тому багато розділів/значень реєстру мають свій аналог у Wow6432Node з аналогічною функціональністю, тому вам потрібно стежити за цим розташуванням. Те саме стосується папок %windir%\SysWOW64 і %PROGRAMFILES(X86)%.
•Найкращий спосіб зіставити певне значення реєстру — використовувати значення умови endes з огляду на те, яким чином шляхи реєстру реалізовані у Windows.
•Найкращий спосіб зіставити альтернативні потоки даних (ADS) у Windows NTFS — скористатися такою умовою:
<condition component="FileItem" property="Extension" condition="contains" value=":" />
|
Умова порівняння contains спричиняє завелике навантаження. За можливості використовуйте умови starts або ends. |
•Можна скористатися спеціальною умовою isnotempty, яка вказує на те, що виявлення має ініціюватися для будь-якого значення. Це стане в пригоді, якщо потрібно встановити відповідність всім мережевим підключенням від певного процесу. Приклад використання:
<condition component="FileItem" property="FileNameWithoutExtension" condition="isnotempty" />
•Кущі реєстру зіставляються за їхніми скороченими назвами, зокрема HKCU для HKEY_CURRENT_USER і HKLM для HKEY_LOCAL_MACHINE.
•Шляхи умов зіставляються без урахування регістру.
•Під час створення правила визначте, яким чином фільтрувати помилкові спрацьовування (забагато невідповідних сповіщень). Загалом, у першій ітерації слід дотримуватися якомога більшого ступеня узагальнення (наприклад, будь-яка зміна цього значення реєстру) й додавати фільтри лише згодом (наприклад, якщо загальне правило призводить до великої кількості невідповідних виявлень). Після цього можна додати фільтри (наприклад, за популярністю/репутацією LiveGrid, назвою процесу), щоб зменшити кількість невідповідних виявлень. Фільтри мають бути якомога точнішими, щоб не пропустити відповідні або важливі виявлення.
•Реалізовано обчислення логічних операторів за короткою схемою (тег <operator>), тому під час створення правила можна оптимізувати логічний вираз правила для підвищення продуктивності зіставлення з ним. Приклад: логічний вираз (A | B) & C можна переписати як C & (A | B). Якщо C не буде мати значення true, решта виразу не буде обчислюватися.