Грамотная настройка средств защиты зачастую рассматривается как низкоприоритетная задача, на которую обращают внимание в последнюю очередь. Однако, если задуматься, то все совсем наоборот:
как бы долго проектировщик ни работал над проектом,
сколько бы души архитектор ни вкладывал в систему,
как бы грамотно Пресейл ни рассказывал про преимущества оборудования,
все будет лишено смысла, если в итоге кто-то забудет в политике правило "permit ip any any", оставленное по забывчивости во время миграции из тестового сегмента в "продакшн".
Если вы скажете, что эта ситуация надуманная, то возразим, что это далеко не так. Да, проекты, в которых встречается упомянутый выше "ночной кошмар безопасника" (для неспециалистов поясним, что "permit ip any any" разрешает ЛЮБОЙ трафик как внутрь, так и наружу вашей сети) очень редки. Однако и они встречаются. У нас был и такой опыт - во время оптимизации правил политики безопасности мы обнаружили, что Заказчик забыл тестовое правило, которое когда-то давно использовалось во время пилотного проекта, в цепочке из сотен других правил политики безопасности межсетевого экрана (МСЭ), установленного в ядре ЦОД (центра обработки данных). Угадайте, какое было одно из самых часто срабатывающих правил политики: фактически, МСЭ был бесполезен.
Другой пример - это приоритизация обработки инцидентов, которые поступают со шлюза. Например, идет поток из 100 инцидентов. На какой из них обратить команде реагирования в первую очередь? На первый? На самый критичный? А маркировать инцидент критичностью кто должен (обычно критичность сохраняют по первоначальному событию на NGFW)? Мы, к примеру, в рамках работ зачастую для повышения эффективности расследований и трудозатрат команды мониторинга рекомендуем в первую очередь, помимо критичности, смотреть на результат блокировки действий участников на NGFW - если операция (трафик) заблокирована, то критичность для расследований уже не так важна, поскольку политика безопасности уже отработала - строго говоря, это даже уже не инцидент и его можно отложить в архив. А вот те события/инциденты, которые имеют пусть и меньший приоритет, но действия в рамках которых не были заблокированы, требуют повышенного приоритетного внимания! Особенно если в отношении активов из этих событий продолжают регистрироваться сработки и подозрительная активность. Для этого, конечно, приходится проводить предварительную работу по определению рисков, критичных сервисов, ранжированию активов, верификации правил политики ИБ и пр. (см.также ниже), но оно того стоит!
не обладают полным набором экспертных знаний по конкретному средству защиты, не знают его возможностей,
не могут донести и показать важность грамотной настройки для ИТ или бизнес-подразделений.
В итоге получается, что диалог проще встраивать с помощью внешнего "медиатора" - экспертного интегратора, который подскажет:
какие "правильные" вопросы нужно задать, чтобы внедряемая ИТ-система была безопасной;
как оценить риски для внедряемой системы;
какие средства защиты можно использовать;
как эффективно использовать имеющиеся средства у Заказчика, чтобы не внедрять новые СЗИ.
Наш опыт показывает, что в рамках проекта можно получить не только эффективную защиту сервиса с использованием имеющегося оборудования, но и сверх-эффект, например:
уменьшить нагрузку на персонал,
более эффективно использовать СЗИ и высвободить ресурсы оборудования, ускорить обработку запросов, уменьшить время отклика сервиса,
выделить ключевые инциденты из общего непрерывного потока событий.
Обращайтесь к нам и мы подскажем, как эффективно использовать оборудование именно у вас! Например, мы знаем, чем NGFW отличается от обычного МСЭ и используем его мощь на 100% возможностей, включая правила IPS, AppControl, Web/URL фильтрация, подключаем IoC, 2FA и другие функции, но не на все подряд, а подходим грамотно:
идем от конкретных бизнес-критичных сервисов
расписываем потоки и критичные активы
задаем приоритет сработки правил и их критичность
управляем настройками безопасности, сохраняя разумный компромисс между глубиной контроля сетевых потоков и приложений и их работоспособностью,