Карта на съответствие между NIS2 2024/2690 и ISO 27001 за доставчици на облачни услуги

В 08:17 във вторник Мария, директор по информационна сигурност (CISO) на европейски доставчик на управлявани услуги, получава предупреждението, от което се страхува всеки MSP. Привилегирован акаунт за отдалечено управление е задействал аларми за невъзможно географско придвижване. В два клиентски тенанта се наблюдават необичайни административни действия. SOC вече е открил конферентен мост за критичен инцидент.

В 09:00 главният изпълнителен директор се включва в разговора. Въпросите веднага се променят.

Попадаме ли в обхвата на NIS2? Прилага ли се за нас Регламент за изпълнение (ЕС) 2024/2690 на Комисията? Трябва ли да подадем ранно предупреждение в рамките на 24 часа? Кои клиенти трябва да бъдат уведомени? Можем ли да докажем, че MFA, регистрирането, сегментацията, управлението на уязвимости, контролите за доставчици и ескалацията на инциденти са функционирали преди инцидента?

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

Това е моментът, в който NIS2 престава да бъде правен текст и се превръща в оперативен проблем на контролната среда.

За доставчиците на услуги за облачни изчисления, доставчиците на управлявани услуги, доставчиците на управлявани услуги за сигурност и доставчиците на услуги на центрове за данни NIS2 и Регламент за изпълнение 2024/2690 повишават изискванията от общо намерение за сигурност към проверими доказателства за контролите. Управлението, управлението на риска, контролът на достъпа, управлението на активите, управлението на уязвимости, реагирането при инциденти, сигурността на доставчиците, регистрирането, мониторингът, шифроването, непрекъсваемостта на дейността и физическата устойчивост трябва да функционират като единна система.

ISO/IEC 27001:2022 е най-добрата основа за тази система, но само ако организацията съпостави изискванията на NIS2 със СУИС, регистъра на риска, Декларацията за приложимост, политиките и модела за доказателства. Сертификатът на стената не е достатъчен. Реалната работа е да се изгради одитируема връзка от регулацията към риска, от риска към контрола, от контрола към политиката и от политиката към оперативните доказателства.

Защо NIS2 2024/2690 променя разговора за съответствие при облачни услуги и MSP

NIS2 използва модел по сектор и размер, но категориите за цифрова инфраструктура и управление на ИКТ услуги са умишлено широки. Съгласно NIS2 Article 2 и Article 3, във връзка с Annex I и Annex II, много организации могат да бъдат класифицирани като съществени или важни субекти, включително доставчици на услуги за облачни изчисления, доставчици на услуги на центрове за данни, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, DNS доставчици, TLD регистри, мрежи за доставка на съдържание и доставчици на удостоверителни услуги. Държавите членки трябва да създадат и периодично да преглеждат списъци на съществени и важни субекти, като първият срок за списъка е 17 април 2025 г.

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

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

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

Регламент за изпълнение 2024/2690 конкретизира тези очаквания за съответните цифрови доставчици. На практика органите, клиентите и одиторите няма да питат само дали съществуват политики. Те ще питат дали контролите са съпоставени, имат собственици, тествани са и са подкрепени с доказателства.

ISO/IEC 27001:2022 превръща NIS2 в оперативен контекст на СУИС

Често срещана грешка при подготовката за NIS2 е да се започне с голям контролен списък и да се разпределят задачи между ИТ, правния екип, SOC, инфраструктурата, управлението на доставчици и съответствието. Това може да създаде активност, но често се проваля при одит, защото никой не може да покаже защо са избрани контролите, как са свързани с риска, кой е приел остатъчния риск и какви доказателства потвърждават ефективността.

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

Клаузи 4.1 до 4.4 изискват организацията да определи вътрешните и външните фактори, да идентифицира заинтересованите страни и техните изисквания, да реши кои изисквания ще бъдат обхванати чрез СУИС и да дефинира обхвата на СУИС, включително интерфейсите и зависимостите. За доставчик на облачни услуги или MSP обхватът трябва изрично да взема предвид NIS2, Регламент за изпълнение 2024/2690, клиентските приложения за сигурност, клиентски изисквания, произтичащи от DORA, облачни региони, подизпълнители, зависимости от центрове за данни, платформи за отдалечено управление, пътища за привилегирован достъп и задължения за уведомяване при инциденти.

Клаузи 5.1 до 5.3 изискват лидерство, съгласуване на политиките, ресурси, комуникация, възложени отговорности и отчетност на ръководството. Това пряко подкрепя NIS2 Article 20.

