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