Пентест по 44-ФЗ 187-ФЗ: от ТЗ до акта работ

Четверг, 14:40. Звонок от контрактной службы госзаказчика: «Ваш акт выполненных работ возвращён юротделом без подписи». Тестирование на проникновение значимого объекта КИИ энергетической компании сделано за две недели - 47 уязвимостей, три с подтверждённой эксплуатацией, отчёт на 80 страниц. Проблема не в технике: в техзадании на пентест не было привязки к конкретным мерам приказа ФСТЭК №239, а формулировки акта не совпадали с предметом государственного контракта на аудит ИБ. Три недели переговоров, переписывание отчёта и правки акта. Юрист заказчика не обязан понимать, что такое RCE, - но он точно видит, что работы не бьются с контрактом. С тех пор каждый госконтракт начинается не со сканера, а с документальной проработки.

Где в законе написано «проведите пентест»​

Нигде. Ни в 44-ФЗ (о контрактной системе), ни в 187-ФЗ (о безопасности КИИ) прямого требования «проведите тестирование на проникновение» нет. Обязанность возникает через подзаконные акты ФСТЭК, которые конкретизируют меры защиты для разных типов информационных систем.

Приказ ФСТЭК №239 - значимые объекты КИИ. Для объектов категорий значимости 1–3 установлен набор мер, включающий анализ уязвимостей (группа мер АНЗ) и контроль защищённости. Анализ уязвимостей прямо подразумевает инструментальное сканирование и верификацию - по сути, пентест. Для более высоких категорий значимости состав обязательных мер шире (подробности - в приложении к приказу №239). Ст. 274.1 УК РФ (введена 187-ФЗ) устанавливает ответственность за неправомерный доступ к КИИ, создание вредоносного ПО для воздействия на КИИ и нарушение правил эксплуатации значимых объектов КИИ - до 10 лет лишения свободы.

Приказ ФСТЭК №17 - государственные информационные системы. Для ГИС классов К1–К2 анализ уязвимостей обязателен при аттестации. Наличие внешнего сетевого доступа расширяет scope тестирования, но не является условием возникновения самой обязанности - анализ нужен в любом случае. По ряду юридических обзоров, готовится замена приказа №17 новым нормативным актом ФСТЭК (конкретную дату утраты силы, номер и текст заменяющего приказа стоит проверять на pravo.gov.ru). По имеющимся публикациям, новый приказ может предполагать более гибкий подход к выбору мер защиты с учётом архитектуры и актуальных угроз конкретной системы.

Приказ ФСТЭК №21 - информационные системы персональных данных. Для ИСПДн уровней защищённости УЗ1–УЗ2 требуются сертифицированные ФСТЭК средства защиты и периодические оценки защищённости, включая тестирование на проникновение.

Правовые риски тестирования на проникновение​

Ст. 274.1 УК РФ - главная «страшилка» для пентестера. Неправомерный доступ к КИИ, создание вредоносных программ для воздействия на КИИ, нарушение правил эксплуатации значимых объектов КИИ. Без письменного разрешения заказчика любая попытка эксплуатации объекта КИИ - потенциальный состав по 274.1. Договор и письменное разрешение - не формальность, а единственное, что отделяет пентестера от обвиняемого.

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

Техническое задание на пентест: привязка к приказам ФСТЭК​

Техническое задание на пентест - ключевой документ при госзакупке услуг ИБ по 44-ФЗ. Именно ТЗ определяет предмет контракта и критерии приёмки результатов. Типичная ошибка - написать «провести тестирование на проникновение» и не привязать scope к конкретным мерам из приказов. Потом удивляются, почему акт не подписывают.

Обязательные элементы ТЗ​

Предмет работ с привязкой к НПА. Формулировка должна содержать прямую ссылку на нормативный акт:

«Проведение анализа уязвимостей и тестирования на проникновение в соответствии с мерами АНЗ.1–АНЗ.5 приказа ФСТЭК России №239 от 25.12.2017 для значимого объекта КИИ категории [N]»

