Доказателства за DORA TLPT с контроли по ISO 27001

Понеделник сутрин е, 07:40 ч., и CISO на средноголяма платежна институция гледа три версии на един и същ неудобен въпрос.

Управителният орган иска да знае дали организацията може да издържи прекъсване на клиентския платежен портал, причинено от ransomware. Регулаторът иска доказателство, че тестването на цифровата оперативна устойчивост не е упражнение в PowerPoint. Вътрешният одит иска ясна следа от задълженията по DORA до ИКТ риска, контролите по ISO 27001, резултатите от тестове, плановете за отстраняване, доказателствата от доставчици и формалното потвърждение от ръководството.

CISO разполага с доклад от Red Team. SOC има екранни снимки на предупреждения. Инфраструктурният екип има журнал за възстановяване от резервно копие. Правният отдел има регистър за готовност по DORA. Отделът по снабдяване има удостоверения от доставчици на облачни услуги.

Нищо от това не е свързано.

Тук се провалят много програми за DORA TLPT и тестване на устойчивостта. Не защото самото тестване е слабо, а защото доказателствата са фрагментирани. Когато одитор попита: „Покажете ми как този тест доказва устойчивостта на критична или важна функция“, отговорът не може да бъде папка, пълна с екранни снимки. Той трябва да бъде защитима верига от доказателства.

Именно в тази верига СУИС, съгласувана с ISO/IEC 27001:2022 ISO/IEC 27001:2022, се превръща в силен инструмент. ISO 27001 дава структура за обхвата, оценката на риска, избора на контроли, Декларацията за приложимост, оперативния контрол, вътрешния одит, прегледа от ръководството и непрекъснатото подобрение. DORA добавя специфичния за сектора регулаторен натиск. Методологията на Clarysec и инструментите за съпоставяне на съответствието свързват двете в единен одитно готов модел на доказателства.

DORA TLPT е тест за управление, а не само симулация на атака

Тестовете за проникване, ръководени от заплахи, или TLPT, лесно могат да бъдат разбрани неправилно. Технически те могат да изглеждат като разширено Red Team упражнение: разузнаване за заплахи, реалистични пътища за атака, скритост, опити за експлоатация, сценарии за странично придвижване и валидиране на реакцията на Blue Team.

За DORA по-дълбокият въпрос е цифровата оперативна устойчивост. Може ли финансовият субект да устои, да реагира и да се възстанови при сериозно ИКТ прекъсване, което засяга бизнес процеси? Може ли да докаже, че критичните или важни функции остават в рамките на допустимите нива на въздействие? Може ли ръководството да докаже, че ИКТ рискът се управлява, финансира, тества, отстранява и подобрява?

DORA Article 1 установява единна рамка на ЕС за сигурността на мрежовите и информационните системи, които поддържат бизнес процесите на финансовите субекти. Тя обхваща управление на ИКТ риска, докладване на съществени ИКТ-свързани инциденти, тестване на цифровата оперативна устойчивост, управление на риска от ИКТ трети страни, задължителни договорни изисквания към доставчици на ИКТ услуги, надзор върху критични доставчици на ИКТ услуги от трети страни и сътрудничество между надзорни органи. DORA се прилага от 17 януари 2025 г.

За организации, които попадат и в обхвата на NIS2, DORA действа като специфичен за сектора правен акт на Съюза за припокриващи се изисквания за киберсигурност. На практика финансовите субекти следва да приоритизират DORA за управление на ИКТ риска, докладване на инциденти, тестване и риск от ИКТ трети страни, когато режимите се припокриват, като същевременно разбират очакванията по NIS2 за групови структури, доставчици и нефинансови цифрови услуги.

DORA поставя и отчетност на най-високо ниво. Article 5 изисква управителният орган да определя, одобрява, наблюдава и прилага механизмите за управление на ИКТ риска. Това включва стратегията за цифрова оперативна устойчивост, политиката за непрекъсваемост на дейността в областта на ИКТ, плановете за реагиране и възстановяване, плановете за одит, бюджетите, политиките за ИКТ трети страни, каналите за докладване и достатъчни знания за ИКТ риска чрез редовно обучение.

