Оценка на риска по ISO 27001, готова за одит, за NIS2 и DORA
Кафето върху бюрото на Сара беше изстинало.
Като главен директор по информационна сигурност (CISO) на бързо растяща финтех компания тя беше свикнала с напрежението. Компанията току-що беше спечелила голям банков партньор, а въпросникът за комплексна проверка на екрана ѝ трябваше да бъде формалност. Първите въпроси бяха познати: предоставете Декларацията за приложимост по ISO/IEC 27001:2022, споделете последния регистър на риска, обяснете методологията за оценка на риска.
След това въпросникът промени фокуса си.
Докажете как вашата програма за управление на риска адресира DORA. Обяснете готовността си за Директивата NIS2, включително управленската отчетност и мерките за риск във веригата на доставки. Предоставете доказателства, че критичните ИКТ доставчици са оценени, наблюдавани и включени в плановете за реагиране при инциденти и за непрекъсваемост на дейността.
До понеделник сутрин същият въпрос вече беше в дневния ред на комитета по риска към управителния съвет. Сертификационният одит по ISO 27001 беше след осем седмици. Клиенти от финансовия сектор оказваха натиск във връзка с DORA. Имаше въпроси по класификацията по NIS2 за хоствана в облак услуга, която се разширява в ЕС. Отделът по снабдяване твърдеше, че прегледи на доставчиците се извършват, но доказателствата бяха разпръснати между имейли, папки с договори и таблица с доставчици. Правният отдел посочи, че регулаторното съпоставяне все още е в процес. Инженерният екип заяви, че регистърът на риска е почти готов.
Съветът зададе единствения важен въпрос:
Можем ли да докажем, че нашата оценка на риска и планът за третиране на риска са достатъчни?
Това е реалният проблем за SaaS, финтех, доставчици на управлявани услуги, облачни услуги и компании за цифрови платформи. Не дали съществува регистър на риска. Не дали контролите от Приложение A са копирани в електронна таблица. Проблемът е дали организацията може да докаже, под натиска на одит и клиенти, че нейният процес за оценка на риска по ISO 27001 е повторяем, основан на риска, одобрен от собствениците на риска, свързан с действия за третиране, съпоставен с правни задължения и реално функциониращ в оперативната дейност.
Когато е изпълнена правилно, оценката на риска по ISO 27001 и планът за третиране на риска могат да подкрепят сертификацията по ISO/IEC 27001:2022, мерките за управление на риска за киберсигурността по NIS2 Article 21, изискванията на DORA за управление на ИКТ риска, отчетността по GDPR, увереността относно доставчици, готовността за инциденти и докладването към управителния съвет.
Когато е изпълнена лошо, тя се превръща в електронна таблица, която одиторите ще разглобят за тридесет минути.
Това ръководство показва как Clarysec изгражда готови за одит доказателства за оценка и третиране на риска по ISO 27001, използвайки Zenith Blueprint: 30-стъпкова пътна карта на одитора, политиките на Clarysec и Zenith Controls: Ръководство за междурегулаторно съответствие.
Защо оценката на риска по ISO 27001 вече е в центъра на съответствието
Регулаторната среда в ЕС се консолидира около един прост принцип: рискът за киберсигурността трябва да бъде управляван, документиран, тестван и поет от ясно определени собственици.
ISO/IEC 27001:2022 вече работи по този начин. Клаузи 4.1 to 4.4 изискват организацията да разбере своя контекст, заинтересованите страни, обхвата на СУИС и взаимодействията между процесите, преди да оценява риска. Клаузи 6.1.2 and 6.1.3 изискват дефиниран процес за оценка и третиране на риска за информационната сигурност. Клаузи 8.2 and 8.3 изискват организацията да извършва оценки на риска и да изпълнява плана за третиране на риска, като съхранява документирана информация.
NIS2 и DORA правят същата основана на риска логика още по-неотложна.
NIS2 Article 20 изисква управителните органи на съществени и важни субекти да одобряват мерките за управление на риска за киберсигурността, да упражняват надзор върху изпълнението им и да преминават обучение по киберсигурност. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки за управление на рисковете за мрежовите и информационните системи. Тези мерки включват анализ на риска, управление на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурна разработка, управление на уязвимости, оценка на ефективността, киберхигиена, криптография, сигурност в областта на човешките ресурси, контрол на достъпа, управление на активите и многофакторно удостоверяване или защитени комуникации, когато е приложимо.
DORA упражнява сходен натиск върху финансовите субекти. Articles 5 and 6 изискват управителният орган да дефинира, одобрява, наблюдава и носи отговорност за механизмите за управление на ИКТ риска. DORA очаква документирана рамка за управление на ИКТ риска, интегрирана в общото управление на риска и подкрепена от политики, процедури, протоколи, инструменти, вътрешен одит, отстраняване на несъответствия и слабости, непрекъсваемост, тестване, управление на инциденти и управление на ИКТ риска, свързан с трети страни.
Практическият извод е неизбежен: регистърът на риска вече не е работен лист на техническия екип. Той е доказателство за управление.
Enterprise Политиката за управление на риска на Clarysec формулира това очакване изрично:
Трябва да се поддържа формален процес за управление на риска в съответствие с ISO/IEC 27005 и ISO 31000, който обхваща идентифициране на риска, анализ, оценяване, третиране, наблюдение и комуникация.
От Enterprise Политика за управление на риска, раздел „Изисквания за управление“, клауза на политиката 5.1.
Същата политика дефинира готовия за одит резултат:
Да се поддържат централизирани, управлявани по версии регистър на риска и план за третиране на риска, които отразяват текущия статус на риска, покритието на контролите и напредъка по смекчаването.
От Enterprise Политика за управление на риска, раздел „Цели“, клауза на политиката 3.3.
Тази формулировка — „текущия статус на риска, покритието на контролите и напредъка по смекчаването“ — е разликата между статичен файл за съответствие и защитима програма за управление на риска.
Започнете с обхват, задължения и критерии за риска
Много слаби оценки на риска по ISO 27001 започват с контролен списък с контроли. Това е обратният ред.
ISO 27001 изисква организацията да определи контекста, изискванията на заинтересованите страни, обхвата на СУИС, отговорностите на ръководството и планирането на риска, преди да избира контроли. ISO/IEC 27005:2022 засилва това, като препоръчва организациите да идентифицират основните изисквания на заинтересованите страни преди оценката на риска. Тези изисквания могат да произтичат от ISO стандарти, секторни регулации, национални закони, клиентски договори, вътрешни политики, предишни дейности по третиране и задължения към доставчици.
За SaaS или финтех компания, ориентирана към ЕС, процесът за риск трябва да започне с инвентар на съответствието и задълженията.
| Източник на изискване | Защо влияе върху оценката на риска по ISO 27001 | Артефакт с доказателства |
|---|---|---|
| ISO/IEC 27001:2022 Clauses 4, 5, 6, 8, 9, and 10 | Дефинира контекста, лидерството, оценката на риска, третирането на риска, оперативния контрол, оценката на резултатността и подобрението | Обхват на СУИС, методология за риска, регистър на риска, план за третиране на риска, SoA, записи от преглед от ръководството |
| NIS2 Articles 20, 21, and 23 | Добавя управленска отчетност, мерки за киберсигурност при всички видове заплахи и очаквания за докладване на инциденти | Одобрение от управителния съвет, съпоставяне с Article 21, наръчник за докладване на инциденти, доказателства за непрекъсваемост |
| DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28, and 30 | Изисква управление на ИКТ риска, непрекъсваемост, архивиране и възстановяване, жизнен цикъл на инцидента, тестване и контроли за ИКТ риска, свързан с трети страни | Рамка за ИКТ риск, тестове на BCP, регистър на инцидентите, записи от тестове за устойчивост, регистър на ИКТ доставчиците |
| GDPR Articles 3, 4, 5, 6, 9, 10, 25, 32, 33, and 34 | Изисква отчетност, законосъобразно обработване, защита на данните още при проектирането, подходяща сигурност и оценка на нарушения | Инвентар на данните, съпоставяне на правните основания, записи за рискове за поверителността, връзки към DPIA, записи от оценка на нарушения |
| Договори с доставчици и клиенти | Превръща търговските ангажименти в критерии за риска, контроли, доказателства и срокове | Регистър на договорите, записи от комплексна проверка, права на одит, SLA, клаузи за изход |
За МСП Политиката за правно и регулаторно съответствие - МСП на Clarysec задава началната точка:
Управителят (GM) трябва да поддържа прост, структуриран регистър на съответствието, който изброява:
От Политика за правно и регулаторно съответствие - МСП, раздел „Изисквания за управление“, клауза на политиката 5.1.1.
Този прост регистър е мост между съответствието и управлението на риска. Ако той посочва, че GDPR се прилага, защото се обработват лични данни от ЕС, че NIS2 може да се прилага, защото организацията предоставя цифрови или управлявани услуги, или че DORA е релевантна чрез клиенти от финансовия сектор, тези задължения трябва да влияят върху критериите за риска и приоритетите за третиране.
Zenith Blueprint е директен по този въпрос във фазата „Управление на риска“, Step 10, „Установяване на критерии за риска и матрица на въздействието“:
Също така вземете предвид правните/регулаторните изисквания във вашите критерии за приемане. Някои рискове може да са неприемливи независимо от вероятността поради законови изисквания.
От Zenith Blueprint, фаза „Управление на риска“, Step 10.
Той дава и практическо правило за работни срещи:
„Всеки риск, който може да доведе до несъответствие с приложимите закони (GDPR и др.), не е приемлив и трябва да бъде смекчен.“
От Zenith Blueprint, фаза „Управление на риска“, Step 10.
За финтех компанията на Сара това променя модела за точкова оценка. Уязвимост в API на доставчик може да има ниска вероятност, но ако експлоатирането ѝ може да предизвика съществен ИКТ-свързан инцидент по DORA, значим инцидент по NIS2, оценка на нарушение по GDPR, неизпълнение на клиентски SLA или ескалация до управителния съвет, въздействието е високо или критично. Експозицията по съответствие става част от логиката на риска, а не отделна електронна таблица.
Изградете регистър на риска, който одиторите могат да тестват
Одиторите не питат само кои са вашите най-значими рискове. Те проверяват дали методът е дефиниран, повторяем, проследим и спазван.
Те ще попитат:
- Как идентифицирахте тези рискове?
- Кои активи, услуги, доставчици, типове данни и процеси бяха в обхват?
- Какви критерии бяха използвани за вероятност и въздействие?
- Кой притежава всеки риск?
- Кои съществуващи контроли намаляват риска?
- Защо е избрано конкретното решение за третиране?
- Къде са доказателствата, че третирането е извършено?
- Кой е одобрил остатъчния риск?
- Кога рискът ще бъде повторно оценен?
Политиката за управление на риска - МСП на Clarysec описва минималния готов за одит запис за риск:
Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.
От Политика за управление на риска - МСП, раздел „Изисквания за управление“, клауза на политиката 5.1.2.
За корпоративни програми фазата „Управление на риска“ в Zenith Blueprint, Step 11, „Изграждане и документиране на регистъра на риска“, разширява структурата. Тя препоръчва колони като идентификатор на риска, актив, заплаха, уязвимост, описание на риска, вероятност, въздействие, ниво на риска, текущи контроли, собственик на риска, решение за третиране, план за третиране или контроли и статус.
Силен запис за риск изглежда така:
| Поле | Примерен запис |
|---|---|
| Идентификатор на риска | R-042 |
| Актив или процес | Обработване на клиентски данни чрез API за плащания на трета страна и продукционна база данни |
| Заплаха | Експлоатиране на критична уязвимост в API на доставчик или поддържаща облачна услуга за бази данни |
| Уязвимост | Ограничена видимост върху управлението на уязвимости при доставчика, непълно тестване на възстановяването и липса на тестван наръчник при нарушение при доставчик |
| Описание на риска | Компрометиране на доставчик или облачна услуга може да изложи финансови данни, да прекъсне услугата, да задейства регулаторно докладване и да наруши клиентски договори |
| Текущи контроли | SSO, достъп, базиран на роли, договор с доставчик, журнализиране в продукционна среда, ежедневни резервни копия, тримесечен преглед на достъпа |
| Вероятност | Средна |
| Въздействие | Критично |
| Ниво на риска | Критично |
| Собственик на риска | CTO и ръководител „Платформено инженерство“ |
| Решение за третиране | Смекчаване |
| Регулаторно съпоставяне | ISO 27001 контроли от Приложение A за доставчици, облак, инциденти, журнализиране, достъп, непрекъсваемост, архивиране и правно съответствие; NIS2 Articles 20, 21, and 23; DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28, and 30; GDPR Articles 32, 33, and 34 |
| Доказателства | Комплексна проверка на доставчик, искане за права на одит, доклад от тест за възстановяване, правило за SIEM мониторинг, tabletop упражнение за инцидент, актуализирана SoA, протоколи от преглед от ръководството |
Това съществено се различава от „риск от трета страна, висок, смекчаване“. Готовата за одит версия свързва актив, заплаха, уязвимост, последствие, текущи контроли, собственик, регулация, доказателства и управление.
Превърнете третирането на риска в план за доказателства
Планът за третиране на риска трябва да отговаря на четири оперативни въпроса:
- Какво ще направим?
- Кой го притежава?
- Кога ще бъде завършено?
- Как ще докажем, че рискът е намален?
ISO/IEC 27001:2022 Clause 6.1.3 изисква организацията да избере варианти за третиране, да определи необходимите контроли, да ги сравни с Приложение A, за да избегне пропуски, да изготви Декларация за приложимост, да формулира план за третиране и да получи одобрение от собственика на риска за плана и остатъчните рискове. Clause 8.3 след това изисква изпълнение на плана за третиране на риска и съхраняване на документирана информация за резултатите.
Enterprise Политиката за управление на риска прави това приложимо на практика:
Длъжностното лице по управление на риска трябва да гарантира, че мерките за третиране са реалистични, ограничени във времето и съпоставени с контролите от ISO/IEC 27001 Annex A.
От Enterprise Политика за управление на риска, раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.4.2.
Политиката за МСП също изяснява, че приемането не е кратък път:
Приемане: Обосновете защо не са необходими допълнителни действия и запишете остатъчния риск.
От Политика за управление на риска - МСП, раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.1.1.
Приемането трябва да бъде обосновано спрямо критериите, одобрено от правилния собственик и наблюдавано. По NIS2 и DORA неодобреният остатъчен риск може да се превърне в провал на управлението.
Пълният план за третиране трябва да съдържа следните полета:
| Поле за третиране | Цел за одит |
|---|---|
| Идентификатор на риска | Свързва третирането обратно с оценения риск |
| Вариант за третиране | Показва обосновката: смекчаване, избягване, прехвърляне или приемане |
| Избрани контроли | Свързва риска с Приложение A, политики и технически предпазни мерки |
| Регулаторен фактор | Показва релевантност към NIS2, DORA, GDPR, договор или клиент |
| Собственик на действието | Доказва отчетност |
| Краен срок | Прави третирането ограничено във времето |
| Доказателства за внедряване | Показва, че действието е завършено |
| Мярка за ефективност | Показва дали вероятността или въздействието са намалени |
| Остатъчен риск | Показва оставащата експозиция |
| Одобрение от собственика на риска | Доказва приемане и управление |
За R-042 на Сара планът за третиране се превръща в списък с действия за междурегулаторно съответствие.
| Идентификатор на риска | Действие за третиране | Препратка към ISO/IEC 27001:2022 Annex A | Релевантност към NIS2 | Релевантност към DORA | Собственик | Доказателства |
|---|---|---|---|---|---|---|
| R-042 | Упражняване на права на одит спрямо доставчика и изискване на доказателства за управление на уязвимости | 5.19, 5.20, 5.21, 5.22, 5.31 | Article 21(2)(d) сигурност на веригата на доставки | Articles 28 and 30 ИКТ риск, свързан с трети страни, и договори | CTO и ръководител „Снабдяване“ | Искане за одит, отговор на доставчика, преглед на договор |
| R-042 | Внедряване на разширен мониторинг за аномална API и привилегирована дейност | 8.15, 8.16, 5.16, 5.17, 5.18 | Article 21(2)(i) контрол на достъпа и управление на активите | Articles 6 and 17 ИКТ риск и управление на инциденти | Мениджър на SOC | SIEM правило, тест на предупреждение, преглед на достъпа |
| R-042 | Тестване на възстановяването от резервно копие и дефиниране на RTO и RPO на ниво услуга | 5.30, 8.13, 8.14 | Article 21(2)(c) непрекъсваемост на дейността и архивиране | Articles 11 and 12 реагиране, възстановяване, архивиране и възстановяване от резервни копия | Ръководител „Платформено инженерство“ | Доклад за възстановяване, одобрение на RTO и RPO |
| R-042 | Провеждане на tabletop упражнение за нарушение при доставчик | 5.24, 5.26, 5.27, 5.29 | Articles 21(2)(b) and 23 управление и докладване на инциденти | Articles 17, 18, 19, and 24 управление на инциденти, класификация, докладване и тестване | CISO | Запис от tabletop упражнение, извлечени поуки, инструмент за проследяване на отстраняването |
| R-042 | Актуализиране на SoA и одобрение на остатъчния риск | 5.4, 5.31, 5.35 | Article 20 управленска отчетност | Articles 5 and 6 управление и рамка за ИКТ риск | CISO и собственик на риска | Актуализирана SoA, запис за одобрение, протоколи от преглед от ръководството |
Този план е силен, защото създава пряка линия от един сценарий на риск към контролите по ISO 27001, задълженията по NIS2, членовете на DORA, собствениците и доказателствата.
Накарайте Декларацията за приложимост да работи по-усилено
Декларацията за приложимост често се третира като сертификационен артефакт. Тя трябва да бъде повече от това.
ISO/IEC 27001:2022 Clause 6.1.3 изисква SoA да включва необходимите контроли, обосновка за включване, статус на внедряване и обосновка за изключения. Насоките на ISO/IEC 27005:2022 засилват необходимостта избраните контроли да се сравняват с ISO/IEC 27001 Annex A, за да се избегнат пропуски.
В готова за одит програма SoA става мостът между третирането на риска и доказателствата за междурегулаторно съответствие. Ако планът за третиране изисква MFA, журнализиране, мониторинг на доставчици, възстановяване от резервни копия, сигурна разработка, ескалация на инциденти или планиране на изход от облачна услуга, SoA трябва да показва, че съответните контроли от Annex A са включени, обосновани, внедрени или планирани и подкрепени с доказателства.
Това помага да се избегне и често срещан одитен провал: регистърът на риска казва едно, планът за третиране — друго, а SoA мълчи. Когато тези артефакти си противоречат, одиторите бързо губят доверие.
Съпоставяне на третирането на риска по ISO 27001 с NIS2, DORA и GDPR
ISO 27001 не заменя NIS2, DORA или GDPR. Той предоставя структуриран механизъм за създаване на доказателства за тях.
Ключът е съпоставянето да бъде вградено в процеса за риск, а не добавено впоследствие.
| Доказателства за третиране на риска по ISO 27001 | Релевантност към NIS2 | Релевантност към DORA | Релевантност към GDPR |
|---|---|---|---|
| Критерии за риска с точкова оценка на регулаторното въздействие | Подкрепя пропорционалните мерки за управление на риска за киберсигурността по Article 21 | Подкрепя пропорционалност, управление и рамка за ИКТ риск по Articles 4, 5, and 6 | Подкрепя отчетност и подходяща сигурност |
| Регистър на риска със собственици и въздействие върху CIA | Подкрепя управленския надзор по Article 20 и анализа на риска по Article 21 | Подкрепя документирано управление на ИКТ риска и собственост върху риска | Подкрепя доказването на осведоменост за рисковете за личните данни |
| План за третиране, съпоставен с Annex A | Подкрепя мерките по Article 21 в областите инциденти, непрекъсваемост, доставчици, достъп, уязвимости и сигурна разработка | Подкрепя ИКТ контроли, управление на инциденти, непрекъсваемост, тестване и устойчивост спрямо трети страни | Подкрепя техническите и организационните мерки по Article 32 |
| Записи за риск при доставчици и договорни контроли | Подкрепя сигурността на веригата на доставки по Article 21(2)(d) | Подкрепя изискванията за ИКТ риск, свързан с трети страни, и договори по Articles 28 and 30 | Подкрепя предпазните мерки при обработващи лични данни и трансфери, когато е приложимо |
| Сценарии за инциденти и наръчници за докладване | Подкрепя работния поток за докладване на значими инциденти по Article 23 | Подкрепя управление, класификация и докладване на инциденти по Articles 17, 18, and 19 | Подкрепя оценката за уведомяване при нарушение по Articles 33 and 34 |
| Третирания за BCP, архивиране и възстановяване | Подкрепя непрекъсваемост, архивиране, аварийно възстановяване и кризисно управление по Article 21(2)(c) | Подкрепя реагиране, възстановяване, архивиране и възстановяване от резервни копия по Articles 11 and 12 | Подкрепя наличност и устойчивост, когато са включени лични данни |
| Прегледи на ефективността на контролите | Подкрепя оценката на ефективността по Article 21(2)(f) | Подкрепя очакванията за тестване и отстраняване по Article 24 | Подкрепя текущата отчетност |
Това съпоставяне е особено важно там, където регулациите се припокриват. DORA е секторният режим за ИКТ устойчивост за много финансови субекти, докато NIS2 може да остане пряко релевантна за определени доставчици, координация или субекти извън обхвата на DORA. Една финтех компания може да има нужда от DORA като основна рамка за ИКТ устойчивост, докато доставчик на управлявани услуги, който я поддържа, може да има преки задължения по NIS2.
Регистърът на риска трябва да може да покаже и двете страни на тази зависимост.
Използвайте Zenith Controls като компас за междурегулаторно съответствие
Clarysec използва Zenith Controls като ръководство за междурегулаторно съответствие, за да предотврати често срещания провал, при който ISO контролите, регулаторните членове и одитните въпроси съществуват в отделни вселени. То не създава отделна рамка за контроли. То съпоставя областите на контрол от ISO/IEC 27001:2022 и ISO/IEC 27002:2022 с други стандарти, одитни очаквания и перспективи за съответствие.
За оценката и третирането на риска по ISO 27001 тези препратки са особено важни:
| Препратка към ISO/IEC 27001:2022 Annex A, използвана в Zenith Controls | Защо е важна за оценката и третирането на риска | Атрибути, обхванати в Zenith Controls |
|---|---|---|
| 5.4 Отговорности на ръководството | Свързва собствеността върху третирането на риска с управлението, яснота на ролите и отчетност | Превантивен контрол, подкрепя поверителност, цялостност и наличност, съпоставя се с Identify, Governance, Governance and Ecosystem |
| 5.31 Правни, законови, регулаторни и договорни изисквания | Свързва регистъра на съответствието с критериите за риска, решенията за третиране и включването в SoA | Превантивен контрол, подкрепя поверителност, цялостност и наличност, съпоставя се с Identify, Legal and Compliance, Governance, Ecosystem, and Protection |
| 5.35 Независим преглед на информационната сигурност | Свързва вътрешния одит, външния одит и увереността за ръководството с ефективността на третирането | Превантивен и коригиращ контрол, подкрепя поверителност, цялостност и наличност, съпоставя се с Identify and Protect, Information Security Assurance, Governance and Ecosystem |
Урокът за междурегулаторно съответствие е прост. Ако правните задължения не са включени в метода за оценка на риска, точковата оценка е непълна. Ако точковата оценка е непълна, приоритетите за третиране може да са грешни. Ако приоритетите са грешни, SoA и докладването към управителния съвет стават ненадеждни.
Zenith Blueprint формулира същото във фазата „Управление на риска“, Step 14, „Политики за третиране на риска и регулаторни кръстосани препратки“. Той препоръчва организациите да създадат таблица за съпоставяне, която изброява ключови регулаторни изисквания за сигурност и съответните контроли или политики в СУИС. Това не е задължително за сертификация по ISO 27001, но е изключително полезно за доказване, че сигурността се управлява в правен и договорен контекст.
Какво ще попитат различните одитори
Сертификационен одитор, преглеждащ по NIS2, клиент с фокус върху DORA, преглеждащ по GDPR, оценител по NIST или специалист по COBIT може да разглежда едни и същи доказателства, но да задава различни въпроси.
| Одиторска перспектива | Типичен одитен въпрос | Очаквани доказателства |
|---|---|---|
| Одитор по ISO 27001 | Дефиниран, повторяем, приложен и свързан ли е методът за оценка на риска с третирането и SoA? | Методология за риска, критерии, регистър, SoA, план за третиране на риска, одобрения на остатъчния риск |
| Преглеждащ с фокус върху NIS2 | Покриват ли мерките за киберсигурност областите по Article 21 и управленската отчетност? | Одобрения от управителния съвет, съпоставяне с Article 21, наръчник за инциденти, доказателства за непрекъсваемост, доказателства за риск при доставчици |
| Преглеждащ с фокус върху DORA | Документирано, управлявано, тествано и разширено ли е управлението на ИКТ риска към ИКТ трети страни? | Рамка за ИКТ риск, процес за класификация на инциденти, тестове на BCP, тестване на устойчивостта, регистър на ИКТ доставчиците |
| Преглеждащ по GDPR | Може ли организацията да докаже подходяща сигурност и отчетност за рисковете за личните данни? | Инвентар на данните, съпоставяне на правните основания, процедура за оценка на нарушения, доказателства за третиране на риска за поверителността |
| Оценител по NIST | Идентифицират ли се рисковете, защитават ли се активите, откриват ли се събитията, реагира ли се и възстановява ли се чрез измерими контроли? | Сценарии за риск, инвентар на активите, внедряване на контроли, мониторинг, записи за реагиране и възстановяване |
| Одитор по COBIT или ISACA | Съгласувано ли е управлението на риска с корпоративните цели, ролите, резултатността, увереността и управленското докладване? | Протоколи по управление, RACI, KRI, констатации от вътрешен одит, проследяване на отстраняването, управленски табла |
Ето защо архитектурата на доказателствата е важна. Един и същ запис за риск трябва да бъде проследим от бизнес целта до актив, заплаха, уязвимост, контрол, собственик, регулаторен фактор, действие за третиране, резултат от тест и управленско решение.
Политиките на Clarysec са проектирани да подкрепят тази архитектура. Enterprise Политиката за управление на риска посочва в раздел „Референтни стандарти и рамки“:
Article 5: Изисква документирана рамка за управление на ИКТ риска, напълно покрита от структурата на тази политика, включително съпоставяне със SoA и KRI.
Това превръща политиката от статичен документ в одиторско доказателство, показващо, че управлението на ИКТ риска е проектирано умишлено с оглед на DORA.
Чести констатации, които компрометират програмите за риск
Когато Clarysec преглежда доказателства за оценка и третиране на риска по ISO 27001, едни и същи констатации се появяват многократно.
Първо, критериите за риска игнорират правното, регулаторното, договорното, доставчическото и свързаното с поверителността въздействие. Това води до слаба точкова оценка. Нарушение на сигурността на личните данни или отказ на критичен доставчик може да бъде оценено като средно, защото вероятността е ниска, въпреки че въздействието по GDPR, NIS2, DORA или върху клиентите трябва да го направи високо или критично.
Второ, собствениците на риска са общи. „ИТ“ не е собственик на риска. Собственикът на риска трябва да бъде роля или лице, което носи отчетност за решенията за третиране, бюджета, сроковете и остатъчния риск.
Трето, плановете за третиране не са ограничени във времето. „Подобряване на мониторинга“ не е план. „Внедряване на предупреждения за привилегировани сесии в SIEM за администраторски акаунти в продукционна среда до 30 юни, със собственик Мениджър на SOC, тествано чрез симулирано администраторско вписване, с приложени доказателства за предупреждение“ е план.
Четвърто, SoA е откъсната от третирането. Ако планът за третиране на риска изисква мониторинг на доставчици, тестване на резервни копия, ескалация на инциденти, MFA или журнализиране, SoA трябва да отразява съответните контроли и статуса на внедряване.
Пето, остатъчният риск не е одобрен. ISO 27001 изисква одобрение от собственика на риска за плана за третиране и остатъчните рискове. NIS2 и DORA правят това още по-важно, защото управленската отчетност е изрична.
Шесто, рискът при доставчици се третира като административна дейност по снабдяване. Съгласно NIS2 Article 21(2)(d) и DORA Articles 28 and 30 рискът при доставчици и ИКТ трети страни трябва да бъде част от управлението на риска, а не годишен въпросник, съхраняван изолирано.
Седмо, липсват доказателства за ефективност. ISO 27001 Clause 6.1.1 изисква планираните действия да бъдат оценени за ефективност. NIS2 включва оценка на ефективността в Article 21(2)(f). DORA очаква тестване и отстраняване. Контрол, който съществува, но никога не се тества, е слабо доказателство.
Политиката за управление на риска - МСП задава очакването ясно:
Управителят и координаторът по риска трябва да гарантират, че дейностите по управление на риска са готови за одит. Регистърът на риска и свързаните действия подлежат на вътрешен и външен одит.
От Политика за управление на риска - МСП, раздел „Прилагане и съответствие“, клауза на политиката 8.2.1.
Докладване към управителния съвет без претоварване на ръководителите
NIS2, DORA и ISO 27001 водят към управленска отчетност, но управителните съвети не се нуждаят от всеки ред за риск. Те се нуждаят от докладване, което подпомага вземането на решения.
Добър пакет за риска за управителния съвет трябва да показва:
- Високи и критични рискове по домейни
- Просрочени действия за третиране
- Регулаторни рискове, включващи NIS2, DORA, GDPR или договори
- Рискове при доставчици, засягащи критични или важни услуги
- Тенденции при инциденти и предотвратени инциденти
- Остатъчни рискове, очакващи приемане
- Резултати от тестове за ефективност на контролите
- Съществени промени в обхвата, доставчиците, технологиите или правото
- Констатации от вътрешен одит и коригиращи действия
Clarysec обичайно препоръчва месечни оперативни прегледи на риска и тримесечни прегледи от ръководството. Месечните прегледи се фокусират върху изпълнението на третирането. Тримесечните прегледи се фокусират върху приемането, финансирането, приоритизацията, регулаторната експозиция и стратегическите решения за риска.
Този ритъм подкрепя и непрекъснатото подобрение. Оценките на риска трябва да се актуализират при инциденти, поява на уязвимости, въвеждане на нови активи, технологични промени, промени в доставчиците, промени в законодателството, промени в клиентските задължения или промяна в апетита за риск.
Пътят за внедряване на Clarysec
Единна програма за риск избягва разпокъсани електронни таблици за ISO, NIS2, DORA, GDPR и клиентска увереност. Практическият път е:
- Потвърдете обхвата на СУИС, услугите, активите, доставчиците, юрисдикциите и клиентските задължения.
- Изградете или актуализирайте регистъра на съответствието, използвайки Политиката за правно и регулаторно съответствие - МСП, когато е приложимо.
- Дефинирайте методологията за риска, критериите за приемане, скалите за вероятност, скалите за въздействие и правилата за регулаторно въздействие.
- Изградете регистъра на риска, използвайки фазата „Управление на риска“ от Zenith Blueprint и подхода на Clarysec за Risk Register and SoA Builder.
- Идентифицирайте рискове, базирани на активи и сценарии, включително сценарии за доставчици, облак, поверителност, непрекъсваемост, инциденти, уязвимости, сигурна разработка и достъп.
- Оценете рисковете чрез критерии, които включват правно, регулаторно, договорно, оперативно, свързано с поверителността, доставчическо и финансово въздействие.
- Изберете варианти за третиране: смекчаване, избягване, прехвърляне или приемане.
- Съпоставете необходимите контроли с ISO/IEC 27001:2022 Annex A и насоките на ISO/IEC 27002:2022.
- Създайте или актуализирайте Декларацията за приложимост.
- Съпоставете третирането с NIS2 Article 21, управлението на ИКТ риска и очакванията за трети страни по DORA, отчетността по GDPR и клиентските договорни задължения.
- Съберете доказателства, валидирайте ефективността на контролите и получете одобрение на остатъчния риск.
- Подгответе пакет за одит, организиран по риск, контрол, регулация и доказателствен артефакт.
- Включете резултатите в преглед от ръководството, вътрешен одит, коригиращи действия и непрекъснато подобрение.
Това не е документация заради самата документация. Това е операционната система за защитимо киберуправление.
Изградете готов за одит пакет за третиране на риска
Историята на Сара завършва добре, защото тя спря да третира ISO 27001, NIS2 и DORA като отделни проекти за съответствие. Тя използва оценката на риска по ISO 27001 като централен механизъм, вгради регулаторните задължения в критериите за риска, съпостави действията за третиране с Приложение A и изискванията на ЕС и събра доказателства, които клиентите, одиторите и управителният съвет могат да разберат.
Вашата организация може да направи същото.
Използвайте Zenith Blueprint: 30-стъпкова пътна карта на одитора, за да дефинирате критерии за риска, да изградите регистъра на риска, да създадете плана за третиране на риска и да направите кръстосани препратки към регулаторните изисквания.
Използвайте Zenith Controls: Ръководство за междурегулаторно съответствие, за да свържете контролните области от ISO/IEC 27001:2022 Annex A с управлението, правното съответствие, увереността и одитните перспективи.
Използвайте Политиката за управление на риска, Политиката за управление на риска - МСП и Политиката за правно и регулаторно съответствие - МСП на Clarysec, за да стандартизирате собствеността, регистрите, решенията за третиране и готовите за одит доказателства.
Най-бързата практическа следваща стъпка е да вземете вашите десет най-значими риска и да ги проверите спрямо пет въпроса:
- Видимо ли е регулаторното въздействие?
- Ограничен ли е във времето планът за третиране на риска и има ли собственик?
- Съпоставено ли е всяко третиране с Annex A и SoA?
- Документирана ли е релевантността към NIS2, DORA, GDPR или клиентите, когато е приложимо?
- Има ли доказателства, че контролът работи?
Ако отговорът е „не“, Clarysec може да помогне да превърнете вашия регистър на риска в защитима програма за третиране на риска с междурегулаторно съответствие, на която одитори, регулатори, клиенти и управителни съвети могат да се доверят.
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
