Моделиране на заплахи за ISO 27001, NIS2 и DORA

Аня, CISO на бързо развиваща се fintech компания, беше помолена да одобри план за пускане на нова B2B платформа за риск при плащания. Управителният съвет искаше излизане на пазара преди края на тримесечието. Продажбите вече бяха подготвили банкови клиенти. Инженерният екип беше скицирал cloud-native архитектура с атрибути на идентичност, сигнали от устройства, метаданни за транзакции, поведенчески оценки на риска, управлявана база данни и външен доставчик на аналитични услуги.

На хартия платформата изглеждаше като търговски пробив. За Аня тя изглеждаше като пет разговора за съответствие, които пристигаха едновременно.

Като доставчик на финансови технологии компанията беше под натиск от DORA. Като доставчик на облачна услуга и цифрова платформа тя трябваше да разбере експозицията си по NIS2. Тъй като платформата обработваше лични данни, свързани с лица от ЕС, се прилагаше GDPR. Корпоративните клиенти очакваха сертификация по ISO/IEC 27001:2022. Ако услугата станеше част от свързан софтуерен продукт, очакванията по Cyber Resilience Act щяха да добавят изискване за продуктови доказателства за сигурност по дизайн.

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

Затова тя забави срещата с четири въпроса:

1. Къде са границите на доверие?
2. Кои сценарии за злоупотреба могат да доведат до измама, експозиция на данни или прекъсване на услугата?
3. Кои проектни решения намаляват риска преди писането на код?
4. Какви доказателства ще удовлетворят проверяващите по ISO 27001, NIS2, DORA, CRA и GDPR след шест месеца?

Именно при четвъртия въпрос много организации се провалят. Моделирането на заплахи често се третира като полезен инженерен workshop, след което се погребва в wiki страница. През 2026 г. това вече не е достатъчно. За SaaS доставчици, fintech дружества, облачни платформи, MSP, MSSP, оператори на цифрова инфраструктура и производители на софтуер моделирането на заплахи се превърна в механизъм за създаване на доказателства за съответствие.

Зрелият процес за моделиране на заплахи превръща констатациите по STRIDE, сценариите за злоупотреба и архитектурните решения в записи в Регистъра на риска, изисквания за сигурност, планове за третиране на риска, тестови сценарии, задачи за уверение от доставчици, доказателства за поверителност по дизайн и проследимост към Декларацията за приложимост.

Защо доказателствата за сигурност по дизайн вече са важни

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

ISO/IEC 27001:2022 изисква риск-базирана Система за управление на информационната сигурност. Клаузи 6.1.2 и 6.1.3 изискват оценка и третиране на риска за информационната сигурност. Клауза 8.1 изисква оперативно планиране и контрол. Приложение A предоставя контроли, които трябва да бъдат избрани чрез Декларацията за приложимост въз основа на риска, правните изисквания и бизнес необходимостта.

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

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

GDPR добавя отчетност и защита на данните по дизайн и по подразбиране. Всяка система, която обработва лични данни, трябва да може да докаже законосъобразно, добросъвестно, прозрачно, ограничено до целта, минимизирано, ограничено по срок на съхранение и сигурно обработване. Модел на заплахите, който картографира потоците от лични данни, пътищата за достъп, журналите, съхранението, изтриването и предаванията към трети страни, е пряко релевантен към GDPR Articles 5, 25, 32 и 35.

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

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

Моделът на Clarysec: един модел на заплахите, много резултати

Подходът на Clarysec започва с практичен принцип: моделът на заплахите не е завършен, докато не произведе решения, които могат да бъдат одитирани.

В Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], във фазата „Управление на риска“, стъпка 9, на екипите се дава прост формат за превръщане на технически наблюдения в езика на риска:

„Сега комбинирайте актив + заплаха + уязвимост в кратко описание на рисков сценарий. По същество опишете потенциалния инцидент. По-късно това ще бъде отделен ред във вашия Регистър на риска. Използвайте прост формат: „[Заплаха] експлоатира [уязвимост] върху [актив], което води до [въздействие].““

Това изречение е мостът между инженерния екип и съответствието.

Бележка на бяла дъска като „риск от подправяне на самоличност в partner API“ се превръща в:

„Атакуващ експлоатира слаба автентикация на partner API в transaction-risk API, което води до неоторизиран достъп до решения за риска при плащания и експозиция на лични данни.“

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

Слоят на политиките прави това повторяемо. P24 Secure Development Policy [P24] постановява:

„Всички нови приложения и съществени промени трябва да преминават през преглед на сигурната архитектура и моделиране на заплахи преди започване на разработката.“
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.1.1.