Для ГИС до утраты силы приказа №17 ссылаемся на него, после - на заменяющий приказ ФСТЭК (номер и дату вступления в силу уточнять на pravo.gov.ru). Для ИСПДн - на приказ №21 с указанием уровня защищённости. Условия действия ранее выданных сертификатов соответствия СрЗИ в переходный период уточнять по актуальным переходным положениям заменяющего приказа.

Scope тестирования. Тут нужно зафиксировать всё, вплоть до запятой:

• Перечень IP-адресов, доменов, сетевых сегментов (scope включения)
• Явные исключения (production-базы данных, SCADA-контроллеры - их трогать нельзя, и это должно быть записано)
• Тип тестирования: black-box, grey-box, white-box
• Допустимые методы: только сканирование уязвимостей (Vulnerability Scanning, T1595.002 по MITRE ATT&CK) или полная цепочка - включая эксплуатацию публичных сервисов (Exploit Public-Facing Application, T1190) и латеральное перемещение (Exploitation of Remote Services, T1210 - после получения первоначального доступа к внутренней сети)

Фазы работ с привязкой к ГОСТ Р 56546-2015. ГОСТ Р 56546 определяет порядок выявления и оценки уязвимостей информационных систем. В ТЗ перечисляем фазы:

• Сбор информации об инфраструктуре (Gather Victim Network Information, T1590; Gather Victim Host Information, T1592)
• Активное сканирование (Active Scanning, T1595)
• Верификация и эксплуатация уязвимостей
• Анализ результатов, подготовка отчёта

Требования к квалификации исполнителя. Для работ по защите КИИ исполнитель должен иметь лицензию ФСТЭК на ТЗКИ. Без неё участие в закупке по 44-ФЗ невозможно - даже если команда технически сильнее всех на рынке.

Код ОКПД2. Для госзакупки услуг ИБ используются коды группы 62.02 «Деятельность консультативная и работы в области компьютерных технологий». Конкретный подкод зависит от scope - аудит безопасности, консалтинг, техническое тестирование. Неправильный ОКПД2 - частая причина отмены закупки ФАС. Казалось бы, мелочь - а контракт летит.

Чего не должно быть в ТЗ​

Конкретных названий инструментов (Nmap, Burp Suite, Metasploit). ТЗ описывает результат, а не способ достижения - указание инструментов ограничивает конкуренцию и даёт повод ФАС. Формулировку «выявление всех уязвимостей» тоже лучше не использовать - это юридическая ловушка, потому что «все» вы не найдёте никогда. Корректно: «выявление уязвимостей в рамках согласованного scope и применимых методов тестирования».

Договор на пентест: формулировки для юротдела заказчика​

Государственный контракт на аудит ИБ - второй критический документ. Даже при идеальном ТЗ неаккуратный договор создаёт правовые риски для обеих сторон.

Ключевые пункты договора​

Разрешение на активное тестирование. Явное письменное согласие заказчика на проведение сканирования и эксплуатацию уязвимостей в отношении перечисленных объектов. Без этого пункта действия пентестера потенциально подпадают под ст. 274.1 УК РФ - ответственность за пентест без разрешения вполне реальна.

Ограничение ответственности. Формулировка в договоре: «Исполнитель не несёт ответственности за нарушение работоспособности систем, возникшее в результате эксплуатации уязвимостей в рамках согласованного scope при соблюдении согласованных ограничений». Юротдел заказчика сопротивляется этому пункту в 9 случаях из 10. Но без него подписывать договор - себе дороже.

Перечень запрещённых действий. Что исполнитель не имеет права делать: DoS-атаки, физическое проникновение (если не согласовано отдельно), социальная инженерия, модификация данных в production-средах.

NDA как приложение к контракту. Для объектов КИИ результаты пентеста могут содержать сведения ограниченного распространения. NDA оформляем приложением к контракту, а не отдельным документом - иначе контрактная служба его «потеряет» (проверено не раз). Фиксируем: порядок передачи отчётов (только в зашифрованном виде), сроки хранения и уничтожения рабочих материалов исполнителя, запрет на передачу результатов третьим лицам.

Типичные претензии юротдела и как с ними работать​

