DORA и TLPT: почему «есть ли у вас контроли?» больше не считается ответом

С 17 января 2025 года финансовый сектор ЕС живёт по DORA. Разбираем, чем базовое тестирование отличается от TLPT, почему учения по TIBER-EU идут на продуктивной среде и как это дотягивается до молдавских IT-подрядчиков.

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

Что такое DORA и кого она накрывает

DORA — Регламент (ЕС) 2022/2554 о цифровой операционной устойчивости финансового сектора. Это именно регламент, а не директива: он применяется напрямую во всех государствах-членах, без национальной имплементации. Поэтому «мы ещё ждём местный закон» здесь не работает — обязанность возникает из текста ЕС напрямую.

Регламент покрывает пять смысловых блоков: управление ICT-риском (то есть риском информационно-коммуникационных технологий), отчётность об инцидентах, тестирование цифровой устойчивости, риск третьих сторон — поставщиков ICT — и обмен информацией об угрозах. Нас в этой статье интересует третий блок, но он не существует в вакууме: без инвентаря систем и без реестра поставщиков его невозможно спланировать.

Первый круг — это практически весь финансовый сектор Европы: кредитные организации, платёжные институты и институты электронных денег, инвестиционные фирмы, управляющие фондами, страховщики, поставщики услуг криптоактивов, рыночные инфраструктуры. Второй круг — тот, который чаще всего игнорируют: сторонние поставщики ICT-услуг. Хостинг, облако, банковское ПО, процессинг, сопровождение.

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

Примечание: прямое действие DORA на поставщика ICT возникает, только если он назначен критическим поставщиком ICT-услуг на европейском уровне. Во всех остальных случаях давление идёт по цепочке контрактов — но от этого оно не становится менее обязательным.

Базовый программный уровень: что тестируется каждый год

DORA требует программы тестирования цифровой устойчивости, которая применяется как минимум ежегодно ко всем ICT-системам, поддерживающим критичные или важные функции. Ключевое слово — «программа». Это не один тест, а набор дисциплин, которые дополняют друг друга и закрывают разные классы риска.

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

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

TLPT: тестирование, ведомое угрозами

Над базовой программой DORA вводит продвинутое тестирование для организаций, назначенных компетентными органами — по критериям риска и системной значимости. TLPT (threat-led penetration testing) проводится не реже одного раза в три года, следует европейской рамке TIBER-EU и отличается от обычного пентеста тремя принципиальными вещами.

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

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

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

Фаза replay: где рождается основная часть улучшений

Полный TLPT обычно занимает от трёх до шести месяцев и делится на подготовку, threat intelligence, собственно тестирование и закрывающую фазу с replay. В replay атакующие и защитники вместе проходят хронологию минута за минутой: где был сигнал, который никто не увидел; где сработало правило, но алерт утонул в шуме; где аналитик принял верное решение, но не имел полномочий его реализовать. На практике эта фаза даёт больше улучшений, чем итоговый список уязвимостей, — потому что она меняет процессы, а не только конфигурации.

Базовый уровень и TLPT: сравнение

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

Что сделать до того, как идти в TLPT

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

• Инвентарь критичных функций и поддерживающих их ICT-систем. Без него периметр TLPT невозможно определить, и упражнение расползётся.
• Классическое внешнее и внутреннее тестирование с устранением находок вплоть до повторной проверки. Не «приняли риск», а закрыли или формально задокументировали остаточный риск.
• Реестр поставщиков ICT и контрактные оговорки о тестировании и аудите. Если поставщик отказывается участвовать в тестировании критичной функции, это уже находка сама по себе.
• Реальная способность к обнаружению. Если у вас нет централизованного мониторинга, TLPT будет измерять его отсутствие — и результат будет честным, но бесполезным для улучшения.

Внимание: чаще всего TLPT проваливается не на этапе взлома, а на этапе подготовки — из-за неполного инвентаря, неучтённых зависимостей и поставщиков, которых забыли включить в периметр. Это организационная ошибка, а не техническая.

Что это значит для молдавских компаний

Молдавский IT-подрядчик, обслуживающий банк из ЕС, столкнётся с DORA в трёх конкретных местах. Первое — договор: клиент обязан включить в него требования безопасности, права доступа и аудита, положения об устойчивости и, для поставщиков, поддерживающих критичные функции, участие в тестировании устойчивости, включая TLPT-упражнения клиента. Второе — доказательства: от вас будут ждать не декларации, а артефакты — отчёты о тестировании, результаты сканирования, записи об устранении. Третье — окна и ограничения: участие в TLPT означает, что ваши системы могут стать частью чужого сценария атаки, и к этому нужно быть готовым организационно.

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

Отдельно стоит сказать про иллюзию готовности. Организация, которая годами заказывала сканирование уязвимостей и считала это тестированием, приходит к TLPT с ощущением, что «мы всё делали». Разница обнаруживается в replay: сканирование не показывает, увидит ли дежурный аналитик lateral movement в три часа ночи и есть ли у него плейбук на этот случай. DORA смещает фокус именно сюда — с наличия контролей на доказанную способность выдержать атаку и восстановиться. Для одних это означает пересмотр бюджета на мониторинг, для других — пересмотр отношений с подрядчиками, для третьих — честный разговор о том, что критичная функция зависит от системы, которую никто не тестировал. Начать этот разговор дешевле, чем получить его результат в виде отчёта TLPT.