Тя също така изисква:

„Прегледите на дизайна трябва да документират диаграми на потоците от данни, граници на доверие и мерки за смекчаване за идентифицираните рискове.“
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.1.2.

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

P06 Risk Management Policy [P06] свързва моделирането на заплахи с корпоративното управление на риска:

„Всички бизнес единици трябва проактивно да идентифицират рискове чрез структурирани техники, произтичащи от ISO/IEC 27005:2024, включително моделиране на заплахи, картографиране на зависимостите между активите и идентифициране по сценарии.“
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.1.1.

Тя също така постановява:

„Идентифицираните рискове трябва да бъдат документирани с препратка към собственик на актив, участник-заплаха, уязвимост и потенциално въздействие върху поверителността, целостта и наличността (CIA).“
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.1.4.

Това е веригата от доказателства, която одиторите искат да видят: изискване на политиката, проектна дейност, рисков сценарий, избор на контроли, внедряване, тестване и одобрение.

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

STRIDE остава един от най-полезните методи за моделиране на заплахи на етап проектиране, защото принуждава екипите да разгледат шест често срещани режима на отказ:

• Подправяне на самоличност
• Манипулиране
• Отричане на действие
• Разкриване на информация
• Отказ на услуга
• Ескалация на привилегии

За платформата на Аня за риск при плащания екипът използва STRIDE за всеки компонент, поток от данни и граница на доверие.

Подправянето на самоличност постави въпроса дали клиент на partner API може да се представи за банков клиент, ако взаимната автентикация е слаба. Манипулирането разкри риска сигналите от устройства или сумите по транзакции да бъдат променени преди приемане. Отричането на действие подчерта необходимостта от администраторски и транзакционни журнали за одит. Разкриването на информация се фокусира върху изтичане през журнали, експорти към аналитични инструменти, инструменти за поддръжка и API за отчети. Отказът на услуга принуди екипа да разгледа пикови прозорци за транзакции и наводняване с неправилно формирани заявки. Ескалацията на привилегии разкри рискове в ролите за поддръжка, токените за сесии и административните функции.

Сценариите за злоупотреба превърнаха тези категории в реални истории:

• Измамник качва манипулирани сигнали от устройство, за да повлияе на оценка на риска.
• Компрометирани удостоверителни данни на партньор наводняват API с измамни заявки.
• Разработчик използва продукционни лични данни в тестова среда.
• Злонамерен вътрешен служител експортира клиентски идентификатори и логика за оценяване.
• Прекъсване при доставчик на облачни аналитични услуги блокира решения за риск по време на прозорец за плащания.
• Неправилна конфигурация на хранилище разкрива качени документи за самоличност.
• Работен поток за изтриване премахва записа в приложението, но оставя резервни копия и копия при доставчик.

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

Тази структура предотвратява неясни констатации като „риск за сигурността на API“. Тя създава рискови твърдения с доказателствена стойност като:

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

Картографиране на моделирането на заплахи към ISO/IEC 27001:2022 и ISO/IEC 27002:2022

ISO/IEC 27001:2022 не изисква изрично моделиране на заплахи. Той изисква последователна и документирана оценка на риска и третиране на риска. Моделирането на заплахи е един от най-силните методи за генериране на тези доказателства в софтуерни, облачни и продуктови среди.

Ключът е проследимостта. В ZB, във фазата „Управление на риска“, стъпка 13, се препоръчва картографиране на контролите към рискове и клаузи, включително препратки към Приложение A в плановете за третиране на риска и отбелязване къде контролите подпомагат GDPR, NIS2 или DORA.

Zenith Controls: The Cross-Compliance Guide [ZC] помага за структуриране на тази проследимост чрез картографиране на контролите от ISO/IEC 27002:2022 към свързани контроли, одитни очаквания и външни рамки.

За моделирането на заплахи контрол 5.8 от ISO/IEC 27002:2022, „Информационна сигурност при управление на проекти“, е управленската опора на проекта. Той показва, че сигурността е интегрирана в инициирането, планирането, изпълнението и приемането на проекта.

Контрол 8.25, Secure development life cycle, е опората за SDLC. ZC свързва 8.25 с поддържащи контроли като 8.26 „Изисквания за сигурност на приложенията“, 8.27 „Защитена системна архитектура и инженерни принципи“, 8.28 „Сигурно програмиране“, 8.29 „Тестване на сигурността при разработка и приемане“, 8.30 „Външно възложена разработка“ и 8.31 „Разделяне на среди за разработка, тестови среди и продукционни среди“.

