[Информационная безопасность] Must have для SOC: как выбрать сценарный подход к выявлению угроз
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Для запуска корпоративного SOC или ситуационного центра управления ИБ мало внедрить систему мониторинга (SIEM). Помимо этого, нужно предусмотреть кучу всего, что понадобится команде SOC в работе. Методики детектирования, правила корреляции, наработки по реагированию — всё это должно укладываться в единый подход к выявлению инцидентов. Без этих вещей рано или поздно в команде будут возникать рядовые вопросы на уровне, что и как работает, кто за что отвечает, какие есть белые пятна и куда развиваться, как показать результат работы и развития.
Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT сами формировали такой сценарный подход и как используем его на практике для защиты наших клиентов. Сегодня расскажу, что мы взяли за основу, как решали сложности и к чему в итоге пришли. Забегая вперед, отмечу, что наш подход не следует воспринимать как абсолютную истину. В случае с корпоративным SOC он может быть в каких-то местах полезным, а в каких-то избыточным.
Шаг 1. Выбор требований к подходу
Первым делом мы выделили шесть основных требований, которым должен был отвечать наш сценарный подход.
- Гибкость логики
Нам было важно иметь возможность быстро скорректировать логику корреляционного правила, например, добавить определённый профиль или исключение.
- Реализация на любой SIEM-системе
Мы изначально создавали Jet CSIRT мультивендорным, чтобы в качестве основного ядра можно было использовать практически любую SIEM-систему. Потому и большинство наработок нужно было унифицировать под любую систему мониторинга.
- Применимость при масштабировании инфраструктуры
Мы сразу предусмотрели возможность развития и расширения инфраструктуры, при которых наши наработки не должны были «выпадать» из выстроенных процессов.
- Понятное представление
Нам также нужно было иметь возможность предоставлять клиентам информацию по детектируемым угрозам в простом понятном виде, без кода и усложнений.
- Возможность покрыть разные наборы различных систем и средств защиты
Инфраструктуры наших клиентов построены с применением разных систем, средств защиты, ПО и их конфигураций. Поэтому мы хотели, чтобы сценарный подход максимально покрывал эти системы, основываясь на их типе или классе.
- Возможность выбора сценариев по заданным критериям
Наконец, мы уделяли большое значение легкости выбора сценариев по заданным критериям: тип контролируемой системы, вид контролируемой активности и т. п.
Шаг 2. Поиск основы
Для разработки подхода мы обратились к лучшим практикам:
- Cyber Kill Chain;
- MITRE ATT&CK;
- MITRE Cyber Analytics Repository;
- Материалы FBI по угрозам от инсайдеров;
-
Различные материалы и инструменты по аналитике, детектированию и тестированию угроз
SPL
- 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 компании «Инфосистемы Джет»
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Разработка под iOS, Системы обмена сообщениями] Apple потребовала от Telegram заблокировать три белорусских канала
- [Информационная безопасность] Минцифра и запрет TLS v. 1.3 (а заодно и HTTPS): отзыв на законопроект
- [Информационная безопасность] Приглашаем экспертов принять участие в опросе СИГРЭ по лучшим практикам SOC в электроэнергетике
- [Информационная безопасность, Системное администрирование, Сетевые технологии] Honeypot vs Deception на примере Xello
- [Информационная безопасность] Постройтесь в линию: как мы набивали шишки на создании процессов выявления и реагирования на кибератаки
- [Информационная безопасность] Хватит использовать пароли
- [Информационная безопасность] Security Week 41: вредоносный код в UEFI
- [Информационная безопасность, Криптовалюты] Как северокорейские хакеры отмывают краденую криптовалюту на миллиарды долларов (перевод)
- [Виртуализация, Облачные вычисления] Лицом к разработчикам: модернизировать частное облако
- [IT-компании, Информационная безопасность, Разработка под Windows] Microsoft выпустила инструмент для обновления Defender в образах для установки Windows 10 и Windows Server 2016/2019
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_soc, #_playbook, #_incident_response, #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:08
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Для запуска корпоративного SOC или ситуационного центра управления ИБ мало внедрить систему мониторинга (SIEM). Помимо этого, нужно предусмотреть кучу всего, что понадобится команде SOC в работе. Методики детектирования, правила корреляции, наработки по реагированию — всё это должно укладываться в единый подход к выявлению инцидентов. Без этих вещей рано или поздно в команде будут возникать рядовые вопросы на уровне, что и как работает, кто за что отвечает, какие есть белые пятна и куда развиваться, как показать результат работы и развития. Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT сами формировали такой сценарный подход и как используем его на практике для защиты наших клиентов. Сегодня расскажу, что мы взяли за основу, как решали сложности и к чему в итоге пришли. Забегая вперед, отмечу, что наш подход не следует воспринимать как абсолютную истину. В случае с корпоративным SOC он может быть в каких-то местах полезным, а в каких-то избыточным.  Шаг 1. Выбор требований к подходу Первым делом мы выделили шесть основных требований, которым должен был отвечать наш сценарный подход.
Шаг 2. Поиск основы Для разработки подхода мы обратились к лучшим практикам:
Проанализировав эти материалы, мы выделили некоторую основу для будущего подхода.
В результате мы определили для себя две основные единицы для детектирования угроз: сценарий и его условие. Сценарий представляет собой общее описание условий вредоносной, нежелательной или контролируемой активности и объединяет условия по виду активности и набору заданных маркеров: этапы Kill chain, ID техник, название тактик MITRE и другие. Ниже пример выделения схожих техник MITRE и дальнейшего выделения источников информации для объединения набора правил.  Пример объединения правил в набор Условие сценария, в свою очередь, конкретизирует эту активность применительно к определенному действию на контролируемом источнике. Все сценарии объединены между собой по нескольким унифицированным критериям в девять категорий:
Шаг 3. Работа со сценариями Теперь о самих сценариях. Для управления и хранения карточек сценариев мы выбрали систему управления репозиториями кода GitLab, так как в ней можно работать одновременно над разными сценариями, организовать единое место хранения актуальных сценариев и легко создавать копии (форки). Все карточки сценариев мы разделили на четыре блока.  Содержание карточки сценария Основное описание содержит информацию, с помощью которой можно однозначно идентифицировать сценарий и в то же время производить поиск по критериям. Этот блок использует формат атрибутов. Вот как выглядит пример одного из таких описаний для сценария:  Разделы с логической структурой и корреляционными правилами включают легко читаемое описание выявляемой угрозы, известные ложные срабатывания и непосредственно сами правила для различных SIEM-систем.  Пример раздела с логической структурой  Пример правил для SIEM Инструкции по реагированию содержат короткие подсказки по направлениям расследования, шаблоны уведомлений и базовые действия по реагированию.  При создании основной базы сценариев мы задались вопросом, как организовать работу со сценариями для конкретной инфраструктуры, ведь у каждого клиента свой набор систем. Как раз здесь и пригодилась возможность форка в GitLab. Основная база сценариев служит стартом для отдельного репозитория заказчика. Эта возможность также пригодится для корпоративных SOC с распределенной инфраструктурой. В зависимости от офиса или подразделения, инфраструктура может отличаться, что приводит к появлению уникальных сценариев, условий и исключений к ним. На схеме ниже вы можете посмотреть, как у нас сценарии мигрируют в репозитории каждого клиента.  Миграция по клиентам Шаг 4. Развитие сценариев Когда мы пришли к общей методике по сценариям, назрел вопрос, как их развивать дальше, ведь атакующие непрерывно совершенствуют техники и тактики, что требует от нас регулярно создавать новые сценарии и корректировать существующие. Здесь мы выделили четыре основных «источника» развития сценариев.
Весь непосредственный процесс развития сценариев мы поделили на этапы — от создания, тестирования и проверки на инфраструктуре Jet CSIRT до непосредственного внедрения нашим клиентам.  Развитие сценариев По итогам В итоге нам удалось решить ряд проблем и получить новые преимущества при работе в таком формате.
Надеюсь, наш опыт будет для вас полезным и поможет разобраться в нюансах формирования сценарного подхода к выявлению угроз для вашего собственного SOC. Автор: Дмитрий Лифанов, ведущий аналитик Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании «Инфосистемы Джет» =========== Источник: habr.com =========== Похожие новости:
Блог компании Инфосистемы Джет ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:08
Часовой пояс: UTC + 5