Аудит соответствия требованиям ФСТЭК: методика и доказательства

Небольшая компания-разработчик выигрывает контракт на сопровождение портала записи для условного государственного учреждения. В договоре есть строчка: перед вводом новой версии исполнитель предоставляет результаты «аудита соответствия требованиям ФСТЭК». Компания находит подрядчика и через три недели получает отчёт на сорок страниц, где почти напротив каждого пункта стоит «соответствует». Отчёт собран по политикам, регламентам и скриншотам, которые прислали сами разработчики.

Через месяц заказчик проводит собственную проверку. Административная панель портала открыта из интернета и защищена только паролем, без второго фактора, а журнал входов хранится три дня и никем не просматривается. При этом в политике безопасности всё было описано правильно.

Пример условный и ни к какой реальной организации не относится, но разрыв между бумагой и реальностью в нём легко узнаваем. Под словами «аудит ФСТЭК» обычно скрываются три разных вопроса. Какие требования вообще применимы к системе? Работают ли меры защиты на самом деле? И нужна ли формальная аттестация, которую никакой аудит и никакой пентест не заменяют? Ниже разберём, как определить применимость, построить проверку на доказательствах, где уместен пентест, как приоритизировать несоответствия и как выбрать исполнителя, чей отчёт выдержит повторную проверку.

Что на самом деле заказывают под названием «аудит ФСТЭК»

Аудит соответствия требованиям ФСТЭК — это структурированная оценка того, насколько информационная система, её меры защиты и поддерживающие процессы отвечают тем требованиям ФСТЭК России, которые к этой системе применимы. Главное слово здесь — «применимы». Единого перечня «для всех» нет: разные акты регулируют разные типы систем и категории информации, а у разных видов оценки разные цели и юридические последствия.

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

Применимость начинается с системы, а не с названия услуги

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

От ответов зависит, какие документы брать за основу. Защита информации в государственных информационных системах — один режим, персональные данные — другой, значимые объекты критической информационной инфраструктуры — третий. Для двух последних у нас есть отдельные разборы: аудит защиты персональных данных по 152-ФЗ и аудит объектов КИИ. Отчёт, построенный «по ФСТЭК вообще», либо проверяет лишнее, либо пропускает обязательное.

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

Аудит, пентест и аттестация — разные работы

Gap-анализ показывает, где система расходится с требованиями. Тестирование на проникновение показывает, что атакующий может сделать на практике в согласованных границах. Аттестация объекта информатизации — формальная процедура с установленным порядком и юридическими последствиями. Пентест и сканирование дают важные доказательства для любой из этих работ, но не превращаются в аттестацию только потому, что проверяют меры, связанные с требованиями ФСТЭК. Пентест — это не сертификация, не аттестация и не заключение о соответствии.

Если вам нужна именно техническая часть — проверка того, работают ли меры защиты на внешних интерфейсах, в веб-приложении или во внутренней сети, — её границы лучше договорить заранее: какие системы входят в периметр, какие требования тест должен подкрепить и какие методы допустимы на продуктиве. Pentest.red проводит такое тестирование и может оформить результаты так, чтобы их было удобно сопоставить с вашей матрицей требований; начать можно со страницы согласования скоупа пентеста. Аттестацию и юридическое заключение о применимости требований это не заменяет: для них нужна отдельная квалифицированная оценка.

Нормативная база в 2026 году: что проверить до начала работ

Документы, на которые ссылаются старые отчёты и шаблоны, устаревают, и в 2026 году это особенно заметно.

Для государственных информационных систем ключевое изменение — приказ ФСТЭК России от 11 апреля 2025 года № 117 о требованиях о защите информации в государственных информационных системах и иных информационных системах государственных органов, государственных унитарных предприятий и государственных учреждений. Приказ зарегистрирован Минюстом 16 июня 2025 года под № 82619 и с 1 марта 2026 года заменил прежнюю рамку приказа № 17.

Отсюда два вывода. Отчёт, подготовленный сегодня, не должен ссылаться на приказ № 17 как на действующие общие требования к ГИС; упоминать его уместно как исторический контекст, например при сравнении с прошлым аудитом. А сфера приказа № 117, как следует из названия, охватывает информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений и не создаёт универсальный режим для любой частной компании. Договор может возложить на коммерческого подрядчика обязанности по поддержке соответствия или предоставлению доказательств. Применяется ли приказ № 117 непосредственно к конкретной системе и оператору, устанавливается отдельно.