Клаузи 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска, собственици на риска, анализ на вероятността и последствията, избор на контроли, сравнение с Annex A, Декларация за приложимост, план за третиране на риска и формално приемане на остатъчния риск. Тук NIS2 става оперативна. Всяко регулаторно изискване се превръща в двигател на риска, задължение за съответствие, изискване за контрол или изискване за доказателства.

Clarysec започва тази работа със Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint, особено във фазата за управление на риска.

От стъпка 13, планиране на третиране на риска и Декларация за приложимост, Zenith Blueprint инструктира екипите да изградят проследимост между рисковете, контролите и регулаторните двигатели:

„Кръстосано съпоставяне с регулации: Ако определени контроли са внедрени специално за съответствие с GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска, или в бележките към SoA. Например контрол 8.27 (сигурно изтриване на данни) може да е много релевантен за изискването на GDPR за унищожаване на лични данни; можете да отбележите „Приложимо – подкрепя GDPR Art.32 (сигурност на обработването)“. Това не се изисква от ISO, но помага да се докаже, че сте взели предвид тези рамки.“

Стъпка 14, политики за третиране на риска и регулаторни кръстосани препратки, добавя практическата дисциплина за съпоставяне:

„За всяка регулация, когато е приложимо, можете да създадете проста таблица за съпоставяне, която изброява ключовите изисквания за сигурност на регулацията и съответните контроли/политики във вашата СУИС. Това не е задължително по ISO 27001, но е полезно вътрешно упражнение, за да се гарантира, че нищо не е пропуснато.“

Това е разликата между твърдението „ние сме сертифицирани по ISO“ и доказването, че „нашата СУИС по ISO/IEC 27001:2022 обхваща Регламент за изпълнение 2024/2690 по NIS2“.

Единна карта на контролите от NIS2 към ISO/IEC 27001:2022

Следното съпоставяне не е правен съвет и не замества анализ на националното транспониране. То е практическа архитектура на контролите за доставчици, които се нуждаят от одитируем път към готовност по NIS2 чрез ISO/IEC 27001:2022.

Това съпоставяне става силно, когато бъде вградено в Регистъра на риска и Декларацията за приложимост. Например доставчикът може да създаде рисков сценарий, наречен „Компрометиране на платформа за отдалечено управление води до неоторизирани действия в клиентски среди“. Контролите включват MFA, управление на привилегирован достъп, сегментация, регистриране, управление на уязвимостите, сигурност на доставчиците, планиране на инциденти и процедури за уведомяване на клиенти. Бележките в SoA могат да препращат към NIS2 Article 21, Article 23, Регламент за изпълнение 2024/2690, клиентски договори и изисквания за надлежна проверка на клиенти по DORA, когато е релевантно.

Управление на облачни услуги: ISO контрол 5.23 е опорна точка за NIS2

За доставчиците на облачни услуги и MSP, които използват облачни услуги за предоставяне на услуги на клиенти, ISO/IEC 27001:2022 Annex A контрол 5.23, Информационна сигурност при използване на облачни услуги, е една от най-важните опорни точки.

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

Zenith Blueprint, във фазата „Контроли в действие“, стъпка 23, обяснява практическата причина:

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

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

Корпоративната Политика за използване на облачни услуги на Clarysec Cloud Usage Policy прави надлежната проверка преди активиране задължителна:

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

От раздел „Управленски изисквания“, клауза на политиката 5.2.

За по-малки доставчици Cloud Usage Policy-sme Cloud Usage Policy-sme - SME създава олекотен модел за одобрение:

„Всяко използване на облачни услуги трябва да бъде прегледано и одобрено от управителя (GM) преди внедряване или абонамент.“

От раздел „Управленски изисквания“, клауза на политиката 5.1.

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

Реагиране при инциденти: 24-часовият срок започва преди изготвянето на доклада

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

ISO/IEC 27001:2022 Annex A контрол 5.24, Планиране и подготовка за управление на инциденти по информационна сигурност, е контролът за планиране. Zenith Controls го обобщава като коригиращ контрол, който подкрепя поверителност, цялостност и наличност и е свързан с концепциите Respond и Recover, управлението, управлението на събития и защитата. Той включва роли, отговорности, пътища за ескалация, комуникационни протоколи, готовност за регулаторно уведомяване, съгласуване с регистриране и мониторинг, интеграция с непрекъсваемост на дейността и аварийно възстановяване, извличане на поуки след инцидент и съпоставяне с NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 и COBIT 2019.

