Аудит соответствия ISO 27001: как доказать, что меры защиты работают

Условная сцена, которую легко представить в компании среднего размера. B2B-сервис расчёта зарплаты готовится к внешнему аудиту: крупный клиент поставил условие — сертификат ISO/IEC 27001 до продления договора. Политики написаны, реестр рисков заполнен, в Положении о применимости аккуратно отмечено, что веб-приложение «регулярно проверяется на уязвимости». На встрече аудитор просит показать, как это происходит. Команда приносит отчёт сканера годичной давности на сорок страниц: без описания области, без даты повторной проверки, без связи с рисками. Половина находок помечена как «высокая», а какие из них исправлены, никто точно не помнит.

Это вымышленный пример, но разрыв в нём легко узнать: документы описывают систему, которая должна работать, а доказательств того, что она работает, не хватает. Аудит соответствия ISO 27001 — это прежде всего работа с доказательствами. Один из ключевых вопросов звучит так: «откуда вы знаете, что эта мера действительно эффективна?».

Ниже разберём, какие проверки скрываются за словами «аудит ISO 27001», где в них место пентесту, как собрать технические доказательства и как выбрать подрядчика, не покупая обещаний, которые никто не вправе давать.

Что на самом деле проверяет аудит соответствия ISO 27001

ISO/IEC 27001 задаёт требования к системе менеджмента информационной безопасности (СМИБ). Действующая редакция — ISO/IEC 27001:2022, третье издание, вышедшее в октябре 2022 года; в 2024 году к нему выпущено Изменение 1. Если ваша документация, договор с клиентом или запрос аудитора ссылаются на конкретную редакцию, это важно: формулировки и перечни мер в разных версиях отличаются, и ссылаться нужно на ту, по которой реально построена система.

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

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

Внутренний аудит, оценка готовности и сертификация: разные работы под одним названием

Под вывеской «аудит ISO 27001» скрываются разные работы с разными инициаторами и результатами. Путаница между ними приводит к тому, что компания заказывает одно, а ждёт результата, который даёт только другое.

Почему пентест не равен сертификационному аудиту

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

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

Три слоя доказательств: процесс, обоснование меры, эффективность

Большая часть доказательств в СМИБ документальна: политики, оценка рисков, решения о принятии риска, протоколы анализа. Но аудитор спрашивает и о том, откуда организация знает, что технические меры работают так, как написано. Удобно разделять доказательства на три слоя.

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

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

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

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

Как планировать технические проверки: NIST SP 800-115 без иллюзий

Для процедуры тестирования, на которую может ссылаться СМИБ, полезной рамкой остаётся NIST SP 800-115 — техническое руководство по тестированию и оценке информационной безопасности. Оно опубликовано в сентябре 2008 года и заменило SP 800-42. Документ помогает планировать и проводить технические тесты и обследования, анализировать находки и вырабатывать стратегии их устранения.

Для темы ISO 27001 в нём важна одна мысль: техническое тестирование и обследование служат двум целям — поиску уязвимостей в системе или сети и проверке соответствия политике или иным требованиям. Для СМИБ тест — не только охота за багами, но и способ убедиться, что заявленное в политике выполняется.

Руководство описывает формальную оценку в три фазы: планирование, выполнение и постобработку. На планировании определяются цели, область, правила проведения работ и ограничения. На выполнении применяются выбранные приёмы. В постобработке анализируются находки и формируются рекомендации по устранению. Цикл «исправить — повторно проверить — закрыть», о котором пойдёт речь ниже, — это уже наша практическая надстройка для СМИБ, а не дословная структура NIST.

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

Учитывайте возраст документа: публикация 2008 года не описывает облака, API-архитектуру и системы на базе ИИ. Используйте её как процессный скелет, дополняя актуальными руководствами.

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

Приложения и API в области СМИБ: ASVS, WSTG и роль OWASP Top 10

Если в область СМИБ входят веб-приложения или API, у OWASP есть три ресурса, которые решают разные задачи. Путать их — значит предъявить аудитору не тот тип доказательства.

OWASP Application Security Verification Standard (ASVS) служит основой для проверки технических мер защиты веб-приложений и одновременно даёт разработчикам перечень требований к безопасной разработке. Его цель — выровнять разброс полноты и строгости проверок на рынке с помощью открытого, коммерчески применимого стандарта. В исходных материалах рассматривалась версия 5.0.0; перед началом работ стоит проверить, какая версия актуальна на момент проверки, и явно указать её в договоре.

OWASP Web Security Testing Guide (WSTG) — руководство по тестированию безопасности веб-приложений. Здесь WSTG 4.2 используется как зафиксированный пример; в договоре и отчёте нужно назвать версию, фактически выбранную для проверки. Разделение ролей простое: WSTG описывает, как тестировать, а ASVS — какие требования этими тестами подтверждаются. Подробнее о том, как строить такую проверку от области до решений, мы писали в материале про аудит безопасности приложений по стандартам.

Версионированные требования как аудиторский след

В ASVS есть механизм, которым стоит пользоваться командам СМИБ. Требования имеют версионированные идентификаторы вида v5.0.0-1.2.5, и проект рекомендует всегда указывать версию, потому что нумерация может меняться между выпусками. Перечни требований доступны в машиночитаемых форматах, включая CSV и JSON.

Практический смысл такой: если в отчёте о тестировании рядом с каждой проверкой стоит версионированный идентификатор требования и ссылка на тест-кейс WSTG, аудитор через год видит, какое требование проверено, по какой версии и когда.