Отдельная процедура — аттестация объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Её порядок установлен приказом ФСТЭК России от 29 апреля 2021 года № 77 (зарегистрирован 10 августа 2021 года, № 64589). Изменения в него внесены приказом от 27 февраля 2026 года № 60, зарегистрированным 24 июня 2026 года под № 87202 и опубликованным 25 июня 2026 года. Описание аттестации, опирающееся только на текст 2021 года, сегодня неполно.

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

Почему чек-лист не доказывает соответствие

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

Руководство NIST SP 800-115 по техническому тестированию и оценке защищённости прямо называет обе роли технических проверок: поиск уязвимостей и подтверждение соответствия политике или иным требованиям. На этой двойной роли держится зрелый аудит. Одна и та же работа выявляет слабые места и даёт доказательства соответствия, поэтому «аудит» и «пентест» не обязаны быть двумя несвязанными проектами, если результаты теста заранее привязаны к требованиям.

Оговорка: SP 800-115 вышел в сентябре 2008 года, заменив SP 800-42, и современного инструментария в нём нет. Сам документ называет себя обзором ключевых элементов, а не исчерпывающей программой. Это каркас для планирования и оформления проверок, а не перечень того, что проверять.

Если организация отчитывается ещё и перед иностранными партнёрами, полезен NIST CSF 2.0: профили текущего и целевого состояния позволяют описать то же положение дел в управленческих терминах без повторных полевых работ. Не следует предполагать наличие готового авторитетного сопоставления требований ФСТЭК с CSF: используемую таблицу команда должна задокументировать и проверить по формулировкам требований, а не по названиям разделов.

Методика: от требования к доказательству

Планирование, выполнение и обработка результатов

SP 800-115 описывает оценку в три фазы: планирование, выполнение и пост-выполнение. При планировании фиксируются область проверки (системы, интерфейсы, площадки, потоки данных), перечень применимых требований с редакциями, правила проведения работ и письменное разрешение владельца системы с целями, временными окнами, допустимыми методами и контактами для экстренной остановки. Без такого разрешения технические тесты не начинают.

При выполнении собираются доказательства: анализ документов и конфигураций, интервью, технические тесты. Пост-выполнение — анализ и оформление выводов и рекомендаций. Устранение и повторная проверка — уже следующий, практический цикл, за который отвечает организация. Его стоит планировать заранее, но не смешивать с фазами оценки, иначе непонятно, по какому состоянию системы сделаны выводы.

Матрица «требование — доказательство»

Сердце аудита — матрица, где каждое требование переписано как проверяемое утверждение. Не «обеспечивается регистрация событий», а «события входа в административный интерфейс регистрируются с учётной записью, временем и источником; журнал хранится не меньше установленного срока и защищён от изменения». Для каждого утверждения указываются метод, тип артефакта, исполнитель, дата и результат: соответствует, частично, не соответствует или неприменимо — с обоснованием.

SP 800-115 разделяет методы исследования (документы, конфигурации, журналы) и тестирования (сканирование, тестирование на проникновение) и подчёркивает ограничения каждого. Матрица делает выбор метода явным: видно, где вывод опирается на скриншот из переписки, а где на воспроизводимый тест.

Полезна дисциплина версий. OWASP ASVS рекомендует указывать версию прямо в идентификаторе требования, например v5.0.0-1.2.5, потому что нумерация между версиями меняется. Для требований ФСТЭК то же самое: акт, редакция, пункт. После перехода с приказа № 17 на № 117 ссылка «пункт такой-то» без документа и даты бессмысленна.

1. ПрименимостьОпределить тип системы, категорию информации, применимый акт и его актуальную редакцию с учётом изменений.
2. Проверочное утверждениеПереписать требование как конкретное утверждение о системе, которое можно подтвердить или опровергнуть.
3. Метод и разрешениеВыбрать наименее разрушительный достаточный метод и получить письменное разрешение на технические проверки.
4. АртефактСобрать датированное доказательство с конкретного узла: выгрузку, фрагмент журнала, протокол теста.
5. Повторная проверкаПосле исправления повторить тот же метод и обновить статус в матрице с новой датой.

Какие доказательства принимать, а какие — нет

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

Последняя колонка важнее, чем кажется: если неясно, как перепроверить находку, после «исправления» останется только слово владельца системы. Как организовать перепроверку, которая что-то доказывает, — в статье о валидации исправлений после пентеста.

