Оценка безопасности по NIS2: охват, тестирование и доказательства

Весной совет директоров условного провайдера управляемого хостинга утвердил бюджет на «пентест под NIS2». В компании около четырёхсот сотрудников, площадки в двух странах ЕС, среди клиентов банки и операторы связи. Подрядчик справился быстро: через три недели пришёл отчёт на полторы сотни страниц — выгрузка сканера, разложенная по категориям OWASP Top 10, с бодрой пометкой «проверено». Отчёт отправили в архив.

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

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

Что NIS2 требует от организации и чего не требует от пентеста

Директива (ЕС) 2022/2555, известная как NIS2, не говорит «проведите тест на проникновение раз в год». Её статья 21 обязывает существенные и важные субъекты принимать надлежащие и соразмерные технические, операционные и организационные меры управления киберрисками и перечисляет минимальные области, которые эти меры должны охватывать. Среди них — обработка инцидентов, безопасность цепочки поставок, безопасность при приобретении, разработке и сопровождении систем, включая обработку и раскрытие уязвимостей, криптография, а также политики и процедуры оценки эффективности самих мер управления рисками.

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

Применимость решается до тестирования

NIS2 — директива, а не регламент. Государства-члены должны были перенести её в национальное право до 17 октября 2024 года, а прежняя директива NIS утратила силу с 18 октября 2024 года. Конкретные обязанности, компетентные органы, процедуры и санкции поэтому нужно смотреть в применимом национальном законе с учётом правил юрисдикции для соответствующего вида субъекта, а не только в тексте директивы.

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

Отдельная оговорка про изменения. В январе 2026 года Комиссия предложила точечные поправки к NIS2. Пока законодательный процесс не завершён, это предложение, а не действующая норма, и строить на нём план оценки преждевременно.

Регулярный аудит, целевой аудит и сканирование — не одно и то же

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

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

Три слоя доказательств: управление, техника, поставщики

Обоснованная оценка соответствия NIS2 собирает доказательства на трёх уровнях, и каждый отвечает на свой вопрос.

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

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

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

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

Связь с управлением рисками: текущий и целевой профиль по NIST CSF 2.0

NIST Cybersecurity Framework 2.0 — американская рамка, а не европейский правовой акт. Но её структура, построенная на результатах, даёт команде оценки нейтральный словарь для двух ключевых понятий: что организация делает сегодня и чего хочет достичь. Разделение текущего и целевого состояния лежит в основе любой gap-оценки или оценки готовности к NIS2.

Несколько ресурсов CSF 2.0 можно сразу использовать в работе. Профили дают шаблоны для описания текущего и целевого состояния. Информативные ссылки (Informative References) показывают, где документы NIST пересекаются по темам, — это помогает связать результаты уровня управления с техническими руководствами вроде SP 800-115. Краткие руководства (Quick Start Guides) разбирают типовые задачи, а CSF 2.0 Tool облегчает работу с содержанием рамки. Вместе они позволяют фиксировать разрывы в структурированном и повторяемом виде, а не в свободном пересказе.

Есть и граница, которую важно не переступать. Сопоставление результатов CSF с обязанностями по статье 21 NIS2 — это интерпретация, а не факт, который даёт какая-либо из рамок. Такое сопоставление нужно оформить письменно, явно указать допущения и передать на проверку юристу или комплаенсу.

Отдельно об ИИ в gap-анализе. Любое сопоставление, созданное моделью, следует считать черновиком, который до передачи руководству или регулятору проверяет человек, понимающий и рамку, и вашу инфраструктуру.

Охват: какие услуги и активы включать в проверку

Охват — то место, где оценка выигрывается или проигрывается ещё до первого запроса к системе. Разумная отправная точка — не перечень IP-адресов, а перечень услуг, ради которых организация подпадает под NIS2, и активов, через которые эти услуги предоставляются. Для хостинг-провайдера это может быть панель самообслуживания клиентов, API управления виртуальными машинами, система резервного копирования, каналы удалённого администрирования и учётные системы, к которым подключаются сотрудники поддержки.

Дальше для каждой группы активов выбирается метод. Это решение стоит принимать осознанно, потому что каждый метод даёт свой тип доказательств и у каждого есть слепые зоны.

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

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

