Управление на плащанията при рансъмуер за NIS2 и DORA

В делничен ден през 2026 г. е 3:17 сутринта. Мария, CISO на бързо развиваща се fintech платформа, е включена в кризисен конферентен мост след съобщение от водещия SOC анализатор: потвърдено е масово криптиране, основните услуги са недостъпни, а група за рансъмуер твърди, че е откраднала 2 TB клиентски данни.
Първо в разговора се включва главният изпълнителен директор. Следват правният екип, екипът по защита на личните данни, финансите, комуникациите, киберзастрахователят, форензичен доставчик и екипът по облачни операции. Портал в dark web показва 48-часово обратно броене и седемцифрено искане в криптовалута.
Главният изпълнителен директор задава въпроса, от който всеки CISO се страхува.
„Можем ли да платим и кой има право да реши?“
Грешният отговор е това да се третира като проблем на преговорите. Правилният отговор е това да се третира като въпрос на управление.
През 2026 г. управлението на решенията за плащане при рансъмуер вече не е частен технически избор в кризисна ситуация. То може да бъде проверявано от регулатори, одитори, застрахователи, клиенти, правоохранителни органи, акционери и ръководния орган. Решението за плащане се пресича с експозиция към санкции, оценка на нарушение на сигурността на личните данни, условия по киберзастраховане, договорни задължения, кризисни комуникации, запазване на доказателства, поетапно докладване по NIS2, класификация на инциденти по DORA, уведомяване по GDPR и подобрения след инцидент.
Затова Clarysec съветва клиентите си да изградят управление на решенията за плащане при рансъмуер в рамките на системата за управление на информационната сигурност (СУИС) преди инцидента. ISO/IEC 27001:2022 предоставя структурата на системата за управление. Контролите по ISO/IEC 27002:2022 предоставят оперативния модел. Zenith Blueprint: 30-стъпкова пътна карта за одитори и Zenith Controls: ръководство за кръстосано съответствие помагат тази структура да се превърне в практически, годни за одит доказателства.
Наръчник за рансъмуер, в който пише „уведомете правния отдел“, не е достатъчен. Организацията трябва да знае кой може да разреши преговори, как се извършва проверката за санкции, кога застрахователят трябва да одобри, как се документира класификацията по GDPR, NIS2 и DORA и как се защитават доказателствата, докато екипите по възстановяване работят под натиск.
Защо ad hoc решенията за плащане при рансъмуер се провалят
Решението за плащане при рансъмуер често се описва като двоично: плащаме или не плащаме. В действителност решението има поне шест слоя:
- Потвърдено ли е събитието, ограничено ли е и правилно ли е класифицирано?
- Засегнати ли са лични данни, регулирани данни или предоставянето на критична услуга?
- Има ли организацията законово право да комуникира или да извършва трансакции с участника в заплахата?
- Изисква ли киберзастраховката предварително уведомление, одобрени доставчици, съгласие или конкретни доказателства?
- Би ли намалило плащането въздействието върху бизнеса, или би увеличило правния, финансовия и репутационния риск?
- Кой има правомощия да реши и как се записва това решение?
По време на текущ инцидент несвързани екипи често дърпат в различни посоки. Финансовият директор може да разглежда откупа като бизнес разход спрямо нарастващия престой. Правният екип вижда санкции, финансови престъпления и регулаторна експозиция. DPO оценява дали криптираните или ексфилтрираните данни създават нарушение на сигурността на личните данни, подлежащо на уведомяване. Функцията по съответствие следи сроковете за докладване по NIS2 и DORA. CISO се опитва да запази доказателства, докато възстановява услугите. Главният изпълнителен директор иска препоръка преди да изтече таймерът на нападателя.
Без формален процес за вземане на решение най-силният глас в стаята може да се превърне в модел на управление. Точно тази ситуация съвременното регулиране на киберсигурността цели да предотврати.
NIS2 превръща киберсигурността в управленска отговорност. Article 20 разглежда управлението и отчетността на ръководните органи, а Article 21 изисква мерки за управление на риска, обхващащи обработване на инциденти, непрекъсваемост на дейността, управление на резервни копия, кризисно управление, сигурност на веригата на доставки, контрол на достъпа, политика за управление на активите, MFA и оценка на ефективността. Article 23 въвежда поетапно докладване за значими инциденти, включително ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа и окончателен доклад в рамките на един месец, когато е приложимо.
За финансовите субекти DORA е секторната регулаторна рамка за оперативна устойчивост. Article 5 възлага отговорност на ръководния орган за управлението на ИКТ риска. Article 17, Article 18 и Article 19 разглеждат управлението, класификацията и докладването на съществени инциденти, свързани с ИКТ. DORA също изисква способности за реагиране и възстановяване, архивиране и възстановяване, извличане на поуки след инцидент, тестване и управление на риска от ИКТ трети страни.
GDPR добавя отделна, но припокриваща се оценка. Ако рансъмуер причини случайно или незаконосъобразно унищожаване, загуба, промяна, неразрешено разкриване или достъп до лични данни, администраторът трябва да оцени дали е настъпило нарушение на сигурността на личните данни. Ако се изисква уведомяване, срокът към надзорния орган обичайно е 72 часа от узнаването. Ако съществува висок риск за физическите лица, може да се изисква и комуникация до засегнатите лица.
Изводът е прост: въпросът за откупа не трябва да се задава за първи път в кризисната стая.
Контроли по ISO 27001:2022, които закрепват управлението на плащанията
СУИС по ISO/IEC 27001:2022 не е контролен списък за одитори. Това е система за управление за вземане на решения, основани на риска. Управлението на плащанията при рансъмуер принадлежи в тази система, защото съчетава оценка на риска, третиране на риска, роли, правни задължения, реагиране при инциденти, непрекъсваемост, управление на доставчици и непрекъснато подобрение.
Най-релевантните контроли от Annex A на ISO 27001:2022 формират свързана верига от контроли.
| Област на контрол по ISO 27001:2022 | Защо е важна при управлението на плащанията при рансъмуер |
|---|---|
| A.5.24 Планиране и подготовка за управление на инциденти по информационна сигурност | Дефинира рамката за реагиране при инциденти, модела за ескалация, комуникациите и готовността преди да започне изнудването. |
| A.5.25 Оценка и вземане на решение относно събития по информационна сигурност | Установява как събитията се превръщат в инциденти, как се определя степента на сериозност и кога се задейства ескалация към ръководството. |
| A.5.26 Реагиране при инциденти по информационна сигурност | Контролира ограничаването, отстраняването, координацията на възстановяването и изпълнението на оперативни решения. |
| A.5.27 Извличане на поуки от инциденти по информационна сигурност | Гарантира, че резултатите от решенията за откуп, предотвратените инциденти, обратната връзка от застрахователя и констатациите на регулатори подобряват бъдещите контроли. |
| A.5.28 Събиране на доказателства | Запазва журнали, образи, кореспонденция, проби от зловреден софтуер и записи на решенията по правно надежден начин. |
| A.5.29 Информационна сигурност по време на прекъсване | Поддържа функционирането на контролите за сигурност, докато бизнесът работи в деградиран режим. |
| A.5.30 Готовност на ИКТ за непрекъсваемост на дейността | Свързва резервните копия, приоритетите за възстановяване, превключването към резервна среда и плановете за непрекъсваемост с процеса за вземане на решение при инцидент. |
| A.5.31 Правни, законови, регулаторни и договорни изисквания | Обхваща проверката за санкции, регулаторното докладване, задълженията към клиенти, задълженията към застрахователя и правното одобрение. |
| A.5.34 Поверителност и защита на PII | Задейства оценката на нарушение по GDPR и оценката на въздействието върху поверителността по време на изнудване. |
| A.6.3 Контакт с органи | Подпомага планираната комуникация с регулатори, CSIRT, правоохранителни органи и компетентни органи. |
| A.8.13 Резервно копиране на информация | Определя дали плащането има оперативна релевантност чрез доказване на възможностите за възстановяване. |
| A.8.15 Регистриране и A.8.16 дейности по мониторинг | Осигуряват доказателствената основа за обхвата, хронологията, въздействието и дейността на нападателя. |
В Zenith Controls разделът за A.5.24, планиране и подготовка за управление на инциденти по информационна сигурност, класифицира контрола като коригиращ, свързан с поверителност, цялостност и наличност, и съгласуван с концепциите Respond и Recover. Той също свързва A.5.24 с оценката на събития по A.5.25, извличането на поуки от инциденти по A.5.27, регистрирането по A.8.15, мониторинга по A.8.16, сигурността по време на прекъсване по A.5.29, непрекъсваемостта и контакта с органи.
Това е важно, защото управлението на плащанията при рансъмуер е верига. Ако не можете да откриете и класифицирате събитието, не можете да вземете решение. Ако не можете да запазите доказателства, не можете да защитите решението. Ако правните задължения не са картографирани, преговорите или плащането може да са незаконосъобразни. Ако възможностите за възстановяване не са тествани, ръководителите могат да бъдат притиснати да вземат решение въз основа на страх, а не на факти.
Zenith Controls формулира ясно връзката между подготовката и вземането на решения:
“5.25 е точката на вземане на решение, която определя кога дадено събитие преминава прага към инцидент по сигурността и задейства действията, описани в 5.26. Навременната и точна оценка на събитията гарантира, че реагирането при инциденти няма да бъде нито забавено, нито насочено погрешно.”
Същото ръководство свързва A.5.31, правни, законови, регулаторни и договорни изисквания, с поверителност, срокове за съхранение на записи, независим преглед и съответствие с вътрешни политики. При рансъмуер A.5.31 е мястото, където проверката за санкции, застрахователните задължения, взаимодействието с правоохранителните органи, договорите с клиенти, задълженията за защита на данните и секторното регулаторно докладване се обхващат в един регистър на съответствието.
Петстепенният модел на Clarysec за управление на плащанията при рансъмуер
Моделът на Clarysec разделя управлението на решенията за плащане при рансъмуер на пет контролни порти. Целта не е да се улесни плащането. Целта е всяко решение, включително отказът за плащане, да бъде основано на доказателства, преминало правен преглед, разрешено и годно за одит.
| Порта | Ключов въпрос | Необходими доказателства | Типичен собственик |
|---|---|---|---|
| Порта 1: Обявяване на инцидент | Обявен ли е инцидент с рансъмуер или изнудване по дефинирани критерии? | SIEM сигнали, телеметрия от крайни точки, бележка за откуп, засегнати активи, първоначален запис за степен на сериозност | Ръководител на инцидента или CISO |
| Порта 2: Правен и регулаторен триаж | Включва ли инцидентът лични данни, регулирани услуги, риск от санкции, договорно уведомление или секторно докладване? | Картографиране на правния регистър, оценка на нарушение по GDPR, класификация по NIS2 или DORA, бележки на правен консултант | Правен отдел, съответствие, DPO |
| Порта 3: Жизнеспособност на възстановяването | Може ли организацията да се възстанови безопасно без плащане в рамките на допустимите граници на въздействие? | Проверки на целостта на резервните копия, статус на RTO/RPO, анализ на въздействието върху бизнеса, резултати от тестове за възстановяване | ИТ, ръководител BC/DR |
| Порта 4: Преглед на риска при плащане | Допустими ли са правно преговори или плащане, одобрени ли са от застрахователя, проверени ли са за санкции и разрешени ли са от ръководния орган? | Запис от проверка за санкции, съгласие на застрахователя, запис от консултация с правоохранителни органи, финансово одобрение, приемане на риска | Изпълнително ръководство или ръководен орган |
| Порта 5: Закриване и подобрение | Записани ли са решенията, комуникациите, първопричината и извлечените поуки? | Доклад за инцидент, верига на съхранение, журнал на комуникациите, план за подобрение на контролите | CISO, ISMS Manager, вътрешен одит |
Този модел използва логиката за третиране на риска по ISO 27001. Плащането при рансъмуер не е контрол за сигурност. То е най-много кризисна опция, разглеждана в контекста на третиране на риска и възстановяване. Преди инцидент организацията трябва вече да е решила как се третират рисковете от рансъмуер: смекчаване чрез контроли, прехвърляне на част от финансовата експозиция чрез застраховка, избягване на неприемливи зависимости от наследени системи или изрично приемане на остатъчен риск, когато е обосновано.
В етапа „Управление на риска“, Step 13, „Планиране на третирането на риска и Декларация за приложимост“, Zenith Blueprint инструктира организациите да определят опциите за третиране за всеки риск и да ги документират в регистъра на риска. Той предупреждава, че прехвърлянето, например чрез киберзастраховка, не премахва необходимостта от контроли, защото прехвърлянето често адресира финансовото въздействие, а не вероятността. В него също се посочва:
“Приемането трябва да бъде изрично и одобрено от ръководството, особено за всички средни рискове. Високи рискове рядко се приемат, освен ако това е действително неизбежно и е съгласувано на най-високо ниво.”
Този ред е пряко релевантен за управлението на плащанията при рансъмуер. Ако от ръководния орган се иска да приеме остатъчния риск от отказ за плащане или правния и репутационния риск от одобряване на преговори, приемането трябва да бъде изрично, записано и одобрено от правилния орган.
Политиката за управление на риска на Clarysec затвърждава същия принцип:
“Решенията за третиране на риска трябва да съответстват на предварително дефинираните опции”
От клауза 5.5.
Следователно решението за откуп не е пряк път около управлението на риска. То трябва да се обработва като формално, документирано решение за третиране на риска при дефинирани правомощия.
Правомощия по политиката: кой може да решава под натиск?
Много провали при рансъмуер са управленски провали, маскирани като технически. Някой се свързва с нападателя извън одобрения канал. Някой обещава плащане преди одобрение от застрахователя. Някой възстановява системи и презаписва форензични доказателства. Някой уведомява клиентите твърде рано, твърде късно или с неточни факти.
Политиките на Clarysec са създадени да премахнат тази неяснота.
За МСП Политиката за роли и отговорности в управлението — SME дава просто правило:
“Всички значими решения, изключения и ескалации, свързани със сигурността, трябва да бъдат записани и проследими.”
От раздел „Изисквания за управление“, клауза 5.5 от политиката.
SME Политиката за реагиране при инциденти — SME възлага правомощията за ескалация:
“Генералният мениджър (GM) носи отчетност за разрешаването на всички решения за ескалация на инциденти, регулаторни уведомления и външни комуникации.”
От раздел „Изисквания за управление“, клауза 5.1.1 от политиката.
Тя също свързва инцидентите с клиентски данни с регулаторните задължения:
“Когато са засегнати клиентски данни, генералният мениджър трябва да оцени правните задължения за уведомяване въз основа на приложимостта на GDPR, NIS2 или DORA.”
От раздел „Третиране на риска и изключения“, клауза 7.4.1 от политиката.
За по-големи организации корпоративната Политика за роли и отговорности в управлението изисква незабавна ескалация, когато може да съществува правна експозиция или нарушения на данни, подлежащи на докладване:
“Правна/регулаторна ескалация: инциденти, включващи потенциална правна експозиция или подлежащи на докладване нарушения на сигурността на данните, трябва незабавно да бъдат ескалирани към служителя по правни въпроси и съответствие и към изпълнителното ръководство.”
От раздел „Изисквания за прилагане на политиката“, клауза 6.4.3 от политиката.
Корпоративната Политика за реагиране при инциденти дефинира правомощията на ръководството при тежки инциденти. Клауза 4.6.1 посочва, че ролята на екипа на изпълнителното ръководство е да:
“Взема стратегически решения по време на инциденти с висока степен на сериозност, включително одобрение на уведомления и публични комуникации.”
В контекст на рансъмуер Clarysec третира обсъждането на плащане, разрешаването на преговори, уведомяването на клиенти, регулаторното изявление и публичната комуникация като стратегически решения, а не като технически действия.
От това следва практическо правило за управление: CISO може да препоръчва, екипът по инцидента може да оценява, правният екип може да съветва, финансите могат да валидират механиката на плащането, застрахователят може да даде съгласие или да откаже покритие, но изпълнителното ръководство или ръководният орган трябва да притежава решението съгласно предварително дефинираните правомощия.
Ескалация, съобразена със санкционните режими, преди всякакви преговори
Процесът при рансъмуер, съобразен със санкционните режими, започва със забрана: никой служител, изпълнител, доставчик, брокер, преговарящ или участник в реагирането при инцидент няма право да преговаря, обещава, улеснява или прехвърля стойност към участник в заплаха без одобрен правен преглед.
Правната контролна точка трябва да настъпи преди всякакво активно взаимодействие с нападателя, а не след като се появи адрес на портфейл. Процесът трябва да включва:
- Ангажиране на правен консултант преди всякаква комуникация извън пасивното събиране на доказателства.
- Идентификация на участника в заплахата чрез форензични данни, разузнаване и информация от правоохранителни органи, когато е налична.
- Проверка за санкции и ограничени страни по имена на групи, псевдоними, адреси на портфейли, инфраструктура, посредници и платежни канали.
- Обмислена и записана консултация с правоохранителните органи.
- Уведомяване на киберзастрахователя съгласно условията на полицата преди назначаване на доставчици или започване на преговори.
- Ангажиране на DPO или ръководител по защита на личните данни, ако може да са засегнати лични данни.
- Финансовият директор или финансовият ръководител потвърждава контролите за плащане, разделението на задълженията, проверките срещу измами и изискванията за одобрение от ръководния орган.
- Записване на решението на ръководството с разгледани алтернативи, включително възстановяване, ограничаване, спиране на услуги, комуникация с клиенти и отказ за плащане.
- Запазване на доказателства за комуникациите с нападателя, индикаторите, данните за портфейли, заседанията за вземане на решения, одобренията и външните съвети.
За рансъмуер правният регистър трябва да включва най-малко следните източници на задължения.
| Източник на задължение | Въздействие върху управлението на плащанията |
|---|---|
| Изисквания за санкции и финансови престъпления | Без преговори или плащане без правна проверка и документирано одобрение. |
| Договор за киберзастраховане | Уведомяване на застрахователя, одобрени доставчици, предварително съгласие, изисквания за доказателства и условия за покритие. |
| GDPR | Оценка на нарушение на сигурността на личните данни, уведомяване на надзорния орган, комуникация със субектите на данни и записи за отчетност. |
| NIS2 | Класификация на значим инцидент, ранно предупреждение до 24 часа, уведомление до 72 часа и окончателен доклад в едномесечен срок, когато е приложимо. |
| DORA | Класификация на съществен инцидент, свързан с ИКТ, докладване до компетентния орган, комуникация с клиенти и анализ на първопричините след инцидент. |
| Договори с клиенти | Уведомление за инцидент по сигурността, ангажименти за ниво на обслужване, права на одит и задължения за комуникация с клиенти. |
| Очаквания на правоохранителните органи | Запазване на доказателства, обработване на комуникацията с нападателя и записи за координация. |
Организациите трябва също да дефинират кой може да спре решението за плащане. Правният екип, съответствието, DPO, консултантът по санкции или ръководният орган трябва да имат изрични правомощия да паузират преговори или плащане, ако проверката е непълна, доказателствата са ненадеждни, условията на застрахователя не са изпълнени или действието може да наруши закон или договор.
Запазване на доказателства: не унищожавайте доказателствата, докато възстановявате услугата
Екипите при рансъмуер естествено бързат да възстановят операциите. Но ако възстановяването унищожи журнали, снимки на състоянието, бележки за откуп, проби от зловреден софтуер, образи на паметта или съобщения от нападателя, организацията може да загуби способността да докаже какво се е случило.
В етапа Controls in Action, Step 23, „Организационни контроли“, Zenith Blueprint указва на организациите да валидират и тестват способностите за управление на инциденти чрез дефиниране на подлежащи на докладване събития по сигурността, документиране на вземането на решения и запазване на форензични доказателства. Той инструктира екипите да:
“Заснемат и регистрират всички решения, роли и комуникации (5.26) и актуализират плана с извлечените поуки (5.27). Потвърдете, че са въведени процедури за запазване на форензични доказателства (5.28), включително снимки на журнали, резервни копия и сигурна изолация на засегнатите системи.”
Същата стъпка обяснява A.5.28 с език, който всеки ръководен орган трябва да разбере:
“това, което можете да докажете, е също толкова важно, колкото и това, което действително се е случило”
Корпоративната Политика за събиране на доказателства и форензика на Clarysec затвърждава, че доказателствата трябва да останат проследими:
“Журнал за верига на съхранение трябва да придружава всички физически или цифрови доказателства от момента на придобиване до архивиране или предаване и трябва да документира:”
От раздел „Изисквания за управление“, клауза 5.6 от политиката.
За МСП Политиката за събиране на доказателства и форензика — SME е умишлено практична:
“Винаги трябва да се създава форензично копие или експорт; оригиналното доказателство никога не трябва да се редактира директно.”
От раздел „Изисквания за прилагане на политиката“, клауза 6.1.1 от политиката.
Тя също изисква правна консултация, когато може да има въздействие върху човешките ресурси, правни въпроси или клиенти:
“Ако инцидентът включва потенциално въздействие върху човешките ресурси (HR), правни въпроси или клиенти, GM трябва да се консултира с правен съветник, преди да продължи с прилагане или ескалация.”
От раздел „Изисквания за управление“, клауза 5.4.2 от политиката.
Практическият пакет с доказателства трябва да бъде открит по време на Порта 2. Създайте ограничена папка с доказателства за инцидента. Експортирайте SIEM хронологии, EDR откривания, облачни одитни журнали, журнали за вписване от доставчика на идентичност, статус на задачи за архивиране, бележки за откуп, екранни снимки, съобщения от нападателя, адреси на портфейли, файлови проби, препратки към правни съвети, кореспонденция със застрахователя и решения от срещи. Определете попечител. Записвайте хеш стойности, когато е подходящо. Не позволявайте на администраторите да почистват засегнати системи преди форензично придобиване, освен ако безопасността на живота, защитата на критична услуга или одобрено от ръководството ограничаване не го изисква.
Един работен лист за класификация по NIS2, DORA и GDPR
Инцидент с рансъмуер може да задейства множество срокове. Предизвикателството не е само да се знаят крайните срокове. То е да се знае кога организацията е узнала, какво е знаела към този момент и как са взети решенията за класификация.
NIS2 Article 23 изисква съществени и важни субекти да уведомят CSIRT или компетентния орган без неоправдано забавяне за значими инциденти. Значимостта е свързана със сериозно оперативно прекъсване, финансова загуба или значителни материални или нематериални вреди за други лица. Поетапният модел включва ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа, междинни актуализации при поискване и окончателен доклад в рамките на един месец от уведомлението за инцидента, когато е приложимо.
DORA изисква финансовите субекти да дефинират и внедрят управление на инциденти, свързани с ИКТ, да записват инциденти и значими киберзаплахи, да класифицират инцидентите по критерии като засегнати клиенти, продължителност, географско разпространение, загуба на данни, критичност и икономическо въздействие и да докладват съществени инциденти, свързани с ИКТ, на компетентните органи чрез първоначални, междинни и окончателни доклади.
GDPR задава различен, но припокриващ се въпрос: причинил ли е инцидентът нарушение на сигурността на личните данни? Ако да, вероятно ли е да доведе до риск за физическите лица? Ако прагът за уведомяване е достигнат, уведомяването на надзорния орган трябва да се оцени спрямо 72-часовия срок. Ако съществува висок риск, може да е необходима и комуникация до физическите лица.
Clarysec препоръчва използването на единен работен лист за класификация при рансъмуер с отделни раздели за всеки режим.
| Област на класификация | Примерен въпрос при рансъмуер | Резултат |
|---|---|---|
| Оперативно въздействие | Прекъснати ли са критични услуги или вероятно ли е да бъдат прекъснати? | Вход за значимост по NIS2 и критичност по DORA |
| Финансово въздействие | Причинил ли е инцидентът или може ли да причини съществена финансова загуба? | Вход за степен на сериозност по NIS2 и DORA |
| Въздействие върху клиенти | Засегнати ли са получатели на услуги, клиенти, контрагенти или трансакции? | Вход за NIS2, DORA и договорно уведомление |
| Лични данни | Достъпвани, ексфилтрирани, променени, унищожени или направени недостъпни ли са лични данни? | Вход за оценка на нарушение по GDPR |
| Чувствителност на данните | Засегнатите данни включват ли специални категории данни, удостоверителни данни, финансови данни, документи за самоличност или данни на деца? | Вход за риск и комуникация по GDPR |
| Трансгранично въздействие | Засегнати ли са няколко държави членки, юрисдикции, клиенти или локации за услуги? | Вход за докладване по NIS2 и DORA |
| Надеждност на доказателствата | Кои факти са потвърдени, подозирани или неизвестни? | Основа за поетапно докладване и актуализации |
Този подход съответства на клаузите на ISO 27001 относно оценка на риска, третиране на риска и документирана информация. Той също е съгласуван с NIST CSF 2.0. Функцията GOVERN на NIST CSF 2.0 очаква организациите да разбират заинтересованите страни, правните и регулаторни задължения, апетита за риск, ролите, политиката, надзора и риска от трети страни. Неговите резултати за откриване, реагиране и възстановяване подпомагат обявяването на инцидент, анализа, координацията на реагирането, уведомяването на заинтересованите страни, изпълнението на възстановяването и валидирането на възстановяването.
За финансовите субекти DORA може да действа като секторен режим за киберсигурност за припокриващи се задължения по NIS2, но това не премахва необходимостта да се разбере приложимостта на NIS2 за дружества от групата, ИКТ доставчици, управлявани услуги или облачни зависимости. Практическият отговор не е да се поддържат отделни наръчници. Той е да се използва един модел за доказателства в СУИС, съпоставен с всички релевантни задължения.
Киберзастраховането и координацията с доставчици са контроли за управление
Киберзастраховането може да бъде ценно, но не е стратегия за рансъмуер. То е механизъм за прехвърляне на риска с условия. По време на събитие с рансъмуер застрахователят може да изисква незабавно уведомяване, използване на одобрени фирми, предварително одобрение за преговори, запазване на доказателства, доказателство за отказ на резервни копия, доказателство за разумни контроли и правен преглед преди каквото и да е разглеждане на плащане.
DORA превръща риска от ИКТ трети страни в първостепенна област на съответствие. NIS2 Article 21 също изисква сигурност на веригата на доставки и отчитане на уязвимости на доставчици и практики за киберсигурност. ISO 27001 поддържа същата логика чрез контроли за доставчици и облак, като A.5.19 до A.5.23, плюс контролите за инциденти, непрекъсваемост и правни изисквания.
Zenith Controls свързва подготовката за инциденти с външни партньори, включително форензични фирми, правен отдел, PR и контакт с органи. От гледна точка на одит липсата на предварително идентифицирани външни партньори може да се разглежда като пропуск в готовността, защото може да забави реакцията при реален инцидент.
За управлението на плащанията при рансъмуер Clarysec препоръчва предварително договаряне на:
- Форензичен retainer или условия за бързо реагиране.
- Наличност на външен правен консултант за стратегия при нарушение, санкции и правна привилегия.
- Канал за уведомяване на киберзастрахователя и списък с одобрени доставчици.
- Път за ескалация към доставчика на облачни услуги за snapshots, журнали, изолация и възстановяване.
- Процедури за сътрудничество при инциденти с MSSP или MDR.
- Процес за преглед на PR и кризисни комуникации.
- Банкови или финансови контроли за одобрение на всяко извънредно плащане.
- Протокол за контакт с правоохранителни органи.
Това се картографира добре към резултатите на NIST CSF 2.0 за веригата на доставки, включително роли и отговорности на доставчиците, надлежна проверка, договорни изисквания за киберсигурност, координация при инциденти с доставчици и дейности след прекратяване.
Практически наръчник за ескалация при плащане при рансъмуер
Петте порти могат да се превърнат в оперативен наръчник. Всяка стъпка трябва да бъде документирана, да има собственик и да бъде упражнявана.
| Фаза | Ключово действие | Отговорна роля | Ключови контроли по ISO 27001:2022 | Доказателство или резултат |
|---|---|---|---|---|
| 1. Триаж и обявяване | Оценяване на събитието спрямо критерии, обявяване на значим или съществен инцидент, активиране на екипа за реагиране | Ръководител SOC, ръководител на инцидента | A.5.24, A.5.25 | Билет за инцидент, журнал за обявяване, първоначален доклад за ситуацията |
| 2. Анализ на въздействието върху бизнеса | Количествено определяне на оперативното въздействие, оценка на позицията спрямо RTO/RPO, определяне на критичността на данни и услуги | Собственици на бизнес процеси, CISO, ръководител BC/DR | A.5.29, A.5.30, A.8.13 | Анализ на въздействието върху бизнеса, констатации за целостта на резервните копия |
| 3. Запазване на доказателства | Експортиране на журнали, запазване на системи, защитаване на доказателства и поддържане на верига на съхранение | Ръководител форензика, екип за реагиране при инциденти | A.5.28, A.8.15, A.8.16 | Форензични образи, експорти на журнали, запис за верига на съхранение |
| 4. Правна проверка и проверка за санкции | Ангажиране на правен консултант, идентифициране на участника в заплахата, проверка за санкции, оценка на задълженията за докладване | Правен служител, DPO, съответствие, външен правен консултант | A.5.31, A.5.34, A.6.3 | Правно становище, запис от проверка за санкции, работен лист за докладване |
| 5. Координация със застраховател и доставчици | Уведомяване на застрахователя, потвърждаване на одобрени доставчици, координация на облачна, MSSP и форензична поддръжка | CISO, правен отдел, мениджър на доставчици | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 | Съгласие на застрахователя, билети към доставчици, журнал на действията на доставчици |
| 6. Кратък доклад за решение на ръководството | Представяне на опции, рискове, правно становище, жизнеспособност на възстановяването, комуникационно въздействие и позиция на застрахователя | Ръководител на инцидента, CISO, правен отдел, финансов директор | A.5.1, A.5.2, A.5.26, A.5.31 | Документ за брифинг относно решение при рансъмуер |
| 7. Разрешаване и документиране | Ръководният орган решава дали да се преговаря, да се откаже, да се плати или да се предприемат алтернативни действия | Главен изпълнителен директор, изпълнително ръководство, ръководен орган | A.5.2, A.5.3, A.5.26, A.5.31 | Подписан запис на решение, приемане на риска, журнал на действията |
| 8. Закриване и подобрение | Извършване на анализ на първопричините, извлечени поуки и актуализации на контролите | ISMS Manager, CISO, вътрешен одит | A.5.27, ISO 27001 clause 10.2 | Доклад за извлечени поуки, план за коригиращи действия, актуализирани записи в СУИС |
Целта не е да се гарантира удобно решение. Може да няма удобно решение. Целта е да се гарантира, че решението е разрешено, основано на доказателства, правно информирано и защитимо.
90-минутното tabletop упражнение, което доказва готовност
Най-простият начин да се тества управлението на плащанията при рансъмуер не е технически red team. Това е tabletop упражнение за вземане на решение.
Използвайте Zenith Blueprint, етап Controls in Action, Step 23, за да валидирате способността за управление на инциденти. Изберете сценарий с рансъмуер и проведете упражнение с фиксирано време. Целта не е предварително да се реши, че организацията би платила или никога не би платила. Целта е да се докаже, че организацията може да достигне до управлявано решение.
Сценарий: клиентска база данни, хоствана в облак, е криптирана; нападателят твърди ексфилтрация; съществуват резервни копия, но целостта им още не е тествана; застрахователят не е уведомен; нападателят предоставя адрес на портфейл с 48-часов срок.
Контролен списък за упражнението:
- Обявете инцидента и назначете ръководител на инцидента.
- Отворете журнал за решението при рансъмуер.
- Класифицирайте събитието, използвайки критериите по A.5.25.
- Идентифицирайте засегнатите активи и бизнес услуги.
- Определете дали са засегнати лични данни.
- Задействайте работни потоци за оценка по GDPR, NIS2, DORA и договорни задължения.
- Уведомете правния екип, DPO, изпълнителното ръководство, застрахователя и форензичния доставчик.
- Запазете доказателства преди разрушителни действия по възстановяване.
- Проверете целостта на резервните копия и опциите за възстановяване.
- Извършете проверка за санкции преди всякакви преговори.
- Запишете дали се изисква консултация с правоохранителните органи.
- Изгответе предварителни изявления за клиенти и регулатори.
- Представете опциите за решение на упълномощения ръководен орган.
- Запишете решението, обосновката, несъгласията, одобренията и следващите действия.
- Насрочете преглед след инцидент и действия за подобрение на контролите.
Резултатът трябва да бъде пълен пакет с доказателства: списък на участниците, хронология, работен лист за класификация, журнал на решенията, чернови на комуникации, правни задачи, задачи към застрахователя, констатации за резервните копия и извлечени поуки. Този пакет е изключително ценен за одит, защото показва работещо управление преди реална криза.
Как одиторите и регулаторите ще тестват процеса
Одитори с различен профил ще разгледат един и същ процес при рансъмуер през различни призми.
| Одиторска перспектива | Какво ще поискат | Как изглеждат добрите доказателства |
|---|---|---|
| Одитор по ISO 27001:2022 | Контролирани ли са планирането на инциденти, оценката на събития, реагирането, доказателствата, правните изисквания и извлечените поуки? | План за реагиране при инциденти, картографиране на SoA, регистър на риска, записи от tabletop упражнения, процедура за доказателства, журнали на решенията, резултати от преглед от ръководството |
| Одитор на СУИС в стил ISO/IEC 27007 | Разбират ли хората ролите си и могат ли записите да докажат функциониране? | Интервюта с CISO, правен отдел, DPO, SOC, ръководители, плюс извадка от билети за инциденти и записи за ескалация |
| Оценител, съгласуван с NIST | Интегрирани ли са резултатите за управление, откриване, реагиране, комуникации и възстановяване? | CSF профил, регистър на риска, правила за мониторинг, критерии за обявяване на инцидент, комуникации със заинтересовани страни, валидиране на възстановяването |
| Одитор по COBIT 2019 или ISACA | Има ли управленска собственост, контрол на процеса, достатъчност на доказателствата и непрекъснато подобрение? | RACI, показатели за процеса, докладване за съответствие, преглед след инцидент, проследяване на коригиращи действия |
| Одитор, фокусиран върху DORA | Класифицират ли се, ескалират ли се, докладват ли се, възстановяват ли се и подобряват ли се ИКТ инцидентите по рамката за управление на ИКТ риска? | Критерии за класификация на инциденти, докладване към ръководния орган, доказателства за комуникация с клиенти, анализ на първопричините, тестване на устойчивостта |
| Одитор по GDPR/поверителност | Навременна, риск-базирана и документирана ли е оценката на нарушението на сигурността на личните данни? | Формуляр за оценка на нарушение, участие на DPO, решение относно надзорния орган, обосновка за комуникация със субекти на данни, записи за контекста на обработването |
Zenith Controls предоставя подробна одиторска методология за A.5.24, A.5.25 и A.5.31. За A.5.24 одиторите преглеждат плана за реагиране при инциденти, класификациите по степен на сериозност, ролите, списъците с контакти, инструкциите за регулаторно докладване, упражненията и договореностите с външни партньори. За A.5.25 те проверяват дали съществуват критерии за класификация на събития, дали записите за обработване на сигнали показват разследване и решения за ескалация, дали се използват SIEM и разузнаване за заплахи и дали DPO или правни екипи участват, когато може да са засегнати лични данни. За A.5.31 одиторите търсят правни регистри, картографиране на съответствието, доказателства за преглед, покритие от вътрешен одит и докладване към висше ръководство.
Одиторският риск не е само в това дали организацията е платила или е отказала да плати. Одиторският риск е, че никой не може да докаже как е взето решението.
От изнудване към подобрение на контролите
Управлението при рансъмуер не приключва, когато системите бъдат възстановени. ISO 27001 очаква непрекъснато подобрение. A.5.27, извличане на поуки от инциденти по информационна сигурност, е в основата на това очакване. DORA изисква анализ на първопричините и допълнителни контроли. Окончателното докладване по NIS2 очаква мерки за смекчаване и вероятна първопричина, когато е приложимо. Принципът на отчетност по GDPR очаква документиране на решенията и предпазните мерки.
Всеки преглед след инцидент с рансъмуер трябва да отговори на следните въпроси:
- Правилно ли бяха идентифицирани сроковете за докладване?
- Работи ли правомощието за вземане на решения както е проектирано?
- Достатъчно рано ли се извършиха правният преглед и проверката за санкции?
- Помогна ли координацията със застрахователя или забави реакцията?
- Бяха ли резервните копия пълни, сегрегирани, възстановими и тествани?
- Бяха ли журналите достатъчни за оценка на достъпа и извличане на данни?
- Реагираха ли доставчиците според договора?
- Бяха ли комуникациите с клиенти точни и навременни?
- Получиха ли ръководителите правилната информация в правилния момент?
- Кои контроли, политики, договори или обучения трябва да се променят?
Тези отговори трябва да актуализират регистъра на риска, Декларацията за приложимост, плана за реагиране при инциденти, стратегията за резервни копия, договорите с доставчици, комуникационния план и програмата за обучение.
В етапа ISMS Foundation and Leadership, Step 5, Zenith Blueprint подчертава планирането на външни комуникации, включително идентифициране на клиенти, регулатори, партньори и обществеността, определяне какво и кога да се комуникира и дефиниране кой комуникира. При рансъмуер тази стъпка се превръща в мост между техническото реагиране и запазването на доверието.
Изградете записа на решението преди бележката за откуп
Най-доброто време за управление на решение за откуп е преди нападателят да постави крайния срок.
Ако вашият наръчник за рансъмуер не дефинира правомощия за вземане на решения, правен преглед, проверка за санкции, одобрение от застрахователя, запазване на доказателства, класификация по NIS2 и DORA, оценка на нарушение по GDPR и документация на ниво ръководен орган, организацията има управленски пропуск, който чака криза.
Clarysec помага на организациите да изградят тази способност в СУИС чрез:
- Zenith Blueprint: 30-стъпкова пътна карта за одитори за поетапно внедряване на ISO 27001, третиране на риска, планиране на комуникациите и валидиране на способността за реагиране при инциденти.
- Zenith Controls: ръководство за кръстосано съответствие за картографиране на контролите по ISO 27001 към NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 и доказателства за одит.
- Корпоративни политики и политики за МСП на Clarysec, включително Политика за реагиране при инциденти, Политика за реагиране при инциденти — SME, Политика за събиране на доказателства и форензика, Политика за събиране на доказателства и форензика — SME, Политика за роли и отговорности в управлението, Политика за роли и отговорности в управлението — SME и Политика за управление на риска.
- Практически шаблони за tabletop упражнения при рансъмуер, журнали на решенията, матрици за правна ескалация, пакети с доказателства и работни листове за кръстосано докладване на съответствието.
Не чакайте обаждането в 3 сутринта, за да откриете кой може да решава. Прегледайте плана си за реагиране при инциденти спрямо петте порти на Clarysec, проведете 90-минутно tabletop упражнение за плащане при рансъмуер и изградете запис на решение, съобразен със санкционните режими и готов за одит, който може да издържи пред регулатори, застрахователи и собствения ви ръководен орган.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council