Кейсы безопасности и плейбуки (SOAR)

Security Events превращает то, что находят ваши правила обнаружения, аналитика угроз и подключённые продукты безопасности, в кейсы: по одному кейсу на всё, в чём стоит разобраться, и каждое обнаружение, касающееся того же пользователя, хоста или адреса, собирается в нём. Аналитики разбирают кейсы в очереди, а плейбуки реагируют на них — сами или по одному нажатию.

Как это работает#

Откройте Продукты → Security Events → Кейсы безопасности → Открытые кейсы, чтобы увидеть очередь. Назначены мне, Не назначено, Закрытые кейсы и Все кейсы — отдельные страницы рядом, и на каждой те кейсы, о которых говорит её название.

Перед началом#

Кейсы и плейбуки подчиняются трём ролям Security. Project Owner и Project Admin могут всё.

Каждое из этих разрешений можно выдать и по отдельности — от создания кейса до одобрения шагов плейбука; см. Справочник разрешений.

Откуда берутся кейсы#

По умолчанию все источники включены. Подключение открывает кейсы для Высокий и выше, если вы не выберете другой уровень; оповещения ниже этого уровня всё равно импортируются как события.

Как группируются обнаружения#

Обнаружение относится к сущности: к значению, по которому группирует его правило, например к IP-адресу в правиле против перебора паролей или к индикатору, который называет совпадение с аналитикой угроз. Обнаружение без сущности стоит особняком.

• Если открытый кейс уже относится к этой сущности, обнаружение добавляется в него. Сущности кейса и его сопоставление с ATT&CK пополняются, а приоритет поднимается до приоритета обнаружения и никогда не понижается.
• Если такого открытого кейса нет, открывается новый кейс с названием обнаружения и с его приоритетом.
• Повторно сработавшее обнаружение увеличивает счётчик в своей строке, а не добавляет новую строку.

Приоритет кейса определяется серьёзностью обнаружения:

Работа с кейсом#

Кейс проходит через четыре статуса. Какой-то из них он может пропустить — например, ложное срабатывание закрывают прямо из New, — и его можно открыть повторно.

На странице кейса есть всё, что нужно для работы с ним:

• Вверху: Assign to Me, Run Playbook, Объявить инцидент и Close Case, шаги статуса и приоритет в меню рядом с ними.
• Status200 AI: что Status200 AI понял из кейса, приоритет и плейбук, которые он предлагает, и доказательства за ними. См. Status200 AI в безопасности.
• Detections: что сработало и открыло кейс или добавилось в него, как часто и последнее совпавшее событие.
• Сущности: пользователи, хосты и адреса, к которым относится кейс, с их активностью во всех ваших событиях безопасности за последние 7 дней. Каждая открывается в Коррелировать.
• MITRE ATT&CK: тактики и техники, с которыми сопоставлены его обнаружения, каждая со ссылкой на свою страницу на attack.mitre.org.
• Запуски плейбуков: что каждый плейбук сделал с кейсом, шаг за шагом, и шаги, ожидающие одобрения.
• Заметки и Хронология: что написала команда и всё, что происходило, с указанием, кто это сделал.

Чтобы работать с несколькими кейсами сразу, выберите их в очереди и используйте Assign to Me, Change Status или Change Priority.

Закрытие кейса#

Close Case запрашивает вердикт и необязательную заключительную заметку:

Вердикты подсчитываются на обзоре. Правило, кейсы которого раз за разом закрываются как False Positive, нуждается в настройке.

Кейс, открытый из оповещений Google SecOps, закрывает их и в Google SecOps, с вердиктом и заметкой о закрытии, когда у его подключения включено Закрывать оповещения, когда закрывается их кейс: см. Google SecOps.

Объявление инцидента#

Объявить инцидент открывает для кейса инцидент Status200 с выбранной вами серьёзностью и связывает их в обе стороны: описание инцидента называет кейс, а заголовок кейса ссылается на инцидент. Дальше в дело вступают дежурства, страницы статуса и постмортем. Для этого нужна роль, которая может и работать с кейсами, и создавать инциденты.

Уведомления#

Status200 сообщает людям о трёх событиях в кейсе. Ничего настраивать не нужно: проект, в котором только нажали Включить рекомендуемое, узнаёт о своих кейсах с приоритетом High и Critical по почте и через push.

