События безопасности (SIEM)

Status200 хранит события безопасности рядом с вашими логами, трассировками и метриками и приводит их все к одной форме, OCSF (Open Cybersecurity Schema Framework), в каком бы формате они ни пришли. Отправляйте события из любого источника, ищите по ним и находите важные с помощью правил обнаружения Sigma, аналитики угроз и мониторов. Найденное ими становится кейсами, которые нужно разобрать, а плейбуки реагируют на них.

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

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

Detections, ИИ и Connections, которые настраивают один раз, остаются свёрнутыми, пока вы их не откроете. Впервые работаете с безопасностью? Начало работы с безопасностью настраивает её в два клика.

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

Данные безопасности могут читать только роли Project Owner и Project Admin и три роли Security; остальные роли ничего не видят в Security Events. См. Роли.

Отправка событий безопасности#

1. Создайте ключ приёма#

   Откройте Настройки проекта → Телеметрия и APM → Ключи приема и нажмите Создать ключ приёма. События безопасности используют те же ключи, что и остальная телеметрия.

2. Отправьте события#

   Отправьте JSON на /security-events/v1/ingest с ключом в x-status200-token:

   OCSFGoogle UDMGeneric JSON

   OCSF

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=ocsf" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -H "x-status200-service-name: my-security-source" \
     -d '{ "events": [ { "class_uid": 3002, "severity_id": 4, "status": "Failure", "message": "Failed logon for alice", "actor": { "user": { "name": "alice" } }, "src_endpoint": { "ip": "203.0.113.7", "hostname": "laptop-alice" } } ] }'

   Google UDM

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=udm" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "metadata": { "event_type": "USER_LOGIN" }, "principal": { "hostname": "laptop-alice", "user": { "userid": "alice" }, "ip": ["203.0.113.7"] }, "security_result": [{ "severity": "HIGH", "action": ["BLOCK"] }] } ] }'

   Generic JSON

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "severity": "high", "event_type": "ssh_brute_force", "message": "12 failed SSH logins in 60s", "username": "root", "hostname": "web-01", "src_ip": "203.0.113.7" } ] }'

   Эндпоинт отвечает 200, как только события поставлены в очередь. Событие без времени, как эти, помещается в момент своего поступления.

3. Найдите их в разделе События#

   Откройте Продукты → Security Events → События. События появятся в течение нескольких секунд, с заполненными серьёзностью, классом, пользователем, хостом и IP-адресами.

Форматы#

Укажите формат через ?format=, через заголовок x-oneuptime-security-event-format или через поле "format" верхнего уровня. Если его не указать, формат каждого события определяется отдельно, так что один вебхук может смешивать обнаружения с необработанными событиями.

• Тело может быть одним событием, массивом событий или { "events": [...] }.
• Заголовок x-status200-service-name задаёт сервис телеметрии, к которому относятся события. Без него они относятся к сервису, названному по продукту или поставщику первого события, или к Security Events.
• Ничего не отбрасывается из-за того, что не удалось сопоставить: каждое поле источника попадает в атрибуты события.

Поля обычного JSON#

Обычное событие читается по распространённым именам полей:

Слово серьёзности становится уровнем OCSF: info читается как Informational, warning как Low, error как Medium, alert как Critical, а emergency как Fatal.

Пересылка через Fluent Bit#

Чтобы отправлять журналы безопасности, которые вы уже собираете, например auditd, syslog или Falco, добавьте в Fluent Bit вывод http:

[OUTPUT]
    Name             http
    Match            security.*
    Host             status200.ru
    Port             443
    tls              On
    URI              /security-events/v1/ingest
    Format           json
    Json_date_key    timestamp
    Json_date_format iso8601
    Header           x-status200-token YOUR_INGESTION_TOKEN
    Header           x-status200-service-name my-security-source
    Retry_Limit      5

На странице Руководство по настройке в разделе Connections есть эти фрагменты с вашими хостом и ключом.

