[Информационная безопасность] Как мы внедрили вторую SIEM в центре мониторинга и реагирования на кибератаки
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Одна голова хорошо, а две – некрасиво… Так мы думали, пока жили в чудное время, когда в нашем центре мониторинга и реагирования на кибератаки была одна-единственная SIEM-платформа. Не секрет, что это была HP ArcSight, оказавшаяся единственным финишером длительного марафона через тернии требований, хотелок и амбициозных планов построения сердца SOC.
И вроде бы ничто не предвещало беды, но в какой-то момент появились и стали все более настойчивыми мысли о необходимости работы с альтернативной платформой. И основным локомотивом тут выступило активное развитие центров ГосСОПКА. Для того чтобы стать одним из подобных центров, нам необходимо было использовать ПО, которое обеспечено «гарантийной и технической поддержкой российскими организациями, не находящимися под прямым или косвенным контролем иностранных физических лиц и (или) юридических лиц» (Приказ ФСБ от 06.05.2019 № 196, п.3.4). Как мы страдали все это пережили и что в итоге получилось, рассказываем ниже.
Кадр из мультсериала «Котопёс»
Мы слышали, что есть SOC’и, которые исповедуют многоженство многовендорность и говорят (а этот вид деятельности, как мы помним, сильно отличается от мешочноразгрузочных работ), что готовы работать с любым распространенным на рынке SIEM-решением. Почему невозможно реализовать такой подход качественно, вы поймете из описания ниже. Мы же настолько привязались к ArcSight и успели выстроить вокруг него целую экосистему решений и процессов, что встраивание в нее чужеродной SIEM стало настоящим вызовом и поставило перед нами ряд сложных вопросов:
1) Какое решение выбрать?
2) Как интегрировать новую SIEM-систему в работу TIER1?
3) Как всё то множество внутренних интеграций, которые на данный момент есть с ArcSight, перенести на новую платформу?
4) Как синхронизировать идеологию развития контента SIEM и обеспечить симметричные наборы правил детектирования?
Выбор решения был не самой простой задачей. Везде нужно было нырять в омут, глубину которого оценить нам было нечем. В результате мы решили сделать выбор другим способом – использовать SIEM от вендора, который пообещал нам высокий приоритет доработок по нашим требованиям и в чьи обещания мы поверили. Таким образом родилось технологическое партнерство с Positive Technologies и в воронке наших SIEM’ов появился MaxPatrol SIEM.
Ок, у нас есть новая платформа. Но кто с ней будет работать?
Если честно, то поначалу у нас было ощущение, что нам не обойтись без второй команды, параллельно работающей с новым инструментарием. Это ощущение подкреплялось тем, что даже старшим линиям аналитиков, участвовавших в тестировании второй SIEM, было непросто ее принять. Поэтому вначале рисовалась концепция следующая: две линии TIER1, заточенные каждая на свой инструмент, и мультиплатформенная TIER2. С фактором готовности к мультиплатформенности как фактором роста специалиста из T1 в T2.
Как раз примерно в это время мы накопили достаточно причин для сплита нашей 1-ой линии на TIER1 и TIER2 (об этом подробнее в другой серии статей). И уж поскольку в изначальной концепции T2 должна работать с обеими платформами, мы завернули все инциденты MP SIEM на 2-ую линию, сформированную из самых опытных бойцов 1-ой и прошедших погружение в работу с новой SIEM. Забегая вперед, скажу, что инженеры 2-ой линии восприняли MP SIEM более позитивно, нежели их старшие коллеги-аналитики – это дало нам надежду, что платформу можно будет приземлить полноценно и на 1-ую линию, а не городить несколько специализированных.
Вопрос интеграции в единую экосистему также прошел не так болезненно, как мы ожидали – возможно, помогло то, что в разрабатываемые интеграционные механизмы изначально закладывались гибкость и конфигурационная избыточность. Особо великих побед, чем бы хотелось похвалиться, не было. Мы достаточно быстро вписали новую систему в экосистему и процессы расследования и сейчас обработка инцидентов с различных SIEM отличается для ребят только интерфейсом самих SIEM. Все механизмы маршрутизации и приоритизации, вся облегчающая принятие решения обогащающая информация, все шаблоны уведомлений идентичны и находятся в тех же самых привычных местах.
А как быть с контентом?
На «пустой» SIEM без контента (правил корреляции событий ИБ и выявления инцидентов) далеко не уедешь и много угроз не выявишь (коробочный контент мы не используем), поэтому остро возникла задача оперативной разработки правил корреляции на новой платформе для уже существующих сценариев JSOC. Вначале решили обойтись малой кровью и перенести правила из ArcSight с копированием логики реализации, но это оказалось ошибкой, на которой мы серьезно обожглись: совершенно другая архитектура продукта требовала «своего» подхода к разработке. Пришлось этот подход сформировать, причем в ускоренном темпе. Очень помогло тесное взаимодействие с вендором, который консультировал по возникающим вопросам, брал в реализацию наши запросы на доработку существующих и создание новых фишек в функционале. Обратная сторона медали – нам регулярно приходилось переписывать контент для его корректной работы на этом самом новом функционале. Но, как говорится, change or die, так что мы не жаловались (ну разве что внутри команды за бокалом чая).
На начальном этапе разработкой контента для новой SIEM занимались только опытные аналитики 4-ой линии, которые собаку съели на работе с ArcSight. Что любопытно – у некоторых ребят к тому времени уже произошла профдеформация и сформировалась «зависимость» от конкретной SIEM с её высоким уровнем зрелости. Переключиться на новую платформу для них было сложно как психологически, так и технически. Позднее банда разработки была значительно расширена новыми участниками, в т.ч. ребятами из 3-ей линии, и как раз у них эта тема взлетела гораздо проще и часто даже продуктивнее.
Несмотря на сквозной для обеих SIEM перечень сценариев, их реализация может серьезно отличаться, в основном из-за ограничений в архитектуре и функциональности разных платформ. Например, в ArcSight в правиле корреляции нельзя задать проверку наличия записи в активном листе по нестрогому соответствию, а в MP SIEM с недавних пор можно. С другой стороны, MP SIEM не генерирует внутренних событий на добавление или удаление записи из табличного списка, а ArcSight умеет это делать, и в ряде сценариев эта возможность используется. Пришлось жить с раздвоением личности вводить «двухсиемность» в нашей базе знаний по сценариям JSOC и описывать нюансы реализации, а также свой инструментарий расследования для каждой из платформ.
При этом очень важно было донести до 1-ой линии, что логика расследования инцидентов не зависит от того, на какой SIEM они сгенерированы, и что новая SIEM – это новый инструмент для решения всё тех же задач. У него есть свои особенности, которые обязательно нужно изучить, но кардинально ничего не меняется.
И работа на 1-ой линии закипела
Погружение TIER1 в работу с MP SIEM проходило постепенно и по процессу, отлаженному при вводе в строй новых сотрудников. Были определены критерии инцидентов, которые не очень страшно отдать в разбор 1-ой линии, еще не имеющей большого опыта с MP SIEM:
— низкокритичные реквизиты инцидента (некатегоризированные хосты/сети и учетные записи);
— длинные SLA-тайминги;
— низкая трудоемкость инцидента (мы же накопили статистику при обработке инцидентов на TIER2);
— не очень зубодробительные корреляционные правила (да-да, 1-ой линии туда необходимо заглядывать).
Сценарии в соответствии с этими критериями были разбиты на несколько этапов и по очереди переданы инженерам TIER1 – после сдачи «зачетов» и получения доступа к решению пула инцидентов.
В результате мы имеем в своем портфеле инструментов две SIEM, на которых запущены абсолютно идентичные по сути и логике обработки сценарии.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Реверс-инжиниринг] Укрощение Горыныча 2, или Символьное исполнение в Ghidra
- [Информационная безопасность, Видеотехника, Мультикоптеры] Почему к домашней летающей камере от Ring нужно отнестись крайне скептически (перевод)
- [Информационная безопасность] Как не выбрасывать свой голос в урну? Надежное голосование — используем банковские технологии
- [IT-инфраструктура, Информационная безопасность, Исследования и прогнозы в IT] «Ростелеком-Солар»: 90% IT-систем российских госструктур могут взломать киберхулиганы
- [Информационная безопасность, IT-инфраструктура, Сетевые технологии] 1. UserGate Getting Started. Введение
- [Информационная безопасность, Системное администрирование, Сетевые технологии] 1. Обучение пользователей основам ИБ. Борьба с фишингом
- [Информационная безопасность, Программирование, C++, ООП] C++: Коварство и Любовь, или Да что вообще может пойти не так? (перевод)
- [Информационная безопасность] Сертифицированные VS. несертифицированные средства защиты информации: требования регулятора или реальная необходимость?
- [Информационная безопасность, IT-инфраструктура] Как мы проводили аудит Корпоративной Почты Mail.ru — нашего нового сервиса для крупного бизнеса
- [Информационная безопасность, IT-инфраструктура, Законодательство в IT] Рассказываем про государственные защищенные сервисы и сети
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_soc, #_siem, #_tier1, #_tier_2, #_tier3, #_tier_iv, #_maxpatrol, #_arcsight, #_blog_kompanii_rostelekomsolar (
Блог компании Ростелеком-Солар
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:54
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Одна голова хорошо, а две – некрасиво… Так мы думали, пока жили в чудное время, когда в нашем центре мониторинга и реагирования на кибератаки была одна-единственная SIEM-платформа. Не секрет, что это была HP ArcSight, оказавшаяся единственным финишером длительного марафона через тернии требований, хотелок и амбициозных планов построения сердца SOC. И вроде бы ничто не предвещало беды, но в какой-то момент появились и стали все более настойчивыми мысли о необходимости работы с альтернативной платформой. И основным локомотивом тут выступило активное развитие центров ГосСОПКА. Для того чтобы стать одним из подобных центров, нам необходимо было использовать ПО, которое обеспечено «гарантийной и технической поддержкой российскими организациями, не находящимися под прямым или косвенным контролем иностранных физических лиц и (или) юридических лиц» (Приказ ФСБ от 06.05.2019 № 196, п.3.4). Как мы страдали все это пережили и что в итоге получилось, рассказываем ниже.  Кадр из мультсериала «Котопёс» Мы слышали, что есть SOC’и, которые исповедуют многоженство многовендорность и говорят (а этот вид деятельности, как мы помним, сильно отличается от мешочноразгрузочных работ), что готовы работать с любым распространенным на рынке SIEM-решением. Почему невозможно реализовать такой подход качественно, вы поймете из описания ниже. Мы же настолько привязались к ArcSight и успели выстроить вокруг него целую экосистему решений и процессов, что встраивание в нее чужеродной SIEM стало настоящим вызовом и поставило перед нами ряд сложных вопросов: 1) Какое решение выбрать? 2) Как интегрировать новую SIEM-систему в работу TIER1? 3) Как всё то множество внутренних интеграций, которые на данный момент есть с ArcSight, перенести на новую платформу? 4) Как синхронизировать идеологию развития контента SIEM и обеспечить симметричные наборы правил детектирования? Выбор решения был не самой простой задачей. Везде нужно было нырять в омут, глубину которого оценить нам было нечем. В результате мы решили сделать выбор другим способом – использовать SIEM от вендора, который пообещал нам высокий приоритет доработок по нашим требованиям и в чьи обещания мы поверили. Таким образом родилось технологическое партнерство с Positive Technologies и в воронке наших SIEM’ов появился MaxPatrol SIEM. Ок, у нас есть новая платформа. Но кто с ней будет работать? Если честно, то поначалу у нас было ощущение, что нам не обойтись без второй команды, параллельно работающей с новым инструментарием. Это ощущение подкреплялось тем, что даже старшим линиям аналитиков, участвовавших в тестировании второй SIEM, было непросто ее принять. Поэтому вначале рисовалась концепция следующая: две линии TIER1, заточенные каждая на свой инструмент, и мультиплатформенная TIER2. С фактором готовности к мультиплатформенности как фактором роста специалиста из T1 в T2. Как раз примерно в это время мы накопили достаточно причин для сплита нашей 1-ой линии на TIER1 и TIER2 (об этом подробнее в другой серии статей). И уж поскольку в изначальной концепции T2 должна работать с обеими платформами, мы завернули все инциденты MP SIEM на 2-ую линию, сформированную из самых опытных бойцов 1-ой и прошедших погружение в работу с новой SIEM. Забегая вперед, скажу, что инженеры 2-ой линии восприняли MP SIEM более позитивно, нежели их старшие коллеги-аналитики – это дало нам надежду, что платформу можно будет приземлить полноценно и на 1-ую линию, а не городить несколько специализированных. Вопрос интеграции в единую экосистему также прошел не так болезненно, как мы ожидали – возможно, помогло то, что в разрабатываемые интеграционные механизмы изначально закладывались гибкость и конфигурационная избыточность. Особо великих побед, чем бы хотелось похвалиться, не было. Мы достаточно быстро вписали новую систему в экосистему и процессы расследования и сейчас обработка инцидентов с различных SIEM отличается для ребят только интерфейсом самих SIEM. Все механизмы маршрутизации и приоритизации, вся облегчающая принятие решения обогащающая информация, все шаблоны уведомлений идентичны и находятся в тех же самых привычных местах. А как быть с контентом? На «пустой» SIEM без контента (правил корреляции событий ИБ и выявления инцидентов) далеко не уедешь и много угроз не выявишь (коробочный контент мы не используем), поэтому остро возникла задача оперативной разработки правил корреляции на новой платформе для уже существующих сценариев JSOC. Вначале решили обойтись малой кровью и перенести правила из ArcSight с копированием логики реализации, но это оказалось ошибкой, на которой мы серьезно обожглись: совершенно другая архитектура продукта требовала «своего» подхода к разработке. Пришлось этот подход сформировать, причем в ускоренном темпе. Очень помогло тесное взаимодействие с вендором, который консультировал по возникающим вопросам, брал в реализацию наши запросы на доработку существующих и создание новых фишек в функционале. Обратная сторона медали – нам регулярно приходилось переписывать контент для его корректной работы на этом самом новом функционале. Но, как говорится, change or die, так что мы не жаловались (ну разве что внутри команды за бокалом чая). На начальном этапе разработкой контента для новой SIEM занимались только опытные аналитики 4-ой линии, которые собаку съели на работе с ArcSight. Что любопытно – у некоторых ребят к тому времени уже произошла профдеформация и сформировалась «зависимость» от конкретной SIEM с её высоким уровнем зрелости. Переключиться на новую платформу для них было сложно как психологически, так и технически. Позднее банда разработки была значительно расширена новыми участниками, в т.ч. ребятами из 3-ей линии, и как раз у них эта тема взлетела гораздо проще и часто даже продуктивнее. Несмотря на сквозной для обеих SIEM перечень сценариев, их реализация может серьезно отличаться, в основном из-за ограничений в архитектуре и функциональности разных платформ. Например, в ArcSight в правиле корреляции нельзя задать проверку наличия записи в активном листе по нестрогому соответствию, а в MP SIEM с недавних пор можно. С другой стороны, MP SIEM не генерирует внутренних событий на добавление или удаление записи из табличного списка, а ArcSight умеет это делать, и в ряде сценариев эта возможность используется. Пришлось жить с раздвоением личности вводить «двухсиемность» в нашей базе знаний по сценариям JSOC и описывать нюансы реализации, а также свой инструментарий расследования для каждой из платформ. При этом очень важно было донести до 1-ой линии, что логика расследования инцидентов не зависит от того, на какой SIEM они сгенерированы, и что новая SIEM – это новый инструмент для решения всё тех же задач. У него есть свои особенности, которые обязательно нужно изучить, но кардинально ничего не меняется. И работа на 1-ой линии закипела Погружение TIER1 в работу с MP SIEM проходило постепенно и по процессу, отлаженному при вводе в строй новых сотрудников. Были определены критерии инцидентов, которые не очень страшно отдать в разбор 1-ой линии, еще не имеющей большого опыта с MP SIEM: — низкокритичные реквизиты инцидента (некатегоризированные хосты/сети и учетные записи); — длинные SLA-тайминги; — низкая трудоемкость инцидента (мы же накопили статистику при обработке инцидентов на TIER2); — не очень зубодробительные корреляционные правила (да-да, 1-ой линии туда необходимо заглядывать). Сценарии в соответствии с этими критериями были разбиты на несколько этапов и по очереди переданы инженерам TIER1 – после сдачи «зачетов» и получения доступа к решению пула инцидентов. В результате мы имеем в своем портфеле инструментов две SIEM, на которых запущены абсолютно идентичные по сути и логике обработки сценарии. Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети =========== Источник: habr.com =========== Похожие новости:
Блог компании Ростелеком-Солар ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:54
Часовой пояс: UTC + 5