TIBER-EU: как регуляторы заставляют банки атаковать самих себя

Разбираем европейский фреймворк threat intelligence-based red teaming: кто такие control team и TIBER cyber team, как устроены фазы теста и почему «не сдать» TIBER невозможно — но и пройти формально тоже.

Представьте, что вы руководитель безопасности крупного банка. Вы знаете, что вас будут атаковать, но не знаете когда, кто и каким способом. Именно в таком положении оказывается blue team во время теста по фреймворку TIBER-EU — европейской модели этичного red teaming, построенного на threat intelligence. Это не аудит, не сканирование и не пентест «по чек-листу»: это контролируемая имитация реального противника, о которой внутри организации знают лишь несколько человек.

Что такое TIBER-EU и зачем он появился

TIBER-EU (Threat Intelligence-based Ethical Red Teaming) — это рамочный документ, разработанный Европейским центральным банком совместно с национальными центробанками ЕС, утверждённый Советом управляющих ЕЦБ и опубликованный в мае 2018 года. Его задача — гармонизировать подход к тестированию киберустойчивости финансовой инфраструктуры по всей Европе. Ключевая идея проста: вместо того чтобы каждая страна придумывала собственные правила игры, появляется единый стандарт, который регуляторы взаимно признают.

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

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

Пять команд, которые делают тест

Одна из самых сильных сторон TIBER-EU — чёткое распределение ролей. В тесте участвуют пять команд, и путаница между ними — главный источник провалов на практике.

Обратите внимание на асимметрию: blue team — это сотни или тысячи людей, которые не знают, что их проверяют. Control team — это единицы людей внутри той же организации, которые знают всё и координируют действия с TIBER cyber team. Именно control team — тот самый «человек в плаще», который держит тест в рамках закона и здравого смысла: следит за тем, чтобы red team не вышла за согласованные границы, и чтобы атака не привела к реальному инциденту.

Threat intelligence provider и red team — это внешние подрядчики. И здесь кроется важный нюанс: провайдеров нужно не просто нанять, а проверить на соответствие требованиям. Для этого существует отдельный документ — TIBER-EU Guidance for Service Provider Procurement, описывающий процесс отбора и закупки услуг. Нанимать «первого, кто умеет в пентест» — распространённая и дорогая ошибка.

Внимание: red team в TIBER-EU — это не команда, которая «ломает всё, что видит». Её задача — сымитировать тактики, техники и процедуры (TTP) реальных атакующих на основе заказной разведки, а не продемонстрировать максимальный технический арсенал. Выход за согласованный scope — это уже не тест, а инцидент.

Как устроен тест: от инициации до аттестации

TIBER-EU — это не одно мероприятие, а последовательность фаз, каждая из которых формализована шаблонами и рекомендациями. Фазы выглядят так: инициация, определение границ (scoping), threat intelligence, red-team тестирование (планирование и отчётность), создание отчёта blue team и плана устранения (remediation plan). Всё это венчается итоговым отчётом (test summary report) и аттестацией — документом, который позволяет регуляторам взаимно признавать результаты теста.

Инициация и scoping

На старте определяется, какие именно критические функции будут тестироваться. Это принципиальный момент: если scope размыт, red team либо потратит время на второстепенные системы, либо случайно заденет то, что трогать нельзя. Хорошо проработанный scoping — это половина успеха теста.

Threat intelligence

Здесь провайдер разведки анализирует спектр возможных угроз и проводит рекогносцировку по конкретной организации. На выходе — не общий отчёт «в мире есть APT», а tailor-made профиль угроз, под который red team будет строить сценарий атаки. Именно этот этап отличает TIBER-EU от классического пентеста: атака моделируется под конкретного противника, а не под универсальный список уязвимостей.

Red-team тестирование

Red team пытается скомпрометировать критические функции организации, имитируя кибератакующего. Здесь важно понимать: результат теста — не «сдал/не сдал». В документе прямо сказано, что цель — выявить сильные и слабые стороны мер киберустойчивости, а фокус сделан на обучающем эффекте и повышении уровня киберзрелости организации. Это принципиально иная философия, чем у сертификационного аудита.

Отчёты и план устранения

После атаки появляются два документа с разных сторон баррикад: отчёт red team и отчёт blue team. Blue team описывает, что она видела, как отреагировала и где не сработало. Затем формируется remediation plan — конкретный план устранения выявленных проблем. Завершает всё test summary report и аттестация, обеспечивающая взаимное признание.