Поиск событий безопасности в ваших логах#

Карточка Ваши логи вверху страницы Connections делает источником логи, которые вы уже отправляете в Status200. Когда Искать события безопасности в логах включён, новые логи проекта читаются каждую минуту, и каждый вход по SSH, команда sudo, запись аудита Kubernetes, изменение в AWS CloudTrail и веб-атака в них сохраняются как событие безопасности. Что охватывает каждый вид, см. в Начало работы с безопасностью.

Подключение продукта безопасности#

Connections опрашивает продукт безопасности за вас и импортирует его новые записи как события безопасности. Подключение хранит настройки продукта и зашифрованные учётные данные; воркер опрашивает его с заданным вами интервалом и пропускает уже импортированные записи.

• Собственные оповещения продукта с уровнем не ниже Open Cases From (Высокий и выше, если вы не выберете другой уровень или Никогда) открывают кейсы, сгруппированные по пользователю, хосту или адресу, к которым они относятся.
• Подключение читает записи по времени, когда продукт их создал, а не по времени описываемой ими активности. Правило SIEM, которое выполняется раз в час, создаёт обнаружения намного позже совпавших событий, и они всё равно импортируются.
• Первый опрос заглядывает на 24 часа назад, поэтому новое подключение сразу показывает недавние записи.
• Проверить подключение в строке подключения проверяет доступ к продукту и работу собственных воркеров Status200 и ничего не импортирует. Run now выполняет опрос немедленно.

Что содержит событие#

Каждое событие хранится с типизированными полями и исходными данными источника:

Обзор событий безопасности#

События — обозреватель телеметрии, как обозреватели логов и трассировок: график событий окна по серьёзности, боковая панель фасетов, список и панель со всеми полями и атрибутами открытого события. Окно, фильтры и поиск хранятся в URL, поэтому отфильтрованным представлением можно поделиться, и оно переживает обновление страницы.

Поиск#

Строка поиска понимает тот же язык, что и другие обозреватели телеметрии (см. Синтаксис поиска):

Поле — это либо краткое имя (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique), либо собственное имя поля, например severityName или principalHost. Любое другое имя читается как атрибут источника. observable:<value> находит каждое событие, где упоминается значение, на какой бы стороне активности оно ни было.

Фасеты#

Боковая панель подсчитывает события окна по полям Источник, Серьёзность, Класс событий, Category, Активность, Статус, Поставщик, Продукт, Detection Rule, Пользователь-источник, Хост-источник, Процесс и Родительский процесс. Нажмите на значение, чтобы оставить только его события, или на минус рядом, чтобы исключить их. Нажмите ещё раз, чтобы отменить. График и каждый подсчёт описывают ровно события из списка.

Корреляция#

Коррелировать рисует события вокруг хоста, пользователя или IP-адреса: их классы событий вокруг искомого значения, отмеченные худшей серьёзностью, и другие значения из тех же событий на внешнем кольце. Нажмите на класс, чтобы вывести список его событий, или на значение, чтобы затем коррелировать по нему. Каждый observable на панели события в разделе События открывает по нему Коррелировать.

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

Правило обнаружения — это правило Sigma, открытый формат YAML для описания подозрительной активности, которое Status200 по расписанию выполняет над вашими событиями. При совпадении оно открывает кейс или добавляет совпадение в уже открытый, открывает оповещение, при желании инцидент, и записывает Detection Finding обратно в события. В Rule Library есть готовые правила, с которых можно начать.

Создайте правило#

Первое правило, которое срабатывает на неудачные входы не из 10.x.x.x:

title: Failed logon burst
description: Repeated authentication failures from one source.
level: high
tags:
  - attack.t1110
  - attack.ta0006
detection:
  selection:
    className: Authentication
    statusName: Failure
  filter_internal:
    principalIp|startswith: '10.'
  condition: selection and not filter_internal

Что может выразить правило#