• О кейсе сообщают только тем, кто может его видеть: Project Owner, Project Admin и ролям Security Admin, Security Member и Security Viewer. Тем, чья роль ограничена некоторыми метками, сообщают только о кейсах с этими метками.
• Никому не сообщают о его собственных действиях: тот, кто открывает кейс вручную, назначает его или запускает плейбук, уведомления об этом не получает.
• Каждый узнаёт о кейсе один раз. Кейс, который открылся с приоритетом Medium, а потом поднялся до Critical, при повышении доходит до тех, кто выбрал High или Critical, и не доходит повторно до тех, кто выбрал Medium: они узнали о нём при открытии.
• Тестовая атака, отправленная кнопкой Отправить тестовую атаку, открывает кейс, о котором никому не сообщается.
• Кейс с приоритетом Critical и шаг, ожидающий одобрения, отправляются сразу и никогда не задерживаются в сводке писем.
• Хронология кейса показывает, кому и когда сообщили.

Выбор уведомлений#

Каждый выбирает сам, в Настройки пользователя → Настройки уведомлений → Безопасность: каналы для каждого уведомления (почта, SMS, звонок, push, Telegram, Slack, Microsoft Teams или вебхук), а для события Новый кейс безопасности — приоритет, начиная с которого ему приходят уведомления:

Сообщения WhatsApp для кейсов безопасности не отправляются. Push-уведомление открывает приложение Status200, а ссылка в нём открывает кейс в браузере.

Публикация в каналах Slack и Microsoft Teams#

Чтобы публиковать сообщения в канале, добавьте правило в Продукты → Security Events → Рабочее пространство → Slack (или Microsoft Teams). Если ни один из них не подключён, единственный пункт этого раздела — Подключить Slack или Teams. Правило указывает каналы для публикации (а в Microsoft Teams — и чаты) и, если нужно, кейсы, к которым оно относится:

Каждое из трёх уведомлений публикуется в каналы всех правил, которым кейс соответствует в этот момент. Правило, в котором Приоритет кейса безопасности содержит любой из Критический и High, публикует кейсы High и Critical при открытии, а кейс Medium — когда он повышается до High. У кейса безопасности никогда не бывает собственного канала.

Плейбуки#

Плейбук — это список шагов, которые выполняются для кейса. Создайте его в Продукты → Security Events → Playbooks из шаблона или с нуля и добавьте шаги на его странице.

Когда запускается плейбук#

Любой включённый плейбук можно также запустить вручную кнопкой Run Playbook в кейсе. Плейбук, который запускается сам, можно ограничить:

• For Cases At Least: только кейсы с этим или более высоким приоритетом.
• Only For Detections From: только если обнаружение, стоящее за кейсом, пришло из этого источника.
• Only For These Detection Rules: только если оно пришло от одного из этих правил.

Отключённый плейбук не запускается ни сам, ни вручную.

Шаги#

В плейбуке не больше 25 шагов. Они выполняются по порядку, каждый — после завершения предыдущего. У каждого шага есть также такие настройки:

• Needs Approval: останавливает запуск перед шагом, пока кто-нибудь не одобрит его в кейсе. Для четырёх шагов, которые лишают кого-то доступа, она включена всегда, если только Security Admin её не выключит.
• Only If Threat Intel Matched: пропускает шаг, если более ранний шаг Check entities against threat intel в этом запуске не нашёл известного индикатора.
• Carry On If It Fails: выполняет следующий шаг, даже если этот завершился ошибкой. Когда настройка выключена, ошибка шага останавливает запуск.

Сдерживание#

Шаги сдерживания действуют через подключение событий безопасности к продукту, и ему нужен не только доступ на чтение:

Шаг сдерживания действует только на пользователей или хосты, к которым относится кейс, и никогда — на всех, кто в нём упомянут:

• Значение, по которому сгруппировано обнаружение кейса, например учётная запись, по которой группирует правило невозможных перемещений, или хост, названный в оповещении подключённого продукта.
• Пользователь или хост кейса, который известен вашей аналитике угроз как индикатор.

Кейс, сгруппированный по адресу, например перебор паролей к вашему VPN, не относится ни к тому, ни к другому: его шаги сдерживания пропускаются, а учётная запись, к которой подбирали пароль, и шлюз, который атаковали, остаются нетронутыми. Шаг действует не более чем на 10 пользователей или хостов. Он находит каждого из них в продукте по имени и сообщает в запуске, что сделал с каждым: выполнено, уже выполнено, не найден, отказано или защищён.

Защищённые сущности#

Protected Entities в разделе Playbooks меню перечисляет пользователей и хосты, к которым ни один плейбук не применяет сдерживание, например учётные записи для аварийного доступа, контроллеры домена и VPN-шлюзы. Значение совпадает независимо от регистра, а * обозначает любую последовательность символов: svc-* защищает все служебные учётные записи. О защищённом пользователе или хосте шаг сообщает как о защищённом и не трогает его. Список ведут пользователи с ролью Security Admin.

Одобрение#

