Пункт 7.13 приложения 3 к ПТКЗИ: обнаружение и предотвращение вторжений

Смысл требования

Пункт 7.13 приложения 3 к ПТКЗИ – практический разбор требования «обнаружение вторжений». Пункт 7.13 требует обнаруживать и предотвращать вторжения при внутреннем и внешнем сетевом взаимодействии.

Межсетевой экран разрешает соединение по адресу и порту, но не всегда понимает, что происходит внутри разрешённого трафика. IDS/IPS анализирует содержимое и поведение, чтобы выявлять эксплуатацию уязвимостей, сканирование и известные шаблоны атак.

IDS обычно сообщает, IPS может автоматически блокировать. На практике продукт сочетает оба режима, а организация определяет, где допустима автоматическая реакция.

Формулировка требования

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

Нормативная формулировка короче реального процесса. Для внедрения её необходимо разложить на объекты контроля, технические меры, роли, периодические действия и доказательства результата.

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

Обязательность применения

Требование обязательно для классов 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп. Для классов 4-ин, 4-спец, 4-бг, 4-юл и 4-дсп оно является рекомендуемым.

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

Рекомендуемый статус для отдельных классов не означает отсутствия риска. Решение о реализации или неприменении должно учитывать архитектуру, критичность и возможные последствия.

Что должна обнаруживать и предотвращать система

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

Не каждое событие следует сразу блокировать. Ошибочное срабатывание на критичном приложении может остановить работу, поэтому правила сначала тестируются в режиме обнаружения.

Сигнатуры регулярно обновляются, но дополняются аномальным и поведенческим анализом. Только известные шаблоны не охватывают модифицированные и новые атаки.

• Сканирование и разведку узлов, портов и служб.
• Эксплуатацию известных уязвимостей ОС, web и СУБД.
• Аномальные протоколы и туннелирование.
• Попытки обхода аутентификации и подбор.
• Командные каналы и вредоносные адреса.
• Внутреннее перемещение по SMB, RDP, SSH и другим протоколам.
• Передачу вредоносного содержимого и признаки DoS.

Практическая реализация должна учитывать штатный, аварийный и восстановительный режимы. Мера, которая работает только при нормальной эксплуатации, может оказаться бесполезной во время реального инцидента.

Размещение и настройка средств обнаружения вторжений

Сенсор должен видеть значимый трафик. Неправильное место установки оставляет внутренние потоки или DMZ вне анализа.

Шифрование ограничивает видимость. Сенсор размещается после расшифрования VPN/TLS либо использует метаданные и интеграцию с конечными узлами.

Настройки адаптируются к нормальному поведению конкретной ИС. База производителя является исходной точкой, но без настройки создаёт лишние события.

• Внешний периметр и публичные сервисы.
• Граница DMZ и внутренней сети.
• Пользовательские и серверные сегменты.
• Управляющий контур и привилегированные протоколы.
• East-west трафик виртуальной инфраструктуры.
• Удалённый доступ после расшифрования VPN.
• SPAN/TAP, inline или облачное зеркалирование.

Полезно заранее определить измеримый критерий качества: свежесть копии, долю обновлённых активов, отсутствие прямой связности, число необоснованных правил или время реакции. Такой показатель делает процесс контролируемым.

Что следует подтвердить при проверке

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

• Архитектуру сенсоров и область видимости каждого;
• Режимы IDS и IPS и условия автоматической блокировки;
• Актуальность сигнатур и правил;
• Соответствие политик реальным протоколам;
• Примеры событий, приоритизации и передачи ответственному;
• Блокировку или действие связанного средства;
• Обоснованные исключения и обработку ложных срабатываний;
• Результат безопасного тестирования видимости и реакции.

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

Выборка должна охватывать разные типы активов и сегментов. Один корректно настроенный объект не подтверждает выполнение требования во всей установленной границе.

Для практического контроля полезно назначить владельца показателя, определить источник данных и установить периодичность анализа. Тогда несоответствие становится не просто замечанием, а задачей с ответственным, сроком и проверяемым результатом.

Для практического контроля полезно назначить владельца показателя, определить источник данных и установить периодичность анализа. Тогда несоответствие становится не просто замечанием, а задачей с ответственным, сроком и проверяемым результатом.

Для практического контроля полезно назначить владельца показателя, определить источник данных и установить периодичность анализа. Тогда несоответствие становится не просто замечанием, а задачей с ответственным, сроком и проверяемым результатом.

Для практического контроля полезно назначить владельца показателя, определить источник данных и установить периодичность анализа. Тогда несоответствие становится не просто замечанием, а задачей с ответственным, сроком и проверяемым результатом.

Для практического контроля полезно назначить владельца показателя, определить источник данных и установить периодичность анализа. Тогда несоответствие становится не просто замечанием, а задачей с ответственным, сроком и проверяемым результатом.

Что закрепить в ТЗ, ЛПА и ОРД

Документы должны устанавливать устойчивые правила, а не переписывать интерфейс конкретного продукта. Тогда процесс сохранится после замены оборудования или программного обеспечения.

• Контролируемые зоны и потоки;
• Режимы IDS/IPS и условия автоматической блокировки;
• Обновление сигнатур и контроль ошибок;
• Уровни событий и сроки реакции;
• Оформление и пересмотр исключений;
• Интеграцию с SIEM, МЭ, EDR или системой заявок;
• Методику безопасного тестирования;
• Контроль работоспособности сенсоров и полноты трафика.

Для каждого действия следует определить инициатора, согласующего, исполнителя и контролирующее лицо. Если эти роли не распределены, фактическая реализация зависит от личной инициативы администратора.

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

Типичные ошибки

Типичные ошибки возникают, когда мера существует только в документах либо реализована на части активов.

• Сенсор видит только интернет, а внутреннее перемещение не контролируется;
• Система работает в IDS, но события никто не обрабатывает;
• Сигнатуры и движок давно не обновлялись;
• Все правила включены в блокировку без настройки;
• Исключение отключает слишком широкий класс атак;
• Шифрованный трафик не учтён;
• Нет контроля того, что SPAN/TAP или сенсор перестал получать данные.

Исправление следует начинать с определения фактического охвата и сравнения его с документами. После этого устраняется разрыв между требованиями, настройками и повседневными действиями.

Отсутствие выявленных отклонений в течение длительного времени не всегда означает идеальный порядок. Иногда это признак того, что контроль не выполняется или охватывает не всю систему.

Связанные материалы

• Пункт 7.12: межсетевое экранирование.
• Пункт 1.3: централизованный сбор событий.
• Пункт 1.4: мониторинг событий ИБ.

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

Вывод

Пункт 7.13 требует видеть сетевые атаки на внешних и внутренних направлениях и иметь механизм их предотвращения.

Рабочая система включает правильно размещённые сенсоры, актуальные правила, настроенные режимы блокировки и процесс реагирования.

Главное доказательство – контролируемый тест показывает, что сенсор видит нужный поток, создаёт событие и приводит к защитному действию.

Практическая ценность требования состоит в том, что оно создаёт воспроизводимый процесс: состояние системы можно проверить, отклонение – обнаружить, а восстановление или защитное действие – выполнить по установленному порядку.

Нормативная основа

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.13. Официальный источник.
• Приказ ОАЦ № 98 от 27.05.2026 изменил отдельные положения приказа № 66, но не изменил строки 7.7–7.13 приложения 3. Официальный источник.

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