Пентест по DORA: обычное тестирование, TLPT и определение объема

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

Это образовательное руководство по закупке таких работ для финансовых организаций и помогающих им команд. Оно не определяет, применяется ли DORA к конкретной организации и была ли она выбрана для TLPT. Эти вопросы следует подтвердить у компетентного органа и квалифицированных юристов. Обычный пентест может быть частью тестирования по DORA, но сам по себе не выполняет все требования DORA и не является сертификацией.

Начните с режима тестирования, а не с названия услуги

DORA задаёт два связанных уровня тестирования. По статье 24 финансовые организации, кроме микропредприятий, поддерживают основанную на рисках программу тестирования цифровой операционной устойчивости. Не реже раза в год надлежащие проверки должны охватывать все ИКТ-системы и приложения, поддерживающие критические или важные функции. В статье 25 перечислено много возможных методов: оценка и сканирование уязвимостей, анализ исходного кода, сценарные и сквозные проверки, а также пентест. Там не сказано, что каждая система нуждается в ежегодном пентесте.

TLPT — продвинутый уровень по статьям 26 и 27. Он обязателен для финансовых организаций, которые соответствующий орган определил по регуляторным критериям. Из числа обязанных проводить TLPT исключены микропредприятия и организации, указанные в первом абзаце статьи 16(1). Обычно выбранная организация проводит TLPT не реже одного раза в три года, однако орган может сократить или увеличить интервал с учётом риск-профиля и операционных обстоятельств. Проверка охватывает несколько или все критические либо важные функции и испытывает работающие продуктивные системы с помощью красной команды, действия которой направляются данными об актуальных угрозах.

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

Стройте объем проверки от критических или важных функций

Список IP-адресов — результат определения объема, а не его отправная точка. Начните с функций, сбой которых может существенно повредить финансовым показателям, непрерывности услуг или соблюдению условий лицензии. Для каждой функции сопоставьте бизнес-услугу, владельцев процессов, пользовательские сценарии, приложения, идентификационные данные и права, инфраструктуру, потоки данных, зависимости восстановления и сторонних поставщиков ИКТ. Зафиксируйте, где работает каждая зависимость и кто вправе разрешить её проверку.

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

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

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

Управляйте проверкой продуктивной среды как операционным изменением

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

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

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

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

Покупайте компетентность и независимость, а не значок DORA

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

Это предмет проверки поставщика, а не рекламные формулы. Запросите имена участников команды и роли, разделение разведки угроз и красной команды, если их предоставляет одна компания, подтверждение страхования, контроль качества, проверку конфликтов, список субподрядчиков, места хранения данных и порядок безопасного удаления. Спросите, кто вправе принимать операционные решения в три часа ночи во время активного сценария. Проверяйте заявления и не полагайтесь на ярлык «одобренный DORA-провайдер». Знакомый поставщик обычных пентестов не обязательно обладает управленческими процессами и способностью к проверке красной командой на основе разведданных, которые нужны для TLPT.

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

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

Включайте сторонних поставщиков ИКТ в проект заранее

Критическая функция часто пересекает границы облака, SaaS, управляемой защиты и внутригрупповых услуг. DORA не позволяет финансовой организации стереть эти зависимости из объема. Она должна определить внешние системы и услуги ИКТ, поддерживающие критические или важные функции, принять меры для участия соответствующих поставщиков и продолжать нести ответственность за соблюдение требований.

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

Объединённый TLPT — узкий механизм, а не универсальный способ исключить поставщика из теста. DORA допускает его, если прямое участие с разумной вероятностью ухудшит услуги клиентам вне сферы DORA или поставит под угрозу конфиденциальность их данных. При наличии необходимого письменного соглашения поставщик ИКТ может напрямую заключить договор с внешним тестировщиком, одна финансовая организация руководит объединённой проверкой, а число участников ограничивается для сохранения качества. У каждой финансовой организации остаются собственные обязанности и управление рисками. Совместный TLPT также может рассматриваться, когда организации группы используют общие ИКТ-системы или внутригруппового поставщика.

Планируйте TLPT как полноценный проект

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

1. Инициация и объемСформировать контрольную команду, выбрать поставщиков, задать риски, функции, системы и флаги; получить необходимое утверждение органа
2. Сценарии угрозНа основе целевой разведки выбрать реалистичных противников, пути атак и цели для согласованного объема
3. Проверка продуктивных системПровести контролируемую активную фазу красной команды продолжительностью не менее двенадцати недель с еженедельными отчётами о ходе теста и фиксацией изменений
4. Воспроизведение и обучениеПодготовить отчёты красной и синей команд, сопоставить наступательные и защитные действия, затем организовать их совместную работу (purple teaming)
5. Исправление и подтверждениеПередать сводку и план исправлений, контролировать владельцев и сроки и сохранить подтверждение органа для взаимного признания

Процесс проверяет не только возможность эксплуатации. Руководитель контрольной команды выбирает не менее трёх сценариев, учитывая целевые данные об угрозах и предусмотренные процедурой экспертные оценки. Красная команда испытывает вход, перемещение и достижение целей; доказательства синей команды показывают обнаруженные действия и реакцию. Согласованная помощь тестировщикам (leg-up) может позволить продолжить остановившийся путь, но её нужно заранее предусмотреть и зафиксировать, поскольку она меняет толкование результата.

После активной фазы красная команда отчитывается, синяя сопоставляет обнаружения и доказательства, а стороны воспроизводят последовательность. Затем красная и синяя команды совместно исследуют альтернативные или незавершённые пути. Так неудавшееся проникновение всё равно может выявить слабую телеметрию, а удавшееся — меру защиты, которая сработала позже ожидаемого. Результат представляет собой материал для обучения, а не отметку «сдано» или «не сдано».

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

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

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

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

Ретест превращает техническое заявление в доказательство закрытия. Там, где это безопасно, он воспроизводит исходное условие, проверяет значимые соседние пути и фиксирует среду, дату и результат. Руководство по проверке исправлений после пентеста объясняет разницу между «исправлено» и «проверено». Подтверждение органа помогает взаимному признанию правильно проведённого TLPT, но не сертифицирует общую защищённость организации и не одобряет каждую меру защиты.

Гипотетическое решение о закупке

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

Обоснованной покупкой не обязательно будет полный TLPT. Организация может заказать аутентифицированное тестирование API и путей атаки через идентификацию, проверить доказательства и договорные ограничения процессора и провести сценарную проверку передачи инцидента. В записке об объеме фиксируется, почему эти методы уместны в этом году и как программа охватывает все поддерживающие системы. Если впоследствии орган выберет организацию для TLPT, карта функций и подготовка поставщика станут основой уже другого, управляемого органом проекта; прежний пентест не превратится в TLPT задним числом.

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