Политиката за реагиране при инциденти-sme на Clarysec Incident Response Policy-sme - SME превръща първото решение във времево ограничено изискване:

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

От раздел „Управленски изисквания“, клауза на политиката 5.3.1.

Тази класификация в рамките на един час подкрепя оперативната дисциплина, необходима за анализа на ранното предупреждение в рамките на 24 часа по NIS2, оценката на нарушение на сигурността на личните данни по GDPR, ескалацията към клиента по DORA и триажа на договорните уведомления.

Дървото за вземане на решения при инцидент на доставчика трябва да отговаря на четири въпроса:

1. Има ли потвърдено или предполагаемо компрометиране на поверителността, цялостността или наличността?
2. Засяга ли събитието предоставянето на услуги, клиентски среди, регулирани клиенти, лични данни или критични функции?
3. Може ли да причини тежко оперативно прекъсване, финансова загуба или материални или нематериални вреди?
4. Кои задължения за уведомяване се прилагат: NIS2, GDPR, клиентски задължения по DORA, договорни SLA или очаквания на национален регулатор?

Дървото за вземане на решения трябва да бъде тествано чрез настолни упражнения преди реален инцидент.

Управление на уязвимостите: докажете намаляване на риска преди въздействието

NIS2 изисква обработване и оповестяване на уязвимости. За клиентите и регулаторите управлението на уязвимости е една от най-лесните за измерване области на контрол, защото произвежда ясни доказателства: покритие на сканирането, срокове за прилагане на корекции, одобрения на изключения, анализ на експлоатирани уязвимости и записи за отстраняване.

ISO/IEC 27001:2022 Annex A контрол 8.8, Управление на технически уязвимости, е обобщен в Zenith Controls като превантивен контрол за поверителност, цялостност и наличност, свързан с Identify и Protect, управление на заплахи и уязвимости, управление, екосистема, защита и отбрана. Той включва идентифициране на уязвимости, оценка, приоритизиране, прилагане на корекции, компенсиращи контроли, интеграция на разузнаване за заплахи, оповестяване на уязвимости, отговорности за облачни и приложни уязвимости, доказателства за одит и срокове за отстраняване.

Корпоративната Политика за управление на уязвимости и корекции на Clarysec Vulnerability and Patch Management Policy дава на одиторите конкретен модел за тестване:

„Организацията трябва да класифицира всички открити уязвимости чрез стандартизирана методология (напр. CVSS v3.x) и да прилага срокове за отстраняване, съобразени с критичността за бизнеса: 5.2.1 Критични (CVSS 9.0-10.0): незабавен преглед; срок за прилагане на корекция максимум 72 часа. 5.2.2 Високи (7.0-8.9): реакция в рамките на 48 часа; срок за прилагане на корекция 7 календарни дни. 5.2.3 Средни (4.0-6.9): реакция в рамките на 5 дни; срок за прилагане на корекция 30 календарни дни. 5.2.4 Ниски (<4.0): реакция в рамките на 10 дни; срок за прилагане на корекция 60 календарни дни.“

От раздел „Управленски изисквания“, клауза на политиката 5.2.

За доставчик на облачни услуги това трябва да обхваща компоненти на хипервайзора, контейнерни образи, слоеве за оркестрация, приложно-програмни интерфейси (API), насочени към клиенти, CI/CD пайплайни, административни конзоли и библиотеки от трети страни. За MSP ключовият въпрос е дали вътрешните уязвимости са отделени от уязвимостите, управлявани от клиента, и дали договорите дефинират отговорността. За доставчик на център за данни обхватът може да включва системи за управление на сгради, системи за контрол на достъпа, платформи за мониторинг, инструменти за отдалечена оперативна поддръжка на място и мрежова инфраструктура.

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

Регистрирането, мониторингът и сегментацията правят инцидентите разследваеми

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

Корпоративната Политика за регистриране и мониторинг на Clarysec Logging and Monitoring Policy изисква обхванатите системи да генерират журналите, от които се нуждаят екипите за реагиране и одиторите:

„Всички обхванати системи трябва да генерират журнали, които записват: 6.1.1.1 Опити за автентикация и достъп на потребители 6.1.1.2 Дейности на привилегировани потребители 6.1.1.3 Промени в конфигурацията 6.1.1.4 Неуспешни опити за достъп или системни събития 6.1.1.5 Откривания на зловреден софтуер и предупреждения за сигурност 6.1.1.6 Външни комуникации и задействания на правила на защитната стена“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.1.1.