Status200 выполняет булево ядро Sigma:

• Выборки — это наборы полей (должно совпасть каждое поле; список значений совпадает с любым из них) или списки ключевых слов, которые совпадают в любом месте сообщения.
• Условия объединяют выборки через and, or, not и скобки или через 1 of selection_*, all of selection_*, any of them и all of them.
• Модификаторы полей: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists и windash. Текст сравнивается без учёта регистра, если вы не добавите cased.
• Поле — это типизированное поле (principalUser), распространённое написание такого поля в Sigma (CommandLine, src_ip, Hostname) или любой ключ атрибута в том виде, в каком он записан в событии (threat.matched).
• Image и CommandLine читают процесс, о котором событие: при запуске процесса — запущенный процесс (processPath, processCommandLine), а ParentImage и ParentCommandLine — процесс, который его запустил (parentProcessPath, parentProcessCommandLine). principalProcess — это процесс, который действовал, то есть при запуске — родительский.
• level задаёт серьёзность: informational, low, medium, high или critical, а при отсутствии — medium. ID ATT&CK в tags (attack.t1110, attack.ta0006) заполняют поля MITRE находки.

Агрегации вроде | count() by principalIp > 5 отклоняются при сохранении: используйте вместо них правило корреляции или Group By Field и Match Count Threshold. logsource носит только информационный характер и ничего не сужает: поместите такой фильтр в выборку, например className: Authentication. timeframe игнорируется, потому что окно задаёт интервал правила.

Правила корреляции#

Корреляция Sigma срабатывает на несколько событий вместе, а не на одно. Вставьте её в Sigma Rule (YAML) вместе с правилами, которые она читает, как YAML-документы, разделённые ---, или назовите правила, которые в проекте уже есть, по их name или id в Sigma. В Rule Library есть готовые, например неудачные входы, за которыми следует успешный.

title: Failed sign-ins, then a success from the same address
level: high
correlation:
  type: temporal_ordered
  rules:
    - failed_sign_ins
    - successful_sign_in
  group-by:
    - principalIp
  timespan: 10m
---
title: Five failed sign-ins
name: failed_sign_ins
correlation:
  type: event_count
  rules:
    - failed_sign_in
  group-by:
    - principalIp
  timespan: 10m
  condition:
    gte: 5
---
title: Failed sign-in
name: failed_sign_in
detection:
  selection:
    className: Authentication
    statusName: Failure
  condition: selection
---
title: Successful sign-in
name: successful_sign_in
detection:
  selection:
    className: Authentication
    statusName: Success
  condition: selection

• Группа — это значение полей group-by, например один адрес. Подсчёт скользящий: всплеск, который поделили два запуска, всё равно считается целиком в пределах своего timespan, а он не больше 24 часов.
• new_value — собственный тип Status200, потому что в Sigma нет корреляции «впервые замечено»: он сравнивает с историей до 30 дней. value_sum, value_avg, value_percentile и value_median отклоняются при сохранении.
• Столбец Тип в Detection Rules называет вид каждого правила, а форма одним предложением говорит, что ищет правило.

Настройки оценки#

Group By и Distinct Count принимают те же имена полей, что и правило. С ними порог означает «столько-то от одного и того же за один запуск», без монитора поверх:

Когда выполняется правило#

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

• Окна идут встык и не скользят. При интервале 10 минут ошибки в 09:58 и 10:01 могут попасть в разные запуски и считаться отдельно, поэтому оставляйте запас при выборе порога.
• После перерыва, например сбоя воркера или повторного включения правила, следующий запуск покрывает весь перерыв, но не больше последних 24 часов.
• Событие, пришедшее с опозданием больше чем на две минуты, когда запуск уже охватил его время, сохраняется и доступно для поиска, но это правило его никогда не прочитает.
• Каждая группа, достигшая порога, становится Detection Finding, до 10 000 за запуск. Оповещения, инциденты и кейсы открываются для 100 групп с наибольшими подсчётами; остальные делят один кейс о правиле, а Последняя ошибка правила говорит, сколько групп совпало.