Следователно одиторският въпрос не е просто: „Проведохте ли TLPT?“

Той е:

• Беше ли TLPT свързан с критични или важни функции?
• Беше ли разрешен, обхванат, безопасен и оценен от гледна точка на риска?
• Бяха ли включени доставчици, облачни зависимости и външно възложени ИКТ услуги, когато е приложимо?
• Генерира ли тестът доказателства за откриване, реагиране, възстановяване и извлечени поуки?
• Бяха ли констатациите преобразувани в третиране на риска, проследено отстраняване, повторно тестване и докладване към ръководството?
• Обясняваше ли Декларацията за приложимост кои контроли от Приложение A на ISO 27001 са избрани за управление на риска?

Затова Clarysec разглежда доказателствата за DORA TLPT като въпрос на доказателства в СУИС, а не само като резултат от тестове за проникване.

Изградете доказателствения гръбнак по ISO 27001 преди началото на теста

ISO 27001 изисква организацията да създаде, внедри, поддържа и непрекъснато подобрява СУИС, която запазва поверителността, целостта и наличността чрез процес за управление на риска. Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешните и външните обстоятелства, заинтересованите страни, правните и регулаторните задължения, интерфейсите и зависимостите, и след това да документира обхвата на СУИС.

За субект, регулиран от DORA, тази стъпка по определяне на обхвата следва изрично да включва критични или важни функции, ИКТ активи, облачни платформи, външно възложени операции, платежни системи, клиентски портали, услуги за идентичност, платформи за регистриране, среди за възстановяване и доставчици на ИКТ услуги от трети страни. Ако обхватът на TLPT не се съпоставя обратно с обхвата на СУИС, одитната следа вече е слаба.

Клаузи 6.1.1, 6.1.2 и 6.1.3 на ISO 27001, заедно с клаузи 8.2 и 8.3, изискват процес за оценка на риска и третиране на риска. Рисковете трябва да бъдат идентифицирани спрямо поверителност, цялостност и наличност. Трябва да бъдат определени собственици на риска. Вероятността и последиците трябва да бъдат оценени. Контролите трябва да бъдат избрани и сравнени с Приложение A. Остатъчният риск трябва да бъде приет от собствениците на риска.

Това е мостът между DORA и одитно готовото тестване.

Zenith Blueprint: 30-стъпкова пътна карта за одитори на Clarysec Zenith Blueprint, във фазата „Управление на риска“, Step 13, описва ясно тази роля на проследимостта:

SoA на практика е свързващ документ: той свързва вашата оценка/третиране на риска с действителните контроли, с които разполагате. Като го попълните, допълнително проверявате дали не сте пропуснали контроли.

За DORA TLPT Декларацията за приложимост не трябва да бъде статичен сертификационен артефакт. Тя трябва да обяснява защо контроли като сигурност на доставчиците, управление на инциденти, ИКТ готовност за непрекъсваемост на дейността, регистриране, мониторинг, техническо управление на уязвимости, резервни копия, сигурна разработка и тестване на сигурността са приложими към сценария за устойчивост.

Практически сценарий на риска може да гласи:

„Компрометиране на привилегировани идентификационни данни за доставчик на идентичност позволява на атакуващ да получи достъп до административни системи за обработка на плащания, да промени конфигурации за маршрутизация и да прекъсне критична платежна функция, което води до недостъпност на услугата, регулаторни задължения за докладване, вреда за клиентите и репутационни щети.“

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

Zenith Blueprint също препоръчва регулаторната проследимост да бъде направена изрична:

Кръстосано препращане към регулации: Ако определени контроли са внедрени специално за съответствие с GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.

Този съвет е прост, но променя одиторския разговор. Вместо организацията да казва на одитора, че DORA е взета предвид, тя може да покаже къде DORA присъства в регистъра на риска, SoA, програмата за тестване, набора от политики и прегледа от ръководството.

