Аудит КИИ: методология, стандарты и выбор подрядчика на основе проверяемых данных

Что охватывает аудит КИИ и как построено это исследование

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

Доказательная база намеренно международная и методологическая. Это NIST SP 800-115 о техническом тестировании безопасности, NIST Cybersecurity Framework 2.0 об управлении киберрисками, руководство OWASP по тестированию, стандарт верификации ASVS и OWASP Top 10 для прикладного уровня, MITRE CWE Top 25 о распространенности программных слабостей, материалы CISA Secure by Design и Secure by Demand о закупках, а также справочник MDN по HTTP для защитных механизмов веб-интерфейсов.

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

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

По темеОценка защищённости ИТ-инфраструктуры: проверка сегментации сети

Как устроен добросовестный аудит КИИ: этапы по NIST SP 800-115

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

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

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

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

• Планирование: границы, письменное разрешение владельца систем, правила проведения работ, исключенные системы, условия остановки
• Выполнение: анализ, идентификация целей, подтверждение уязвимостей только в согласованных пределах
• Анализ: первопричины, оценка риска, связь с бизнес-процессами
• Отчет и устранение: меры, ответственные, сроки, повторная проверка

Стандарты и фреймворки, на которые опирается аудит критической инфраструктуры

NIST CSF 2.0 помогает организациям понимать и улучшать управление киберрисками и адресован промышленности, государству и организациям в целом. Фреймворк включает профили, краткие руководства и информативные ссылки (сопоставления с другими ресурсами). В аудите CSF выполняет роль управленческого слоя: он переводит технические находки в язык рисков и результатов, понятный руководству.

CSF 2.0 активно развивается: 24 февраля 2026 года NIST отметил два года CSF 2.0, опубликовал итоговое краткое руководство по информативным ссылкам и до 15 октября 2026 года принимает комментарии к проекту руководства по использованию ИИ для анализа и отчетности по CSF. Аудитор, ссылающийся на CSF, должен указывать актуальную версию и используемые профили.

Для прикладного уровня OWASP ASVS дает основу для тестирования технических мер защиты веб-приложений и ставит целью выровнять разброс охвата и строгости проверок на рынке. Последняя стабильная версия — 5.0.0. Идентификаторы требований рекомендуется указывать вместе с версией, например v5.0.0-1.2.5, поскольку номера могут меняться между версиями. Для аудита это вопрос прослеживаемости: без версии невозможно однозначно сопоставить результаты двух проверок.

OWASP Web Security Testing Guide описывается проектом как ведущий ресурс по тестированию безопасности для разработчиков и специалистов; текущий выпуск — 4.2, версия 5.0 в разработке. OWASP Top 10 в редакции 2025 года — документ повышения осведомленности, отражающий широкий консенсус о наиболее критичных рисках веб-приложений. Это отправная точка, а не исчерпывающий стандарт тестирования.

Что данные о слабостях говорят о приоритетах аудита КИИ

Список MITRE CWE Top 25 за 2025 год выделяет наиболее опасные и распространенные слабости, стоящие за 39080 записями CVE в наборе данных этого года. По описанию MITRE, такие слабости часто легко найти и эксплуатировать, а их последствия — полный захват системы, кража данных или остановка работы приложений.

Параллельно опубликованы список 2025 CWE Top 10 KEV Weaknesses, ранжирующий активно эксплуатируемые слабости по каталогу CISA KEV, и перечень из 15 дополнительных слабостей, оказавшихся «на грани» включения в Top 25. Для приоритизации в аудите это ценно: слабости из KEV показывают, что злоумышленники реально используют, а не только что теоретически возможно.

MITRE отмечает, что отдельные слабости, например внедрение команд, привлекают особое внимание атакующих, а анализ первопричин помогает устранять целые классы дефектов, такие как нарушения безопасности памяти и внедрения. Те же классы повторяются в серии предупреждений CISA Secure by Design — переполнение буфера, межсайтовый скриптинг, внедрение команд ОС, обход каталогов — и в примере требования ASVS о защите от внедрения команд ОС. Совпадение трех независимых источников — сильный аргумент в пользу того, чтобы аудит явно проверял эти классы.

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

Веб-интерфейсы, API и защитные механизмы на уровне протокола