За МСП, които разчитат на външни доставчици, Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME добавя договорно изискване:

„Договорите трябва да изискват от доставчиците да съхраняват журнали най-малко 12 месеца и да предоставят достъп при поискване“

От раздел „Управленски изисквания“, клауза на политиката 5.5.1.3.

Сегментацията е също толкова важна. Network Security Policy-sme Network Security Policy-sme - SME посочва:

„Вътрешните мрежи трябва да бъдат сегментирани по функция (напр. финанси, гости, IoT, административни системи)“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.

Zenith Blueprint, във фазата „Контроли в действие“, стъпка 20, предоставя практическата одитна процедура за мрежова архитектура и сегментация. Той инструктира екипите да прегледат и документират мрежовата топология, да проверят правилата на защитната стена, конфигурациите на IPS/IDS и отдалечения достъп, да потвърдят, че групите за сигурност в облака и правилата за VPC или подмрежи съответстват на планираната архитектура, да изброят вътрешните и външните мрежови услуги и да валидират, че чувствителните системи не са достъпни от общи потребителски VLAN или мрежи за гости.

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

Сигурност на доставчиците: доставчикът също е клиент

Доставчиците на облачни услуги, MSP, MSSP и центрове за данни са доставчици на регулирани клиенти, но те също са клиенти на софтуерни доставчици, телекомуникационни оператори, доставчици на идентичност, SaaS платформи, хардуерни доставчици, подизпълнители и инфраструктурни оператори.

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

Корпоративната Политика за сигурност на трети страни и доставчици на Clarysec Third party and supplier security policy изисква контролиран достъп на трети страни:

„Всеки достъп на трети страни трябва да се журнализира и наблюдава и, когато е възможно, да се сегментира чрез бастионни сървъри, VPN или Zero Trust шлюзове.“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.3.2.

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME изразява минимално необходимия достъп с директна формулировка:

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

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.

Тези клаузи естествено се съпоставят с ISO/IEC 27001:2022 Annex A контроли 5.19, 5.20, 5.21 и 5.22. Те също подкрепят управлението на обработващи лични данни и подизпълнители по GDPR, прегледите на риска от трети страни по DORA и клиентските въпросници за одит.

Непрекъсваемост на дейността и устойчивост на центровете за данни: докажете допусканията

NIS2 Article 21 включва непрекъсваемост на дейността, управление на резервни копия, аварийно възстановяване и управление на кризи. DORA Articles 11 to 14 изискват политики за непрекъсваемост на ИКТ дейността, планове за реагиране и възстановяване, анализ на въздействието върху бизнеса, политики за архивиране, процедури за възстановяване, цели за възстановяване, тестване, прегледи след инцидент и кризисни комуникации за финансовите субекти.

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

Корпоративната Политика за непрекъсваемост на дейността и аварийно възстановяване на Clarysec Business Continuity Policy and Disaster Recovery Policy изисква ежегоден BIA и преглед след съществени промени:

„Анализът на въздействието върху бизнеса (BIA) трябва да се извършва поне веднъж годишно за всички критични бизнес звена и да се преглежда при съществени промени в системи, процеси или зависимости. Резултатите от BIA трябва да дефинират: 5.2.1. Максимално допустим период на прекъсване (MTD) 5.2.2. Целеви стойности за време за възстановяване (RTO) 5.2.3. Целеви точки за възстановяване (RPO) 5.2.4. Критични зависимости (системи, доставчици, персонал)“

От раздел „Управленски изисквания“, клауза на политиката 5.2.

В сценарий с център за данни BIA трябва да обхваща електрозахранващи линии, UPS, генератори, договори за гориво, охлаждане, пожарогасене, мрежови оператори, системи за физически достъп, отдалечена оперативна поддръжка на място, мониторинг, резервен хардуер и клиентски комуникационни канали. В облачен сценарий той трябва да обхваща региони, зони на наличност, репликация, неизменяемост на резервните копия, зависимости от идентичност, DNS, удостоверителни органи, API шлюзове и системи за поддръжка. В сценарий с MSP той трябва да обхваща инструменти за отдалечено управление, сейфове за привилегирован достъп, EDR конзоли, системи за билети, хранилища за документи и аварийни комуникации.

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

