Зачем оптимизировать правила Firewall

Грамотная настройка средств защиты зачастую рассматривается как низкоприоритетная задача, на которую обращают внимание в последнюю очередь. Однако, если задуматься, то все совсем наоборот:

• как бы долго проектировщик ни работал над проектом,
• сколько бы души архитектор ни вкладывал в систему,
• как бы грамотно Пресейл ни рассказывал про преимущества оборудования,

все будет лишено смысла, если в итоге кто-то забудет в политике правило "permit ip any any", оставленное по забывчивости во время миграции из тестового сегмента в "продакшн".

Если вы скажете, что эта ситуация надуманная, то возразим, что это далеко не так. Да, проекты, в которых встречается упомянутый выше "ночной кошмар безопасника" (для неспециалистов поясним, что "permit ip any any" разрешает ЛЮБОЙ трафик как внутрь, так и наружу вашей сети) очень редки. Однако и они встречаются. У нас был и такой опыт - во время оптимизации правил политики безопасности мы обнаружили, что Заказчик забыл тестовое правило, которое когда-то давно использовалось во время пилотного проекта, в цепочке из сотен других правил политики безопасности межсетевого экрана (МСЭ), установленного в ядре ЦОД (центра обработки данных). Угадайте, какое было одно из самых часто срабатывающих правил политики: фактически, МСЭ был бесполезен.

Другой пример - это приоритизация обработки инцидентов, которые поступают со шлюза. Например, идет поток из 100 инцидентов. На какой из них обратить команде реагирования в первую очередь? На первый? На самый критичный? А маркировать инцидент критичностью кто должен (обычно критичность сохраняют по первоначальному событию на NGFW)?
Мы, к примеру, в рамках работ зачастую для повышения эффективности расследований и трудозатрат команды мониторинга рекомендуем в первую очередь, помимо критичности, смотреть на результат блокировки действий участников на NGFW - если операция (трафик) заблокирована, то критичность для расследований уже не так важна, поскольку политика безопасности уже отработала - строго говоря, это даже уже не инцидент и его можно отложить в архив.
А вот те события/инциденты, которые имеют пусть и меньший приоритет, но действия в рамках которых не были заблокированы, требуют повышенного приоритетного внимания! Особенно если в отношении активов из этих событий продолжают регистрироваться сработки и подозрительная активность. Для этого, конечно, приходится проводить предварительную работу по определению рисков, критичных сервисов, ранжированию активов, верификации правил политики ИБ и пр. (см.также ниже), но оно того стоит!

Другой совсем свежий пример 2022 года - пример классической ошибки, сделанной ИТ-никами. Сервер для очередного нужного ИТ сервиса выставляется наружу в Интернет, при этом ИБшники про него ничего не знают и, как следствие, не имеют возможности защитить.

• зачем нужна безопасность
• как оценить риски для сервиса
• какие есть средства защиты,

а ИБшники :

• не в курсе проектов ИТ
• не обладают полным набором экспертных знаний по конкретному средству защиты, не знают его возможностей,
• не могут донести и показать важность грамотной настройки для ИТ или бизнес-подразделений. 

В итоге получается, что диалог проще встраивать с помощью внешнего "медиатора"  - экспертного интегратора, который подскажет:

• какие "правильные" вопросы нужно задать, чтобы внедряемая ИТ-система была безопасной;
• как оценить риски для внедряемой системы;
• какие средства защиты можно использовать;
• как эффективно использовать имеющиеся средства у Заказчика, чтобы не внедрять новые СЗИ.

показывает, что в рамках проекта можно получить не только эффективную защиту сервиса с использованием имеющегося оборудования, но и сверх-эффект, например:

• уменьшить нагрузку на персонал, 
• более эффективно использовать СЗИ и высвободить ресурсы оборудования, ускорить обработку запросов, уменьшить время отклика сервиса,
• выделить ключевые инциденты из общего непрерывного потока событий.

и мы подскажем, как эффективно использовать оборудование именно у вас!

• идем от конкретных бизнес-критичных сервисов
• расписываем потоки и критичные активы
• задаем приоритет сработки правил и их критичность
• управляем настройками безопасности, сохраняя разумный компромисс между глубиной контроля сетевых потоков и приложений и их работоспособностью,
• интегрируемся с SIEM, TI/TH, IRP.

Будем рады помочь и вам!