Съпоставете тестването по DORA с контроли по ISO 27001, които одиторите разпознават

DORA Article 6 очаква документирана рамка за управление на ИКТ риска, интегрирана в цялостното управление на риска. Приложение A на ISO 27001 предоставя каталога с контроли, който прави това оперативно приложимо.

За DORA TLPT и тестването на устойчивостта тези контроли от Приложение A на ISO/IEC 27001:2022 са особено важни:

Zenith Controls: Ръководство за съпоставяне на съответствието на Clarysec Zenith Controls помага на организациите да не третират тези контроли като изолирани елементи от контролен списък. То съпоставя контролите по ISO/IEC 27002:2022 с атрибути, домейни, оперативни способности, одиторски очаквания и модели за съпоставяне между рамки.

Например Zenith Controls класифицира контрол 5.30 на ISO/IEC 27002:2022, ИКТ готовност за непрекъсваемост на дейността, като „Коригиращ“, съгласуван с „Наличност“, свързан с концепцията за киберсигурност „Реагиране“ и поставен в домейна „Устойчивост“. Тази класификация е полезна при обяснение пред одитори защо учението за възстановяване не е просто ИТ операция, а контрол за устойчивост с определена роля в контролната среда.

Zenith Controls също класифицира контрол 8.29, Тестване на сигурността при разработка и приемане, като превантивен контрол, който поддържа поверителност, цялостност и наличност, с оперативни способности в сигурността на приложенията, уверението за информационната сигурност и сигурността на системите и мрежите. За констатации от TLPT, които се проследяват до слабост в дизайна на приложение, несигурно поведение на API, слаб поток за автентикация или недостатъчна валидация, това е пътят на контрола към управление на сигурната разработка.

Контрол 5.35, Независим преглед на информационната сигурност, също е важен. Той поддържа независимо предизвикателство, уверение за управлението и коригиращо подобрение. Вътрешните екипи могат да координират тестването, но одитно готовите доказателства изискват преглед, ескалация и надзор отвъд хората, които са изградили или експлоатирали тестваните системи.

Защитете системата, докато я тествате

Опасно допускане при тестването на устойчивостта е, че тестването автоматично е полезно. В действителност инвазивното тестване може да причини недостъпност, да изложи чувствителни данни, да замърси журнали, да задейства автоматизирани защити, да прекъсне клиентски сесии или да накара доставчици да активират аварийни процедури.

Политиката за тестване на сигурността и Red Team упражнения на Clarysec Политика за тестване на сигурността и Red Team упражнения дава на организациите управленски модел за безопасно изпълнение. Клауза 6.1 посочва:

Видове тестове: Програмата за тестване на сигурността трябва да включва най-малко: (a) сканирания за уязвимости, състоящи се от автоматизирани седмични или месечни сканирания на мрежи и приложения за идентифициране на известни уязвимости; (b) тестове за проникване, състоящи се от ръчно задълбочено тестване на конкретни системи или приложения от квалифицирани тестери за идентифициране на сложни слабости; и (c) Red Team упражнения, състоящи се от сценарийно базирани симулации на реални атаки, включително социално инженерство и други тактики, за тестване на способностите на организацията за откриване и реагиране като цяло.

За TLPT елементът Red Team е очевиден, но одиторската стойност идва от дизайна на програмата. Сканиранията за уязвимости, тестовете за проникване, Red Team упражненията, тренировките за устойчивост и повторното тестване трябва да образуват цикъл, а не колекция от несвързани тестове.

Клауза 6.2 на същата политика разглежда безопасното изпълнение:

Обхват и правила за изпълнение: За всеки тест или упражнение координаторът по тестване на сигурността (STC) трябва да определи обхвата, включително системите и IP диапазоните в обхвата, разрешените методи за тестване, целите, времето и продължителността. Правилата за изпълнение трябва да бъдат документирани. Например оперативно чувствителни системи могат да бъдат определени само за наблюдение, за да се избегне прекъсване, а всяко тестване в продукционна среда трябва да включва процедури за връщане към предишно състояние и спиране. Трябва да бъдат установени мерки за безопасност, като определени времеви прозорци и комуникационни канали, за предотвратяване на непреднамерена недостъпност на услуги.

