Проблема
В реальных SOC часто есть почти всё: Suricata, Zeek, osquery/Fleet, sysmon-like events, application logs. Но ответа на простой вопрос всё равно нет, потому что поля несогласованы, таймстемпы плавают, owner не назначен, а сценарий поиска не формализован.
Ещё одна проблема - стоимость. Сбор каждого дополнительного поля или потока кажется маленьким решением, пока на нём не вырастает дорогое хранение, шумные парсеры и тяжёлые enrichment-пайплайны.
Решение
Полезно относиться к телеметрии как к продукту. Для каждого источника нужен короткий контракт: какие вопросы он закрывает, какие поля критичны, какая допустимая задержка, как выглядит деградация качества и кто принимает решение об изменении схемы.
Хорошая defensive-практика отделяет baseline telemetry от expensive burst collection. Обычный день и first-response режим - это разные профили, и их не надо смешивать.
Что проверить руками
- Составить таблицу 'вопрос -> источник -> обязательные поля -> owner -> стоимость'.
- Проверить, какие alert-ы зависят от полей, за которые никто не отвечает.
- Разделить постоянный ingest и временный burst-mode для расследования.
- Для каждого источника определить минимальный набор quality-checks: timestamp, host identity, event count, parser failures.
Типичные ошибки
- Считать, что чем больше логов, тем зрелее SOC.
- Не измерять цену enrichment и хранения при добавлении нового источника.
- Не тестировать сценарий деградации, когда поле пропало, а правило всё ещё 'работает'.
Defensive checklist
- У каждого важного источника есть owner и минимальный quality-contract.
- Детектирование знает, какие поля являются hard requirement.
- Есть разница между normal ingest и burst collection.
- Parser/field drift отслеживается отдельно от incident noise.
Безопасный пример кода
Минимальный контракт телеметрии в JSON. Пример рассчитан на owned/lab-среду и показывает инженерную логику проверки, а не эксплуатационную цепочку.
{
"source": "suricata_eve",
"questions": [
"Which external IP talked to the host?",
"Was a DNS tunnel suspicion tied to the same asset?"
],
"required_fields": ["timestamp", "src_ip", "dest_ip", "event_type", "host.name"],
"owner": "soc-platform",
"latency_slo_seconds": 60,
"quality_checks": ["event_count_baseline", "parser_failures", "field_presence"]
}Как это должно попасть в отчёт
- Таблица контрактов для ключевых источников.
- Список рискованных зависимостей правил от нестабильных полей.
- Ретест: сценарий деградации поля не проходит незаметно.