Подготовка к аудиту: ISO 27001, SOC 2, Cyber Essentials
Практическое руководство по тому, что на самом деле проверяют аудиторы для ISO 27001, SOC 2 и Cyber Essentials, и как подготовиться без паники.
Большинство команд относятся к проверке соответствия как к учебной эвакуации, которая происходит раз в год. Это не обязательно должно быть так, и сами фреймворки не такие таинственные, как они звучат в речи поставщиков. Вот что действительно важно при подготовке к ISO 27001, SOC 2 или Cyber Essentials.
Определите, какой именно фреймворк вам нужен
Эти три часто путают, но они решают разные проблемы. ISO 27001 — это стандарт системы управления; он подтверждает, что у вас есть функционирующая Система управления информационной безопасностью (ISMS) с оценками рисков, политиками и встроенным постоянным улучшением. SOC 2 — это отчет об аттестации, обычно тип II, охватывающий период времени (обычно 6–12 месяцев) по критериям доверительных услуг: безопасность, доступность, целостность обработки, конфиденциальность, приватность. Cyber Essentials — это поддерживаемая британским правительством схема, сосредоточенная на пяти базовых технических контролях: брандмауэры, безопасная конфигурация, управление доступом, защита от вредоноса, управление патчами.
Если заказчик говорит «нам нужно, чтобы вы соответствовали SOC 2», уточните, какой тип и какие критерии им действительно важны. Для большинства сделок B2B SaaS требуются только Security и Availability, а не все пять критериев.
Соберите доказательства до того, как аудитор их запросит
Аудиторы не верят на слово — им нужны артефакты. Для ISO 27001 это означает Statement of Applicability, в котором все 93 контроля из Annex A (редакция 2022) сопоставлены с тем, что вы реализовали или исключили, с обоснованием. Для SOC 2 это означает скриншоты, логи и тикеты, доказывающие, что контроли работали последовательно на протяжении всего периода аудита, а не только в день, когда кто-то вспомнил о настройке.
Настройте сбор доказательств как постоянный процесс, а не спешку:
# Пример: получить доказательства обзора доступа IAM ежемесячно через AWS CLI
aws iam generate-credential-report
aws iam get-credential-report --output text --query 'Content' | base64 -d > access-report-$(date +%Y%m).csv
Храните эти файлы с отметками времени в специальном хранилище доказательств (папка Google Drive, Vanta, Drata — что бы вы ни использовали), организованные по ID контроля, а не по месяцам. Аудиторы выбирают образцы на протяжении периода; вам нужно доказать, что контроль был активен в марте и октябре, а не только когда кто-то вспомнил.
Контроли, которые каждый раз приводят к ошибкам
Обзоры доступа — самое частое выявленное несоответствие. Если вы не можете продемонстрировать ежеквартальный обзор того, кто имеет доступ к production-системам, с доказательством того, что кто-то действительно удалил устаревшие учетные записи, ожидайте выявления несоответствия независимо от фреймворка. Запустите это как повторяющуюся задачу в календаре, а не как услугу по требованию.
Управление рисками поставщиков — второй крупный пробел. ISO 27001 пункты A.5.19-A.5.23 и критерии управления поставщиками SOC 2 оба ожидают, что вы оцените субпроцессоров — облачных провайдеров, процессоры платежей, все, что касается данных клиентов. Одностраничный вопросник оценки рисков поставщика на каждого критического поставщика, проверяемый ежегодно, охватывает большую часть этого.
Планы реагирования на инциденты, существующие только как документ, который никто не тестировал, — это частое выявление. Проведите хотя бы один настольный сценарий до того, как окончится период вашего аудита, и сохраните заметки совещания. Аудиторы специально просят доказательства того, что план был реализован на практике, а не просто написан.
Для Cyber Essentials вопросы технического охвата имеют большее значение, чем ожидают люди. Вам необходимо точно описать вашу границу — каждое устройство, облачный сервис и политику BYOD в охвате — потому что искажение охвата является основанием для отказа даже если технические контроли в порядке. Управление патчами проверяется буквально: критические и высокоприоритетные патчи должны быть применены в течение 14 дней после выпуска для услуг, доступных в интернете.
Реалистичный внутренний график
Для SOC 2 тип II запланируйте 3–6 месяцев сбора доказательств до того, как начнется период аудита, так как тип II требует доказательства того, что контроли работали на протяжении периода наблюдения, а не только в конкретный момент времени. Сертификация ISO 27001 обычно занимает 6–12 месяцев от оценки пробелов до получения сертификата, включая этап 1 (проверка документации) и этап 2 (проверка на месте или удаленно) органом сертификации. Cyber Essentials быстрее — опросники самооценки можно заполнить за недели, если ваши основы уже в порядке, а Cyber Essentials Plus добавляет внешнюю техническую проверку.
Не позволяйте аудиту быть единственным разом, когда вы проверяете собственную работу
Проведите внутреннюю оценку готовности по отношению к фактическому списку контролей за 60–90 дней до реального аудита. Относитесь к выявленным несоответствиям из этой внутренней проверки так же, как вы относились бы к выявленным несоответствиям аудитором — исправьте, задокументируйте исправление и сохраните след бумаги. Эта внутренняя проверка обычно — это то место, где команды обнаруживают пробелы в обзорах доступа и устаревшие контракты с поставщиками до того, как это сделает кто-то внешний, с отчетом, приложенным к возобновлению контракта с заказчиком.
Если вы хотите глубже изучить технические контроли, стоящие за этими фреймворками — дизайн управления доступом, логирование, реагирование на инциденты — посмотрите дорожки Blue Team и Certifications на Korra Studio.
Написано с помощью ИИ, проверено и опубликовано Михалом Пильхом (CISSP), Korra Studio.
Это одна заметка из базы знаний Korra Studio — платформа сочетает каждую тему с наставничеством один на один.
Начать бесплатноarrow_forward