Това се съпоставя директно със Zenith Blueprint, фазата „Контроли в действие“, Step 21, която се фокусира върху контрол 8.34 от Приложение A на ISO 27001, Защита на информационните системи по време на одитно тестване. Zenith Blueprint предупреждава, че одитите, тестовете за проникване, форензичните прегледи и оперативните оценки могат да включват повишен достъп, инвазивни инструменти или временни промени в поведението на системите. Той подчертава разрешаването, обхвата, времевите прозорци, одобрението от собственика на системата, връщането към предишно състояние, мониторинга и сигурното боравене с тестови данни.

Одитно готовият пакет от доказателства трябва да включва:

• Харта и цели на TLPT
• Обобщение на разузнаването за заплахи и обосновка на сценария
• Критични или важни функции в обхвата
• Системи, IP диапазони, идентичности, доставчици и среди в обхвата
• Изключения и системи само за наблюдение
• Правила за изпълнение
• Оценка на риска при тестване в продукционна среда
• Процедури за връщане към предишно състояние и спиране
• Модел за уведомяване на SOC, включително какво се разкрива и какво се запазва в тайна
• Одобрения от правен отдел, звено по защита на личните данни и доставчици
• Доказателства за създаване и отнемане на тестови акаунти
• Сигурно място за съхранение на тестови артефакти и журнали

DORA TLPT, който не може да покаже безопасно разрешаване и контрол върху тестовата дейност, може да разкрие пропуски в устойчивостта, но създава и пропуски в управлението.

Превърнете резултатите от TLPT в третиране на риска

Най-често срещаният провал след теста е проблемът с доклада от Red Team, оставен на рафта. Качествен доклад се предава, разпространява, обсъжда и след това постепенно губи инерция. Констатациите остават отворени. Компенсиращи контроли не се документират. Приетите рискове са неформални. Повторно тестване не се извършва.

Политиката за тестване на сигурността и Red Team упражнения прави това недопустимо. Клауза 6.6 посочва:

Отстраняване на констатации: Всички идентифицирани уязвимости или слабости трябва да бъдат документирани в доклад с констатации с оценки на тежестта. След получаване на доклада собствениците на системи отговарят за създаване на план за отстраняване с крайни срокове; например критичните констатации трябва да бъдат отстранени в срок до 30 дни, а констатациите с висока тежест — в срок до 60 дни, в съответствие с Политиката за управление на уязвимости и корекции на организацията. STC трябва да проследява напредъка по отстраняването. Трябва да се извършва повторно тестване, за да се потвърди, че критичните проблеми са отстранени или адекватно смекчени.

Клауза 6.7 добавя управленския слой:

Докладване: В края на всеки тест трябва да бъде издаден формален доклад. За тестове за проникване докладът трябва да включва резюме за ръководството, методология и подробни констатации с подкрепящи доказателства и препоръки. За Red Team упражнения докладът трябва да описва подробно сценариите, кои пътища за атака са били успешни, какво е било открито от Blue Team и извлечените поуки относно пропуските в откриването и реагирането. CISO трябва да представя обобщени резултати и статус на отстраняването на висшето ръководство и, когато е приложимо, да ги включва в годишния доклад за сигурността до Съвета на директорите.

Това съответства на указанията на ISO/IEC 27005:2022 за третиране на риска: избор на варианти за третиране, определяне на контроли от Приложение A на ISO 27001 и специфични за сектора изисквания, изграждане на план за третиране на риска, възлагане на отговорни лица, определяне на срокове, проследяване на статуса, получаване на одобрение от собственика на риска и документиране на приемането на остатъчния риск.

Всяка значима констатация от TLPT трябва да се превърне в едно от четири неща: действие за отстраняване, подобрение на контрол, формално приемане на риска или изискване за повторно тестване.

Целта не е да се произвеждат повече документи. Целта е всеки документ да обяснява следващото решение.

