По изискване
Какво всъщност изисква DORA от вашето тестване на сигурността
DORA превръща тестването на устойчивостта в правно задължение за финансовите субекти в ЕС. Ето какво изискват членове 24 до 27 и техническите стандарти за TLPT и как red team тестването, съобразено с TIBER-EU, подкрепя тази работа.
От сценария до доказателствата от теста.
Свързваме договорения сценарий със системите в обхвата и доказателствата, които ангажиментът трябва да осигури.
Какво изисква
Какво казва DORA за тестването
Глава IV (членове 24 до 27) изисква финансовите субекти, които не са микропредприятия, да създадат, поддържат и преглеждат надеждна и всеобхватна програма за тестване на цифровата оперативна устойчивост като част от рамката си за управление на ИКТ риска. Тя трябва да бъде основана на риска, да използва независими тестери — вътрешни или външни — и да включва процедури за приоритизиране, класифициране и отстраняване на всеки открит проблем, с вътрешно валидиране, че слабостите са напълно отстранени. Поне веднъж годишно подходящи тестове трябва да обхванат всички ИКТ системи и приложения, поддържащи критични или важни функции. Член 25 изброява подходящите тестове — от сканиране за уязвимости и оценки на мрежовата сигурност до прегледи на изходния код, тестове по сценарии и тестване за проникване.
Член 26 добавя тестването за проникване, водено от заплахи (TLPT), за субектите, определени от техния компетентен орган: поне веднъж на три години, обхващащо няколко или всички критични или важни функции, върху реално работещи продукционни системи, с обхват, валидиран от органа, и с включване на съответните доставчици на ИКТ услуги — трети страни. Делегиран регламент (ЕС) 2025/1190, изготвен в съответствие с TIBER-EU, определя процеса: контролен екип, поне три сценария, водени от заплахи, активна фаза на red team с продължителност поне 12 седмици, повторение и purple teaming, планове за отстраняване и атестация от органа.
Чл. 24(1)-(4) – Програма за тестване и независимост
Субектите, които не са микропредприятия, се нуждаят от документирана програма за тестване, основана на риска, в рамките на своята рамка за управление на ИКТ риска. Тестовете трябва да се провеждат от независими страни — вътрешни или външни — като конфликтите на интереси се избягват при проектирането и изпълнението.
Чл. 24(5)-(6) – Отстраняване и годишно тестване
Всеки открит проблем трябва да бъде приоритизиран, класифициран и отстранен, с вътрешно валидиране, че е напълно отстранен. Поне веднъж годишно подходящи тестове трябва да обхванат всички ИКТ системи и приложения, поддържащи критични или важни функции.
Чл. 25 – Тестване на ИКТ инструменти и системи
Изброява подходящите тестове, включително сканиране за уязвимости, оценки на мрежовата сигурност, прегледи на изходния код, където е осъществимо, тестове по сценарии и тестване за проникване. Централните депозитари на ценни книжа и централните контрагенти трябва също да оценяват уязвимостите преди внедряване или повторно внедряване на съответните компоненти.
Чл. 26 – Усъвършенствано тестване въз основа на TLPT
Субектите, определени от своя компетентен орган, трябва да провеждат TLPT поне веднъж на три години върху реално работещи продукционни системи, поддържащи критични или важни функции. Органът валидира обхвата и накрая издава атестация.
Чл. 27 – Изисквания към тестерите
Тестерите по TLPT трябва да са с най-висока професионална компетентност и добра репутация, да покажат експертиза в разузнаването на заплахи, тестването за проникване и red teaming, да са сертифицирани или да следват официални кодекси за поведение, да осигуряват независима увереност и да притежават застраховка „професионална отговорност“.
Делегиран регламент (ЕС) 2025/1190 – РТС за TLPT
Определя кой трябва да извършва TLPT и как: подготовка и определяне на обхвата, целенасочено разузнаване на заплахите с поне три сценария, активна фаза на red team с продължителност поне 12 седмици, приключване с повторение и purple teaming, след което планове за отстраняване.
Какво да се тества
Какво трябва да обхване едно тестване, съобразено с DORA
Критични или важни функции
Започнете от описа на вашите критични или важни функции и картографирайте ИКТ системите, приложенията и процесите зад всяка от тях. Годишното тестване трябва да достигне до всички тях, а не само до средата, достъпна от интернет.
Услуги от трети страни и възложени дейности
Когато доставчици на ИКТ услуги — трети страни, поддържат критични или важни функции, планирайте как те ще участват. За TLPT член 26(3) изисква да осигурите тяхното участие, като вие запазвате пълната отговорност за съответствието.
Съчетание от видове тестове, основано на риска
Член 25 очаква набор от тестове, избрани според риска: сканиране за уязвимости, тестване за проникване на мрежи и приложения, преглед на изходния код, където е осъществимо, и тестове по сценарии. Едно-единствено външно сканиране едва ли покрива този набор.
Откриване и реакция
TLPT тества хора, процеси и технологии върху реално работещи продукционни системи. Извън TLPT упражненията по сценарии с red team или purple team показват дали средствата ви за откриване и процедурите за реакция биха засекли реалистична атака.
Какво получавате
Какво предава PXLSec и как то подкрепя вашите доказателства
Доклади, съотнесени към вашата програма
Всеки доклад записва обхват, методология, дати, тестери и констатации, препратени към критичните или важните функции и системи във вашата програма за тестване, така че да се впише директно в записите ви по член 24.
Приоритизирани, класифицирани констатации
Констатациите носят степен на критичност, засегнати активи, доказателства и насоки за отстраняване, което осигурява информацията, необходима за приоритизиране, класифициране и отстраняване на проблемите, както очаква член 24(5).
Доказателства за повторен тест и закриване
Тестваме повторно корекциите и потвърждаваме закриването писмено, в подкрепа на вътрешното валидиране, което ви е нужно, за да покажете, че установените слабости, недостатъци или пропуски са напълно отстранени.
Red teaming, съобразен с TIBER-EU
Предоставяме red team тестване, съобразено с TIBER-EU, и подкрепяме подготовката за TLPT — от упражнения по сценарии до purple teaming. Дали даден доставчик е подходящ за вашия TLPT, се решава от вашия контролен екип и органа по TLPT.
Чести капани
Чести грешки
Грешки, които струват време при одит, и как да ги избегнете.
Третиране на TLPT като цялата програма
TLPT се отнася само за субектите, определени от техния орган. Всеки друг субект, който не е микропредприятие, все пак се нуждае от програмата по член 24 и от годишно тестване на системите, поддържащи критични или важни функции.
Тестване без карта на функциите
Без актуална карта на критичните или важните функции към системи и доставчици обхватът се превръща в гадаене. Тогава се появяват пропуски точно там, където надзорните органи обикновено гледат — например при възложена или споделена инфраструктура.
Констатации, които никога не се закриват
Член 24(5) изисква отстраняване и вътрешно валидиране, а не просто доклад. Непроследени констатации, недокументирани приемания на риск и липсващ повторен тест правят програмата ви трудна за доказване.
Слаба независимост
Използването на тестери, които са изградили или поддържат тестваните системи, поражда конфликтите на интереси, които член 24(4) ви задължава да избягвате. Записвайте как е осигурена независимостта при всеки тест.
Кой решава какво се приема
PXLSec е независима фирма за офанзивна сигурност, а не одитор, оценител, сертифициращ орган или регулатор. Ние извършваме тестването и осигуряваме доказателствата; вашият одитор, оценител или компетентен орган решава какво приема. Тази страница е обща насока, а не правен съвет.
Често задавани въпроси
Често задавани въпроси
Всеки финансов субект ли трябва да провежда TLPT?
Не. TLPT по член 26 се отнася само за финансовите субекти, определени от техния компетентен орган или орган по TLPT, по критериите в член 26(8) и Делегиран регламент (ЕС) 2025/1190. Микропредприятията и субектите по опростената рамка за управление на ИКТ риска са изключени. Останалите субекти в обхвата все пак се нуждаят от общата програма за тестване по член 24.
Как TIBER-EU се отнася към DORA TLPT?
Техническите стандарти за TLPT са изготвени в съответствие с TIBER-EU и отразяват неговата методология, процес и структура. ЕЦБ посочва, че TIBER-EU е обновен, за да се съгласува напълно с тези стандарти. Субектите могат да прилагат TIBER-EU или национално негово прилагане, доколкото то е съвместимо с DORA и стандартите.
Може ли PXLSec да извърши нашия TLPT?
PXLSec предоставя red team тестване, съобразено с TIBER-EU, и подкрепя подготовката за TLPT. Не претендираме за акредитация по която и да е национална схема за TIBER или TLPT. Вашият контролен екип трябва да оцени всеки тестер спрямо член 27 от DORA и член 7 от стандартите за TLPT, а органът по TLPT може да възрази, преди доставчик да бъде нает.
Можем ли да използваме вътрешни тестери?
За общото тестване член 24 допуска вътрешни или външни тестери, при условие че са независими и конфликтите на интереси се избягват. За TLPT вътрешните тестери се нуждаят от одобрение от органа и от външен доставчик на разузнавателна информация, а външни тестери трябва да се използват на всеки три теста. Значимите кредитни институции могат да използват само външни тестери за TLPT.
PXLSec одитор или регулатор ли е?
Не. PXLSec е фирма за тестване на сигурността. Не одитираме, не сертифицираме и не атестираме съответствие с DORA, а съгласно DORA атестацията за TLPT се издава от органа. Нашите доклади са доказателства, които можете да използвате в собствената си работа по съответствие и в диалога с надзорния си орган.
Това правен съвет ли е?
Не. Тази страница е обща насока за разпоредбите за тестване в DORA и техническите стандарти към него, основана на официалните текстове. Как DORA се прилага за вас зависи от вида, размера на субекта и надзорния орган, затова потвърдете задълженията си с вашите правни съветници и съветници по съответствие и с компетентния орган.
Услуги, които осигуряват това
Нека обсъдим обхвата на теста.
Кажете ни какво искате да защитите. Опитен специалист ще ви помогне да определите обхвата и следващите стъпки. Обикновено отговаряме в рамките на един работен ден.
Поверителност от първия разговор
Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.
Как защитаваме информацията ви · Политика за поверителност