Условный пример. В СМИБ заявлено, что пользовательские сессии защищены от перехвата и фиксации. Запись «требования ASVS по управлению сессиями, версия 5.0.0, проверены такими-то тест-кейсами WSTG такого-то числа; два требования не выполнены, находки исправлены и подтверждены ретестом такого-то числа» — уже доказательство, которое можно проверить. Заметим, что обычный HTTP вполне позволяет хранить состояние сессии на сервере; вопрос не в протоколе, а в том, как реализованы выдача, привязка, срок жизни и отзыв идентификатора сессии.

Top 10 — для осведомлённости, а не для области тестирования

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

Приоритизация находок: первопричины и данные об эксплуатации

Аудиторский след убедительнее, когда очерёдность исправлений определяется воспроизводимой логикой, а не меткой критичности сканера и не интуицией инженера. Здесь помогает классификация слабостей MITRE CWE.

Перечень CWE Top 25 наиболее опасных программных слабостей за 2025 год основан на анализе первопричин записей CVE из набора данных для выпуска 2025 года. По оценке MITRE, их часто легко найти и эксплуатировать, а последствия доходят до захвата системы, кражи данных или сбоя приложений. Рядом публикуются ещё два полезных списка: CWE Top 10 KEV Weaknesses, который ранжирует слабости по данным каталога CISA Known Exploited Vulnerabilities, то есть уязвимостей с подтверждённой эксплуатацией, и перечень On the Cusp — слабости, которые едва не вошли в основной список.

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

Поставщики как часть доказательств: Secure by Design и Secure by Demand

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

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

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

Наблюдаемые меры и связь с другими фреймворками

Многие организации живут сразу в нескольких фреймворках. NIST Cybersecurity Framework 2.0 помогает понимать киберриски и управлять ими; его ресурсный центр предлагает профили, краткие руководства и информативные ссылки — сопоставления, показывающие, где пересекаются разные ресурсы.

Профили CSF удобны, чтобы описать текущее и целевое состояние на языке, понятном руководству, но управляющей системой остаётся СМИБ: сопоставление избавляет от двойной работы, а не подменяет требования ISO/IEC 27001.

Меры, которые можно увидеть снаружи

На самом конкретном уровне часть веб-мер наблюдается напрямую. Документация MDN по HTTP описывает механизмы, конфигурацию которых можно увидеть в ответе сервера: Content Security Policy, которая помогает обнаруживать и смягчать часть атак, включая межсайтовый скриптинг и внедрение данных; CORS и Cross-Origin Resource Policy; Permissions Policy; атрибуты cookie, такие как Secure, HttpOnly и SameSite; механизмы HTTP-аутентификации. MDN также упоминает инструменты вроде HTTP Observatory для проверки конфигурации сайта.

Датированный снимок этих заголовков — дешёвое и воспроизводимое доказательство того, что задокументированная мера по усилению защиты веб-ресурсов действительно применяется в боевой среде. Но переоценивать его не стоит. Наличие заголовка CSP не доказывает, что политика достаточно строгая, а аккуратный CORS на одном домене ничего не говорит о соседнем API. Снимок — доказательство конфигурации, а не устойчивости к атаке. Кроме того, снимок со стенда или предпродуктивной среды нельзя без проверки переносить на боевую: конфигурации балансировщиков, CDN и обратных прокси там нередко различаются.

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

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

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

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

Новая версия стандарта, например ASVS 5.0.0 или OWASP Top 10 2025, делает проверку актуальнее, но может поменять идентификаторы и сломать сравнимость с прошлыми отчётами. Фиксируйте версию каждой проверки, а при переходе сопоставляйте старые и новые идентификаторы.

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

Реестр доказательств и безопасная подготовка проверок

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

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

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

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

Как выбрать услугу аудита ISO 27001 или подготовки к нему

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

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

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

И главный фильтр: избегайте предложений, обещающих исход сертификации. Решение принимает орган по сертификации, и гарантировать его не может никто.

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

Решение под ваш профиль и итог

Процесс решений укладывается в пять шагов с письменным следом. Определите область СМИБ и риски, которые она должна обрабатывать. Составьте перечень мер, эффективность которых нужно подтвердить. Для каждой меры подберите самый лёгкий метод, дающий убедительное доказательство: анализ документов, снимок конфигурации, автоматизированное сканирование или структурированное тестирование по NIST SP 800-115 и руководствам OWASP. Решите, кто выполняет каждую работу, исходя из риска и требований к независимости. Фиксируйте результаты в реестре доказательств и передавайте их в обработку рисков.

Если область СМИБ охватывает в основном бизнес-процессы и почти не включает собственное ПО, приоритет — документальные доказательства, снимки конфигурации и контроль поставщиков. Если в область входят клиентские веб-приложения и API, добавьте проверку по ASVS и тестирование по WSTG с версионированными ссылками. Если организация сама разрабатывает ПО, добавьте для применимых технических классов отслеживание первопричин по CWE и требования Secure by Design к собственным продуктам и к поставщикам компонентов.

В конечном счёте аудит соответствия ISO 27001 проверяет, может ли организация доказать то, что заявляет. Открытые, версионированные и поддерживаемые методики технических проверок не заменяют стандарт и решение органа по сертификации. Но они делают заявления СМИБ проверяемыми, аудит — предсказуемее, а выбор подрядчика — осмысленнее.