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