Това картографиране помага дизайн workshop да се превърне в доказателства за Декларацията за приложимост. То също подпомага клаузи 4 до 6 на ISO/IEC 27001:2022, защото изискванията на заинтересованите страни, обхватът на ISMS, ангажиментите на ръководството и решенията за третиране на риска стават видими.

Карта за едновременно съответствие с NIS2, DORA, CRA, GDPR и NIST CSF

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

NIST CSF 2.0 е особено полезна за комуникация с изпълнителното ръководство. Нейната функция GOVERN подпомага правни, регулаторни, договорни и свързани с поверителността задължения, а резултатите ѝ за веригата на доставки помагат да се свържат критичността на доставчиците, договорните изисквания, надлежната проверка, мониторингът и планирането на инциденти със същите доказателства от модела на заплахите.

GDPR изисква специално внимание, защото моделирането на заплахи и работата по DPIA трябва взаимно да се подсилват. P17 Data Protection and Privacy Policy [P17] постановява:

„Моделирането на заплахи и оценките на въздействието върху защитата на данните (DPIA) са задължителни за високорискови системи за обработване.“
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.3.4.

За по-малки екипи P17S Data Protection and Privacy Policy - SME [P17S] постановява:

„Поверителността по дизайн и по подразбиране трябва да се прилага във всички нови системи и услуги“
От раздел „Изисквания за управление“, клауза на политиката 5.3.1.

Резултатът е практичен оперативен модел: използвайте едни и същи диаграми на потоците от данни, граници на доверие и сценарии за злоупотреба за риск за сигурността, риск за поверителността, преглед на доставчици и регулаторни доказателства.

90-минутен спринт за риск на ниво дизайн при високорискови функционалности

Моделирането на заплахи не трябва да започва като тежка програма. За нов платежен API, процес на въвеждане, функционалност с изкуствен интелект, услуга за идентичност, миграция към облак или външна интеграция 90-минутен спринт за риск на ниво дизайн може да създаде ценни доказателства.

1. Отворете контролна точка за сигурност на проекта

Използвайте клауза 6.1.1 на P24 като задействащо условие. За всяко ново приложение или съществена промяна създайте папка с доказателства, която съдържа:

• Архитектурна диаграма
• Диаграма на потоците от данни
• Карта на границите на доверие
• Списък на активите
• Бележки за лични данни
• Списък на доставчици и ИКТ зависимости
• Първоначални изисквания за сигурност
• Работен лист за модел на заплахите
• Записи в Регистъра на риска
• Проследимост на мерките за смекчаване и тестовете
• Запис за одобрение

За по-малки организации P24S Secure Development Policy - SME [P24S] поддържа същата дисциплина, като свързва процесите за сигурна разработка с контрол на достъпа на разработчици, тестване, моделиране на заплахи и документация. Тя също изисква централизирано съхранение на контролни списъци, одобрения от прегледи, доклади от тестване и инвентари на компоненти за целите на одита. Клауза 11.3.1 препраща към SA-3 до SA-15, за да дефинира процеси за сигурна разработка, включително моделиране на заплахи.

2. Начертайте минимално необходимия поток от данни

Не започвайте с полирана диаграма. Започнете с потоците, които създават риск:

• Потребител качва документи за самоличност или транзакционни данни.
• Уеб приложението изпраща заявки към API.
• API записва в управлявано хранилище или база данни.
• Доставчик получава данни за верификация или аналитика.
• Вътрешен портал за анализатори визуализира резултати.
• Клиентска система извлича статус или решения.
• Журнали, инструменти за мониторинг и резервни копия получават копия.

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

3. Изпълнете STRIDE и сценариите за злоупотреба заедно

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

4. Превърнете констатациите в рискови сценарии

Използвайте формулата от стъпка 9 на ZB:

„[Заплаха] експлоатира [уязвимост] върху [актив], което води до [въздействие].“

Например:

„Атакуващ експлоатира слаби контроли за достъп до object storage върху хранилището за документи за самоличност, което води до неоторизирано разкриване на лични данни и експозиция за регулаторно уведомяване.“

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

5. Изведете изисквания и тестове

Моделът на заплахите не е завършен, когато рисковете са изброени. Той е завършен, когато мерките за смекчаване са внедрени, тествани или формално приети.

Change Management Policy - SME дава практично задействащо условие:

„Ако промяна включва чувствителни данни, системни права за достъп или външни интеграции, се изисква преглед на въздействието върху сигурността. Определеното контактно лице по сигурност или съответствие трябва да оцени дали промяната въвежда допълнителни рискове и да препоръча допълнителни предпазни мерки.“
От раздел „Третиране на риска и изключения“, клауза на политиката 7.5.1.

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

Какво ще попитат различните одитори