Тестването на устойчивостта трябва да доказва възстановяване, а не само откриване

Успешен TLPT може да покаже, че SOC е открил command-and-control трафик, блокирал е странично придвижване и е ескалирал правилно. Това е ценно, но тестването на устойчивостта по DORA отива по-далеч. То пита дали организацията може да продължи или да възстанови бизнес услугите.

Zenith Blueprint, фазата „Контроли в действие“, Step 23, обяснява контрол 5.30, ИКТ готовност за непрекъсваемост на дейността, с език, който всеки CISO трябва да използва пред управителния орган:

От гледна точка на одита този контрол често се тества с една фраза: Покажете ми. Покажете ми последния резултат от тест. Покажете ми документацията за възстановяване. Покажете ми колко време отне превключването към резервен ресурс и обратно. Покажете ми доказателствата, че обещаното може да бъде изпълнено.

Този стандарт „Покажете ми“ е разликата между зрялост на политиките и оперативна устойчивост.

Политика за непрекъсваемост на дейността и аварийно възстановяване за SME на Clarysec Политика за непрекъсваемост на дейността и аварийно възстановяване - SME, от раздел „Изисквания за прилагане на политиката“, клауза 6.4.1, посочва:

Организацията трябва да тества както своите BCP, така и DR способности поне веднъж годишно. Тестовете трябва да включват:

Разделът за прилагане на същата политика, клауза 8.5.1, прави отчетността за доказателствата изрична:

Генералният мениджър (GM) трябва да гарантира, че следното се поддържа и е готово за одит:

За финансов субект, регулиран от DORA, годишното тестване може да бъде минимумът, а не амбицията. Критични или важни функции с по-висок риск следва да се тестват по-често, особено след архитектурни промени, миграция към облак, съществени инциденти, нови ИКТ доставчици, значими версии на приложения или промени в експозицията към заплахи.

Силен пакет от доказателства за тест на устойчивостта следва да включва:

• Анализ на въздействието върху бизнеса, който картографира критичната или важната функция
• RTO и RPO, одобрени от собственици на бизнеса
• Карта на системните зависимости, включително идентичност, DNS, мрежа, облак, база данни, мониторинг, резервни копия и услуги от трети страни
• Резултати от тестове за резервни копия и възстановяване
• Времеви маркери за превключване при отказ и връщане обратно
• Доказателства за функциониране на контролите за сигурност по време на прекъсване
• Шаблони за комуникация с клиенти, регулатор и вътрешни заинтересовани страни
• Журнали за участие на ръководителя на инцидента и кризисния екип
• Извлечени поуки и действия за подобрение
• Доказателства от повторен тест за предишни пропуски при възстановяване

Тук в картината влиза и GDPR. GDPR Articles 2 and 3 въвеждат в обхват повечето SaaS и fintech дейности по обработване на лични данни в ЕС. Article 4 дефинира лични данни, обработване, администратор, обработващ лични данни и нарушение на сигурността на личните данни. Article 5 изисква цялостност, поверителност и отчетност, което означава, че организацията трябва да може да докаже съответствие. Ако TLPT или тестване на възстановяване използва продукционни лични данни, копира журнали, съдържащи идентификатори, или валидира реагиране при нарушение, предпазните мерки за поверителност трябва да бъдат документирани.

Доказателствата от доставчици са сляпото петно в DORA, което одиторите няма да пренебрегнат

Съвременните финансови услуги се изграждат от облачни платформи, SaaS приложения, доставчици на управлявани услуги по сигурността, платежни процесори, платформи за данни, доставчици на идентичност, инструменти за наблюдаемост, екипи за външна разработка и доставчици на резервни копия.

DORA Article 28 изисква финансовите субекти да управляват риска от ИКТ трети страни като част от рамката за управление на ИКТ риска и да остават изцяло отговорни дори когато ИКТ услугите са възложени външно. Article 30 изисква писмени договори за ИКТ услуги с описания на услугите, условия за подизпълнение, места на обработване, защита на данните, достъп и възстановяване, нива на обслужване, съдействие при инциденти, сътрудничество с органи, права за прекратяване, по-строги условия за критични или важни функции, права на одит, мерки за сигурност, участие в TLPT, когато е приложимо, и договорености за изход.