Практическа проследимост на риска при пробив в отдалечения достъп на MSP

Практическият семинар може да започне с един сценарий:

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

Създайте ред в Регистъра на риска и попълнете проследимостта.

След това актуализирайте Декларацията за приложимост. За всеки релевантен контрол от Annex A обяснете защо се прилага и коя тема по NIS2 подкрепя. Накрая съберете доказателства преди одит: отчети за прилагане на MFA, списъци с привилегировани акаунти, настройки за съхранение на журнали, статус на корекции за RMM, предупреждения от SIEM, записи за класификация на инциденти, одобрения за достъп на доставчици и резултати от настолни упражнения.

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

Интегрираната СУИС трябва да удовлетворява различни гледни точки за уверение, без да създава отделни пакети с доказателства за всяка рамка.

Тук Zenith Controls помага като ръководство за кръстосано съответствие. За контроли като 5.23, 5.24 и 8.8 то свързва очакванията за контроли по ISO/IEC 27001:2022 с темите по NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF и ISO 22301. Целта не е да се създават отделни програми за съответствие. Целта е една архитектура на доказателствата, маркирана по контрол, риск, регулаторен двигател и собственик.

Моделът на внедряване на Clarysec

За доставчиците на облачни услуги, MSP, MSSP и центрове за данни работата трябва да се развие в пет слоя.

Първо, потвърдете обхвата. Определете дали организацията и услугите попадат в обхвата на NIS2, кои правила на държавата членка се прилагат, дали Регламент за изпълнение 2024/2690 се прилага за категорията доставчик и дали клиентите налагат DORA, GDPR, NIST или секторно-специфични задължения.

Второ, изградете контекста на СУИС. Съгласно клаузи 4 и 5 на ISO/IEC 27001:2022 идентифицирайте заинтересованите страни, правните задължения, клиентските ангажименти, зависимостите от доставчици, границите на услугите и управленските отговорности.

Трето, извършете оценка и третиране на риска, използвайки принципите на ISO/IEC 27005:2022. Консолидирайте NIS2, DORA, GDPR, договорите, вътрешните политики и рисковете по услугите в един базов регистър на изискванията. Дефинирайте критерии за риск, собственици, вероятност, въздействие, варианти за третиране, избор на контроли и одобрения на остатъчния риск.

Четвърто, съпоставете контролите в Декларацията за приложимост. Използвайте Zenith Blueprint стъпки 13 и 14, за да проследите рисковете към контролите от Annex A и регулаторните очаквания. Използвайте Zenith Controls, за да разберете как контроли като 5.23, 5.24, 8.8, 5.20 и 5.30 се съпоставят между рамки и одитни гледни точки.

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

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

Регламент за изпълнение 2024/2690 по NIS2 не изисква хаос. Той изисква проследимост, собственост и доказателства.

Ако сте доставчик на облачни услуги, MSP, MSSP или оператор на център за данни, започнете с вашите услуги, клиенти, зависимости, сценарии за инциденти и задължения за доказателства. След това изпълнете структурирано упражнение за съпоставяне от NIS2 към ISO/IEC 27001:2022:

1. Потвърдете дали вашият субект и услуги попадат в обхвата.
2. Съпоставете темите от NIS2 и Регламента за изпълнение с обхвата на вашата СУИС.
3. Актуализирайте Регистъра на риска и Декларацията за приложимост.
4. Приложете политиките на Clarysec за използване на облачни услуги, сигурност на доставчици, регистриране, управление на уязвимости, реагиране при инциденти, мрежова сигурност и непрекъсваемост.
5. Използвайте Zenith Blueprint Zenith Blueprint стъпки 13, 14, 20 и 23, за да създадете проследимост и оперативни доказателства.
6. Използвайте Zenith Controls Zenith Controls, за да съпоставите кръстосано контролите по ISO/IEC 27001:2022 с очакванията по NIS2, DORA, GDPR, NIST и COBIT 2019.
7. Тествайте доказателствата чрез симулация на одит, преди клиент, регулатор или сертификационен одитор да ги поиска.

Clarysec може да ви помогне да надхвърлите съответствието по контролен списък и да изградите интегрирана СУИС, която издържа на натиска от NIS2, DORA, GDPR и клиентски одити. Изтеглете съответните инструменти на Clarysec, резервирайте семинар за съпоставяне или поискайте оценка на готовността за одит, за да превърнете регулаторната сложност в защитимо управление на сигурността и оперативна устойчивост.