Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» задаёт правовую рамку обеспечения безопасности КИИ и определяет контуры государственного реагирования. Официальная публикация закона доступна на государственном портале правовой информации. Также НКЦКИ (CERT-GOV-RU) указывает 187-ФЗ как правовую основу, которая «даёт определение ГосСОПКА, её силам и средствам».

При этом нормативные требования к представлению информации о компьютерных инцидентах в ГосСОПКА конкретизируются в подзаконных актах. В частности, приказ ФСБ России № 367 устанавливает перечень информации и порядок её представления, а на странице НКЦКИ подчёркивается обязанность передавать сведения о компьютерных инцидентах в НКЦКИ не позднее 24 часов с момента обнаружения и перечисляются способы передачи. Факт официального опубликования приказа отражён также в «Российской газете».

В инженерном плане это означает необходимость выстраивать не только детектирование, но и каналируемый, измеримый и устойчивый процесс подготовки и доставки событий безопасности: структурирование/нормализация телеметрии IDS, корреляция и дедупликация, надёжная доставка с подтверждениями и журналированием, измерение качества обнаружения и эксплуатационных характеристик доставки [1] [2] [3] [4].

В качестве источника телеметрии в статье рассматривается Suricata, так как она предоставляет документированный вывод событий через EVE-JSON и описывает его как «firehose approach» (единый поток журналов разных типов) [4].

Почему именно «узел обмена» поверх IDS

На практике IDS производит разнотипные события: сигнатурные срабатывания (alert), данные о потоках (flow), протокольные события (http, dns, tls), сообщения об аномалиях и т. п. Suricata прямо указывает, что EVE-вывод может включать alerts, anomalies, metadata, file info и протокольные записи и что наиболее распространённый вариант — «firehose», когда всё идёт в один файл [4] [5].

Если внешнему контуру (SOC/SIEM/центр реагирования) требуется стабильная структура данных и минимизация неоднозначности, «сырой» EVE-поток целесообразно преобразовывать в нормализованное внутреннее событие, которое:

– фиксирует обязательные атрибуты (время, тип, src/dst, критичность, идентификаторы корреляции);

– сохраняет ссылку на исходное событие (для аудита и расследований);

– имеет единый формат вне зависимости от конкретного event_type.

Особое значение имеет корреляция: поле flow_id в EVE-JSON предназначено для связи протокольных событий, flow-логов и «evidence» с alert-событиями и метаданными, относящимися к одной сессии/потоку. Это облегчает агрегацию событий вокруг инцидента и снижает шум в последующей аналитике [5].

Референсная архитектура узла обмена событий

Предлагаемая архитектура реализует конвейер:

1. Sensor (Suricata) →
2. Collector (потоковое чтение eve.json, NDJSON-парсинг, фильтрация типов) →
3. Mapper/Normalizer (маппинг полей, валидация схемы, присвоение event_id, опциональная дедупликация) →
4. Outbox (локальная очередь/журнал для устойчивости) →
5. Sender (доставка, ретраи, таймауты, журналирование) →
6. Receiver (приём, фиксация time_rcv, сохранение) →
7. Monitor (метрики качества и эксплуатации).

Outbox как основа устойчивости

Требование «не потерять событие при недоступности приёмника» в практических системах часто реализуется через outbox-паттерн: запись в локальную очередь перед отправкой и удаление только после подтверждения приёма. Такой механизм обеспечивает как минимум семантику at-least-once (с риском дублей, которые снимаются event_id и дедупликацией), что критично для последующего формирования доказуемой хронологии инцидента.

Что такое «корректное событие»

Для эксплуатационной пригодности важно отличать «принято» от «правильно сформировано». Поэтому вводится метрика корректности формата (например, доля событий, прошедших валидацию обязательных полей). Это упрощает контроль качества интеграционного слоя независимо от качества детектирования сенсора.

Метрики: качество детектирования и эксплуатационные характеристики

Метрики детектирования (DR, FRP)

Для оценки детектирования используются TP/FP/TN/FN. NIST IR 7972 даёт определение Detection Rate (DR) как TP/(TP+FN).

False Positive Rate (FPR) обычно задаётся как FP/(FP+TN); эта формула приведена, например, в справочной статье о FPR [9] [10].

На практике важно фиксировать единицу оценки: интервал атаки, поток (flow_id), сессия или иной объект. Иначе метрики превращаются в «счётчик алертов» и теряют интерпретируемость.

Метрика задержки AL95

Пусть — задержка доставки i-го события. Для оценки «хвоста» задержек используется 95-й процентиль: . NIST Dataplot определяет p-й процентиль как значение, ниже которого находится р % данных (и выше которого — (1-р) % данных) [8].

Процентильная метрика более устойчивая к выбросам и лучше отражается качество обслуживания при burst-нагрузках и кратковременных сбоях сети/приемника.