Многие системы критической инфраструктуры имеют веб-консоли управления, порталы и API. По справочнику MDN, HTTP — протокол прикладного уровня по модели клиент-сервер; он не хранит состояние между запросами, а cookies добавляют состояние в часть взаимодействий. HTTP используется и для межмашинного обмена, и для программного доступа к API. Поэтому аудит должен охватывать аутентификацию, управление сессиями и обращение с cookies, а не только внешний периметр.

MDN описывает ряд защитных механизмов, доступных через заголовки ответа. Content Security Policy позволяет ограничивать загружаемые ресурсы и помогает выявлять и смягчать атаки вроде межсайтового скриптинга и внедрения данных. CORS управляет реакцией сайта на межсайтовые запросы. CORP защищает от определенных запросов с других источников для смягчения атак по сторонним каналам. Permissions Policy явно ограничивает функции и API, доступные коду сайта. MDN также указывает инструмент HTTP Observatory, помогающий безопасно настраивать сайты.

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

Поставщики, продукты и операционные технологии

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

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

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

По темеБезопасность контейнерной инфраструктуры: как доказать допуск образа и безопасно отозвать релиз

Компромиссы: глубина, риск нарушения работы и качество доказательств

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

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

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

Чек-листы и риск-ориентированный подход также требуют баланса. OWASP Top 10 — документ осведомленности, и проверка «по Top 10» не равна полной верификации. ASVS и CSF дают более полную структуру, но их нужно адаптировать к реальным рискам конкретной инфраструктуры.

Операционные последствия: от находок к устранению

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

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

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

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

Как выбрать услуги аудита КИИ: вопросы к подрядчику

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

Проверяйте утверждения, а не принимайте их на веру. Заявления о лицензиях, аттестатах и опыте работы с объектами КИИ требуют документального подтверждения, а обязательность конкретных разрешений по национальному законодательству нужно проверять самостоятельно с юристами. Используйте вопросы из руководств CISA Secure by Demand как модель: они созданы именно для разговора заказчика с поставщиками.

Тревожные признаки: отчет только по результатам автоматического сканирования; отсутствие процедуры письменного разрешения и правил проведения работ; ссылки на стандарты без версий; отсутствие повторной проверки; обещание гарантированно «пройти» проверку регулятора; нежелание объяснять ограничения выбранных методов.

• Как ваша методология соотносится с этапами NIST SP 800-115 и какие ограничения у каждого метода?
• Какую версию ASVS вы используете и указываете ли версионированные идентификаторы требований?
• Сопоставляете ли вы находки с CWE и учитываете ли слабости из каталога KEV?
• Как вы согласуете полномочия, окна тестирования и условия остановки для критических систем?
• Как результаты связываются с результатами и профилями NIST CSF 2.0?
• Входит ли в работу повторная проверка после устранения?
• Какие вопросы к поставщикам продуктов и ОТ вы задаете на основе Secure by Demand?

Практическая схема принятия решений по аудиту КИИ

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

Если ресурсы ограничены, начинайте с шагов, дающих наибольшее снижение риска: системы с доступом извне, классы слабостей из CWE Top 25 и KEV, отсутствие базовых функций вроде многофакторной аутентификации и журналирования. Затем расширяйте охват по профилю CSF.

• 1. Зафиксировать нормативные входные данные с юристами и регулятором
• 2. Определить границы: системы, интерфейсы, поставщики, исключения
• 3. Получить письменное разрешение владельца и согласовать правила работ
• 4. Выбрать методы по NIST SP 800-115 с обоснованием и ограничениями
• 5. Для веб-интерфейсов и API проверять по версионированным требованиям ASVS и процедурам WSTG
• 6. Приоритизировать по CWE Top 25 и KEV, отражать находки в терминах CWE
• 7. Оценить поставщиков по критериям Secure by Design и Secure by Demand
• 8. Связать результаты с профилями CSF 2.0, назначить ответственных и повторную проверку

Вывод: что должен давать сильный аудит КИИ

Сильный аудит КИИ сочетает проверку соответствия и техническое тестирование, опирается на версионированные стандарты, приоритизирует реально эксплуатируемые классы слабостей и завершается планом устранения с повторной проверкой. Международные источники — NIST SP 800-115, CSF 2.0, OWASP ASVS, WSTG и Top 10, MITRE CWE Top 25, CISA Secure by Design — дают для этого проверенный каркас.

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

По темеАудит безопасной конфигурации: что проверять и как принять результат