Требования SAMA к тестированию на проникновение
Если вас надзирает Центральный банк Саудовской Аравии, тестирование на проникновение — это ежегодная повторяющаяся обязанность, а не проект. Стандарт конкретен в двух вещах, которые решают, выдержат ли ваши доказательства проверку: тестирование должно быть независимым, а объём должен доходить до систем, которых касаются ваши клиенты.
Требование, сформулированное прямо
От организаций под надзором Центрального банка Саудовской Аравии ожидается проведение независимых внешних тестов на проникновение не реже одного раза в год с объёмом, покрывающим системы, обращённые вовне, веб-приложения и сетевую инфраструктуру.
Три слова в этой фразе несут основную нагрузку, и каждое — место, где доказательства чаще всего не проходят проверку:
- Независимые — выполненные не той командой, которая строит или эксплуатирует тестируемые системы.
- Ежегодно, не реже — годовой цикл является нижней границей, а существенное изменение систем, доступных из интернета, — отдельным триггером.
- Тест на проникновение — не сканирование уязвимостей с другой обложкой. Аудиторы научились их различать.
Где доказательства SAMA действительно рушатся
Четыре сценария отказа объясняют большую часть того, что оспаривается, и все четыре дешевле предотвратить, чем исправлять.
Сканирование, поданное как тест на проникновение
Признак структурный: каждая находка — это CVE с описанием от вендора, ничего не связано в цепочки, и нет повествования о том, чего мог бы добиться атакующий. Тест на проникновение демонстрирует воздействие: этот открытый сервис отдаёт учётные данные, эти учётные данные доходят до этой внутренней системы, в которой лежат эти данные. Если ваш отчёт — отсортированный список версий, это сканирование. Различие целиком.
Независимость, которая не выдерживает
Тестирование, выполненное инженерной командой, поставщиком управляемых услуг, который также эксплуатирует инфраструктуру, или вендором, оценивающим собственный продукт. Каждый из этих случаев не удовлетворяет требованию независимости, каким бы компетентным ни было тестирование.
Объём, упускающий клиентский слой
Бэкенды мобильного банкинга, партнёрские API, новая финтех-интеграция, запущенная после подписания объёма. Системы, доступные из интернета, и веб-приложения прямо названы в стандарте, поэтому пробел здесь — это прямое упущение, а не вопрос трактовки.
Нет повторного тестирования
Отчёт с двенадцатью находками высокой критичности и без доказательств, что хоть одна закрыта, с точки зрения проверяющего является документацией нерешённой проблемы. Цикл устранения и повторного тестирования — это то, что превращает тест в доказательство соответствия.
Что покрывает работа
Регуляторная база, каждый год:
- Тестирование внешней сети — весь парк, доступный из интернета: интернет-банк, платёжные интерфейсы, VPN и удалённый доступ, почтовая инфраструктура и узлы, опубликованные под проект и никогда не снятые.
- Тестирование веб-приложений и API — аутентификация и управление сессиями, авторизация и разграничение доступа между клиентами, бизнес-логика в транзакционных потоках, инъекции и API за мобильными приложениями. В финансовой организации находки по бизнес-логике обычно важнее всего и именно их автоматизация никогда не находит.
Рекомендуется дополнительно и включается большинством организаций в годовой или чередующийся цикл:
- Тестирование внутренней сети — куда реально дотягивается закрепление и выдерживает ли сегментация между корпоративной и платёжной средами.
- Active Directory — злоупотребление ADCS, Kerberoasting, делегирование и пути через ACL до Domain Admin. Именно так скромное закрепление превращается в компрометацию масштаба всего банка, и для внешнего тестирования это невидимо.
- Облако — повышение привилегий в Entra ID и Azure RBAC, открытые хранилища и некорректная конфигурация идентификаторов там, куда переехали нагрузки.
- Предполагаемая компрометация — старт от закрепления, а не от периметра, что отвечает на вопрос, который совет директоров задаёт на самом деле: как далеко мог бы зайти злоумышленник?
Если вы также обрабатываете карточные данные, параллельно применяется требование 11.4 PCI DSS и существенно пересекается — при совместном определении объёма это одна работа, а не две.
Результат
Отчёт, построенный под то, как финансовые организации его действительно используют: резюме для руководства, которое ваш совет директоров и регулятор смогут прочитать без перевода, техническая часть с шагами воспроизведения, доказательствами и оценками CVSS для ваших инженеров, и явное сопоставление каждой находки с тем контролем стандарта, к которому она относится, чтобы вашей команде по соответствию не пришлось строить это сопоставление самостоятельно.
Затем то, что превращает отчёт в доказательство: сопровождение устранения, пока вы исправляете, повторное тестирование закрытых находок и аттестационное письмо о том, что тест был проведён, кем, в каком объёме и в какие даты. Всё включено. Образец отчёта показывает формат.
Кто выполняет
Вы взаимодействуете напрямую с тестировщиком — без менеджера по работе с клиентами, без джуниора, запускающего инструменты под именем сеньора в счёте, без трёх недель ожидания между тестированием и отчётом. Для регуляторного срока именно эта прямота обычно позволяет уложиться в дату.
Квалификации, поскольку в закупках финансового сектора об этом спрашивают всегда: OSCP+, eCPPT, eWPT, eCIR, плюс AZ-500, SC-200 и SC-300 для части по Microsoft и Azure — все проверяются через credential wallet OffSec. До перехода в наступательную безопасность на полную занятость я был инженером по обнаружению и аналитиком CTI — полезный бэкграунд именно в этом секторе: отчёт расскажет не только о том, как работает цепочка атаки, но и о том, как она выглядела бы в вашей SIEM и поймал бы её ваш мониторинг.
Работаю удалённо из Аммана в GMT+3, те же часы и та же рабочая неделя, что в Эр-Рияде, на арабском или английском.
С чего начать
Сообщите тип вашей лицензии, что входит в объём и к какому сроку тест должен быть завершён. В ответ вы получите фиксированную стоимость и дату старта. Если годовой цикл приближается и вы хотите сначала увидеть текущую внешнюю экспозицию, бесплатное сканирование периметра занимает несколько минут.
Смежное: тестирование на проникновение в Саудовской Аравии о том, как SAMA соотносится с NCA ECC, контроль 2-11 ECC, если вы несёте ещё и государственное обязательство, и обзор соответствия для всего остального. Свяжитесь со мной — арабский приветствуется.
Вопросы по SAMA
На организации-члены под надзором Центрального банка Саудовской Аравии: банки, страховые и перестраховочные компании, финансовые компании, кредитные бюро и поставщиков платёжных услуг, включая финтех-компании, работающие по лицензии SAMA или в её регуляторной песочнице. Если ваша лицензия от SAMA, стандарт распространяется на вас. Финтех-компании часто этим удивлены: обязанность приходит вместе с лицензией, на этапе, когда программа безопасности зачастую ещё только формируется.
Независимое внешнее тестирование на проникновение не реже одного раза в год. Слова «не реже» здесь выполняют реальную работу: существенное изменение систем, доступных из интернета, как правило, должно запускать тестирование независимо от того, в какой точке годового цикла вы находитесь, и организации, запустившей новую клиентскую платформу через полгода после ежегодного теста и не протестировавшей её, предстоит непростой разговор. Относитесь к ежегодному тесту как к нижней границе, а к значимым изменениям — как к отдельному триггеру.
Что тестирование не могут проводить люди, которые строят или эксплуатируют тестируемые системы. Внутренняя функция безопасности, подчиняющаяся отдельно от инженерии, ближе к цели, но самый чистый и общепринятый ответ — внешняя сторона, не участвующая ни в построении, ни в эксплуатации среды. Это требование организации нарушают чаще всего и обнаруживают это на проверке, а не на этапе определения объёма — то есть в дорогом порядке.
Прямо названный объём — системы, доступные из интернета, веб-приложения и сетевая инфраструктура. Большинство организаций идёт дальше, и обоснованно: тест, доказывающий, что атакующий может добраться до периметра, но никогда не спрашивающий, что происходит дальше, отвечает на половину вопроса. Хорошо работающая схема — полная внешняя и веб-прикладная оценка ежегодно как регуляторная база, плюс тестирование внутренней сети и Active Directory как минимум через год или всякий раз, когда парк существенно меняется.
Да, и это обычный случай. У вас, как правило, уже есть сопоставление со стандартом, функция GRC и взаимодействие с внутренним аудитом; нужны тестирование и доказательства, которые в это встроятся. Я задаю объём под тот контроль, который вам нужно закрыть, сопоставляю находки с ним в отчёте и передаю повторное тестирование и аттестацию, которые ваша команда по соответствию подшивает в дело. Я не GRC-консалтинг и не буду пытаться продать вам программу внедрения стандарта — тестирование и есть та часть, которую делаю я.
Подходит срок ежегодного теста SAMA?
Независимо, по объёму стандарта, с повторным тестированием и аттестацией, которые подшивает ваша команда по соответствию.