Това означава, че сценарият за TLPT не може да спре при защитната стена на организацията, ако критичната функция зависи от доставчик.

Политика за сигурност на трети страни и доставчици за SME на Clarysec Политика за сигурност на трети страни и доставчици - SME, от раздел „Изисквания за прилагане на политиката“, клауза 6.3.1, посочва:

Критичните или високорисковите доставчици трябва да бъдат преглеждани поне веднъж годишно. Прегледът трябва да проверява:

Политиката за тестване на сигурността и Red Team упражнения добавя специфично за тестването изискване към доставчиците в клауза 6.9:

Координация на тестването с трети страни: Когато критичен доставчик или доставчик на услуги попада в обхвата на общата сигурност на организацията, в съответствие с Политиката за сигурност на трети страни и доставчици, организацията трябва, когато е възможно, да получи уверение относно практиките му за тестване на сигурността или да координира съвместно тестване. Например, когато се използва доставчик на облачни услуги (CSP), организацията може да разчита на неговите доклади от тестове за проникване или да го включи в съвместни Red Team сценарии при спазване на договорните клаузи.

За одитно готови доказателства по DORA уверението от доставчици трябва да бъде свързано със същия сценарий на риска като TLPT. Ако доставчикът на идентичност е съществен за възстановяването на плащанията, пакетът от доказателства трябва да включва надлежна проверка на доставчика, договорни изисквания за сигурност, условия за съдействие при инциденти, координация на тестването, доклади за уверение, доказателства за ниво на обслужване, стратегия за изход и ограничения върху тестването.

NIS2 Article 21 също е важен за SaaS, облачни услуги, управлявани услуги, управлявана сигурност, центрове за данни, CDN, удостоверителни услуги, DNS, TLD, онлайн пазари, търсене и доставчици на социални мрежи. Той изисква подход към всички опасности, който обхваща анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурна разработка, оценка на ефективността, обучение, криптография, контрол на достъпа, управление на активите, MFA и сигурни комуникации.

Практическият резултат е прост: финансовите субекти следва да изградят един модел на доказателства, който първо удовлетворява DORA, а след това прави кръстосани препратки към очакванията по NIS2, когато са включени доставчици, групови субекти или нефинансови цифрови услуги.

Практически регистър на доказателствата за Clarysec TLPT

Да приемем следния сценарий:

„Заплаха компрометира администраторски акаунт в SaaS платформа за поддръжка, преминава към средата за платежни операции, променя конфигурацията и прекъсва обработката на транзакции.“

Създайте регистър на доказателствата с по един ред за всеки доказателствен обект. Не чакайте тестът да приключи. Попълвайте го по време на планирането, изпълнението, отстраняването и приключването.

След това използвайте Zenith Blueprint Step 13, за да добавите проследимост в регистъра на риска и Декларацията за приложимост. Всеки доказателствен елемент трябва да се свързва със сценарий на риска, собственик на риска, избран контрол, план за третиране и решение за остатъчния риск.

Ако констатация е свързана със софтуерна слабост, цитирайте контролите за сигурна разработка и тестване. Политика за сигурна разработка за SME на Clarysec Политика за сигурна разработка - SME, от раздел „Изисквания за прилагане на политиката“, клауза 6.5.2, изисква:

Тестването трябва да бъде документирано с:

Ако констатация създава форензичен материал, запазете веригата на съхранение. Политика за събиране на доказателства и форензика за SME на Clarysec Политика за събиране на доказателства и форензика - SME, от раздел „Изисквания за управление“, клауза 5.2.1, посочва:

Всеки елемент от цифрови доказателства трябва да бъде регистриран с:

Това е точката, която много екипи пропускат. Доказателствата не са само финалните доклади. Те са контролираният запис за това кой е одобрил, кой е изпълнил, какво се е случило, какво е било открито, какво е било възстановено, какво е било променено, какво остава експонирано и кой е приел тази експозиция.

