Пункт 7.10 приложения 3 к ПТКЗИ: защита от воздействия вредоносных программ

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

Пункт 7.10 приложения 3 к ПТКЗИ – практический разбор требования «защита от вредоносного ПО». Пункт 7.10 требует защищать активы ИС от вирусов, троянских программ, шифровальщиков, загрузчиков, майнеров, web-shell и иных вредоносных компонентов.

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

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

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

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

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

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

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

Требование обязательно для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп.

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

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

Какие уровни защиты использовать

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

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

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

• Почтовый и web-периметр: проверка вложений, ссылок и загрузок.
• Конечные узлы: антивирус или EDR для файлов, процессов и памяти.
• Контроль приложений: запуск только доверенных программ и сценариев.
• Ограничение макросов и скриптов.
• Контроль съёмных носителей и автоматическая проверка.
• Минимальные права и защита от отключения средства.
• Сегментирование и защищённые резервные копии.

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

Как организовать централизованную защиту

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

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

Безопасные тестовые файлы и имитации позволяют проверить агент, уведомление и процесс реагирования без применения реального вредоносного ПО.

• Развёртывание агента по реестру активов.
• Защита от остановки и удаления пользователем.
• Обновление движка, сигнатур, правил и агента.
• Разные политики для серверов и рабочих станций.
• Оповещения и автоматическая изоляция критичных узлов.
• Интеграция с централизованным сбором событий.
• Контроль узлов без агента и давно не выходивших на связь.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Перечень мер и типы охватываемых активов;
• Минимальные параметры политик и защиту от отключения;
• Сроки обновления сигнатур, движка и агентов;
• Уровни событий и порядок реагирования;
• Согласование исключений и их пересмотр;
• Контроль охвата и узлов без телеметрии;
• Порядок проверки работоспособности;
• Обязанности пользователей по сообщению о подозрительной активности.

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

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

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

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

• Агент установлен не на всех серверах и административных АРМ;
• Устройство давно не выходит на связь, но считается защищённым;
• Пользователь может отключить средство;
• Исключён весь диск или большой каталог;
• События обнаруживаются, но не обрабатываются;
• Резервные копии доступны из того же домена;
• Не контролируются макросы, сценарии и легитимные инструменты.

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

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

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

• Пункт 7.1: перечень разрешённого ПО.
• Пункт 7.8: обновление программного обеспечения.
• Пункт 1.3: централизованный сбор событий.

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

Вывод

Пункт 7.10 требует многоуровневой защиты от вредоносных программ на всей установленной области ИС.

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

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

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

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

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

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