• Вступление
• Разбираемся на примере NGFW
• Когда мы столкнулись с такой ситуацией
• Enterprise vs Open Source: враги или партнеры?
• Оптимальный путь — осознанный симбиоз
• Резюмируем

Вступление

Представьте ситуацию: вы внедряете решение и ожидаете, что решение «из коробки» защитит вас от различного типа атак. На практике оказывается, что штатные механизмы не справляются. Такое, увы, случается часто — многие российские вендоры предлагают Enterprise-решения, которые в реальных условиях требуют доработок. О том, почему так происходит и как с этим справляться с помощью сигнатур, в статье рассказывает младший инженер технической поддержки Алексей Евсеев.

Алексей Евсеев

Младший инженер технической поддержки

Разбираемся на примере NGFW

Один из важнейших компонентов NGFW — системы обнаружения вторжений (IDS/IPS). Базы сигнатур можно разделить на коммерческие и Open Source. Коммерческими базами сигнатур зачастую располагают компании, специализирующиеся на поиске и предотвращении уязвимостей.

Преимущество таких баз — выделенная команда специалистов (TI): они пристально следят и анализируют при использовании ИИ огромное количество трафика и событий, выявленных посредством эвристического анализа. В дальнейшем именно они выпускают обновление онлайн баз для блокирования новых угроз, через которые СЗИ в реальном времени проверяют легитимность событий. Все эти действия направлены на предотвращение zero-day уязвимостей в кратчайшие сроки. Однако некоторые компании видят у коммерческих баз один существенный недостаток — их стоимость.

С другой стороны, существуют Open Source базы сигнатур: они обновляются не так быстро, зато бесплатны. Еще одно преимущество — вариативность их пополнения и открытый исходный код. Используя их, администратор зачастую сам может писать сигнатуры для IPS/IDS под различные задачи.

Когда бизнес выбирает Enterprise-решения, он ожидает гарантированную техническую поддержку, легкую интеграцию с корпоративными системами, например, с SOC, точное обнаружение и предотвращение новых угроз, а также соответствие требованиям законодательства. Однако у этого подхода есть и обратная сторона — ложное чувство безопасности. Вендоры нередко добавляют тысячи шаблонных правил «на всякий случай», что приводит к высокому уровню ложных срабатываний.

Поэтому инженер должен уметь писать точечные исключения или разрабатывать собственные сигнатуры для решения нетиповых задач. Современные же ML-модели, используемые в коммерческих NGFW, пока не могут полностью заменить Threat Intelligence. Сейчас они способны обнаруживать аномалии, но часто не понимают контекст атаки — например, не различают легитимный сканер и действия злоумышленников.

Если вы выбираете российское Enterprise-решение с Open Source базой сигнатур, будьте готовы привлечь к эксплуатации инженера с высоким уровнем экспертизы для написания кастомизированных сигнатур. Кроме того, для эффективного обнаружения и управления аномалиями в инфраструктуре и сети рекомендуем интегрировать это с работой центра мониторинга и реагирования (SOC) в любом формате — внутренний, гибрид или MSSP. В этом случае именно команда SOC будет выступать в роли TI-подразделения: выявлять аномалии, анализировать инциденты и формировать требования к донастройке системы. Без этих мер эффективность решения существенно снизится.

Когда мы столкнулись с такой ситуацией

Наша команда тестировала отечественный межсетевой экран нового поколения и проводила разные испытания. В процессе выявили, что штатные сигнатуры предотвращения DoS/DDoS-атак не отрабатывали — атака оставалась незамеченной.

Тогда мы решили пойти другим путем: написали кастомную сигнатуру, поскольку система использовала инструмент на базе Open Source — Suricata (прим. система обнаружения вторжений с открытым кодом). Это позволило точнее детектировать аномальный трафик и блокировать атаки до того, как они повлияли на инфраструктуру. Это была одна из тех ситуаций, которая позволяет в очередной раз убедиться — любое решение может быть просто дорогой «коробкой» без глубокой экспертизы инженера.

Enterprise vs Open Source: враги или партнеры?

В мире кибербезопасности существует любопытный парадокс: компании готовы платить за дорогие «коробочные» решения, веря в их «волшебную» эффективность. Однако «под капотом» часто скрываются решения, которые можно использовать и бесплатно. Вендор берет проверенные Open Source инструменты, облачает их в удобный интерфейс, добавляет логотип — вот уже на рынке появляется новое «уникальное» Enterprise-решение.

В этом кроется фундаментальная проблема: такая переупаковка далеко не всегда означает реальную адаптацию под современные угрозы. По факту компания зачастую получает малую эффективность в предотвращении zero-day и отсутствие онлайн-баз сигнатур. Любая новая уязвимость при таких вводных остается актуальна до следующего обновления, которое может затянуться. Поэтому очень важно в связке с такими решениями иметь центр мониторинга и реагирования (SOC), который сможет отследить аномалию и описать ее, а экспертный инженер — уже закроет уязвимость.

Действительно, Open Source дает полный контроль — можно анализировать, дорабатывать, улучшать. Но полностью отказываться от коммерческих решений рискованно: без них теряется скорость реагирования и экспертный Threat Intelligence. Собственный SOC не заменит полностью TI-отделы крупных вендоров, а инженеры — не всегда успеют оперативно закрыть уязвимость. Впрочем, слепо верить маркетингу — еще опаснее.

Оптимальный путь — осознанный симбиоз

Выбор Enterprise-решений с Open Source базой сигнатур оправдан там, где критически важны удобство управления, глубокая интеграция с SOC и соответствие требованиям регуляторов. Для среднего бизнеса такой подход становится золотой серединой — он дешевле полноценного коммерческого решения с дорогостоящими подписками или затрат на собственную команду. Более того, можно частично компенсировать нехватку внутренних ресурсов, подключая инженеров и мониторинг по формату услуги — это снижает нагрузку на бюджет. Крупный бизнес, напротив, предпочитает on-premise: утечка данных за периметр недопустима, а облачные интеграции часто становятся слабым звеном в защите. Такие компании могут позволить себе штатных специалистов, но даже им не стоит полагаться исключительно на возможности «из коробки».

Ключ к результативной защите — в гибком сочетании стандартных возможностей и кастомизации. Готовые Enterprise-решения обеспечивают базовый уровень безопасности, но без регулярного тестирования в боевых условиях и тонкой настройки правил под конкретную инфраструктуру они рискуют превратиться в «замок с бумажными стенами». Слоганы обещают абсолютную защиту, но реальность требует постоянной адаптации — только так можно быть уверенным, что система отражает не только вчерашние, но и завтрашние угрозы.

Резюмируем

Идеальных решений не существует — Enterprise-продукты часто требуют кастомизации. Open Source не заменяет коммерческие системы, но отлично дополняет их, закрывая «слепые зоны». Не стоит полагаться на «волшебную таблетку» — нужно брать контроль и ответственность в свои руки.