Если вы находитесь именно на этом этапе — понимаете, какие услуги критичны, но не уверены, как разложить их на проверяемые группы активов и методы, — техническую часть охвата можно обсудить с Pentest.red на странице определения охвата пентеста. Вопрос применимости NIS2 и юридическое сопоставление при этом остаются за вашими юристами.

Техническое тестирование по NIST SP 800-115

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

Проверки и тесты

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

Само руководство — обзор техник с их преимуществами и ограничениями, а не готовая программа тестирования; ни одна техника сама по себе не достаточна.

Три фазы и практическое продолжение

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

1. Услуга и охватОпределяем услугу, ради которой организация подпадает под NIS2, активы, через которые она работает, и границы проверки с обоснованием.
2. Разрешение и планПисьменная авторизация уполномоченных сторон, правила проведения, окна тестирования, экстренные контакты, выбор проверок и тестов для каждой группы.
3. ВыполнениеПроверки документов и конфигураций плюс активные тесты; каждое действие фиксируется так, чтобы его можно было воспроизвести.
4. Анализ после выполненияПодтверждение находок, отсев ложных срабатываний, привязка к применимым CWE и требованиям ASVS с версией, оценка влияния на услугу.
5. Устранение и ретестОтветственные и сроки, затем повторная проверка той же техникой; в досье попадает результат ретеста, а не обещание исправить.

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

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

Тестовая среда и продуктив

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

Прикладной уровень: OWASP ASVS, WSTG и механизмы HTTP

Услуги существенных и важных субъектов часто доходят до клиентов через веб-приложения и API, поэтому прикладной уровень заслуживает глубины, а не беглого взгляда. Здесь у заказчика есть три разных инструмента, и их важно не путать.

ASVS как общая мерка

OWASP Application Security Verification Standard задаёт основу для проверки технических мер защиты и содержит перечень требований к безопасной разработке. Его заявленная цель — выровнять разброс в охвате и строгости, который рынок предлагает под названием «проверка безопасности веб-приложений», с помощью открытого стандарта, пригодного для коммерческого использования. Для заказчика это, пожалуй, самый полезный документ во всей связке: он позволяет сравнить, что на самом деле проверяют разные подрядчики.

В версии ASVS 5.0.0 у каждого требования есть числовой идентификатор. Идентификаторы могут меняться между версиями, поэтому OWASP рекомендует указывать их с префиксом версии, например v5.0.0-1.2.5. Требования публикуются в машиночитаемых форматах, включая CSV и JSON. Если требовать в отчётах идентификаторы с версией, применимые находки по мерам защиты приложений можно проследить до конкретного требования. Это сохраняет критерий сравнения; сопоставимость среды и предусловий ретеста всё равно проверяется отдельно. Как построить аудит приложения вокруг такой мерки, подробно разобрано в материале про аудит безопасности приложений.

WSTG и Top 10: процедуры и осведомлённость

OWASP Web Security Testing Guide — это сборник процедур тестирования: как именно проверять аутентификацию, управление сессиями, обработку входных данных. Опубликованная редакция, на которую опирался исходный материал, — 4.2. Если ASVS отвечает на вопрос «что должно выполняться», то WSTG — «как это проверить».

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

Механизмы HTTP, которые дёшево проверить

Документация MDN описывает несколько механизмов уровня протокола, проверка которых стоит недорого. Content Security Policy позволяет определить, какие ресурсы может загружать страница, и помогает обнаруживать и смягчать атаки вроде межсайтового скриптинга и внедрения данных. CORS задаёт, когда браузер разрешает скрипту прочитать ответ другого источника; это не замена серверной авторизации. Cross-Origin Resource Policy ограничивает использование ответа в межсайтовых запросах режима no-cors и помогает снизить некоторые риски межсайтового чтения, включая связанные со спекулятивным выполнением. Для быстрой первичной проверки настроек MDN указывает на HTTP Observatory от Mozilla.

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

Приоритизация находок: CWE Top 25 и признаки эксплуатации

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

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

