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

Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT сами формировали такой сценарный подход и как используем его на практике для защиты наших клиентов. Сегодня расскажу, что мы взяли за основу, как решали сложности и к чему в итоге пришли. Забегая вперед, отмечу, что наш подход не следует воспринимать как абсолютную истину. В случае с корпоративным SOC он может быть в каких-то местах полезным, а в каких-то избыточным.



Шаг 1. Выбор требований к подходу


Первым делом мы выделили шесть основных требований, которым должен был отвечать наш сценарный подход.

  • Гибкость логики
    Нам было важно иметь возможность быстро скорректировать логику корреляционного правила, например, добавить определённый профиль или исключение.
  • Реализация на любой SIEM-системе
    Мы изначально создавали Jet CSIRT мультивендорным, чтобы в качестве основного ядра можно было использовать практически любую SIEM-систему. Потому и большинство наработок нужно было унифицировать под любую систему мониторинга.
  • Применимость при масштабировании инфраструктуры
    Мы сразу предусмотрели возможность развития и расширения инфраструктуры, при которых наши наработки не должны были «выпадать» из выстроенных процессов.
  • Понятное представление
    Нам также нужно было иметь возможность предоставлять клиентам информацию по детектируемым угрозам в простом понятном виде, без кода и усложнений.
  • Возможность покрыть разные наборы различных систем и средств защиты
    Инфраструктуры наших клиентов построены с применением разных систем, средств защиты, ПО и их конфигураций. Поэтому мы хотели, чтобы сценарный подход максимально покрывал эти системы, основываясь на их типе или классе.
  • Возможность выбора сценариев по заданным критериям
    Наконец, мы уделяли большое значение легкости выбора сценариев по заданным критериям: тип контролируемой системы, вид контролируемой активности и т. п.

Шаг 2. Поиск основы


Для разработки подхода мы обратились к лучшим практикам:

Проанализировав эти материалы, мы выделили некоторую основу для будущего подхода.

  • Чтобы обеспечить возможность объединения активностей по определенным критериям, решили ориентироваться на 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 компании «Инфосистемы Джет»