Одна голова хорошо, а две – некрасиво… Так мы думали, пока жили в чудное время, когда в нашем центре мониторинга и реагирования на кибератаки была одна-единственная SIEM-платформа. Не секрет, что это была HP ArcSight, оказавшаяся единственным финишером длительного марафона через тернии требований, хотелок и амбициозных планов построения сердца SOC.
И вроде бы ничто не предвещало беды, но в какой-то момент появились и стали все более настойчивыми мысли о необходимости работы с альтернативной платформой. И основным локомотивом тут выступило активное развитие центров ГосСОПКА. Для того чтобы стать одним из подобных центров, нам необходимо было использовать ПО, которое обеспечено «гарантийной и технической поддержкой российскими организациями, не находящимися под прямым или косвенным контролем иностранных физических лиц и (или) юридических лиц» (Приказ ФСБ от 06.05.2019 № 196, п.3.4). Как мыстрадали все это пережили и что в итоге получилось, рассказываем ниже.
Кадр из мультсериала «Котопёс»
Мы слышали, что есть SOC’и, которые исповедуютмногоженство многовендорность и говорят (а этот вид деятельности, как мы помним, сильно отличается от мешочноразгрузочных работ), что готовы работать с любым распространенным на рынке SIEM-решением. Почему невозможно реализовать такой подход качественно, вы поймете из описания ниже. Мы же настолько привязались к ArcSight и успели выстроить вокруг него целую экосистему решений и процессов, что встраивание в нее чужеродной 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 – это новый инструмент для решения всё тех же задач. У него есть свои особенности, которые обязательно нужно изучить, но кардинально ничего не меняется.
Погружение TIER1 в работу с MP SIEM проходило постепенно и по процессу, отлаженному при вводе в строй новых сотрудников. Были определены критерии инцидентов, которые не очень страшно отдать в разбор 1-ой линии, еще не имеющей большого опыта с MP SIEM:
Сценарии в соответствии с этими критериями были разбиты на несколько этапов и по очереди переданы инженерам TIER1 – после сдачи «зачетов» и получения доступа к решению пула инцидентов.
В результате мы имеем в своем портфеле инструментов две SIEM, на которых запущены абсолютно идентичные по сути и логике обработки сценарии.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
И вроде бы ничто не предвещало беды, но в какой-то момент появились и стали все более настойчивыми мысли о необходимости работы с альтернативной платформой. И основным локомотивом тут выступило активное развитие центров ГосСОПКА. Для того чтобы стать одним из подобных центров, нам необходимо было использовать ПО, которое обеспечено «гарантийной и технической поддержкой российскими организациями, не находящимися под прямым или косвенным контролем иностранных физических лиц и (или) юридических лиц» (Приказ ФСБ от 06.05.2019 № 196, п.3.4). Как мы
Кадр из мультсериала «Котопёс»
Мы слышали, что есть SOC’и, которые исповедуют
- Какое решение выбрать?
- Как интегрировать новую SIEM-систему в работу TIER1?
- Как всё то множество внутренних интеграций, которые на данный момент есть с ArcSight, перенести на новую платформу?
- Как синхронизировать идеологию развития контента 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 умеет это делать, и в ряде сценариев эта возможность используется. Пришлось
При этом очень важно было донести до 1-ой линии, что логика расследования инцидентов не зависит от того, на какой SIEM они сгенерированы, и что новая SIEM – это новый инструмент для решения всё тех же задач. У него есть свои особенности, которые обязательно нужно изучить, но кардинально ничего не меняется.
И работа на 1-ой линии закипела
Погружение TIER1 в работу с MP SIEM проходило постепенно и по процессу, отлаженному при вводе в строй новых сотрудников. Были определены критерии инцидентов, которые не очень страшно отдать в разбор 1-ой линии, еще не имеющей большого опыта с MP SIEM:
- низкокритичные реквизиты инцидента (некатегоризированные хосты/сети и учетные записи);
- длинные SLA-тайминги;
- низкая трудоемкость инцидента (мы же накопили статистику при обработке инцидентов на TIER2);
- не очень зубодробительные корреляционные правила (да-да, 1-ой линии туда необходимо заглядывать).
Сценарии в соответствии с этими критериями были разбиты на несколько этапов и по очереди переданы инженерам TIER1 – после сдачи «зачетов» и получения доступа к решению пула инцидентов.
В результате мы имеем в своем портфеле инструментов две SIEM, на которых запущены абсолютно идентичные по сути и логике обработки сценарии.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
