«ГосСОПКА — это не ящик для отчётов. Это система, которая превращает разрозненные сбои в единую карту киберугроз. Если ты подал шум вместо сигнала, карта станет бесполезной, а сосед по отрасли не увидит надвигающуюся атаку, пока она не дойдёт до него. Твоя оперативность и точность — это его заблаговременное предупреждение.»
Граница инцидента: что превращает сбой в событие КИИ
Формальный критерий — Приказ ФСТЭК России №169. Суть в том, что статус события определяется не технической сложностью атаки, а её потенциальным влиянием на критически важный процесс. Один и тот же доступ к серверу — это внутренняя проблема, если там тестовый стенд, и событие КИИ, если сервер управляет энергоснабжением района.
Фокус смещён с инструментов на последствия: угрозу национальной безопасности, экономической стабильности или жизнеобеспечению населения.
Типы инцидентов: признаки, которые часто упускают
Законодательство говорит о четырёх типах. На практике их границы размыты, и ключ — в контексте:
| Тип инцидента | Что важно понимать, кроме очевидного |
|---|---|
| Несанкционированный доступ | Сюда входят не только успешные проникновения, но и целенаправленные попытки с использованием привилегированных учётных записей или уязвимостей в системах КИИ. Особый риск — доступ к данным, чья утечка наносит системный ущерб: персональные данные лиц под особым контролем, технологические схемы, данные о транспортных потоках. Попытка подбора пароля к учётке администратора SCADA — уже инцидент, даже если она не удалась. |
| Нарушение целостности | Это любое изменение конфигураций, алгоритмов или логики работы систем без санкции. Вредоносное ПО — лишь частный случай. Несогласованная модификация ПО, ведущая к искажению управляющих сигналов, также считается инцидентом, даже если последствия были мгновенно нейтрализованы. Сюда же попадает подмена прошивки на сетевом оборудовании объекта КИИ. |
| Отказ в обслуживании | Критерий — не просто недоступность сервиса, а нарушение функций, от которых зависит безопасность. Простой корпоративного сайта — не инцидент КИИ. А вот недоступность системы экстренного оповещения, диспетчерской службы аэропорта или автоматики на объекте ТЭК — безусловно, является. Важен контекст критичности функции. |
| Утечка информации | Любое неправомерное перемещение данных за пределы защищённого контура. Учитывается не только факт изъятия, но и категория данных. Перехват незашифрованного трафика между узлами КИИ, даже если злоумышленник им не воспользовался, уже считается инцидентом, поскольку нарушена конфиденциальность. Массовый вывоз данных через уязвимость в веб-интерфейсе — классический пример. |
Категория объекта КИИ в реестре ФСТЭК определяет не только меры защиты, но и жёсткие сроки оповещения. Для объектов 1-й категории уведомление должно поступить в течение 24 часов с момента выявления, для 2-й категории — 72 часа. Просрочка — это не только административный риск. Она создаёт «слепое пятно» в оперативной картине: пока ты разбираешься, аналогичная атака может быть совершена на другой объект отрасли.
Подключение к ГосСОПКА: три слоя, которые нельзя проигнорировать
Подключение — это не разовая настройка «кнопки отправки». Это постоянный процесс, построенный на трёх уровнях. Провал на любом из них сводит работу системы к простой формальности.
Слой 1: Сбор и фильтрация событий
Это отправная точка. SIEM-система здесь — не просто сборщик логов, а фильтр, выделяющий события по критериям Приказа №169. Без чётких правил корреляции в ГосСОПКА уходит информационный шум, который невозможно анализировать.
Помимо базовых метаданных (источник, время, пользователь), критически важен контекст: был ли доступ авторизованным по усиленной аутентификации, затрагивал ли он данные особой категории, происходил ли в нерабочее время. Интеграция с системами анализа поведения (UEBA) помогает выявлять сложные атаки, маскирующиеся под легитимную активность.
Слой 2: Защищённый шлюз передачи данных
Это канал с гарантированной доставкой. Он должен быть построен на сертифицированном СКЗИ. Ключевая функция — обеспечить доставку сообщения даже при нестабильном канале связи. Это подразумевает локальную очередь сообщений, механизмы повторной отправки и контроль состояния соединения.
Используется протокол HTTPS/TLS версии 1.2 или выше с обязательной двусторонней аутентификацией по сертификатам от аккредитованного УЦ. Идентификатор объекта КИИ из реестра ФСТЭК проставляется в каждое сообщение автоматически, что исключает ошибки ручного ввода.
Слой 3: Внутренние процессы реагирования
Передача данных в ГосСОПКА не отменяет необходимости собственного плана реагирования. Этот план должен чётко распределять роли: кто анализирует, кто принимает решение об изоляции угрозы, кто является контактным лицом для регулятора.
Интеграция шлюза с системой управления инцидентами (ITSM) позволяет автоматически создавать задачи, отслеживать сроки устранения и формировать отчёты. Обратная связь от НКЦКИ — рекомендации и данные о схожих атаках — должна не просто архивироваться, а встраиваться в процессы обновления политик безопасности и правил корреляции в SIEM.
Технические протоколы: как данные попадают в систему
Взаимодействие с ГосСОПКА строится на строгой стандартизации, исключающей разночтения. Основные компоненты:
| Элемент | Требования и скрытые сложности |
|---|---|
| Формат данных | IODEF (Incident Object Description Exchange Format) — структурированный XML. Обязательные поля: тип инцидента, точная временная метка в UTC, идентификатор объекта КИИ, описание. Пропуск обязательных полей ведёт к отклонению сообщения системой. Сложность — корректное заполнение сложных структур данных об атаке. |
| Канал передачи | Защищённое TLS-соединение. Аутентификация — клиентский сертификат от аккредитованного УЦ. Недостаточно просто его получить: срок действия, алгоритмы шифрования и настройки хранилища ключей должны соответствовать требованиям ФСТЭК. Просроченный сертификат оборвёт всю связь. |
| Механизм доставки | Используется подтверждение доставки (ACK/NACK). Если шлюз не получил ACK, он обязан выполнить серию повторных попыток. Отсутствие механизма повторной отправки или его некорректная настройка — типичная причина «потери» инцидента. |
| Идентификация | Уникальный идентификатор объекта должен строго совпадать в заголовке HTTP-запроса и в теле IODEF-сообщения. Несоответствие — автоматический повод для отклонения. Это частая ошибка при ручном формировании тестовых сообщений. |
Сценарий из практики: атака на медицинскую информационную систему
Обнаружение. SIEM фиксирует аномалию: 47 попыток доступа к базе диагнозов с одной учётной записи медработника в 03:00, за которыми последовал экспорт 1200 полных медицинских карт. Срабатывает правило корреляции, основанное на времени (ночные часы) и объёме данных, многократно превышающем обычные рабочие операции.
Классификация. Аналитик проверяет контекст. Экспортированные данные включают информацию о пациентах, подпадающих под особые категории (например, ВИЧ-статус). Система относит событие к типу «несанкционированный доступ к данным высокой конфиденциальности». Объект КИИ (региональная медицинская система) имеет 2-ю категорию, что устанавливает срок на передачу информации — 72 часа.
Формирование сообщения. Автоматически генерируется IODEF-сообщение. Оно включает: идентификатор объекта КИИ, тип инцидента, детали (временные метки, IP-адрес, учётная запись), категорию данных («Сведения, составляющие врачебную тайну») и контекст о массовом характере выгрузки в нерабочее время.
Передача и реакции. Шлюз отправляет сообщение и получает подтверждение (ACK) от ГосСОПКА. Параллельно автоматически запускаются внутренние процедуры: блокировка скомпрометированной учётной записи, изоляция источника атаки в сети, уведомление службы безопасности, создание задачи в ITSM для отслеживания расследования. У регулятора появляется информация для формирования предупреждений другим медучреждениям.
Ошибки, которые обесценивают работу с системой
- Передача необработанных логов. Отправка всех событий из SIEM без фильтрации приводит к перегрузке канала и делает невозможным выделение значимых инцидентов на стороне НКЦКИ. Система становится «слепой».
- Ошибка в категории объекта КИИ. Некорректное определение категории в реестре ведёт к нарушению сроков оповещения. Передача данных по объекту 1-й категории за 72 часа вместо 24 — формальная просрочка со всеми вытекающими.
- Игнорирование подтверждений доставки. Отправка сообщения без контроля получения ACK. При сбое связи инцидент не будет зарегистрирован, но в организации посчитают обязанность выполненной. Нужна настройка алертинга на NACK или таймаут.
- Отчётность вместо реагирования. Формальная отправка данных без запуска внутреннего расследования и устранения угрозы. Это создаёт риски повторных атак и противоречит принципу непрерывного повышения защищённости, заложенному в 152-ФЗ.
- Изолированность шлюза. Отсутствие интеграции шлюза ГосСОПКА с внутренними системами управления инцидентами разрывает процесс: данные ушли, но внутреннее реагирование не формализовано, сроки не отслеживаются, обратная связь от регулятора не поступает к ответственным.
Суть подхода
ГосСОПКА — это компонент коллективной киберобороны. Её ценность прямо пропорциональна качеству и оперативности поступающих данных. Каждый некорректно переданный или пропущенный инцидент ослабляет общую картину угроз. Ошибки здесь — это не просто риск штрафов. Это брешь в системе раннего предупреждения для всей отрасли. Подход «отчитались и забыли» не просто неэффективен — он создаёт системные риски там, где их можно было предотвратить.