Примечание: в TIBER-EU есть отдельные документы по purple teaming — совместной работе red и blue команд на этапе тестирования или закрытия. Это позволяет превратить обнаруженные пробелы в детекте в работающие правила и проверенные сценарии реагирования, а не просто в список замечаний.

Связь с DORA: почему это стало обязательным

До недавнего времени TIBER-EU был добровольным, хотя и очень уважаемым фреймворком. Ситуация изменилась с появлением Digital Operational Resilience Act (DORA) — европейского регламента о цифровой операционной устойчивости. DORA вводит требования к threat-led penetration testing (TLPT), и TIBER-EU помогает эти требования выполнить: фреймворк обновлён в 2024 году, чтобы полностью соответствовать Regulatory Technical Standards по TLPT в рамках DORA.

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

География и взаимное признание

Фреймворк принят в Австрии, Бельгии, Чехии, Дании, Эстонии, Финляндии, Франции, Германии, Исландии, Ирландии, Италии, Лихтенштейне, Люксембурге, Мальте, Нидерландах, Норвегии, Португалии, Румынии, Словакии, Испании и Швеции, а также применяется самим ЕЦБ и реализован на европейском уровне в рамках ECB Banking Supervision. Другие юрисдикции находятся в процессе принятия или, как ожидается, присоединятся позже.

Для организаций, работающих в нескольких странах, это критически важно: национальные TIBER-EU cyber teams проводят тесты в своих юрисдикциях, а организации с мультиюрисдикционной активностью могут участвовать в совместных тестах с несколькими cyber teams одновременно. Вместо того чтобы проходить пять разных тестов по пяти разным методикам, организация проходит один тест, который признают все.

Координацию обеспечивает TIBER-EU Knowledge Centre (TKC) — форум под эгидой ЕЦБ, где национальные и европейские TIBER-EU cyber teams обмениваются опытом и обсуждают инициативы. Это та самая инфраструктура, которая обеспечивает единообразие применения фреймворка в разных странах.

Что это значит для вашей организации на практике

Если вы оцениваете свою готовность к TIBER-EU или к TLPT по DORA, полезно смотреть на это глазами тех, кто проводит тесты. С точки зрения red team, самый интересный этап — именно threat intelligence: без качественного профиля угроз атака превращается в стандартный набор эксплойтов, а тест теряет смысл. С точки зрения blue team, самое ценное — честный отчёт о том, что детект не сработал, а не красивый документ о том, что «в целом всё хорошо».

Практические шаги, которые обычно дают наибольший эффект:

• Определите критические функции до scoping, а не после — и убедитесь, что в них входят люди и процессы, а не только системы.
• Проведите due diligence провайдеров threat intelligence и red team по TIBER-EU Guidance for Service Provider Procurement, а не по прайс-листу.
• Сформируйте control team заранее и отработайте с ней протоколы эскалации и остановки теста.
• Заранее договоритесь о формате blue team report — иначе получите либо оправдания, либо стенограмму логов.
• Планируйте remediation plan как продукт теста, а не как формальность для регулятора.

Отдельно стоит продумать purple teaming: совместная работа red и blue на этапе тестирования или закрытия позволяет сразу превратить найденные слепые зоны в работающие детекты. Без этого организация рискует получить отчёт с перечнем проблем, которые через год повторятся в следующем тесте.

Важно: TIBER-EU не выдаёт сертификат. Успешный тест — это не «галочка», а зафиксированное понимание того, где именно ваша защита даёт сбой под давлением целенаправленной атаки. Организации, которые воспринимают TIBER-EU как экзамен, обычно получают меньше пользы, чем те, кто воспринимает его как тренировку.

Вывод: тест, который не заканчивается отчётом

Главная ценность TIBER-EU — не в самом факте проведения red-team теста, а в цикле: разведка угроз → имитация атаки → честный разбор → устранение → повторная проверка. Фреймворк с 2018 года прошёл путь от добровольной инициативы ЕЦБ до методологической основы для DORA, и это лучшее доказательство того, что модель работает. Для организаций критической инфраструктуры вопрос уже не в том, стоит ли проводить threat-led тестирование, а в том, насколько качественно оно будет проведено. И здесь разница между формальным тестом и настоящим TIBER-EU-тестом измеряется не количеством найденных уязвимостей, а тем, насколько организация стала устойчивее после того, как узнала о них.