Обнаружение изменений в Security posture

Эти примеры правил отправляют оповещения об изменениях в Security posture вашей организации на основе активностей, которые записывает лента активности Compliance API. Они предполагают, что ваша система управления информацией и событиями безопасности (security information and event management, SIEM) хранит эти активности, как описано в разделе Отправка событий в вашу SIEM.

Прежде чем писать правило

Каждое правило — это простое описание и запрос, не привязанный к какому-либо конкретному языку запросов.

• В запросах используются имена полей ленты активности, а также stored_at — так на этой странице называется момент, когда вы сохранили активность. Любое другое имя — это ваш собственный список или псевдоним.
• Прежде чем правило начнёт подсчитывать активности, выполните дедупликацию по id.
• Если в правиле не указано иное, запускайте его на промежутке времени с момента его последнего завершённого запуска, по stored_at, а не по created_at, потому что активность может поступить с опозданием; в запросах этот диапазон опущен.
• Пишите правила, которые срабатывают на сохранённую вами активность, и никогда — на несохранённую: она может запаздывать или быть изменением, которое лента не записывает. Чтобы сравнить сохранённые активности с текущими результатами, см. Сверка событий с результатами.

Правила для подтверждений

Эти пять правил читают активности org_security_control_attestation_updated.

Принят риск

Отправляйте оповещение, когда кто-либо принимает риск (accepted_risk) несоблюдения меры безопасности, чтобы второй человек мог проверить это решение.

type == "org_security_control_attestation_updated"
AND status == "accepted_risk"
AND actor.type != "system_actor"

Правило исключает system_actor, потому что автоматическое изменение, например подтверждение, которое перестало действовать (lapsed), сохраняет status, но не является принятием риска.

Мера подтверждена как «Не пройдено»

Отправляйте оповещение, когда кто-либо подтверждает меру как «Не пройдено» (control_failed), чтобы кто-то занялся этой мерой.

type == "org_security_control_attestation_updated"
AND status == "control_failed"
AND actor.type != "system_actor"

Правило исключает system_actor по той же причине, что и в правиле Принят риск.

Подтверждение изменил кто-то вне списка разрешённых

Отправляйте оповещение, когда подтверждение записывает, изменяет, повторно сохраняет или снимает кто-то, кого нет в вашем списке людей, управляющих подтверждениями. Храните их значения user_id (allowed_user_ids) в вашей SIEM.

type == "org_security_control_attestation_updated"
AND actor.type != "system_actor"
AND NOT (actor.type == "user_actor" AND actor.user_id IN allowed_user_ids)

• Правило срабатывает на любого участника, кроме user_actor из списка или system_actor.
• Составляйте список по actor.user_id: actor.email_address — это адрес, который был у человека на момент записи активности (Сопоставление с вашей SIEM).

Один человек внёс много изменений в подтверждения

Отправляйте оповещение, когда один человек вносит за короткое время больше изменений в подтверждения, чем обычно для вашей организации. Порог 10 и окно в 1 час — это примеры; выберите оба значения исходя из вашей собственной активности.

type == "org_security_control_attestation_updated"
AND actor.type == "user_actor"
| group by organization_uuid, actor.user_id over a sliding 1 hour of created_at
| where count(distinct id) >= 10

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

Подтверждение автоматически перестало действовать

Рассматривайте активность lapsed как повод пересмотреть меру, которую она указывает.

type == "org_security_control_attestation_updated"
AND action == "lapsed"

Активность lapsed означает, что результат проверки меры или её текущее значение отличается от того, при котором было сохранено подтверждение, а не что прошла дата окончания (review_date). Она может поступить с опозданием.

Поддержание работоспособности правил при изменении значений

В любом из этих полей могут появиться новые значения.

• Определяйте автоматические изменения по actor.type, а не по значению actor.service.
• Не отбрасывайте активности, значение control, action или status которых не указано в правиле; новое значение action может записывать принятие риска. См. Справочник по событиям.

Проверка правила

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

Если вы храните эти активности как события Open Cybersecurity Schema Framework (OCSF), сопоставление их полей описано в разделе Сопоставление событий Security posture с OCSF.