Серьёзность#

level правила — это серьёзность его находок: informational, low, medium, high и critical становятся Informational, Low, Medium, High и Critical. Его оповещения и инциденты получают одну из серьёзностей вашего проекта в таком порядке:

1. Серьёзность оповещения (или Серьёзность инцидента) правила, если она задана.
2. Ваша серьёзность, названная по уровню, например High, без учёта регистра.
3. По рангу: правила critical и high получают вашу самую высокую серьёзность, остальные — самую низкую.

Оповещения и находки#

Каждая сработавшая группа открывает оповещение с заголовком [Detection] <rule name> — <group value> или [Detection] <rule name> для правила без Group By Field. Пока оно открыто, новые совпадения для этой группы не открывают нового. Правило видит только совпадения и не может понять, что атака прекратилась, поэтому его оповещения остаются открытыми, пока кто-нибудь их не закроет.

Detection Finding — это событие безопасности класса Detection Finding (класс OCSF 2004) от продукта Status200 Detections, с тегами MITRE правила, значением группы первым в observables и такими атрибутами:

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

Мониторы событий безопасности#

Монитор событий безопасности подсчитывает события, подходящие под его фильтры, в скользящем окне и применяет к подсчёту обычные критерии мониторов: меняет статус монитора, открывает оповещения или инциденты и вызывает дежурных. Создайте его в Мониторы → Создать монитор с типом Security Events; он отображается там вместе с другими вашими мониторами.

Его форма показывает Monitor events that include this text, Monitor Security Events for (time), Event Severity и Класс событий. Фильтровать по сервису телеметрии и Фильтровать по атрибутам находятся в разделе Дополнительные поля, заголовок которого показывает, какие из них использует монитор. Его критерии проверяют Security Event Count.

Само обнаружение пишите как правило с его порогом. Используйте монитор, когда нужны скользящее окно, статус, который восстанавливается сам, страница статуса или разные политики дежурств для разных критериев.

Следите за своими обнаружениями#

Находки — это события, поэтому монитор может следить за самими правилами:

• Шквалы: монитор по классу Detection Finding, считающий каждую находку. Двадцать разных правил, сработавших за час, — сигнал, который не увидит ни одно правило по отдельности.
• Изменения частоты: фильтр по status200.detection.rule_id одного правила. Правило, которое срабатывает раз в неделю, а теперь срабатывает пятьдесят раз в час, требует другой реакции.
• Тишина: если находок, которых обычно несколько, становится ноль, чаще всего это значит, что источник перестал отправлять данные. Используйте критерий, который проверяет, что подсчёт ниже заданного числа.

Действие Создать монитор в строке правила открывает новый монитор, уже настроенный таким образом: класс Detection Finding, ID правила (никогда не его имя, которое изменилось бы при переименовании) и последний час. Такой монитор считает находки, по одной на группу за запуск, а не события за ними. Чтобы требовать определённое число событий до срабатывания, используйте Match Count Threshold правила.

Аналитика угроз#

Threat Intel подписывается на фиды STIX/TAXII с известными вредоносными IP-адресами, доменами, URL, адресами электронной почты и хешами файлов. События, где упоминается одно из этих значений, при поступлении помечаются атрибутами threat.*, по которым могут фильтровать правила и мониторы, а каждую минуту недавние события сверяются с фидами и открывают оповещения и находки так же, как правило. См. Аналитика угроз.

Хранение и оплата#

События безопасности оплачиваются за каждый принятый ГБ, как и остальная телеметрия, и хранятся в течение срока хранения телеметрии: Срок хранения по умолчанию (дни) проекта в Настройки проекта → Телеметрия и APM → Хранение данных или срок хранения, заданный для сервиса телеметрии, к которому они относятся. Когда срок хранения события истекает, оно удаляется.

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

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