Подводные камни бесплатной SIEM

Согласно исследованию State of Open Source Report, проведенному компанией OpenLogic, 96% опрошенных организаций используют решения с открытым исходным кодом. Решения open source (OSS) есть в любом сегменте ИТ-рынка, в том числе и среди средств для обеспечения информационной безопасности. Нередко их рекомендуют для построения систем SIEM.

При поверхностном анализе кажется, что это отличный выбор. Основная функция SIEM — систематизированный сбор и корреляция телеметрии, которые можно организовать на хорошо известных инструментах хранения и обработки данных. Собрали все данные через Logstash, прикрутили поиск Elasticsearch, построили нужные визуализации в Kibana — и готово! Три секунды поиска позволяют найти и готовые решения для SIEM (часто собранные на тех же компонентах) — от Wazuh до Security Onion. В SIEM всегда важно адаптировать сбор и обработку данных к реалиям организации — и собственная OSS-система предлагает для этого бесконечные возможности. Причем стоимость лицензии равна нулю. Но успех этого предприятия решающим образом зависит от состава команды разработчиков, особенностей организации и того, насколько долго она готова ждать результата и тратиться на поддержку в дальнейшем.

Время — деньги

Ключевой вопрос, важность которого постоянно недооценивается, — сколько времени пройдет, пока SIEM в компании не просто заработает, а начнет приносить пользу. По данным Gartner, даже готовую полнофункциональную SIEM полноценно внедряют в среднем полгода, а каждая десятая компания тратит на это год.

С собственной разработкой или адаптацией одной из OSS SIEM это время надо умножать на два-три (пессимистам — на десять), а для расчетов бюджета — умножать это время на стоимость разработчиков. При этом сложно представить себе, что полноценная SIEM-система будет поддерживаться талантливым одиночкой — компании придется содержать целую команду.

Опасной психологической ловушкой является быстрое появление прототипа. Развернуть в тестовой среде готовое OSS-решение можно за считаные дни, но вот его доводка до промышленной эксплуатации может занять многие месяцы и даже годы.

Дефицит навыков

В SIEM нужно собирать, индексировать и анализировать тысячи событий в секунду. Проектирование высоконагруженной системы или даже адаптация уже имеющейся системы требуют специфических, дефицитных навыков. Кроме собственно разработчиков, для проекта потребуются очень квалифицированные ИТ-администраторы, специалисты DevOps, аналитики и даже дизайнеры дэшбордов.

Другой род дефицита, который придется преодолевать строителям SIEM, — недостаток практического опыта для написания эффективных правил нормализации, корреляции и прочего контента, который в коммерческой SIEM будет готов «из коробки». Конечно, и этот «коробочный» контент потребует значительных доработок, но доводить его до нужного организации состояния и быстрее, и проще.

Регуляторное соответствие

Для многих компаний наличие системы SIEM является требованием регулятора. Чтобы достичь регуляторного соответствия тем, кто собирает SIEM самостоятельно или внедряет OSS-решение, придется приложить немало усилий. Проецировать возможности SIEM на регуляторные требования нужно будет самостоятельно, в отличие от коммерческих систем, которые часто имеют готовый алгоритм сертификации и все необходимые для этого инструменты.

Иногда у руководства компаний возникает желание внедрить SIEM для галочки, с минимальными затратами. Но поскольку требования PCI DSS, GDPR, да и приказа ФСТЭК № 239 описывают не само наличие SIEM, а определенную полноту реализации ее возможностей, такая символическая SIEM-система не позволит успешно пройти никакие аудиты.

О соответствии придется вспоминать не только при внедрении системы. Если в процессе самостоятельного сопровождения и эксплуатации какие-то из компонентов решения перестанут обновляться и достигнут статуса end-of-life, вероятность пройти ИБ-аудит резко упадет.

Свобода от вендора и зависимость от сотрудников

Вторым по важности мотивом выбора решений open source всегда были гибкость в адаптации решения к потребностям организации, а также отсутствие зависимости от производителя ПО и его решений по развитию и лицензированию продукта.

Оба аргумента очень серьезны, и в крупных организациях они иногда перевешивают другие факторы. Но выбор нужно делать, четко понимая его достоинства и недостатки:

• OSS SIEM легче приспособить к нестандартным источникам данных.
• OSS SIEM позволяет обеспечивать полный контроль над практиками хранения и обработки данных.
• Стоимость масштабирования OSS SIEM — это затраты на дополнительное оборудование и разработку нужных функций. При этом нет непрозрачно определенных цен за дополнительные рабочие станции, хранилища данных или другие учетные единицы, придуманные вендором коммерческой системы.
• И первоначальный запуск, и развитие OSS SIEM требуют зрелых специалистов, одновременно разбирающихся в практиках разработки и реалиях SOC. Если те, кто знал систему лучше всего и смог ее успешно внедрить, уходят из компании или меняют род работы, развитие системы может застопориться. Более того, она постепенно теряет работоспособность.
• Первоначальная стоимость внедрения OSS SIEM может быть ниже за счет отсутствия лицензионного платежа. Но на этапе сопровождения эта разница постепенно скрадывается за счет постоянных дополнительных затрат на квалифицированных сотрудников, занятых только развитием SIEM. На длинном временном отрезке общая стоимость владения OSS SIEM часто оказывается выше.

Качество контента

Актуальность контента для обнаружения и реагирования — ключевой фактор эффективности SIEM. Для коммерческих решений обновления корреляционных правил, плейбуков и данных об угрозах обычно поставляются в рамках подписки. Они разрабатываются большими командами исследователей, проходят подробное тестирование и, как правило, внедряются с небольшими трудозатратами со стороны ИБ-команды. Для OSS SIEM обновления приходится искать самостоятельно: в сообществах, на GitHub и в бесплатных фидах. Правила требуют подробной проверки и адаптации под конкретную инфраструктуру, риск ложных срабатываний выше. В результате внедрение обновлений в open-source-SIEM требует значительно больших усилий внутренней команды.

Слон в комнате — оборудование

Для запуска SIEM придется приобретать или арендовать оборудование, и в зависимости от архитектуры системы эта статья расходов может отличаться в разы. Здесь не столь важно, является ли система open source или это коммерческое закрытое решение. Тем не менее, самостоятельно внедряя OSS SIEM, выше шансы принять неоптимальное решение по архитектуре системы. В долгосрочном периоде это оборачивается постоянными эксплуатационными затратами.

Подробно вопрос об оценке аппаратных «аппетитов» SIEM мы рассматривали в отдельной статье.

Финальный счет

Хотя идея полностью настраиваемой и адаптируемой платформы с нулевой ценой лицензирования очень привлекательна, велики риски того, что этот проект займет значительно больше времени и сил у внутренней команды разработки, не позволит оперативно внедрять инновации и переключит внимание ИБ с вопросов разработки детектов и сценариев реагирования на чисто эксплуатационные вопросы. Поэтому управляемое, поддерживаемое большой командой экспертов и хорошо интегрированное коммерческое решение лучше сочетается с целями типичной организации по эффективному снижению риска и предсказуемому бюджетированию.

Коммерческие SIEM позволяют команде использовать готовые правила, плейбуки, парсеры телеметрии и сосредоточиться на специфических для организации проектах (будь то threat hunting или улучшение видимости в облачной инфраструктуре) вместо того, чтобы изобретать и дорабатывать базовую функциональность SIEM или пытаться пройти с ней регуляторный аудит.