Технические проверки: глубина против операционного риска

Техническая верификация обычно сочетает анализ конфигураций, сканирование уязвимостей и, где это разрешено и оправдано, тестирование на проникновение. SP 800-115 соотносит свою тематику с семействами мер аудита и подотчётности, оценки рисков, защиты систем и коммуникаций, целостности систем и информации — то есть с тем, что обычно и должен подтвердить аудитор.

Наименее разрушительный достаточный метод

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

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

Тестовый стенд и продуктив

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

Воспроизводимость

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

Веб-интерфейсы и API: проверки на уровне приложения

Многие системы под требованиями ФСТЭК — это порталы, личные кабинеты и API для обмена данными с другими ведомствами. Для них полезна дисциплина OWASP, если версии стандартов зафиксированы в отчёте. О самом тестировании подробнее — в материале о поиске уязвимостей в веб-приложениях.

OWASP WSTG задаёт тест-кейсы, а OWASP ASVS — проверяемые требования к мерам защиты приложения. Для конкретной матрицы можно зафиксировать WSTG 4.2 и ASVS 5.0.0 как выбранные версии; исполнитель должен прямо указать, какие выпуски использовал. Требования ASVS доступны в CSV и JSON, поэтому их удобно импортировать в матрицу. OWASP Top 10 в редакции 2025 года — информационный документ о критичных рисках веб-приложений. Он хорош для разговора с руководством, но стандартом проверки не является: «покрытие Top 10» без требований ASVS и тест-кейсов WSTG — слабое доказательство.

Прикладные доказательства легко зафиксировать и перепроверить. HTTP сам по себе не связывает запросы между собой, а сеанс пользователя приложение поддерживает через cookies или токены; данные сеанса вполне могут храниться на сервере. Поэтому аудитор проверяет устройство сеансов: атрибуты cookie (Secure, HttpOnly, SameSite), смену идентификатора после входа, завершение при выходе и по таймауту. Заголовок Content-Security-Policy ограничивает, какие ресурсы может загружать страница, и помогает смягчать межсайтовый скриптинг и внедрение данных. Политика CORS определяет, каким сторонним источникам браузер разрешит читать ответы. Слишком широкая настройка становится существенной находкой, если позволяет нежелательным источникам читать чувствительные ответы браузера; критичность зависит от учётных данных, данных и последствий. Авторизация API проверяется тест-кейсами на доступ к чужим объектам и функциям. Всё это фиксируется как датированная пара «запрос — ответ» и легко повторяется после исправления.

Приоритизация несоответствий: регуляторика, эксплуатируемость, бизнес

Отсутствующий регламент и доступная из интернета панель с обходом авторизации формально оба «не соответствуют», но устранять их с одинаковой срочностью странно.

Для технических находок полезна привязка к классам слабостей CWE. Список MITRE CWE Top 25 за 2025 год выделяет наиболее опасные слабости, стоящие за опубликованными уязвимостями; MITRE отмечает, что их часто легко найти и эксплуатировать и что они могут вести к захвату системы, краже данных или отказу в обслуживании. Привязка к CWE показывает первопричину и помогает устранять класс дефектов, а не симптом: если в одном методе API нет проверки авторизации, стоит искать то же в соседних. MITRE также публикует список CWE Top 10 KEV Weaknesses 2025 года — ранжирование по уязвимостям из каталога известных эксплуатируемых уязвимостей CISA. Попадание класса слабости в рейтинг на основе KEV — один из сигналов приоритизации. Известную эксплуатацию конкретной находки подтверждают данные о её уязвимости или наблюдаемая активность.

Практичная модель критичности учитывает три измерения: регуляторное (нарушено ли обязательное требование применимого акта), техническое (класс слабости, доступность извне, известная эксплуатация) и бизнесовое (какие данные и процессы затронуты). Отчёт только со статусами «да» и «нет» скрывает от руководства именно то, что нужно для решения. Подробнее — в статье о риск-ориентированной приоритизации уязвимостей.

Компромиссы и ограничения

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

Разовый аудит фиксирует состояние на одну дату, а конфигурации дрейфуют и релизы приносят новые слабости. CISA в материалах Secure by Design призывает сокращать эксплуатируемые дефекты ещё на этапе проектирования, а в руководстве по безопасному развёртыванию ПО подчёркивает роль надёжного тестирования и измерений. Для аудита это значит: проверять стоит и процессы — как изменения попадают в продуктив, кто их согласует, запускаются ли проверки безопасности, — а не только конфигурацию на дату визита.

