Симптомы

Как на практике организовать правила СОВ?
Как разделить журналирующие, блокирующие, разрешающие правила?
Как лучше задавать профили СОВ, указывать зоны или адреса источника/назначения?

Решение

Можно использовать 2 глобальных подхода к работе СОВ - проактивный и реактивный.

Реактивный заключается в следующем.

Создаётся журналирующее правило, которое сканирует трафик на предмет определения вредоносной активности. Затем время от времени результат его работы анализируется по журналам и наиболее частые/наиболее опасные сигнатуры вручную добавляются в другой профиль СОВ, который используется в другом правиле СОВ - с действием Блокировать и расположенным в списке выше журналирующего. Аналогичным образом, при обнаружении в журнале ложных срабатываний (и такое тоже бывает) могут создаваться разрешающие правила (без профиля СОВ), которые могут явно исключать из проверки трафик от определённых адресов или к определённым адресам, или для определённого Сервиса. Они располагаются ещё выше явно запрещающего правила. Как вариант, для снижения нагрузки на оборудование, журналирующее правило может работать не постоянно, а включаться только время от времени, на небольшой промежуток (скажем, раз в неделю на 4-8 часов, или раз в месяц на сутки, интервал подбирается вручную наблюдением за загрузкой ресурсов UG), с целью наполнения журнала. Или работать постоянно, но лишь для какой-то подсети предприятия, если их несколько.

Проактивный подход. Вместо накопления статистики по обнаруженным вредоносным сигнатурам и блокирования конкретных обнаруженных, создаются отдельные конкретные профили СОВ с сигнатурами, характерными для конкретных сервисов, и отдельными блокирующими правилами защищается трафик к этим конкретным сервисам. Например, есть почтовый сервер на базе ПО Microsoft Exchange, который получает/отправляет почту в Интернет по протоколу SMTP. Для его защиты создаётся профиль СОВ, куда включаются все сигнатуры, в описании которых есть SMTP и/или Exchange. А затем создаётся блокирующее правило СОВ, которое этим самым профилем проверяет трафик конкретно к адресу данного сервера. Аналогично для, скажем, сервера веб-портала к 1С создаётся профиль с сигнатурами, в описании которых есть 1С и/или HTTP, и им защищается трафик к адресу этого веб-портала. И так далее. И, самое важное, эти 2 подхода можно гибко объединять - для известных сервисов/серверов создать профили/правила проактивно (и поставить их выше в списке), а для "генеральной" защиты "всей сети" использовать реактивный метод, и относящиеся к нему правила будут идти ниже проактивных правил.