SIEM or not SIEM: that is the question

В нашу SIEM систему поступают данные из журналов различных систем безопасности, в том числе обнаружения/предотвращения вторжений и целевых атак, журналов контроллеров домена, прокси-серверов, firewall’ов и т.д. Стоит сказать, что чем больше данных вы будете собирать и обрабатывать, тем полнее будет картина, тем лучше и точнее вы сможете сопоставлять события и выявлять нарушения, а также строить прогнозы для своевременного изменения или корректировки правил обработки событий в SIEM.

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

Обычно драйвером проекта является желание автоматизировать ежедневную рутинную работу по разбору инцидентов, ускорить анализ огромного объема журналов событий, который необходимо пересматривать при расследовании инцидентов и для сбора доказательной базы. В результате внедрения SIEM сократится время обработки событий, и, как следствие, освободятся человеческие ресурсы.

Основной проблемой может стать отсутствие у заказчика опыта подключения к SIEM источников данных. Ситуацию усугубляет тот факт, что у производителей существуют свои подходы и инструменты для осуществления этой операции. Чтобы как следует разобраться в данном вопросе, нужно потратить много времени, но зачастую у компании нет на это свободных человеческих ресурсов, не хватает компетенций, знания особенностей SIEM. Отмечу, что делегировав задачу подключения источников интегратору и не поставив при этом четкого ТЗ, компания рискует получить на выходе посредственную реализацию.

В любом случае SIEM-система будет требовать постоянной поддержки и тюнинга. Это можно осуществлять собственными силами или прибегать к услугам аутсорсера – интегратора, имеющего большую компетенцию в данном вопросе. На мой взгляд, первый вариант более правильный – нужно уметь самостоятельно управлять системой и настраивать ее.

Во многом задачи и потребности в части SIEM в разных отраслях совпадают: всем интересна периметровая защита, никто не хочет проникновения злоумышленников в корпоративную сеть, утечки чувствительных данных и т.п. В то же время степень критичности и характер инцидентов однозначно отличаются, причем даже в компаниях одной отрасли – это целиком зависит от модели ведения бизнеса. Например, более «агрессивное» присутствие компании в сети Интернет (направленность на e-commerce) подразумевает большое внимание к ней со стороны сетевых злоумышленников, следовательно, некоторые типы угроз извне более актуальны. При этом нельзя сбрасывать со счетов и внутреннего нарушителя, особенно сотрудников, превышающих свои полномочия или использующих свое положение и информацию, которая им доступна, не по назначению.

SIEM – прекрасный инструмент для сопоставления и анализа событий, но ошибки при составлении правил и вообще человеческий фактор всегда имеют место. Нельзя слепо доверять тому, что было написано ранее: нужно всегда дополнять или пересматривать то, что есть – проверять, насколько корректно работают созданные вами правила. Так, отсутствие срабатываний ослабляет бдительность и вовсе не говорит о том, что ничего не происходит – вполне вероятно, что вы просто чего-то не видите. Избыточность срабатываний (в том числе ложных) при слишком чувствительных настройках также отвлекает, и вы перестаете реагировать на всплывающие предупреждения с должным вниманием, как следствие, можете пропускать что-то важное.

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

При этом стоит отметить, что SIEM-решение позволяет существенно экономить по мере роста компании, в основном затратно само внедрение, а последующая поддержка может быть оптимизирована.

В любом случае хороших ИБ-специалистов не так много, поэтому сотрудник, умеющий правильно обращаться с SIEM, – это пока «штучный товар». Конкретные профессиональные качества, необходимые сотрудникам, зависят от того, что вы от них ждете – разбора инцидентов от оператора 1-й линии или же построения правил и тюнинга системы от аналитика/архитектора и т.д. Но так или иначе эти специалисты должны быть легко обучаемы и открыты всему новому. Важными качествами являются незашоренность и наличие исследовательской жилки – желание постоянно совершенствовать свои навыки, приобретать новый опыт.

Многие эксперты говорят, что в чистом виде системы подобного класса перестанут существовать и преобразуются в нечто новое. Я полагаю, что будет симбиоз нескольких ИБ-решений – новая высокоуровневая система безопасности, включающая в себя все аспекты новых модных направлений. Она, наконец, сможет нормально «подружить» поиск и анализ уязвимостей и последующую проверку их эксплуатируемости в конкретном сегменте сети, а также будет включать защитные функции по необходимости и др. Все технологии уже есть в разных продуктах: осталось только реализовать эту концепцию в едином решении, скорее всего, в софт- верном. Важно, чтобы оно было удобным для интегрирования в существующую инфраструктуру компании и интуитивно понятным для управления и поддержки.

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

Речь идет не о прибыли, а, скорее, об оптимизации и снижении потерь – сохранении средств компании и экономии в перспективе. Монетизировать выгоду от использования SIEM или оценить эффективность системы для бизнеса сложно. Дело в том, что в подобной оценке будут фигурировать эфемерные определения: предотвращение событий с определенной долей вероятности, влекущих за собой тяжелые последствия для бизнеса – возможную остановку деятельности, потерю средств компании/клиентов, недоступность сервисов, а также репутационные потери.

Думаю, да, но он не всегда очевиден: опосредованно накопленные данные используются в расследованиях, а также при управлении инцидентами ИБ, и через это оказывается влияние на различные бизнес-процессы в плане их пересмотра – корректировки и оптимизации.