В среде западных экспертов активно идет дискуссия на тему "SIEM мертв". Но это не мешает продолжаться активному процессу слияний и поглощений на этом рынке. Сегодня сразу два монстра рынка ИБ - IBM и McAfee объявили о приобретении двух игроков рынка SIEM - Q1 Labs и NitroSecurity соответственно.
Детали первой сделки не разглашаются, но IBM вместе с покупкой Q1 Labs анонсировал и создание нового подразделение по ИБ - Security Systems Division, которое будет включать в себя все продукты (программные и аппаратные) и сервисы по ИБ, включая решения Tivoli, Rational, ISS ит.д. Посмотрим, что выйдет из этой сделки. Пока у IBM ничего путного с приобретениями по ИБ не выходило.Вторая сделка также покрыта завесой тайны в части финансовых условий.
В целом стоит заметить, что из "независимых" игроков на рынке SIEM осталось не так уж и много игроков - Splunk, netForensics, LogLogic и SenSage. netForensics почти "умер" и их уже серьезно не воспринимают - сдали они свои лидерские позиции. А вот остальные игроки очень интересны (в России почти не представлены, кроме Splunk).
Детали первой сделки не разглашаются, но IBM вместе с покупкой Q1 Labs анонсировал и создание нового подразделение по ИБ - Security Systems Division, которое будет включать в себя все продукты (программные и аппаратные) и сервисы по ИБ, включая решения Tivoli, Rational, ISS ит.д. Посмотрим, что выйдет из этой сделки. Пока у IBM ничего путного с приобретениями по ИБ не выходило.Вторая сделка также покрыта завесой тайны в части финансовых условий.
В целом стоит заметить, что из "независимых" игроков на рынке SIEM осталось не так уж и много игроков - Splunk, netForensics, LogLogic и SenSage. netForensics почти "умер" и их уже серьезно не воспринимают - сдали они свои лидерские позиции. А вот остальные игроки очень интересны (в России почти не представлены, кроме Splunk).
ты знаешь, IPS для баз данных - Guardium был неплохой покупкой и вроде не убили пока.
ОтветитьУдалитьПросто его пока не с кем интегрировать ;-)
ОтветитьУдалитьА что это Cisco ничего не покупает? MARSу-то кирдык настает как-никак...
ОтветитьУдалитьМы решили не распылять свои усилия и сконцентрироваться на ключевых компетенциях. Тем более, что направление SIEM считается умирающим среди экспертов.
ОтветитьУдалитьа что вместо него?
ОтветитьУдалить>Тем более, что направление SIEM считается умирающим среди экспертов.
ОтветитьУдалитьМожно мысль пояснить? Управление событиями и управление инцидентами больше не нуждаются в средствах автоматизации?
Или Prelude на западе так замордовал коммерческих производителей, что они решили закрывать направления? :)
SIEM - хорошая вещь. Несмотря на то, что это средство для автоматизации достаточно высокоуровневых процессов, его не так сложно внедрить, чтобы была полезная отдача + для него понятно строится процесс постоянного улучшения - т.е. через какое-то время действовать SIEM решение начинает очень эффективно...
А MARS все-таки жаль, что закрыли... Не идеальное решение, но и неплохое (хотя за отсутствие поддержки русского языка в собираемых логах повбывав бы - 21-й век на дворе, везде юникод).
Вместо MARS - http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/ns1090/landing_siem.html
ОтветитьУдалитьdoom: Проблема с любой SIEM-системой - правила корреляции. Кто будет их писать и поддерживать в актуальном состоянии? Чем больше источников SIEM поддерживает, тем сложнее держать базу правил в актуальном состоянии. А писать правила самостоятельно никто не хочет и не будет - слишком сложно. А без этого SIEM превращается просто в хранилище событий, не более.
ОтветитьУдалитьАлексей, почему-то многим кажется, что правила корреляции должны быть выданы здесь и сейчас и это целая научная работа их создать. А ведь все гораздо проще в реальности - если инциденты реально обрабатываются, то правила корреляции будут появляться и совершенствоваться сами собой. А если нет управления инцидентами - то даже с супер точными правилами корреляции от SIEM проку не будет.
ОтветитьУдалитьКуда хуже - правила нормализации. Если вендор не обновляет свои правила нормализации, то SIEM умрет сам собой. Но все основные вендоры более-менее оперативно обновления выпускают (снова припомню проблему с поддержкой русского языка в логах у марса :) ).
Пример: попала в базу Касперского новая сигнатура Trojan.Win32.Chifrax.a. А у AVAST это Win32:Trojan-gen (AVAST). Как их учесть? А вдруг они используют какую-то новую дыру с таким-то кодом CVE? Как это учесть? А ведь эта информация меняется ежедневно? Как писать правила?
ОтветитьУдалитьДа очень просто.
ОтветитьУдалитьНачнем с того, что это надо учитывать только тем организациям, которые используют Kaspersky и AVAST параллельно и у которых есть реальные инциденты заражения этим трояном - т.е. это уже будет происходить далеко не каждый день.
Далее. Имеем 2 инцидента (один от Kaserpsky, второй от Avast) - расследование быстро покажет, что в реальности инцидент один и тот же. Анализируем - видим, где проблема. Создаем правило. Да это рутина определенная - но это вполне подъемно. Более того, там где нет какого-то промышленного SIEM'а подобную же работу делают кустарными методами (пишутся различные скрипты и т.п.).
Кроме того, есть же еще быстро набирающая обороты тема Security Automation - SCAP'ы, OVAL'ы и прочее - т.е. движение к унификации тоже есть и очень активное (я недавно увидел, что DISA стали делать STIG'и в XCCDF).
Это надо учитывать вендору SIEM. В противном случае будет ситуация, когда SIEM не знает о новых атаках и дырах.
ОтветитьУдалитьЧто касается расследования, то это как раз то, чего нормальный SIEM позволяет избежать. Если я знаю, что у меня не Винда, а Linux, заданные узлы некритичные и данные сигнатуры у меня в базе, то я помечу правило как низкоприоритетное и мне не понадобится проводить расследование. Иначе на каждое событие не отреагируешь - ресурсов не хватит.
Ну а SCAPы и т.д. пока не сильно поддерживаются вендорами SIEM ;-( Они только присматриваются ко всем этим протоколам унификации наименований и обмена.
>Это надо учитывать вендору SIEM. В противном случае будет ситуация, когда SIEM не знает о новых атаках и дырах.
ОтветитьУдалитьНекоторые так и делают (не буду рекламировать уж). Но подобную задачу они решают на уровне нормализации (ведь приводить к общему знаменателю тоже можно с различной глубиной) и активно привлекают вендора средства защиты. Вот здесь, конечно, общий язык в лице семейства SCAP очень помог бы...
>Что касается расследования, то это как раз то, чего нормальный SIEM позволяет избежать.
Не соглашусь. Задача SIEM эффективно регистрировать (ну и иногда еще классифицировать и проиритезировать) инциденты ИБ с минимальным числом ошибок первого и второго рода. Если же инцидент оказался неактуальным - это просто ошибка второго рода - бывает :)
Так можно сказать, что и комплексные системы мониторинга невозможны - потому что порождают шибко много инцидентов ИТ, а задать взаимосвязи для сложного ИТ сервиса это невероятно сложная задача.
Да вообще для большой системы все сложно: и права актуальными поддерживать, и в политике МЭ не скатиться к permit any any...
Если нужно только регистрировать, то достаточно обычно syslog-коллектора ;-)
ОтветитьУдалитьsyslog регистрирует события, а не инциденты ;)
ОтветитьУдалитьПрисоединюсь к сожалению про MARS..
ОтветитьУдалитьОтличную систему от Protego Networks похоронили. Рановато.
Возможно, SIEMы сегодняшнего дня, лишь определенная ступень развития в данном направлении. Но для сетевиков MARS является "глазами и ушами", поскольку эффективно осуществляет экспертную обработку событий на сетевом уровне в контексте ИБ. По сути, используется для поддержания здоровья сетевой и вычислительной инфраструктуры, выявления и устранения проблем в ней.
Но, поскольку, проблемы на прикладном уровне начинают сказываться на сетевом, то у SIEMов начинаются свои проблемы при попытке корреляции событий с прикладным уровнем: на прикладном уровне больше разнообразия, конкуренции, нет стандартизации и на порядки больше возможных типов инцидентов. Все это поддерживать в актуальном состоянии затратно и невыгодно в текущей ситуации.
Отдельно стоит отметить негативное влияние конкуренции среди разработчиков ПО и сетевого оборудования. Они не хотят делиться форматами и типами событий, протоколов, интерфейсов, документов и т.п., надеясь получить конкурентное преимущество. О какой корреляции событий тут может потом идти речь?