SIEM против закона Мёрфи

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

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

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

Да, в принципе объекты мониторинга можно разделить на классические и специфические. Первые «отрасленезависимы», обычно это инфраструктурные элементы – межсетевые экраны, службы каталогов, файловые ресурсы, базы данных, шлюзы безопасности прикладного уровня, веб-серверы и т. д. Соответственно, они подразумевают штатные коннекторы. Другое дело – специфические объекты, в телекомах это биллинговые системы, в банках – АБС, в инвестиционно-банковском секторе – системы управления позициями, рисками, заявками. Для них коннекторы нужно разрабатывать самостоятельно или с помощью интеграторов.

Любой инцидент – это всегда форс-мажор, его критичность зависит от того, какое воздействие он оказывает на бизнес компании. Соответственно, сложно оценить, насколько серьезность инцидента в финансовой сфере отличается от таковой в ритейле, например. И там, и там потери потенциально могут исчисляться миллионами.

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

Формат логов, их размер, общий объем, какую нагрузку он даст на хранилище данных, сможет ли движок SIEM-системы в принципе его обработать. И самое главное – нужно четко понимать, как интерпретировать и использовать полученный массив данных. Собрать – это лишь часть процесса, система должна «переварить» информацию и понять, что действительно важно – что является просто event’ом, а что – инцидентом. То есть необходимо установить нормативные показатели, а затем контролировать их корреляцию с общей ситуацией.

Допустим, происходит одно событие – атака на устройство – с критичностью 9, и для тебя это не форс-мажор. Но вторая подобная активность за короткий промежуток времени уже настораживает. Понятно, что это не script kiddie, когда забрасывают шар, не «попадают» и решают не связываться. Налицо планомерная атака на устройство, идут систематические попытки подбора. Это критерий, который поднимает тебе флажок. Или наоборот – то, что раньше считалось риском, сегодня уже таковым не является. ИТ-инфраструктура ежедневно «дышит», и SIEM-система по отношению к ней выполняет роль своеобразного стетоскопа. Другое дело, что этим прибором нужно уметь правильно пользоваться – необходимы квалифицированные кадры.

Термину SIEM уже больше 10 лет, логично предположить, что с каждым годом таких экспертов становится все больше. Но при этом важно понимать, о каких именно специалистах идет речь – об операторах, аналитиках, архитекторах-администраторах. С первыми проблем нет вообще – курсы «молодых бойцов» вкупе с жизненным опытом, и ты уже можешь на среднем уровне реагировать на события. А вот архитекторы-администраторы – люди действительно уникальные, гуру в своей области. Достаточно одного звонка такому эксперту, чтобы определить, например, почему система повела себя крайне странно.

Сейчас мы уходим от идеологии классических SIEM, они становятся чем-то большим, чем просто системы сбора, корреляции и анализа событий. Современное решение – next generation SIEM – должно обязательно включать большое количество дополнительных модулей: Data Warehouse Security, Big Data Security, инцидент-, фрод-менеджмент и т. д.

Эти модули обрабатывают огромные объемы данных, анализируют, моделируют ситуации, в результате формируется максимально полная модель угроз. Сегодня пользователи хотят работать в едином окне, и производители, естественно, поддерживают это стремление к консолидации.

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

Тенденция перехода от SIEM внутри компаний к SOC. Многие крупные российские компании либо серьезно рассматривают этот вопрос и уже проектируют, строят собственные центры, либо используют услуги аутсорсеров.

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

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

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