Комментарии 46
Подскажите где можно почитать о примерах правил корреляции? О методике внедрения SIEM систем или это все КТ каждого интегратора? :)
Хорошая книга есть, правда, на английском, в ней еще и ведущие игроки SIEM описываются вкратце.
David R. Miller, Shon Harris, Stephen Vandyke, «Security Information and Event Management (SIEM) implementation», McGrawHill, 2011
На русском не подскажу…
+ можно почитать блог Чувакина chuvakin.blogspot.ru/
Если вас интересует конкретная реализация правил в конкретной системе — то это в админгайды лезть надо.
David R. Miller, Shon Harris, Stephen Vandyke, «Security Information and Event Management (SIEM) implementation», McGrawHill, 2011
На русском не подскажу…
+ можно почитать блог Чувакина chuvakin.blogspot.ru/
Если вас интересует конкретная реализация правил в конкретной системе — то это в админгайды лезть надо.
Недавно делал обработчик событий для HP 5500 HI Switch Series. Очень проблемно писать что-то самому — когда нету документов о форматах логов, о типах событий в них, о всевозможных комбинациях данных. Это я к тому, что в админгайдах ничего нет и правила пишутся в основном на основе опыта, чаще — своего(такими данными редко кто делится). А когда доходит дело до правил, то иногда встаешь в ступор:
-какие правила могут быть для свича? роутера?
-какие правила могут быть для DLP? Check Point IPS?
Можно создать уведомления на какие-либо события, но это не есть правила корреляции.
DLP и IPS это уже готовые системы, которые на основе своих алгоритмов и сигнатур выявляют угрозы. Как можно коррелировать уже выявленные угрозы?
Идеальной считаю систему, ни где много правил корреляции, а где правила могут устанавливать взаимосвязи с несколькими источниками событий. Vpn-сервер +network access control +антивирус +фаервол + терминальный сервер + SAP = и чтобы по одному клику можно было увидеть с какого внешнего IP и под какой учетной записью подключился пользователь к VPN, который отправил на печать отчет ХХХХХ.
-какие правила могут быть для свича? роутера?
-какие правила могут быть для DLP? Check Point IPS?
Можно создать уведомления на какие-либо события, но это не есть правила корреляции.
DLP и IPS это уже готовые системы, которые на основе своих алгоритмов и сигнатур выявляют угрозы. Как можно коррелировать уже выявленные угрозы?
Идеальной считаю систему, ни где много правил корреляции, а где правила могут устанавливать взаимосвязи с несколькими источниками событий. Vpn-сервер +network access control +антивирус +фаервол + терминальный сервер + SAP = и чтобы по одному клику можно было увидеть с какого внешнего IP и под какой учетной записью подключился пользователь к VPN, который отправил на печать отчет ХХХХХ.
Следует различать микро-корреляцию и макро-корреляцию. Первая сопоставляет несколько событий от одного источника, например ips регистрирует срабатывания нескольких различных сигнатур с одного и того же ip-адреса в течение, скажем, получаса. Можно написать правило, которое занесет этот ip в watchlist (например suspicious_hosts), потом всем остальным событиям с этим адресом в source или destination немного повышать уровень «тревожности», далее можно нафантазировать продолжение.
Макро-корреляция — как раз таки сопоставлени событий от разных источников, тут вообще полет фантазии ничем не ограничен. Например, представим, что у нас такой крутой футуристичный офис и в полах встроены датчики давления. Можно написать правило, которое сгенерирует письмо юзеру с темой «а ну-ка встань и проветрись, а то совсем заработался, %username%!», если он не встает с места более 6 часов подряд и постоянно фисируется активность работы разрешенных программ на компьютере.
Макро-корреляция — как раз таки сопоставлени событий от разных источников, тут вообще полет фантазии ничем не ограничен. Например, представим, что у нас такой крутой футуристичный офис и в полах встроены датчики давления. Можно написать правило, которое сгенерирует письмо юзеру с темой «а ну-ка встань и проветрись, а то совсем заработался, %username%!», если он не встает с места более 6 часов подряд и постоянно фисируется активность работы разрешенных программ на компьютере.
Мониторить состояние устройств/серверов/критически важных системПод это описание больше подходит Nagios\Zabbix и др. SIEM собирает и обрабатывает события из журналов системы. Думаю тут корректней будет использовать «Мониторинг событий»
Какой объем жесткого диска требуется для хранения данных?Мне в свое время понравилась статья, правда там тоже есть нюансы.
правило корреляции… они выглядят как регулярные выраженияНи разу не встречал правило корреляции в виде регулярного выражения. Можете назвать пример SIEM в которой правило корреляции выглядит как регулярное выражение? В моем понимание правило — это взаимосвязь нескольких событий, например: 10 попыток неудачно аутентификации за короткий промежуток времени, множественные события с одного IP адреса.
поддержку для источника… отправлять события как SYSLOGНу тут не все так просто. Часто, события передаваемые по SYSLOG сильно отличаются по структуре. Для примера: сервер ESXi, rhel, умный switch. Они все могут передавать события на сервер журналов, но для их обработки придется попотеть. Если для ArcSight это еще можно сделать без больших затрат, то для таких систем как TSIEM, SSIM разработка может занять значительные сроки.
Нужна ли какая-то поддержка SIEM… ИБ обновляться и добавлятьсяПравила, это такая вещь которую ни один интегратор не доведет до ума(мое мнение) и все равно придется на протяжение всей эксплуатации системы создавать новые правила\новые шаблоны отчетов.
У OSSIM, например, обработка сислога сделана достаточно неплохо. Понимает и линуксовые, и свитчи, и много чего еще.
Сислог — в первую очередь транспорт и формат заголовка (timestamp+hostname отправителя). Но не формат самих данных. Расположение полей, их назначение и содержимое сильно отличается в зависимости от того, кто шлет этот сислог, например лог событий FW сильно будет отличаться от лога Samba, Radius или почтового релея, при этом все они будут слать свои собития по сислогу. Поэтому в рамках темы SIEM нельзя просто сказать «поддерживается syslog!» Потому что первостепенная задача SIEM — структурирование данных, категорирование событий, приведение их к единому виду. Т.е. например фаервол одного вендора скажет в логе «deny», другой «discard», третий «drop», а SIEM должен категорировать все эти события в единый формат, например «Firewall/Access/Failure».
А вот по этой теме интересная статья есть! От Олеси Шелестовой — habrahabr.ru/company/pt/blog/171083/ Как раз данная проблема и затрагивается.
Но, под поддержкой SYSLOG подразумевалось именно
А разгребать все дальше — задача обработчика, встроенного в систему — все эти discard / drop
Но, под поддержкой SYSLOG подразумевалось именно
транспорт и формат заголовка (timestamp+hostname отправителя), т.е.поддержка сислога как протокола. Сислог, в первую очередь, все же протокол, и описан в RFC 5424, tools.ietf.org/html/rfc5424 — и у него есть общие поля.
А разгребать все дальше — задача обработчика, встроенного в систему — все эти discard / drop
Думаю тут корректней будет использовать «Мониторинг событий»
Вы правы, так корректней будет. Поправил.
Можете назвать пример SIEM в которой правило корреляции выглядит как регулярное выражение? В моем понимание правило — это взаимосвязь нескольких событий, например: 10 попыток неудачно аутентификации за короткий промежуток времени, множественные события с одного IP адреса.
IBM Q1 Labs QRadar, например, может использовать в правилах регекспы. Правило может быть как собственно включать один регексп (выборку по чему-либо), так и как вы описали. Хотя, я согласен — не очень удачно у меня написано, поправлю. В любом случае, с использованием визуальных конструкторов правил (я имею ввиду, когда у вас происходит некий диалог с системой) использование регулярок сведено до минимума.
Если для ArcSight это еще можно сделать без больших затрат, то для таких систем как TSIEM, SSIM разработка может занять значительные сроки.
Вы правы, но всегда можно найти найти вендора, SIEM которого будет поддерживать нужное оборудование. Например, крупные организации используют, в общем-то, одно и то же оборудование, поддержка событий которых уже встроена в систему «из коробки». Пример — тот же QRadar. На крайний случай, можно принять сырой поток (RAW) и обработать его, причем сделать это самостоятельно — с тем же QRadar`ом идет неплохая дока, по которой написать обработчик сможет даже человек, далекий от программирования. Да собственно, там и программированием это сложно назвать.
Правила, это такая вещь которую ни один интегратор не доведет до ума(мое мнение) и все равно придется на протяжение всей эксплуатации системы создавать новые правила\новые шаблоны отчетов.
Согласен с вами на все сто. Я это самое и имел ввиду, когда писал кусок про поддержку. Только тут вопрос в том — кто ее будет осуществлять. Интегратор — по запросу от заказчика либо сам заказчик.
Имел горе работать с TSIEM, QRadar боюсь даже пробовать(оба SIEM принадлежат IBM). Хотя я и понимаю, что они его целиком выкупили.
QRadar не стоит бояться, отличный продукт, довольно легок в освоении (для системы класса SIEM, конечно). Порог вхождения в тот же ArcSight гораздо выше, например.
McAfee еще можно попробовать, он в плане работы легче ArcSight / QRadar, но у него есть ряд недостатков в плане внедрения, на мой взгляд, у IBM тут более продумано все.
Расскажи про недостатки McAfee SIEM, мне интересно, не приходилось пока с ним работать.
Ну это не совсем недостатки, скорее, особенности, несколько усложняющие жизнь при определении нужных компонентов и последующую их инсталляцию. Это могут быть как железные, так и VirtualAppliаnce — центральный модуль, «приемники» и прочие системы, все это добро выпускается в куче комбинаций (например, т.н. отдельно стоящие компоненты / Combo — когда в одной оболочке несколько компонентов), отсюда несколько запутанная система лицензирования. Ко всему этому надо прибавить иной раз достаточно значительные вмешательства в сетевую инфраструктуру. Плюс — очень гибкая система, позволяющая, по идее, не платить за ненужные модули (зато вы заплатите за работу по интеграции этих модулей, так что неизвестно, будет ли выгода...). Минус, как ни странно, вытекает из этой гибкости сборки — довольно сложно масштабировать с сохранением единого «головного» модуля, где будет информация о всех значимых инцидентах (например, QRadar я могу развернуть таким образом, что на центральный модуль нагрузка по обработке будет минимальной, но в то же время, я, находясь в центральном офисе, смогу просмотреть все инциденты из одной консоли — для географически распределенных филиалов).
Но вот после внедрения, McAfee, наверное, одна из самых простых и эффективных в работе SIEM (за счет того, что он достаточно глубоко может внедряться в инфраструктуру). Но это уже мое мнение.
Так, чтобы подробно рассказать о McAfee — это, скорее, тема отдельной статьи.
Но вот после внедрения, McAfee, наверное, одна из самых простых и эффективных в работе SIEM (за счет того, что он достаточно глубоко может внедряться в инфраструктуру). Но это уже мое мнение.
Так, чтобы подробно рассказать о McAfee — это, скорее, тема отдельной статьи.
Понятно. У QRadar'а, кстати, тоже много вариантов appliance'ов, с первой попытки не разберешься.
А в чем выражается «глубоко может внедряться в инфраструктуру»? В чем глубина-то?
А в чем выражается «глубоко может внедряться в инфраструктуру»? В чем глубина-то?
У QRadar`a да, но там, в общем, все проще в плане того, что модулей меньше — нет обязательного раскидывания по функциональным особенностям. У McAfee же там несколько вариантов центрального модуля, несколько вариантов приемников, приемники обязательно должны стоять отдельно в тех местах, где планируется обработка информации, но и тут есть исключения + все усугубляется некой разобщенностью документации, трудно найти нужную информацию. Приемник — это может быть блейд способный работать на L2, т.е. мы в критических местах внедряем эти приемники, возможно, с другими продуктами макафи — такие как Email Gateway, DLP и т.д., за счет чего получаем что-то большее и выходящее за рамки понятия SIEM — т.е. мы уже можем влиять на трафик, блочить и пропускать email и т.д. В общем, если разобраться досконально, то наверное, выяснится, что там ничего особенного сложного то и нет, но у меня еще возможности не было очень глубоко изучить. Основная прелесть — в том, что всем этим добром можно управлять из еРО.
Я McAfee SIEM в данный момент занимаюсь, так что, возможно, что-то излишне субъективно написано, либо не совсем точно ввиду того, что не совсем до конца все возможности изучил.
Я McAfee SIEM в данный момент занимаюсь, так что, возможно, что-то излишне субъективно написано, либо не совсем точно ввиду того, что не совсем до конца все возможности изучил.
Да мне тоже предстоит протестировать их SIEM в ближайшее время, понять, стоит ли с ним работать, предлагать заказчикам.
Твоя информация мне очень пригодится, спасибо.
Твоя информация мне очень пригодится, спасибо.
пару слов добавлю:
McAfee ESM — название их SIEM — очень круто, если есть другие продукты МакАфи:)
Без них это довольно обычный SIEM, у которого есть доп. навороты — анализатор трафика и мониторинг СУБД.
Анализатор трафика — это железка, которая по SPAN мониторит трафик и разбирает его на составляющие — тут письмо, тут картинку в фейсбук запостили, тут по RDP приконнектились. СУБД — отслеживаются транзакции, доступы и т.д.
Лично мне не показалось, что есть какие то сложности, модули довольно стандартные — менеджер, ресивер для событий и лог-менеджер для сырых логов. Также есть их комбинации — менеджер+ресивер, ресивер+лог-менеджер и все в одном.
Расчет не такой уж и сложный, главное определиться, сколько событий ловим и где территориально ловим.
Также знаком с QRadar, не скажу, что сильно отличается по функционалу.
Очень ИМХО — МакАфи быстрее, и интерфейс, и отчеты. Также МакАфи заявляют о дикой производительности топовых железок, но чего не видел, того не видел…
Кстати, есть еще такая штука как Splunk — вот это где рай для линуксоида :) Мне нравилось когда-то им заниматься :) Очень много возможностей по кастомизации, но это одновременно и минус, так что…
McAfee ESM — название их SIEM — очень круто, если есть другие продукты МакАфи:)
Без них это довольно обычный SIEM, у которого есть доп. навороты — анализатор трафика и мониторинг СУБД.
Анализатор трафика — это железка, которая по SPAN мониторит трафик и разбирает его на составляющие — тут письмо, тут картинку в фейсбук запостили, тут по RDP приконнектились. СУБД — отслеживаются транзакции, доступы и т.д.
Лично мне не показалось, что есть какие то сложности, модули довольно стандартные — менеджер, ресивер для событий и лог-менеджер для сырых логов. Также есть их комбинации — менеджер+ресивер, ресивер+лог-менеджер и все в одном.
Расчет не такой уж и сложный, главное определиться, сколько событий ловим и где территориально ловим.
Также знаком с QRadar, не скажу, что сильно отличается по функционалу.
Очень ИМХО — МакАфи быстрее, и интерфейс, и отчеты. Также МакАфи заявляют о дикой производительности топовых железок, но чего не видел, того не видел…
Кстати, есть еще такая штука как Splunk — вот это где рай для линуксоида :) Мне нравилось когда-то им заниматься :) Очень много возможностей по кастомизации, но это одновременно и минус, так что…
Splunk довольно трудно назвать SIEM'ом, это в первую очередь лог-менеджмент, причем с приоритетом на неструктурированные данные. SIEM же работает исключительно со структурированными. Скажем, если сравнивать с ArcSight, то не с ArcSight ESM, а с ArcSight Logger. Ну или QRadar Log Manager.
По функционалу да, не сильно отличается, я бы даже сказал — полностью собранная версия McAfee вообще ничем, по большему счету, не отличается — кроме масштабируемости, поправьте, если не прав.
Основной плюс McAfee — это все же более понятный интерфейс + большие возможности при, как вы раньше упомянули, наличии прочих продуктов макафи.
Но интерфейс, все же, понятие очень субъективное. Хотя, насчет скорости — это не субъективно, макафи быстрее QRadar`а. Что, впрочем, неудивительно, если учесть, что последний написан на Java.
Основной плюс McAfee — это все же более понятный интерфейс + большие возможности при, как вы раньше упомянули, наличии прочих продуктов макафи.
Но интерфейс, все же, понятие очень субъективное. Хотя, насчет скорости — это не субъективно, макафи быстрее QRadar`а. Что, впрочем, неудивительно, если учесть, что последний написан на Java.
Спасибо автору за статью.
Хотелось бы задать следующий вопрос: с какими еще системами SIEM, помимо вышеупомянутых, удалось познакомиться? Какие понравились, какие можете выделить?
И с какой стороны происходит знакомство с системами SIEM: со стороны Заказчика, администратора SIEM, Исполнителя, другое..?
Хотелось бы задать следующий вопрос: с какими еще системами SIEM, помимо вышеупомянутых, удалось познакомиться? Какие понравились, какие можете выделить?
И с какой стороны происходит знакомство с системами SIEM: со стороны Заказчика, администратора SIEM, Исполнителя, другое..?
В основном QRadar (проходил обучение), OSSIM, McAfee SIEM сейчас активно изучаю, ArcSight поверхностно. Знакомство происходит со стороны интегратора, то есть, получается, исполнителя — есть вендоры, с которыми мы работаем, соответственно, есть возможность получить продукт, ознакомиться с актуальной документацией, иногда удается сходить на какие-то курсы.
На данный момент QRadar понравился в плане относительной простоты развертывания, хотя для полноценной работы там приходится вникать, McAfee — удобство работы, но это уже, скорее, для конечного заказчика более актуально.
На данный момент QRadar понравился в плане относительной простоты развертывания, хотя для полноценной работы там приходится вникать, McAfee — удобство работы, но это уже, скорее, для конечного заказчика более актуально.
У меня есть некоторый опыт общения с SIEM других вендоров. Так вот этого небольшого опыта достаточно, чтобы сделать вывод о сложности и индивидуальности каждой системы. В общем и целом, они решают одну задачу, но в реализации, в деталях, очень разные. Соответственно, периодически посещает мысль создания общего сравнения всех решений в одном месте. Как уже говорил ранее, сложность каждого решения не позволит это сделать быстро и качественно. Не возникало подобных желаний?
Тут хотя бы с критериями сравнения определиться… У каждого вендора найдется документик с перечнем того, где они крутые, а остальные — нет.
Все правильно: определить критерии, заполнить их для разных решений.
С определением критериев как раз большая беда. Слишком общие критерии (eps, количество поддерживаемых источников, количество отчетов, предустановленных правил и т.п.) практически не дают никакого понятия о том, чем же они отличаются в процессе интеграции и повседневной работе с ними. А по миллиону других параметров системы не пересекаются. Дьявол — в деталях.
Есть вот такой вот отчет гартнера, например, можно составить некое впечатление:
www.peeep.us/1e0b522d
Есть вот такой вот отчет гартнера, например, можно составить некое впечатление:
www.peeep.us/1e0b522d
Сравнение — это гиблое дело, на мой взгляд, все надо от окружения смотреть. Если у заказчика кругом продукты макафи — зачем я ему буду предлагать арксайт? Это все очень синтетически будет, в реальных условиях я соберу информацию об инфраструктуре и потребностях, и предложу то, что встанет с наименьшими трудозатратами. SIEM — это не антивирус, у которого хотя бы общие критерии можно выделить.
дык о том и речь.
Но таких ситуаций («у заказчика кругом макафи») не так уж и много, поэтому всегда требуется некое сравнение. Лучше всего, по моему мнению, это делается в рамках небольших пилотных проектов на кусочке реальной инфраструктуры. Поставили, подключили пять-шесть источников, поигрались с системой, реализовали три-четыре интересных use-case'а. Проделав это на двух-трех решениях сразу становиться понятно, какое имено решение лучше ложится на конкретную инфраструктуру.
Но таких ситуаций («у заказчика кругом макафи») не так уж и много, поэтому всегда требуется некое сравнение. Лучше всего, по моему мнению, это делается в рамках небольших пилотных проектов на кусочке реальной инфраструктуры. Поставили, подключили пять-шесть источников, поигрались с системой, реализовали три-четыре интересных use-case'а. Проделав это на двух-трех решениях сразу становиться понятно, какое имено решение лучше ложится на конкретную инфраструктуру.
В отчет Гартнера пока не вникал, почитаю в ближайшее время.
Можно начать с общих критериев, указать кол-во eps, указать кол-во отчетов, как хранятся события, где хранятся инциденты, потом описать, как лицензируется продукт, как масштабируется… и т.д.
Начать можно с малого, а потом развить тему.
Можно начать с общих критериев, указать кол-во eps, указать кол-во отчетов, как хранятся события, где хранятся инциденты, потом описать, как лицензируется продукт, как масштабируется… и т.д.
Начать можно с малого, а потом развить тему.
del продублировалось
Спасибо за статью, коллега. Плюс поставить не могу, отмечаю благодарность словами.
Правда присоединяюсь к недоумению по поводу
Правда присоединяюсь к недоумению по поводу
правило корреляции… они выглядят как регулярные выраженияесли уж и подыскивать аналогии, то это скорее SQL-запрос, но уж никак не регулярка :) Да и то, скорее триггер, чем просто запрос.
Спасибо. Да, с правилами не очень ясно написал, видать, мысль опередила пальцы, поправлю. Имелось ввиду, что в правиле может быть регулярное выражение.
А можно пример такого «SQL» запроса с описанием, что делает в данном конкретном случае?
Пример одного из встроенных правил ArcSight:
Protocol_Deny: ( ( Category Behavior = /Access OR Category Behavior = /Access/Start ) AND NotInActiveList(«Trusted List») AND ( NotInActiveList(«Reconnaissance List») OR NotInActiveList(«Scanned List») ) AND Category Device Group = /Firewall AND Category Outcome = /Failure )
Описание:
Protocol_Deny: ( ( Category Behavior = /Access OR Category Behavior = /Access/Start ) AND NotInActiveList(«Trusted List») AND ( NotInActiveList(«Reconnaissance List») OR NotInActiveList(«Scanned List») ) AND Category Device Group = /Firewall AND Category Outcome = /Failure )
Описание:
This rule looks for application protocol scans. The rule monitors failure access detected by a firewall. The rule fires when 3 events occur in 3 minutes with the same attacker/target pair with different application protocols each time. On first threshold, the attacker address is added to the /Reconnaissance active list and the target address is added to the /Scanned active list.
Спасибо за статью, все понятно описано и разложено по полочкам.
Хотелось бы добавить, что в составе SIEM иногда имеются графические утилиты для тестирования разрабатываемых регулярных выражений.
В частности, у ArcSight ESM эта утилита так и называется — regex.
В частности, у ArcSight ESM эта утилита так и называется — regex.
Более того, без этой утилиты делать флекс для арксайта довольно-таки непросто, потому что синтаксис регулярок особый.
Вы действительно ей пользуетесь при разработке flex?
Я пытался начать с ней работать, но как то не сложилось.
Я пытался начать с ней работать, но как то не сложилось.
Ну не в голом же блокноте. Я с ее помощью пишу флекс от получаса до трех-четырех часов, в зависимости от того, насколько сильно «заморочен» лог (насколько отличаются между собой разные строки, сколько токенов надо выделить, нужны ли submessage и т.п.).
Тулза хороша тем, что можно загонять в нее большой кусок лога (тысячи строк) для теста готовой регулярки и разбивки на токены. Также она сама генерит конфиг, при тестировании на куске лога сразу показывает в отдельном окошке значения токенов и все в таком духе. Не вижу смысла отказывать себе в таком удобном инструменте. Это не «магическая штука», которая сама все сделает (такая есть у RSA, кстати), это просто удобная микро-ide для флексов.
Тулза хороша тем, что можно загонять в нее большой кусок лога (тысячи строк) для теста готовой регулярки и разбивки на токены. Также она сама генерит конфиг, при тестировании на куске лога сразу показывает в отдельном окошке значения токенов и все в таком духе. Не вижу смысла отказывать себе в таком удобном инструменте. Это не «магическая штука», которая сама все сделает (такая есть у RSA, кстати), это просто удобная микро-ide для флексов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SIEM: ответы на часто задаваемые вопросы