Тестирование на проникновение для комплаенса
Большинство тестов на проникновение заказывают потому, что этого требует регулирование. Стандарт определяет объём работ, периодичность и — ту часть, которую недооценивают, — доказательства, которые вы должны суметь предъявить потом. Эта страница сравнивает режимы, под которые я тестирую, чтобы вы поняли, какой из них действительно касается вас.
Сравнение стандартов
Каждый из этих режимов предписывает независимое тестирование безопасности или фактически его требует. Важные различия: кого обязывает, с какой периодичностью и что вы должны суметь показать потом.
Саудовская Аравия
- NCA Essential Cybersecurity Controls (на английском) — национальная база для госорганов, их подрядчиков и критической инфраструктуры. Контроль 2-11 охватывает тестирование на проникновение: определено, задокументировано, утверждено и внедрено, с объёмом, покрывающим как минимум доступные из интернета сервисы и техническую инфраструктуру за ними. Периодически.
- NCA Critical Systems Cybersecurity Controls — если системы классифицированы как критичные, периодичность становится не реже раза в шесть месяцев. Именно это изменение ритма обычно и ломает бюджетное допущение.
- SAMA Cyber Security Framework (на английском) — банки, страховщики, финансовые компании и платёжные провайдеры под надзором Центрального банка Саудовской Аравии. Независимые внешние тесты не реже раза в год, охватывающие доступные из интернета системы, веб-приложения и сетевую инфраструктуру.
Объединённые Арабские Эмираты
- NESA / UAE Information Assurance Standards (на английском) — федеральные органы и информационная инфраструктура, отнесённая к критической. Оценки уязвимостей и тесты на проникновение проводятся и отслеживаются, на практике ежегодно, с документированным устранением и доказательством повторного теста для критичных и высоких находок в установленный срок. Аудиторы проверяют квалификацию исполнителя.
- Dubai ISR (DESC) — госорганы Дубая и их поставщики. Действует параллельно с NESA; одна работа может подтвердить оба режима.
- CBUAE, DFSA и ADGM (на английском) — банки и финансовые компании внутри страны, компании DIFC, компании ADGM. Во всех трёх случаях ожидается регулярное независимое тестирование.
- VARA — поставщики услуг виртуальных активов в Дубае. Независимый тест на проникновение не реже раза в год по Technology and Information Rulebook, а также тестирование на основе разведданных, если VARA сочтёт это соразмерным.
- ADHICS (на английском) — медицинские организации Абу-Даби и их технологические поставщики.
Международные
- PCI DSS — для всех, кто хранит, обрабатывает или передаёт данные держателей карт. Требование 11.4 предписывает внутренние и внешние тесты не реже раза в год и после существенных изменений, а также тестирование сегментации, если она используется для сокращения области действия.
- SOC 2 — не предписывающее требование, но тест на проникновение это доказательство, которого большинство аудиторов ожидает по CC4.1 и CC7.1, и корпоративные клиенты всё чаще требуют его в отчёте.
- ISO 27001 — управление техническими уязвимостями по Приложению A, где тест это практический способ показать, что контроль работает.
Что аудиторы запрашивают на самом деле
Отчёт необходим, но недостаточен. Полный пакет доказательств составляют четыре документа, а большинство организаций приходит только со вторым:
- Документ об объёме — что тестировалось, что нет и почему такой объём соответствовал контролю. Тест, исключивший именно те системы, о которых идёт речь в контроле, не проходит, каким бы хорошим он ни был.
- Отчёт — находки, уровни критичности, детали воспроизведения и сопоставление с затронутыми контролями.
- Документированное устранение — что вы исправили, когда, и что приняли как риск с указанием причины. Принять риск можно; не зафиксировать решение нельзя.
- Доказательство повторного теста — подтверждение, что критичные и высокие находки действительно закрыты, в срок, установленный вашим стандартом. Ожидание 90 дней у NESA подводит чаще всего: тест на одиннадцатом месяце не оставляет времени на повторный до закрытия цикла.
Письмо-аттестация — кто тестировал, какой объём, какие даты — связывает пакет и обычно именно оно подшивается или передаётся клиенту. Каждая работа здесь включает такое письмо.
Независимость — требование, которое читают неверно
Несколько из этих стандартов используют слово независимый, и у него конкретный смысл: тест не может выполнять тот, кто построил или эксплуатирует проверяемую систему. Внутренняя служба безопасности, тестирующая инфраструктуру собственной организации, удовлетворяет одним стандартам и не удовлетворяет другим; команда, написавшая приложение и затем его тестирующая, не удовлетворяет ни одному.
Это во многом объясняет существование внешних консультантов на этом рынке, и стоит сверить это с вашей конкретной обязанностью, прежде чем считать, что внутренних сил достаточно. Ошибка здесь дорога, потому что обнаруживается на аудите, а не при планировании объёма.
Как я планирую работу для комплаенса
Первый разговор о обязанности, а не о технологиях: какой стандарт, какой контроль, какой срок и менялось ли что-то существенное с прошлого теста. Из этого я обычно могу за один звонок сказать, покрывает ли одна работа всё, под что вы подпадаете, и что должен включать объём, чтобы доказательства выдержали аудит.
Что вы получаете: фиксированную цену до начала работ, тестирование тем самым человеком, с которым вы говорили, немедленное уведомление о критичных находках вместо сюрприза в итоговом документе, отчёт, написанный одновременно для руководства и для инженеров, поддержку во время устранения, повторный тест и письмо-аттестацию. Есть пример отчёта, если хотите сначала посмотреть формат (на английском), и страница цен для понимания порядка величин.
По регионам
Если вы в Персидском заливе, региональные страницы подробнее разбирают, какие режимы применяются и как они пересекаются: тестирование на проникновение в Саудовской Аравии и тестирование на проникновение в ОАЭ. В остальных случаях страницы услуг описывают само тестирование, а обращение напрямую это самый быстрый путь к ясному ответу.
Вопросы о тестах для комплаенса
Как правило, да, и это намного дешевле альтернативы. Технический объём во многом совпадает — внешний периметр, веб-приложения и API, внутренняя сеть, Active Directory, облако, — поэтому различается сопоставление с контролями и форма отчёта, а не само тестирование. Условие одно: так нужно спланировать с самого начала. Тест, спроектированный только под PCI, не даст доказательств, которых требует NESA, хотя сама работа почти идентична. Назовите при согласовании объёма все режимы, под которые вы подпадаете, и отчёт свяжет находки с каждым из них.
Нет, и это самая частая причина отклонения доказательств. Сканер сопоставляет известные сигнатуры с известными версиями и выдаёт список; тест на проникновение связывает находки в цепочку и показывает, чего злоумышленник действительно мог бы добиться. Стандарты говорят об этом всё прямее, а аудиторы научились распознавать отчёт сканера с обложкой пентеста — признак в том, что каждая находка это CVE и ни одна не связана с другой. Разница подробно (на английском).
Четыре вещи, и у большинства организаций есть только вторая. Документ об объёме работ, показывающий, что тестировалось и почему такой объём был уместен. Сам отчёт с находками, уровнями критичности и деталями воспроизведения. Документированное устранение критичных и высоких находок. И доказательство повторного теста, подтверждающего, что исправления сработали, в срок, установленный вашим стандартом, — обычно 90 дней. Письмо-аттестация с указанием, кто тестировал, в каком объёме и в какие даты, связывает всё воедино и обычно именно оно попадает в дело.
Ежегодно — обычная базовая периодичность: SAMA, NESA, VARA и PCI DSS сходятся на ней. Сокращают срок две вещи: классификация как критичной системы по саудовским CSCC, которая требует тестирования не реже раза в шесть месяцев, и существенные изменения. Почти каждый стандарт требует повторного теста после материальных изменений среды независимо от даты последнего ежегодного теста — крупная миграция или новое приложение, доступное из интернета, фактически обнуляют отсчёт.
Обычно да, и причины предсказуемы: объём был слишком узким для того, что требует контроль; тест выполняла команда, построившая систему, то есть он не был независимым; не было доказательства повторного теста; либо сканирование подали как тест на проникновение. Все четыре случая исправимы, и решением обычно становится одна правильно спланированная работа, а не программа. Пришлите мне замечание аудитора и прежний отчёт, и я скажу, какой из четырёх случаев это был, прежде чем вы что-либо потратите.
Не уверены, какой стандарт касается вас?
Короткого разговора обычно достаточно — и он покажет, может ли один тест закрыть их все.