Перейти к основному содержимому

SimpleZero Detect

Актуально для: SimpleZero Detect, конвейер SIEM · Проверено: 09.11.2026

SimpleZero Detect — своя SIEM платформы: сбор событий на площадке клиента, нормализация, корреляция по правилам и хранение событий. Хранилище построено на ClickHouse, события нормализуются в открытую схему OCSF, правила пишутся в формате Sigma. Поэтому контент обнаружения не привязан к одному поставщику, и его можно переводить в другие SIEM.

Конвейер​

источники → siem-collector → siem-ingest → siem-bus ─┬─→ siem-correlator → алерты → SOC
                                                     └─→ siem-store → ClickHouse → siem-search

Шина отдаёт один поток двум независимым потребителям: корреляция и хранилище не ждут друг друга. Новое правило по прошедшим дням (ретроспективный поиск) выполняется запросом к хранилищу.

Сбор: siem-collector​

  • Syslog по UDP, TCP и TLS. Разбираются RFC 5424 и RFC 3164, включая точное время rsyslog. Поток TCP делится на сообщения по RFC 6587 — подсчётом октетов или переводом строки.
  • Ничего не теряется при разборе. Нечитаемая строка становится событием с исходным текстом, а не пропадает.
  • Событие нормализуется в класс OCSF и получает идентификатор — по нему хранилище отбрасывает дубли, а алерты ссылаются на события.
  • Буфер на диске. Пачка лежит на диске, пока приём её не подтвердит, и переживает перезапуск сборщика. Каждая пачка — отдельный файл, записанный через fsync и переименование. Порядок пачек сохраняется, при переполнении вытесняются самые старые, отвергнутые приёмом пачки откладываются в rejected/. Размер буфера рассчитывается на 72 часа среднего потока площадки — обрыв связи с вечера пятницы до утра понедельника; каждый из двух сборщиков площадки рассчитан на весь её поток.
  • Сборщик проверяет приём по сертификату своего УЦ.

Приём: siem-ingest​

  • По токену сборщика определяет клиента и его сроки хранения и проставляет их в каждое событие.
  • Отвечает сборщику только тогда, когда пачку держит шина, — подтверждённая пачка уже не потеряется.
  • Сроки хранения по типу источника: у клиента может быть своя пара «горячих» и общих дней для каждого типа источника: например, события Windows — 2 дня в горячем слое и 7 всего, UserGate — 1 и 14. Неназванные типы получают сроки клиента. siem-ingest retention показывает таблицу сроков, siem-ingest retention sql — запросы, которые пересчитывают сроки уже сохранённых событий.

Шина: siem-bus​

  • NATS JetStream, три узла, каждое сообщение в трёх копиях; поток хранится 24 часа — запас на время, пока хранилище или корреляция недоступны.
  • Доли потока. Каждый клиент закреплён за долей в таблице долей шины. Новый клиент попадает в наименее нагруженную долю, перенос — явная операция siem-ingest shares move.
  • Пачка на шине — сжатые gzip строки JSON; одно событие занимает 120–150 байт.

Корреляция: siem-correlator​

  • Правила Sigma: поиск по полям и ключевым словам, модификаторы, условия, logsource.
  • Корреляции Sigma v2: event_count, value_count, temporal, temporal_ordered — окна по времени самого события. Клиент всегда входит в группировку, поэтому окно не смешивает события разных клиентов. На всплеск — один алерт.
  • Неподдерживаемое отвергается при загрузке правила, а не пропускается молча.
  • Несколько корреляторов делят доли потока через аренду в хранилище ключей шины (срок 30 секунд): доли делятся поровну между живыми узлами, доли остановленного или упавшего узла переходят выжившим. siem-correlator leases показывает, кто что держит.
  • Окна восстанавливаются при старте: коррелятор перечитывает из шины последнее окно, поэтому перезапуск не теряет алертов. Повторный алерт получает тот же идентификатор и схлопывается в таблице алертов.
  • Первые правила: перебор паролей SSH и успешный вход после перебора, перебор и распыление паролей Windows, закодированные команды PowerShell.

Хранилище: siem-store​

  • Одна широкая таблица событий для всех клиентов: время события и время получения, клиент, тип источника, класс, действие, результат, важность, хост, пользователь, процесс, командная строка, файл, хэш, URL, адреса и порты, исходный текст и остальные поля.
  • Ключ сортировки — клиент, класс, время: запрос почти всегда про одного клиента, один класс и интервал времени. Разбиение по дням.
  • Индексы: полнотекстовый — по исходному тексту и командной строке; фильтры Блума — по пользователю, хосту, адресам и хэшу.
  • Слои хранения. Через заданное число дней события уходят из горячего слоя в холодный (второй диск или S3), по истечении срока хранения удаляются.
  • Сроки — настройка каждого клиента. Новые события получают новые сроки сразу; для уже сохранённых пересчёт выполняется операцией только по этому клиенту. Сокращение срока удаляет данные, поэтому консоль показывает, сколько будет удалено, и просит подтверждения. Изменение попадает в аудит.
  • Удержание по требованию (legal hold) останавливает удаление событий клиента независимо от сроков.
  • Доступ по клиентам. Каждый запрос фильтруется политикой строк ClickHouse: аналитик видит своих клиентов, роль портала клиента — только его события.
  • Алерты хранятся в отдельной таблице: правило, важность, клиент, сущности, окно и ссылки на события, совпавшие с правилом. Кейсы SOC ссылаются на алерты.

Рабочее место аналитика: язык запросов по нормализованным полям, полнотекстовый поиск, сохранённые поиски, хронология пользователя, хоста или адреса. У каждой роли есть лимиты на время и память запроса, чтобы один тяжёлый поиск не останавливал остальные.

Размер установки​

Профили «Пилот», «Стандарт» и «MSSP», поведение при отказах и замеры пропускной способности — в разделе Архитектура и роли.