Для запуска корпоративного SOC или ситуационного центра управления ИБ мало внедрить систему мониторинга (SIEM). Помимо этого, нужно предусмотреть кучу всего, что понадобится команде SOC в работе. Методики детектирования, правила корреляции, наработки по реагированию — всё это должно укладываться в единый подход к выявлению инцидентов. Без этих вещей рано или поздно в команде будут возникать рядовые вопросы на уровне, что и как работает, кто за что отвечает, какие есть белые пятна и куда развиваться, как показать результат работы и развития.

Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ 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 компании «Инфосистемы Джет»