Акт и отчёт: оформление пентеста КИИ по приказам ФСТЭК​

Акт выполненных работ - документ, по которому контрактная служба закрывает обязательства. Если формулировки акта не совпадают с предметом контракта (а предмет привязан к приказам ФСТЭК) - юрист не подпишет. Вот тут и начинается та история из начала статьи.

Структура отчёта с привязкой к мерам​

Каждый этап работ маппим на конкретную меру из приказа:

• «Проведён анализ уязвимостей внешнего периметра (мера АНЗ.1, приказ ФСТЭК №239). Выявлено N уязвимостей, из них M - высокой критичности»
• «Выполнена верификация уязвимостей методом имитации действий нарушителя (мера АНЗ.2). Подтверждена возможность эксплуатации K уязвимостей»
• «Проведена оценка защищённости конфигураций средств защиты (мера АНЗ.4). Выявлены N отклонений от baseline»

Для оценки критичности используем CVSS v3.1. CVSS-вектор нужно рассчитывать корректно через калькулятор FIRST - например, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N даёт Base Score 5.4 (Medium), типичный для Stored XSS с ограниченным воздействием. Ошибки в расчёте - повод для юриста усомниться в компетентности исполнителя. Видел случай, когда из-за неправильного CVSS-вектора пересчитали критичность половины находок, и акт завернули повторно.

Рекомендации привязываем к мерам: «Для устранения уязвимости X рекомендуется реализация меры [код меры] приказа ФСТЭК №[номер]».

Ошибки, которые блокируют приёмку​

• Отчёт в формате Bug Bounty - список уязвимостей без связи с нормативными требованиями. Для заказчика по 44-ФЗ такой отчёт бесполезен: юрист видит «XSS в поле поиска», а ему нужно «нарушение меры АНЗ.2 приказа №239».
• Англоязычные термины без перевода. «Remote Code Execution» вместо «удалённое выполнение произвольного кода». Юрист не обязан знать английский - и он прав.
• Нет baseline для сравнения. Отчёт фиксирует текущее состояние, но не показывает, какие меры из приказа реализованы, а какие нет. Без этого заказчик не может использовать отчёт для подготовки к проверке ФСТЭК.

Чек-лист оформления пентеста по 44-ФЗ 187-ФЗ​

Согласие на обработку ПДн. Если в scope попадают ИСПДн - нужно отдельное соглашение. Уведомление Роскомнадзора (ст. 22 152-ФЗ) - обязанность оператора, но исполнитель должен убедиться в его наличии.

Страхование профессиональной ответственности. По 44-ФЗ не обязательно, но де-факто снимает большинство возражений юротдела при обсуждении ограничения ответственности. Когда юрист спрашивает «а если вы нам что-то сломаете?» - полис на 10М₽ закрывает вопрос быстрее любых аргументов.

Три года я сопровождаю госконтракты на пентест для субъектов КИИ. Главный вывод: техническая часть работ - это 30% времени, документальная - 70%. В российской практике нельзя приложить PDF из Nessus и считать работу закрытой. Каждая строчка акта должна ссылаться на конкретный пункт конкретного приказа, каждая уязвимость - маппиться на меру защиты. Это утомительно, но именно привязка к НПА защищает исполнителя. Когда юрист видит в отчёте «мера АНЗ.2 приказа №239 - подтверждена возможность обхода СрЗИ типа МЭ-Б класса 5» вместо абстрактного «обнаружен SQL injection» - вопросов становится на порядок меньше. Рынок движется в сторону зрелой оценки: судя по общему тренду регулирования, требования к оценке зрелости процессов защиты будут усиливаться (хотя конкретных официальных инициатив ФСТЭК на момент публикации не подтверждено). Через пару лет недостаточно будет «провести пентест» - придётся показать, что процесс выявления уязвимостей встроен в непрерывный цикл управления защитой. Кто не начнёт выстраивать документальную базу сейчас, будет догонять в режиме аврала. Если сталкивались с нестандартными требованиями юротдела при оформлении госконтрактов на пентест - на codeby.net есть тред с разбором типовых формулировок и шаблонов ТЗ для приказов ФСТЭК.