Четыре шага, которые лишают кого-то доступа, ждут одобрения. Выключить для одного из них Needs Approval может только Security Admin, и Status200 записывает, кто это сделал. При одобрении пользователи или хосты, на которые подействует шаг, перечислены в Act On, и все они отмечены: снимите отметку с тех, кого шаг должен оставить в покое. Защищённые там не предлагаются. Тот, кто начал запуск, не может одобрить его шаги: это делает кто-то другой, но отклонить шаг он всё же может.

Отмена#

Шаги отмены, как и шаги, которые они отменяют, действуют на пользователей или хосты, к которым относится кейс. После остановки запуска у пользователя или хоста, к которому применено сдерживание, на его шаге есть и собственная кнопка: Unsuspend, Lift Containment или Освободить. Завершённый сеанс Okta отменить нельзя. Каждая отмена сохраняется в хронологии кейса и в журнале аудита проекта.

Сообщения#

Заметка, письмо, публикация в Slack и публикация в Teams могут использовать значения кейса:

Письмо или публикация без собственного сообщения отправляют сводку по кейсу.

Запуски и одобрения#

Каждый запуск отображается шаг за шагом в своём кейсе и в Продукты → Security Events → Playbooks → Запуски плейбуков:

Шаг, ожидающий одобрения, показывает в запуске кнопки Approve и Reject с необязательным комментарием. Одобрение продолжает запуск с этого шага; отклонение завершает его. Решение, его автор и комментарий сохраняются в шаге, в хронологии кейса и в журнале аудита проекта. Ожидает одобрения в разделе Playbooks меню показывает запуски, ждущие решения, и их число; Запуски плейбуков показывает все запуски.

Запуск, от воркера которого перестали приходить сигналы, например после перезапуска, подхватывается снова: запуск в очереди ставится в очередь повторно через 2 минуты, а запуск, молчащий 30 минут, считается неудавшимся.

Обзор#

Продукт открывается на странице Продукты → Security Events → Обзор:

• Открытые кейсы, назначенные вам, открытые кейсы, которые никто не взял, и шаги плейбуков, ожидающие одобрения; каждое число открывает страницу, где они перечислены.
• Среднее время до принятия, Среднее время до сдерживания и Среднее время до закрытия по кейсам, открытым за последние 30 дней: от открытия кейса до того, как кто-то возьмёт его в работу (назначит человека или выведет из New), до Contained и до Closed. Кейс, который ещё ждёт, в среднее значение не входит.
• Кейсы, открытые за каждый из последних 30 дней, по приоритету, и обнаружения, созданные за каждый из последних 14 дней, по источнику.
• Открытые кейсы по приоритету и по статусу, вердикты за последние 30 дней, тактики ATT&CK, стоящие за кейсами, чаще всего срабатывавшие обнаружения и сущности, которые упоминаются в наибольшем числе находок.

Над ними полоса показывает, как настроена безопасность: её источники, обнаружения, кейсы и плейбуки, каждый со своими цифрами. Проект, который её ещё не настроил, видит там Включить рекомендуемое и Отправить тестовую атаку; см. Начало работы с безопасностью. Когда ничего не требует внимания, страница показывает Всё спокойно, а графики появляются, как только есть что показать.

Поиск угроз#

• Сущности ранжирует пользователей, хосты, адреса и хеши, которые чаще всего упоминаются в ваших находках, за последний день, неделю или месяц, и ищет любое значение в событиях за 30 дней.
• Rule Library содержит готовые правила обнаружения для угроз в области идентификации, конечных точек, облака, сети, веба и Kubernetes. Каждое из них — правило Sigma, написанное для полей, к которым нормализуется каждый подключённый источник. Добавить правило создаёт его как ваше собственное правило обнаружения — включённым и открывающим кейсы, а не оповещения; изменяйте его в Detection Rules, как любое другое. Правила с отметкой Рекомендуемые находят угрозы в данных, которые у Status200 уже есть, а одна кнопка добавляет те, которых у вас ещё нет.
• ATT&CK Coverage рисует матрицу MITRE ATT&CK, подсвечивая техники, которые покрывают ваши включённые правила, и обводит те, которые покрыло бы правило из библиотеки.

Автоматизация#

• Рабочие процессы: кейс или заметка могут запускать рабочий процесс при создании, изменении или удалении. Шаг Run a workflow запускает рабочий процесс, триггером которого служит вебхук.
• API: у кейсов, заметок, обнаружений, плейбуков, запусков и защищённых сущностей тот же REST API, что и у остального Status200, по путям /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run и /security-protected-entity. См. Справочник API.
• ИИ-агенты: у MCP-сервера есть инструменты для кейсов, заметок, обнаружений и плейбуков. См. Сервер MCP.

Устранение неполадок#

Дальнейшие шаги#