Практический метод выглядит так. Технические слабости сопоставляют с CWE, где это применимо; для остальных находок фиксируют подходящий критерий и причину отсутствия сопоставления. Затем ранжируют по двум осям: признаки эксплуатации и влияние на конкретную услугу в охвате. При сопоставимой достижимости уязвимость в API управления виртуальными машинами может требовать более срочного устранения, чем во внутренней вики, если последствия для услуги выше. Секреты и привилегии в вики способны изменить этот порядок; принадлежность к классу CWE из списка KEV сама по себе не доказывает эксплуатацию конкретной находки. У анализа по первопричинам есть второе преимущество: он показывает, где в жизненном цикле разработки можно убрать целый класс дефектов — например, внедрения или ошибки работы с памятью, — а не латать каждый экземпляр. Подробнее о том, как выстроить такой порядок, — в статье про приоритизацию уязвимостей на основе риска.

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

Поставщики и продукты: Secure by Design и Secure by Demand

NIS2 прямо называет безопасность цепочки поставок одной из областей управления рисками, и оценка, которая заканчивается на собственном периметре, этот слой пропускает. Полезную опору здесь дают материалы CISA.

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

Производители, подписавшие Secure by Design Pledge, обязуются добросовестно стремиться к семи ключевым целям, а CISA публикует их отчёты о прогрессе. Это даёт проверке поставщиков конкретные материалы, которые можно запросить. Но подписанное обязательство — обещание, а не независимая проверка. Оно определяет, какие вопросы задать, а не заменяет ответы.

Для заказчиков CISA выпустила руководство Secure by Demand о том, как вести переговоры о закупке ПО, отдельное руководство Secure by Demand для владельцев и операторов операционных технологий, а также совместное с австралийским ASD's ACSC руководство о выборе безопасных и проверяемых технологий. Из них хорошо получаются анкеты и договорные требования. Спросите поставщика, включены ли MFA, журналирование и единый вход в базовую поставку или продаются отдельно. Подписал ли он Pledge и что показывает последний отчёт о прогрессе. Есть ли у него дорожная карта по безопасности памяти, охватывающая собственный код и open-source-зависимости. Какие классы уязвимостей, например внедрения или обход каталогов, устранены на уровне архитектуры, а не исправляются поштучно. Как он тестирует и поэтапно выкатывает обновления, чтобы они не ломали клиентские системы.

Методика оценки сторонних поставщиков, включая SaaS, подробно описана в материале про оценку рисков третьих сторон.

Приёмка результатов и повторный тест

Приёмка связывает результаты оценки с решением заказчика. Именно здесь решается, получит ли организация доказательства или просто документ. Удобно заранее договориться, какие артефакты подрядчик сдаёт и по каким признакам вы их принимаете.

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

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

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

Любой дизайн оценки чем-то жертвует. Ширина охвата конкурирует с глубиной проверки самых критичных услуг: за тот же бюджет можно пройтись сканером по всему периметру или вручную разобрать две ключевые системы. Проверка по чек-листу помогает систематизировать охват, но без анализа взаимодействий может пропустить связки слабостей; сравнительная стоимость зависит от глубины и доступа. Разовый тест проще закупить, но он устаревает по мере изменения систем. Доказательная база не решает эти дилеммы за организацию, но делает их явными — и тогда выбор можно обосновать перед руководством.

У каждой рамки своя задача, и ни одна не даёт полного охвата: SP 800-115 задаёт цикл тестирования, ASVS — проверяемые требования к приложениям, CSF 2.0 — язык управления, а Top 10 — уровень осведомлённости.

Как выбрать подрядчика для оценки по NIS2

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

Попросите каждого кандидата назвать источники и версии, на которых построена методика: например, жизненный цикл по NIST SP 800-115, верификация приложений по ASVS 5.0.0, классификация по CWE Top 25 2025 года. Запросите обезличенный образец отчёта и посмотрите, есть ли у применимых находок идентификаторы ASVS с версией и привязка к CWE, а для остальных — явные критерии, разделены ли проверки и тесты, раскрыты ли ограничения техник и среда тестирования, входит ли ретест в рекомендации. Уточните, как подрядчик оформляет разрешение и правила проведения и как обращается с продуктивными системами.

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

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

Итог: оценка, которая выдерживает вопросы

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

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

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