Как одиторите проверяват едни и същи доказателства за TLPT

Доказателствата за DORA TLPT ще бъдат четени по различен начин според профила на одитора. Clarysec проектира пакетите от доказателства така, че всяка перспектива да намери необходимото, без да принуждава екипите да дублират работа.

COBIT 2019 присъства в препратките за съпоставяне на съответствието в Zenith Blueprint за безопасно изпълнение на одит и тестване, включително DSS05.03 и MEA03.04. Значението не е, че COBIT заменя DORA или ISO 27001, а че специалистите по уверение в стил ISACA ще търсят контролирано изпълнение, мониторинг, оценяване и доказателства за съответствие.

Разказът към управителния орган: какво трябва да одобри ръководството

Докладването към управителния орган трябва да избягва техническия театър. Управителният орган не се нуждае от детайли за експлойти. Той се нуждае от доказателства, годни за вземане на решения:

• Коя критична или важна функция беше тествана?
• Какъв сценарий на заплахата беше симулиран и защо?
• Сработи ли откриването?
• Сработи ли ескалацията при реагиране?
• Отговори ли възстановяването на RTO и RPO?
• Кои доставчици бяха включени или ограничени?
• Какви съществени слабости остават?
• Какви са разходът за отстраняване, собственикът и срокът?
• Кои остатъчни рискове изискват формално приемане?
• Какво ще бъде повторно тествано?

Тук клауза 5 на ISO 27001 става важна. Висшето ръководство трябва да гарантира, че политиката и целите за информационна сигурност са установени, съгласувани със стратегическата посока, интегрирани в бизнес процесите, обезпечени с ресурси, комуникирани и непрекъснато подобрявани. Ролите и отговорностите трябва да бъдат възложени. Целите трябва да бъдат измерими, когато е практически възможно, и да отчитат приложимите изисквания и резултатите от третирането на риска.

Ако TLPT установи, че времето за възстановяване е шест часа при четиричасов бизнес толеранс, това не е просто елемент в списъка с инфраструктурни задачи. Това е управленско решение, включващо апетит за риск, бюджет, ангажименти към клиенти, регулаторна експозиция, договори, архитектура и оперативен капацитет.

Често срещани пропуски в доказателствата при тестване на устойчивостта по DORA

При прегледите на Clarysec често се откриват едни и същи пропуски в доказателствата при финансови субекти и доставчици на ИКТ услуги, които се подготвят за DORA.

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

Второ, зависимостите от доставчици се признават, но не се доказват. Екипите казват, че доставчикът на облачни услуги, управляваният SOC или SaaS платформата са в обхвата, но липсват договори, права на одит, разрешения за тестване, условия за съдействие при инциденти и планове за изход.

Трето, тестването създава доказателства, но не и третиране. Констатациите остават в доклад от Red Team, вместо да бъдат преобразувани в актуализации на регистъра на риска, промени в контролите, собственици, срокове, повторно тестване и решения за остатъчния риск.

Четвърто, възстановяването се приема за даденост, вместо да се демонстрира. Съществуват политики за резервни копия, но никой не може да покаже времеви маркери за превключване при отказ, проверки на целостта при възстановяване, валидиране на достъпа или потвърждение от собственик на бизнеса.

Пето, поверителността и форензичните доказателства не се контролират. Журнали и екранни снимки съдържат лични данни, тестови артефакти се съхраняват в споделени файлови ресурси, временни акаунти остават активни, а веригата на съхранение на доказателствата е непълна.

Шесто, докладването към ръководството е прекалено техническо. Висшите ръководители не могат да видят дали устойчивостта се е подобрила, дали рискът е в рамките на апетита за риск или какви инвестиционни решения са необходими.

Всеки от тези пропуски може да бъде решен, като DORA TLPT се третира като структуриран работен поток за доказателства по ISO 27001.

Интегрираният подход на Clarysec към одитно готова устойчивост

Подходът на Clarysec комбинира три слоя.