Воспроизводимая методика экспериментов

Данные и трафик

Для экспериментальных прогонов удобно использовать открытые наборы данных. Страница UNB/CIC описывает CSE-CIC-IDS2018: датасет организован по дням, включает сырые PCAP и логи по машинам, а также извлечённые признаки; допускается использование PCAP для собственного извлечения признаков.

Подача трафика на сенсор

Для реплея PCAP применяется tcpreplay. Документация показывает базовый запуск tcpreplay -i eth0 sample.pcap и управление скоростью через --mbps. Это позволяет проводить воспроизводимые прогоны и сравнивать конфигурации сенсора и интеграционного слоя [6].

План прогонов

Рекомендуемый набор прогонов (минимум):

– E1 (функциональный): проверка корректности маппинга и схемы, доля валидных событий.

– E2 (качество): расчёт DR/FPR на размеченных интервалах/flows [9].

– E3 (устойчивость доставки): недоступность приёмника → поведение outbox, потери, восстановление.

– E4 (нагрузка): рост интенсивности → распределение задержек, AL95.

Такая методика разделяет качество детектирования (зависит от правил и сенсора) и качество доставки/обмена (зависит от outbox/sender/receiver и сети), что упрощает инженерные выводы.

Обсуждение применимости к сценариям взаимодействия с ГосСОПКА

С точки зрения нормативного контекста ключевым является наличие процесса, который позволяет:

– своевременно формировать сведения об инцидентах,

– сохранять доказуемые артефакты (что было обнаружено, когда, какие меры предприняты),

– обеспечить соблюдение сроков и порядка представления сведений, установленных приказом ФСБ № 367 [3].

Предложенная архитектура не утверждает «соответствие ведомственному формату телеметрии», так как конкретные технические интерфейсы зависят от регламентов подключения. Однако она создаёт проверяемую основу для адаптации: нормализованный формат и маппинг позволяют настроить требуемые поля; outbox и журналирование — обеспечить доказуемость доставки; метрики — подтверждать качество обнаружения и эксплуатационную пригодность.

Архитектура узла обмена событий безопасности поверх Suricata позволяет отделить задачи детектирования от задач обмена и доставки: EVE-JSON даёт структурированный поток событий, flow_id обеспечивает корреляцию по сессиям/потокам, outbox-паттерн повышает устойчивость доставки, а связка метрик DR/FPR и AL95 делает систему измеримой. Нормативные требования к порядку представления информации об инцидентах в ГосСОПКА (в т. ч. сроки и способы направления) задают организационные ограничения, которым система обмена должна соответствовать на уровне процессов и доказуемых артефактов.

Литература:

1. Официальное опубликование: Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». https://publication.pravo.gov.ru/document/view/000120170726002 (дата обращения 10.03.2026)
2. НКЦКИ (CERT-GOV-RU). Правовые основания (187-ФЗ и др.). https://www.cert.gov.ru/materialy/pravovye-osnovaniya (дата обращения 10.03.2026)
3. НКЦКИ (CERT-GOV-RU). Приказ ФСБ России № 367: перечень и порядок представления информации в ГосСОПКА (в т. ч. указание на срок 24 часа). https://www.cert.gov.ru/materialy/pravovye-osnovaniya/prikaz-fsb-rossii-ot-24–07–2018-g-367-ob-utverzhdenii-perechnya-informatsii-predstavlyaemoy-v-gosso (дата обращаения 10.03.20.26)
4. Suricata Documentation. Eve JSON Output (описание EVE и «firehose approach»). https://docs.suricata.io/en/latest/output/eve/eve-json-output.html (дата обращения 11.03.2026)
5. Suricata Documentation. Eve JSON Format (flow_id и корреляция событий одного session/flow). https://docs.suricata.io/en/latest/output/eve/eve-json-format.html (дата обращения 11.03.2026)
6. tcpreplay Wiki. tcpreplay (реплей PCAP, параметр --mbps). https://tcpreplay.appneta.com/wiki/tcpreplay.html (дата обращения 11.03.2026)
7. UNB/CIC. CSE-CIC-IDS2018 Dataset (организация по дням, PCAP/логи, признаки). https://www.unb.ca/cic/datasets/ids-2018.html (дата обращения 11.03.2026)
8. NIST Dataplot Reference Manual. Percentile (определение p-го процентиля). https://www.itl.nist.gov/div898/software/dataplot/refman2/auxillar/percenti.htm (дата обращения 12.03.2026)
9. NIST IR 7972. Performance Metrics… (DR = TP/(TP+FN) и др.). https://nvlpubs.nist.gov/nistpubs/ir/2014/NIST.IR.7972.pdf (дата обращения 12.03.2026)
10. Wikipedia. False positive rate (FPR = FP/(FP+TN)). https://en.wikipedia.org/wiki/False_positive_rate (дата обращения 12.03.2026)