Нормативный источник: пункт 7.18 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Краткое описание требования
Межсетевой экран контролирует предусмотренный ему трафик, а антивирусная защита решает задачи противодействия вредоносным программам. Однако существенное для безопасности действие может происходить непосредственно на рабочей станции или сервере: изменение важных настроек, выполнение необычной последовательности процессов, попытка отключить защиту, использование разрешённого системного средства не по назначению.
Пункт 7.18 посвящён обнаружению и реагированию на угрозы на уровне конечного узла. Его смысл — не только собрать события, но и обеспечить управляемое действие при выявлении угрозы. На практике для такой задачи применяются средства класса EDR и другие решения с подходящими функциями контроля, однако сам нормативный пункт не требует продукта с определённым коммерческим названием.
Следует отделять пункт 7.18 от пункта 7.10 о защите от вредоносных программ. Функции антивируса могут участвовать в обнаружении угроз на узле, но факт установки антивируса сам по себе ещё не показывает, как обнаруживаются предусмотренные сценарии и как организовано реагирование. Обратное также верно: наличие центра управления EDR без охвата узлов и действующего процесса реакции не подтверждает результат.
Оригинальная формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации, раздел «7. Иные требования», пункт 7.18: «обеспечение обнаружения и реагирования на угрозы безопасности конечных узлов (уровня узла) в информационной системе».
Пункт устанавливает два результата: обнаружение угроз на конечных узлах и реагирование на них. При этом не предписывает конкретную торговую марку EDR, автоматическую изоляцию каждого устройства или обязательную передачу всех событий в определённую SIEM.
Обязательность требования
По таблице приложения 3 требование обязательно для классов 3-бг и 3-дсп. Для 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец и 3-юл оно рекомендуемое.
Обязательность других мер защиты, в частности пункта 7.10, определяется самостоятельно по соответствующим строкам таблицы. Если в ИС класса, для которого 7.18 является рекомендуемым, принято решение о внедрении этой меры, её состав и критерии выполнения следует закрепить в документации и затем проверять по принятым решениям.
Что именно проверяет проверяющий
Проверка должна установить связь между составом конечных узлов, реально работающим обнаружением и доступными действиями реагирования.
- Охват: определено, какие рабочие станции, серверы, виртуальные машины и специализированные узлы входят в границы ИС и какие из них поддерживаются выбранным средством.
- Работоспособность: на охваченных узлах средство активно, передаёт предусмотренные сведения, а прекращение связи или отключение агента обнаруживается установленным способом.
- Сценарии: известно, какие категории угроз выявляются, по каким признакам формируется событие и какие ограничения есть у выбранных функций.
- Реагирование: определено, кто принимает решение, какое действие допустимо для соответствующего типа узла и как фиксируется результат.
- Подтверждение: при безопасной тестовой проверке можно получить событие с идентификатором узла, увидеть его обработку и подтвердить выполнение согласованного действия.
Для чувствительных серверов и оборудования АСУТП возможность автоматического прекращения работы или сетевой изоляции должна оцениваться отдельно. Недоступное либо нарушающее технологический процесс действие не следует бездумно включать ради формального соответствия. Подходящий порядок реагирования может предусматривать ограничение определённой операции, передачу события ответственному и согласованное действие эксплуатационного персонала.
Варианты реализации
Средство с функциями обнаружения и реакции на узле. На поддерживаемые ОС устанавливается агент, который регистрирует предусмотренные события и передаёт их в центр управления. В зависимости от продукта доступны расследование, ограничение отдельного процесса, изоляция устройства либо другие действия. Поддерживаемые функции необходимо проверять по версиям продукта и платформам: одинаковое название решения не гарантирует одинаковые возможности на Windows, Linux и специализированных ОС.
Комбинация источников и процессов. Там, где единый агент не охватывает все необходимые узлы, могут применяться штатные журналы ОС, существующие средства защиты, централизованный анализ событий и согласованные механизмы управления узлами. В этом случае нужно особенно ясно показать, чем выполняется обнаружение, кто принимает решение и каким техническим действием реализуется реагирование. Простая пересылка системных журналов без определения угроз и реакции недостаточна для содержательного подтверждения меры.
Раздельный подход для различных категорий узлов. Пользовательские компьютеры, серверы приложений, контроллеры домена и специализированные системы имеют разные допустимые способы реагирования. Например, автоматическая изоляция пользовательской станции может быть оправданной, тогда как для критичного сервера предварительно потребуется согласование, чтобы не нарушить доступность ИС. Такое различие следует описывать как архитектурное решение, а не как исключение без обоснования.
Наличие интеграции с SIEM может упростить сопоставление событий узла с сетью и учётными записями. Однако сам пункт 7.18 не требует непременно направлять телеметрию именно в SIEM определённого типа; важно показать выполнение установленного контроля в выбранной архитектуре.
Минимальная модель обнаружения и реагирования
Для выбранного узла должна прослеживаться последовательность: событие → оценка → решение → действие → подтверждение результата.
Рассмотрим пример рабочей станции. Защитное средство регистрирует штатно предусмотренное тестовое событие и присваивает ему идентификатор, время, имя устройства и тип обнаружения. Ответственный анализирует контекст, сопоставляет событие с известной тестовой процедурой и фиксирует решение. При проверке функции реакции выполняется заранее согласованное безопасное действие, после которого система показывает его статус, а оператор подтверждает результат.
Для производственного сервера сценарий будет другим: в тестовой среде можно проверить техническую функцию изоляции, а на рабочем узле отдельно подтвердить порядок согласования и возможность ограниченного действия. Недопустимо ради демонстрации создавать реальную угрозу, отключать важный сервер или нарушать бизнес-процесс. Используют встроенные тестовые механизмы продукта либо специально подготовленный безвредный сценарий, разрешённый владельцем ИС.
При интерпретации результатов важно отличать попытку действия, отображённую в интерфейсе, от подтверждённого завершения. Например, отправленная команда изоляции не равнозначна фактическому ограничению связности, пока результат не проверен допустимым для узла способом. Возможности удалённого реагирования зависят от платформы, сетевой доступности и режима работы агента.
Контроль охвата и отказов
Даже качественные правила обнаружения бесполезны для узла, которого нет в системе наблюдения. Поэтому реестр активов следует регулярно сопоставлять с перечнем узлов, передающих события. Особое внимание требуется к недавно созданным виртуальным машинам, устройствам после переустановки ОС, удалённым рабочим местам и серверам, на которых агент временно отключался для обслуживания.
Отсутствие событий об угрозах не доказывает, что обнаружение работает. Полезно различать три состояния: «нет выявленных угроз», «узел работает и сообщает об отсутствии обнаружений» и «сведения от узла не поступают». Если система не умеет отличить второе от третьего, нарушения в охвате могут долго оставаться незамеченными.
Для узлов без технической совместимости с выбранным агентом нужно фиксировать ограничение и описывать альтернативный способ контроля либо обоснованное архитектурное решение. Нельзя молча исключать активы из проверки и одновременно заявлять полный охват всей ИС.
Что закрепить в ТЗ, ЛПА и ОРД
В ТЗ и проектных решениях указывают категории защищаемых узлов, ожидаемые функции обнаружения и допустимые действия реагирования. В эксплуатационных инструкциях фиксируют контроль состояния агентов или источников, обработку событий и порядок безопасной проверки. В ЛПА и ОРД определяют полномочия на изоляцию или остановку процессов, порядок согласования критичных действий и фиксацию результатов.
Особое внимание следует уделять полномочиям самого средства: оператор с правом удалённо изменять состояние узлов обладает существенными возможностями. Разграничение прав, журналирование действий операторов и контроль исключений относятся к обеспечению устойчивости реализации, даже если не перечислены дословно в пункте 7.18.
Типичные ошибки при реализации
- Средство установлено не на всех предусмотренных узлах. Реестр активов и список защищаемых устройств расходятся.
- Видно только наличие программы. Нет подтверждения актуальной связи с центром, используемых политик и регистрации тестового события.
- Обнаружение не связано с действием. События накапливаются, но порядок принятия решения и выполнения реакции отсутствует.
- Изоляция считается универсальной. Не проверены последствия для критичных серверов и возможность восстановления связи после действия.
- Принята команда за результат. В журнале отображается отправка команды, но её фактическое выполнение не подтверждено.
- Нет контроля потери телеметрии. Узел длительно не передаёт события, а система показывает только отсутствие обнаружений.
- Антивирус автоматически объявлен достаточным. Не установлено, какие именно угрозы на уровне узла распознаются и как выполняется реагирование.
Вывод
Пункт 7.18 требует обеспечить обнаружение угроз на уровне конечных узлов и организовать реагирование. Для подтверждения важна не марка защитной платформы, а проверяемая цепочка от охваченного актива до события и результата согласованного действия. Средства класса EDR могут быть подходящим вариантом, но конкретная архитектура должна определяться границами ИС, особенностями узлов и допустимым воздействием на их работу.
Нормативная основа
- Приказ ОАЦ от 20.02.2020 № 66, действующая редакция — приложение 3 к ПТКЗИ, пункт 7.18 и таблица обязательности.
- Microsoft: действия реагирования на устройстве — пример функций и эксплуатационных ограничений конкретного продукта; не нормативное требование Республики Беларусь.