Първият слой е 30-стъпковата пътна карта за внедряване Zenith Blueprint. За тази тема Step 13 изгражда третиране на риска и проследимост на SoA, Step 21 защитава системите по време на одитно тестване, а Step 23 валидира ИКТ готовността за непрекъсваемост на дейността. Тези стъпки превръщат TLPT от техническо събитие в документиран управленски цикъл.

Вторият слой е библиотеката с политики на Clarysec. Политиката за тестване на сигурността и Red Team упражнения определя видовете тестове, обхвата, правилата за изпълнение, отстраняването, докладването и координацията с доставчици. Политика за непрекъсваемост на дейността и аварийно възстановяване за SME задава очакванията за годишно тестване на BCP и DR и одитно готови доказателства за непрекъсваемост. Политика за сигурност на трети страни и доставчици за SME поддържа уверение от доставчици. Политика за сигурна разработка за SME гарантира, че тестването на сигурността е документирано. Политика за събиране на доказателства и форензика за SME поддържа регистриране на доказателства и дисциплина по веригата на съхранение.

Третият слой е Zenith Controls, ръководството на Clarysec за съпоставяне на съответствието. То помага за съпоставяне на контролите по ISO/IEC 27002:2022 с атрибути, домейни, оперативни способности и очаквания между рамки. За DORA TLPT най-важният модел не е един контрол. Това е връзката между тестване, непрекъсваемост, управление на инциденти, управление на доставчици, регистриране, мониторинг, сигурна разработка, независим преглед и управление.

Когато тези слоеве работят заедно, понеделнишкият сутрешен проблем на CISO се променя. Вместо три несвързани въпроса от управителния орган, регулатора и вътрешния одит, организацията има една доказателствена история:

„Идентифицирахме критичната функция. Оценихме ИКТ риска. Избрахме и обосновахме контролите. Разрешихме и безопасно изпълнихме TLPT. Открихме, реагирахме и се възстановихме. Включихме доставчици, когато беше необходимо. Документирахме доказателствата. Отстранихме констатациите. Повторно тествахме. Ръководството прегледа и прие оставащия риск.“

Това е одитно готова устойчивост.

Следващи стъпки

Ако вашата програма за DORA TLPT все още е организирана около доклади, а не около вериги от доказателства, започнете с доказателствен преглед стъпка по стъпка с Clarysec.

Използвайте Zenith Blueprint Zenith Blueprint Step 13, за да свържете сценариите за TLPT с рискове, контроли и Декларацията за приложимост. Използвайте Step 21, за да проверите безопасното разрешаване, правилата за изпълнение, връщането към предишно състояние, мониторинга и почистването. Използвайте Step 23, за да докажете ИКТ готовността за непрекъсваемост на дейността с доказателства за възстановяване.

След това съгласувайте оперативните си документи с Политиката за тестване на сигурността и Red Team упражнения на Clarysec Политика за тестване на сигурността и Red Team упражнения, Политика за непрекъсваемост на дейността и аварийно възстановяване за SME Политика за непрекъсваемост на дейността и аварийно възстановяване - SME, Политика за сигурност на трети страни и доставчици за SME Политика за сигурност на трети страни и доставчици - SME, Политика за сигурна разработка за SME Политика за сигурна разработка - SME и Политика за събиране на доказателства и форензика за SME Политика за събиране на доказателства и форензика - SME.

Накрая използвайте Zenith Controls Zenith Controls, за да съпоставите кръстосано доказателствата си за DORA TLPT с контролите по ISO 27001, NIS2, GDPR, COBIT 2019 и очакванията на одиторите.

Ако искате следващият ви тест на устойчивостта да произведе повече от констатации, използвайте Clarysec, за да го превърнете в защитима верига от доказателства. Изтеглете инструментариумите, насрочете оценка на одитната готовност на доказателствата или поискайте преглед стъпка по стъпка на начина, по който Clarysec съпоставя DORA TLPT с контролите по ISO 27001:2022 — от планирането до одобрението от управителния орган.