Для запуска корпоративного SOC или ситуационного центра управления ИБ мало внедрить систему мониторинга (SIEM). Помимо этого, нужно предусмотреть кучу всего, что понадобится команде SOC в работе. Методики детектирования, правила корреляции, наработки по реагированию — всё это должно укладываться в единый подход к выявлению инцидентов. Без этих вещей рано или поздно в команде будут возникать рядовые вопросы на уровне, что и как работает, кто за что отвечает, какие есть белые пятна и куда развиваться, как показать результат работы и развития.
Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT сами формировали такой сценарный подход и как используем его на практике для защиты наших клиентов. Сегодня расскажу, что мы взяли за основу, как решали сложности и к чему в итоге пришли. Забегая вперед, отмечу, что наш подход не следует воспринимать как абсолютную истину. В случае с корпоративным SOC он может быть в каких-то местах полезным, а в каких-то избыточным.
Первым делом мы выделили шесть основных требований, которым должен был отвечать наш сценарный подход.
Для разработки подхода мы обратились к лучшим практикам:
Проанализировав эти материалы, мы выделили некоторую основу для будущего подхода.
В результате мы определили для себя две основные единицы для детектирования угроз: сценарий и его условие.
Сценарий представляет собой общее описание условий вредоносной, нежелательной или контролируемой активности и объединяет условия по виду активности и набору заданных маркеров: этапы Kill chain, ID техник, название тактик MITRE и другие.
Ниже пример выделения схожих техник MITRE и дальнейшего выделения источников информации для объединения набора правил.
Пример объединения правил в набор
Условие сценария, в свою очередь, конкретизирует эту активность применительно к определенному действию на контролируемом источнике.
Все сценарии объединены между собой по нескольким унифицированным критериям в девять категорий:
Теперь о самих сценариях. Для управления и хранения карточек сценариев мы выбрали систему управления репозиториями кода GitLab, так как в ней можно работать одновременно над разными сценариями, организовать единое место хранения актуальных сценариев и легко создавать копии (форки). Все карточки сценариев мы разделили на четыре блока.
Содержание карточки сценария
Основное описание содержит информацию, с помощью которой можно однозначно идентифицировать сценарий и в то же время производить поиск по критериям. Этот блок использует формат атрибутов. Вот как выглядит пример одного из таких описаний для сценария:
Разделы с логической структурой и корреляционными правилами включают легко читаемое описание выявляемой угрозы, известные ложные срабатывания и непосредственно сами правила для различных SIEM-систем.
Пример раздела с логической структурой
Пример правил для SIEM
Инструкции по реагированию содержат короткие подсказки по направлениям расследования, шаблоны уведомлений и базовые действия по реагированию.
При создании основной базы сценариев мы задались вопросом, как организовать работу со сценариями для конкретной инфраструктуры, ведь у каждого клиента свой набор систем. Как раз здесь и пригодилась возможность форка в GitLab. Основная база сценариев служит стартом для отдельного репозитория заказчика.
Эта возможность также пригодится для корпоративных SOC с распределенной инфраструктурой. В зависимости от офиса или подразделения, инфраструктура может отличаться, что приводит к появлению уникальных сценариев, условий и исключений к ним.
На схеме ниже вы можете посмотреть, как у нас сценарии мигрируют в репозитории каждого клиента.
Миграция по клиентам
Когда мы пришли к общей методике по сценариям, назрел вопрос, как их развивать дальше, ведь атакующие непрерывно совершенствуют техники и тактики, что требует от нас регулярно создавать новые сценарии и корректировать существующие. Здесь мы выделили четыре основных «источника» развития сценариев.
Весь непосредственный процесс развития сценариев мы поделили на этапы — от создания, тестирования и проверки на инфраструктуре Jet CSIRT до непосредственного внедрения нашим клиентам.
Развитие сценариев
В итоге нам удалось решить ряд проблем и получить новые преимущества при работе в таком формате.
Надеюсь, наш опыт будет для вас полезным и поможет разобраться в нюансах формирования сценарного подхода к выявлению угроз для вашего собственного SOC.
Автор: Дмитрий Лифанов, ведущий аналитик Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании «Инфосистемы Джет»
Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT сами формировали такой сценарный подход и как используем его на практике для защиты наших клиентов. Сегодня расскажу, что мы взяли за основу, как решали сложности и к чему в итоге пришли. Забегая вперед, отмечу, что наш подход не следует воспринимать как абсолютную истину. В случае с корпоративным SOC он может быть в каких-то местах полезным, а в каких-то избыточным.
Шаг 1. Выбор требований к подходу
Первым делом мы выделили шесть основных требований, которым должен был отвечать наш сценарный подход.
- Гибкость логики
Нам было важно иметь возможность быстро скорректировать логику корреляционного правила, например, добавить определённый профиль или исключение. - Реализация на любой SIEM-системе
Мы изначально создавали Jet CSIRT мультивендорным, чтобы в качестве основного ядра можно было использовать практически любую SIEM-систему. Потому и большинство наработок нужно было унифицировать под любую систему мониторинга. - Применимость при масштабировании инфраструктуры
Мы сразу предусмотрели возможность развития и расширения инфраструктуры, при которых наши наработки не должны были «выпадать» из выстроенных процессов. - Понятное представление
Нам также нужно было иметь возможность предоставлять клиентам информацию по детектируемым угрозам в простом понятном виде, без кода и усложнений. - Возможность покрыть разные наборы различных систем и средств защиты
Инфраструктуры наших клиентов построены с применением разных систем, средств защиты, ПО и их конфигураций. Поэтому мы хотели, чтобы сценарный подход максимально покрывал эти системы, основываясь на их типе или классе. - Возможность выбора сценариев по заданным критериям
Наконец, мы уделяли большое значение легкости выбора сценариев по заданным критериям: тип контролируемой системы, вид контролируемой активности и т. п.
Шаг 2. Поиск основы
Для разработки подхода мы обратились к лучшим практикам:
- Cyber Kill Chain;
- MITRE ATT&CK;
- MITRE Cyber Analytics Repository;
- Материалы FBI по угрозам от инсайдеров;
- Различные материалы и инструменты по аналитике, детектированию и тестированию угроз
- github.com/Neo23x0/sigma (кстати, мы не только пользуемся корреляционными правилами из этой базы, но и активно развиваем ее, участвуя в комьюнити OSCD)
- github.com/atc-project/atomic-threat-coverage
- atomicredteam.io
- github.com/sindresorhus/awesome
- nsacyber.github.io/unfetter/index.html
- github.com/endgameinc/eql
Проанализировав эти материалы, мы выделили некоторую основу для будущего подхода.
- Чтобы обеспечить возможность объединения активностей по определенным критериям, решили ориентироваться на APT Kill chain и Insider Kill chain.
- Для понимания, что и какими методами детектируется, использовали категории, техники и тактики MITRE ATT&CK.
- Взяли на вооружение наработки по логике корреляционных правил, в том числе и тех, что уже были созданы в Jet CSIRT.
В результате мы определили для себя две основные единицы для детектирования угроз: сценарий и его условие.
Сценарий представляет собой общее описание условий вредоносной, нежелательной или контролируемой активности и объединяет условия по виду активности и набору заданных маркеров: этапы Kill chain, ID техник, название тактик MITRE и другие.
Ниже пример выделения схожих техник MITRE и дальнейшего выделения источников информации для объединения набора правил.
Пример объединения правил в набор
Условие сценария, в свою очередь, конкретизирует эту активность применительно к определенному действию на контролируемом источнике.
Все сценарии объединены между собой по нескольким унифицированным критериям в девять категорий:
- нелегитимная административная активность;
- компрометация учетной записи;
- компрометация узла;
- нарушение политик безопасности;
- заражение вредоносным ПО;
- вредоносная сетевая активность;
- несанкционированный доступ к системам;
- утечка данных;
- атака на отказ в обслуживании.
Шаг 3. Работа со сценариями
Теперь о самих сценариях. Для управления и хранения карточек сценариев мы выбрали систему управления репозиториями кода GitLab, так как в ней можно работать одновременно над разными сценариями, организовать единое место хранения актуальных сценариев и легко создавать копии (форки). Все карточки сценариев мы разделили на четыре блока.
Содержание карточки сценария
Основное описание содержит информацию, с помощью которой можно однозначно идентифицировать сценарий и в то же время производить поиск по критериям. Этот блок использует формат атрибутов. Вот как выглядит пример одного из таких описаний для сценария:
Разделы с логической структурой и корреляционными правилами включают легко читаемое описание выявляемой угрозы, известные ложные срабатывания и непосредственно сами правила для различных SIEM-систем.
Пример раздела с логической структурой
Пример правил для SIEM
Инструкции по реагированию содержат короткие подсказки по направлениям расследования, шаблоны уведомлений и базовые действия по реагированию.
При создании основной базы сценариев мы задались вопросом, как организовать работу со сценариями для конкретной инфраструктуры, ведь у каждого клиента свой набор систем. Как раз здесь и пригодилась возможность форка в GitLab. Основная база сценариев служит стартом для отдельного репозитория заказчика.
Эта возможность также пригодится для корпоративных SOC с распределенной инфраструктурой. В зависимости от офиса или подразделения, инфраструктура может отличаться, что приводит к появлению уникальных сценариев, условий и исключений к ним.
На схеме ниже вы можете посмотреть, как у нас сценарии мигрируют в репозитории каждого клиента.
Миграция по клиентам
Шаг 4. Развитие сценариев
Когда мы пришли к общей методике по сценариям, назрел вопрос, как их развивать дальше, ведь атакующие непрерывно совершенствуют техники и тактики, что требует от нас регулярно создавать новые сценарии и корректировать существующие. Здесь мы выделили четыре основных «источника» развития сценариев.
- Наши собственные исследования на основе открытых и закрытых отчетов по целевым атакам и информации о новом вредоносном ПО.
- Собственный опыт предоставления услуг по мониторингу и реагированию, участия в расследовании инцидентов, реагировании на атаки и пост-инцидентной активности.
- Новые техники и тактики из MITRE ATT&CK, которая постоянно растет и развивается.
- Целевые запросы от клиентов, в которых ту или иную задачу требуется решить средствами системы мониторинга.
Весь непосредственный процесс развития сценариев мы поделили на этапы — от создания, тестирования и проверки на инфраструктуре Jet CSIRT до непосредственного внедрения нашим клиентам.
Развитие сценариев
По итогам
В итоге нам удалось решить ряд проблем и получить новые преимущества при работе в таком формате.
- Мы систематизировали и структурировали все знания, а также объединили атомарные техники выявления угроз в группы, чтобы нам было проще ориентироваться в возможностях детектирования угроз.
- Новые члены команды могут без каких-либо сложностей изучить, что и как работает в Jet CSIRT. С появлением методики нам удалось максимизировать спектр детектирования угроз.
- Мы добились легкого представления детектируемых угроз для ИБ-специалистов, не знакомых с SIEM-системами.
- Нам удалось исключить проблему с потерей наработок, когда какие-либо файлы с информацией могли быть уничтожены, утеряны или храниться у их создателей.
- Мы унифицировали обработку инцидентов: на все имеющиеся сценарии написали полные плейбуки с необходимыми действиями и мерами.
- У нас появилась возможность быстро и без каких-либо трудностей воспользоваться любым из реализованных правил без доступа к определенной SIEM-системе. Мы реализовали контроль версий и вносимых изменений в состав логики и добавляемых исключений для сценария.
Надеюсь, наш опыт будет для вас полезным и поможет разобраться в нюансах формирования сценарного подхода к выявлению угроз для вашего собственного SOC.
Автор: Дмитрий Лифанов, ведущий аналитик Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании «Инфосистемы Джет»