Международные руководства не заменяют национальные требования. NIST, OWASP и CWE повышают качество доказательств, но соответствие оценивается по применимым документам ФСТЭК. Если считать международную меру равнозначной национальной без сверки формулировок, легко получить ложное ощущение соответствия: требование ASVS к журналированию может не совпадать с требованием конкретного акта по составу событий или сроку хранения.

Наконец, внутренняя команда знает среду, а внешний исполнитель приносит независимость. Если применимые требования предписывают определённый тип исполнителя или лицензии, это имеет приоритет и проверяется по официальным текстам и реестрам.

До, во время и после аудита

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

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

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

Как выбрать исполнителя услуг аудита ФСТЭК

Сравнивать исполнителей стоит только после того, как определены применимые требования, область и глубина. Логика руководства CISA Secure by Demand, написанного для заказчиков ПО, хорошо переносится на закупку аудита: задавайте проверяемые вопросы и требуйте доказательств, а не маркетинговых заявлений.

Спросите, какие документы и в каких редакциях будут использованы и как исполнитель определяет их применимость. Уточните методику: фазы работ, версию WSTG, версию и уровень ASVS. Попросите обезличенный образец отчёта с матрицей «требование — доказательство». Выясните, как находки сопоставляются с CWE и приоритизируются, как оформляются разрешение, правила работ, условия остановки и обращение с данными, входит ли в договор повторная проверка.

Если в периметре есть продукты сторонних поставщиков, учитывайте позицию CISA: продукты должны быть безопасными «из коробки», а многофакторная аутентификация, журналирование и единый вход — предоставляться без доплаты. Аудитор обычно сопоставляет эти функции с требованиями к управлению доступом и регистрации событий, поэтому проверьте заранее, доступны ли они в вашей редакции продукта и включены ли.

Тревожные признаки — гарантия «прохождения» проверки или аттестации, отсутствие технической части, ссылки на стандарты и приказы без версий и дат (в том числе на приказ № 17 как на действующие требования к ГИС), отчёт только со статусами, отказ показать обезличенный образец и обещание «аттестации» по итогам пентеста. Лицензии и разрешения исполнителя, если они требуются, проверяйте по официальным реестрам, а не со слов поставщика.

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

Порядок решений: с чего начинать

Сначала определяется применимость: тип системы, категория информации, конкретный акт и его действующая редакция. Затем фиксируется область, для каждого требования выбираются метод и тип доказательства, определяется глубина технических тестов с учётом риска и оформляется разрешение. Только потом выбирается исполнитель — по проверяемым критериям. Дальше несоответствия приоритизируются, устраняются и перепроверяются, а матрица поддерживается. Выбрать исполнителя раньше, чем определена применимость, — значит купить вместе с услугой чужую интерпретацию требований.

Эмпирическое правило, которое всегда сверяется с формулировкой требования: если веб-приложение или API доступны из интернета и обрабатывают регулируемые данные, требуйте технического тестирования по выбранным и зафиксированным версиям WSTG и ASVS в применимой части. Для иных технологий выбирайте соответствующие системе методы; для внутренней системы с низким влиянием может хватить анализа документов и конфигураций, если формулировка требования это допускает.

Вывод: соответствие подтверждается доказательствами

Качественный аудит соответствия требованиям ФСТЭК отвечает не на вопрос «есть ли документ», а на вопрос «работает ли мера и чем это подтверждено». Применимость определяется по актуальным официальным текстам: с 1 марта 2026 года общие требования к защите информации в ГИС задаёт приказ № 117, а порядок аттестации по приказу № 77 изменён приказом № 60. Каркас методики дают фазы SP 800-115, проверяемые требования и тест-кейсы для приложений — ASVS и WSTG с зафиксированными версиями, приоритизацию по первопричинам — классы CWE.

В условном примере одна строка матрицы со ссылкой на действующую редакцию требований, документированное и обоснованное для этой системы утверждение «административный интерфейс недоступен из интернета и требует второго фактора» и один воспроизводимый тест выявили бы описанный разрыв. Сами по себе они не подтверждают соответствие всему набору применимых требований. Пентест в такой схеме — источник сильных доказательств, но не аттестация и не заключение о соответствии. Лучший результат получается, когда корректное определение требований, версионированная методика, воспроизводимые проверки и план устранения с повторной проверкой собраны в одну работу.