Правила обнаружения

Платформа поставляется с 62 production-правилами: аутентификация и активность конечных точек, lateral movement, ransomware, разведка, command and control, обход защиты, кража учётных данных, облако и инсайдерская активность. Каждое называет свои техники MITRE ATT&CK и известные ложные срабатывания; у 56 из них есть тестовые события, доказывающие срабатывание, и события, доказывающие, что они молчат.

Каждый тенант получает свою копию каталога в разделе Правила. GET /api/rules/mitre-coverage показывает, какие техники ATT&CK покрывают правила, по тактикам.

Из чего состоит правило

{
  "rule_key": "core.auth.brute_force",
  "name": "Multiple Failed Authentication Attempts",
  "severity": "medium",
  "confidence_score": 80,
  "condition": {
    "event_type_any": ["auth_failure"],
    "tags_any": ["auth", "login_failure", "bruteforce", "password_spray"]
  },
  "mitre_attack": ["T1110"],
  "false_positive_notes": [
    "Misconfigured service accounts cycling expired passwords — check if source is a known service host"
  ],
  "recommended_actions": [
    "Check number of failures in the last 10 minutes for the same user and source IP"
  ]
}

rule_key читается как <домен>.<платформа>.<поведение>. Он же определяет, какой команде направляется алерт (см. Команды).

Как читаются условия

Чтобы правило сработало, должен выполниться каждый ключ условия. Внутри одного ключа достаточно любого из перечисленных значений.

Ключ	Выполняется, когда
event_type_any	Тип события — одно из значений
source_type_any	Событие пришло из одного из этих источников
tags_any	У события есть хотя бы один из этих тегов
field_contains	{"field": "process.command_line", "value": "-enc"} — поле содержит текст без учёта регистра
field_contains_any	Список таких проверок; выполняется хотя бы одна. Каждая может задать value или values.
field_contains_all	Список таких проверок; выполняются все
field_not_contains_any, field_not_equals_any, field_not_startswith_any	Поле не совпадает ни с одним значением — чтобы исключить известный доверенный путь
threshold	{"field": "...", "gte": 100} — число в поле не меньше gte
iocs_present	Событие несёт какой-либо индикатор компрометации
ioc_any, entity_any	Событие называет один из этих индикаторов или сущностей
local_ioc_reputation_any	Один из индикаторов события имеет такую репутацию в ваших данных об угрозах
any_of	Список целых условий; выполняется хотя бы одно

Поля ищутся сначала в нормализованном виде события, затем в сыром. Теги вроде port_scan или beaconing добавляются при поступлении события — см. Как работает обнаружение.

Изменение правил

Действие	Кто	Как
Выключить или включить правило	ANALYST	Переключатель в Правилах или PATCH /api/rules/{rule_key}/toggle
Изменить правило	ADMIN	PUT /api/rules/{rule_key} с изменяемыми полями
Добавить правило	ADMIN	POST /api/rules с rule_key, name, severity и condition
Удалить правило	ADMIN	DELETE /api/rules/{rule_key}

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

Должно выполниться каждое условие

Правило с event_type_any и tags_any срабатывает только на события этого типа и с одним из этих тегов. Условие, которому не удовлетворяет ни одно событие, не сработает никогда — проверьте новое правило через эндпоинт тестового события, прежде чем на него полагаться.

Шумные правила

Каждое подтверждение и отклонение засчитывается правилам, стоящим за алертом. GET /api/findings/rule-metrics/{rule_key} даёт число срабатываний правила, ложных срабатываний и их долю, а GET /api/findings/noisy-rules перечисляет правила, у которых не меньше 5 разобранных алертов, из них 30% и более отклонены (оба порога меняются через min_hits и fp_rate_threshold).

Чтобы остановить известный безвредный сценарий, не отключая правило, подавите его из отклонённого алерта: POST /api/findings/{id}/suppress-similar со scope — FINGERPRINT (именно этот алерт), RULE_KEY (это правило), ENTITY_KEY (этот хост или пользователь) — и duration_minutes (-1 — навсегда). Подавленные события всё равно сохраняются, и каждое записывается в журнал аудита, но алертов не поднимают.

Правила YARA

Правила YARA для сканера файлов управляются там же: GET /api/rules/yara, POST /api/rules/yara/upload, DELETE /api/rules/yara/{filename} и POST /api/rules/yara/reload.