Одитор по ISO/IEC 27001:2022 ще попита дали моделирането на заплахи е част от дефиниран процес за оценка на риска, дали критериите са последователни, дали собствениците на риска са одобрили остатъчните рискове, дали плановете за третиране на риска са свързани със SoA и дали доказателствата се съхраняват. Той ще търси повторяемост, история на версиите, видимост в прегледите от ръководството и покритие от вътрешен одит.

За Приложение A той ще свърже вашите доказателства с 5.8, 8.25, 8.26, 8.27 и 8.29. Стъпка 21 на ZB, Controls in Action, подчертава защитената системна архитектура и инженерните принципи, като пита кои принципи насочват сигурната архитектура. Одиторите могат да попитат дали моделирането на заплахи се извършва по време на проектирането чрез методи като STRIDE или attack trees и дали архитектурните решения се преглеждат преди внедряване.

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

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

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

Проверяващ, ориентиран към NIST CSF или COBIT 2019, ще търси управление, собственост върху процесите, резултатност, отчетност и непрекъснато подобрение. Той може да се интересува по-малко от самия работен лист по STRIDE и повече от това дали процесът е надежден, измерван, одобрен и подобряван.

Чести пропуски в доказателствата от моделиране на заплахи

Най-честите пропуски не са технически. Те са пропуски в доказателствата.

Екипите извършват моделиране на заплахи твърде късно, след като системата вече е изградена. В този момент workshop-ът се превръща в инструктаж преди тестове за проникване, а не в контрол на дизайна.

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

Поверителността и сигурността са разделени. Един екип документира риск от подправяне на самоличност и инжектиране, докато друг документира срокове за съхранение и правно основание. Отчетността по GDPR работи по-добре, когато потоците от данни, сценариите за злоупотреба и критериите за задействане на DPIA са свързани.

Предположенията за доставчиците остават недокументирани. NIS2, DORA и NIST CSF повишават очакванията за ИКТ риск във веригата на доставки. Ако мярка за смекчаване зависи от шифроването, журналирането, изтриването, устойчивостта или реагирането при инциденти на доставчик, съберете доказателствата.

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

Приемането на остатъчния риск е неформално. „Приемаме това за MVP“ не е достатъчно. ISO/IEC 27001:2022 очаква приемане на остатъчния риск от подходящите собственици на риска като документирана информация.

Вашият пакет с доказателства от моделиране на заплахи за 2026 г.

За всяка съществена система или значима промяна поддържайте стандартен пакет с доказателства, който може да подкрепи ISO 27001, NIS2, DORA, CRA, GDPR и клиентски уверения за контролите.

Risk Management Policy - SME улавя добре оперативния модел:

„Тя гарантира, че управлението на риска е активен компонент на планирането, изпълнението на проекти, избора на доставчици и реагирането при инциденти, в съответствие с ISO 27001, ISO 31000 и приложимите регулаторни изисквания.“
От раздел „Цел“, клауза на политиката 1.2.

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

Направете моделирането на заплахи готово за одит преди следващото пускане

Организациите, които ще се справят най-добре с натиска за съответствие през 2026 г., не са тези с най-много диаграми. Това са организациите, които могат да докажат проста верига:

Рискът на ниво дизайн е идентифициран. Рискът е оценен. Контролите са избрани. Мерките за смекчаване са внедрени. Тестовете са валидирали мерките за смекчаване. Остатъчният риск е одобрен. Доказателствата са картографирани към значимите рамки.

Започнете с една високорискова промяна: платежна интеграция, нов API, работен поток с изкуствен интелект, функционалност за идентичност, миграция към облак, клиентска продуктова версия или услуга, свързана с доставчик. Проведете 90-минутен спринт за риск на ниво дизайн. Използвайте ZB, за да превърнете констатациите в рискови сценарии, планове за третиране на риска и проследимост към SoA. Използвайте ZC, за да картографирате контроли от ISO/IEC 27002:2022 като 5.8, 8.25, 8.26, 8.27 и 8.29 към поддържащи контроли, риск, свързан с доставчици, поверителност, тестване и одитни доказателства. Съгласувайте P24, P06, P17, P24S и вашата процедура за управление на промените, така че моделирането на заплахи да стане задължително, повторяемо и подлежащо на преглед.

Ако искате Clarysec да помогне, започнете с преглед на доказателствата от моделирането на заплахи. Ще оценим един реален проект, ще идентифицираме пропуски спрямо очакванията на ISO/IEC 27001:2022, NIS2, DORA, CRA и GDPR и ще ви предоставим практична пътна карта за отстраняване, която инженерите, одиторите и управителният съвет могат да разберат.