Доказателства за технически и организационни мерки по член 32 от GDPR с ISO, NIS2 и DORA
Имейлът пристига във входящата поща на CISO с познатата тежест на сделка, която може да промени тримесечните резултати на компанията.
Голям корпоративен потенциален клиент иска доказателства за „технически и организационни мерки по член 32 от GDPR, съпоставени с ISO 27001:2022, NIS2 и DORA, когато е приложимо“. Междувременно правният екип е информирал съвета за отговорността на ръководството по NIS2 и очакванията на DORA за оперативна устойчивост. Указанието на съвета звучи просто: докажете съответствие, избегнете дублиране на работа и не превръщайте това в три отделни проекта.
Компанията има контроли. MFA е активирана. Резервните копия се изпълняват. Разработчиците извършват преглед на кода. Екипът по защита на данните поддържа записи на дейностите по обработване. Екипът по инфраструктура сканира за уязвимости. Доставчиците се преглеждат в процеса на възлагане и покупки. Но когато потенциалният клиент поиска доказателства, отговорът се разпада на фрагменти.
Отчетът от доставчика на услуги за идентичност е на едно място. Журналите за резервните копия са на друго. Регистърът на риска не е актуализиран след последното продуктово издание. Доказателствата за сигурността на доставчиците се намират в имейли от отдела за възлагане и покупки. Има бележки от настолни упражнения по реагиране при инциденти, но никой не може да докаже, че извлечените поуки са върнати обратно в третирането на риска. Съветът е одобрил разходи за сигурност, но одобрението не е свързано с ИКТ риск или с документирано решение за контрол.
Това е реалният проблем с техническите и организационните мерки по член 32 от GDPR, често наричани TOMs. Повечето организации не се провалят, защото нямат контроли. Те се провалят, защото не могат да докажат, че контролите са базирани на риска, одобрени, внедрени, наблюдавани и подобрявани.
Принципът на отчетност в GDPR прави това очакване изрично. Article 5 от GDPR изисква личните данни да бъдат защитени чрез подходяща сигурност срещу неразрешено или незаконосъобразно обработване и срещу случайна загуба, унищожаване или повреждане. Article 5(2) възлага на администратора отговорността да доказва съответствие. Определенията в GDPR също са съществени. Личните данни са широко понятие, обработването обхваща почти всяка операция с данни, псевдонимизацията е призната предпазна мярка, а нарушението на сигурността на личните данни включва случайно или незаконосъобразно унищожаване, загуба, изменение, неразрешено разкриване или достъп.
Следователно доказателственият файл по Article 32 не може да бъде папка с произволни екранни снимки. Той трябва да бъде жива система за контрол.
Подходът на Clarysec е да превърне техническите и организационните мерки по член 32 от GDPR в проследим доказателствен механизъм, изграден върху ISO/IEC 27001:2022 ISO/IEC 27001:2022, подсилен от управление на риска по ISO/IEC 27005:2022 и кръстосано съпоставен със задълженията по NIS2 и DORA, когато са приложими. Целта не е документация заради самата документация. Целта е организацията да бъде готова за одит, преди клиент, одитор, регулатор или член на съвета да зададе трудния въпрос.
Защо техническите и организационните мерки по член 32 от GDPR се провалят на практика
Article 32 често се разбира погрешно като списък с инструменти за сигурност: криптиране, резервни копия, журналиране, контрол на достъпа и реагиране при инциденти. Тези мерки са важни, но са защитими само когато са подходящи спрямо риска и са свързани с жизнения цикъл на личните данни.
За SaaS компания, която обработва данни за служители на клиенти, „използваме криптиране“ не е достатъчно. Одитор може да попита кои данни защитава криптирането, къде се изисква криптиране, как се управляват ключовете, дали резервните копия са криптирани, дали продукционни данни се маскират при тестване, кой може да заобикаля контролите и как се одобряват изключенията.
Корпоративната Политика за защита на данните и поверителност на Clarysec формулира оперативния принцип:
„Внедряване на технически и организационни мерки (TOMs), които защитават поверителността, целостта и наличността на личната информация (PII) през целия ѝ жизнен цикъл.“
Източник: Политика за защита на данните и поверителност, Цели, клауза на политиката 3.3. Политика за защита на данните и поверителност
Фразата „през целия ѝ жизнен цикъл“ е мястото, където много програми за технически и организационни мерки отслабват. Личните данни може да са защитени в продукционна среда, но да бъдат копирани в аналитични системи, журнали, експорти за поддръжка, тестови среди, резервни копия, платформи на доставчици и устройства на служители. Всяко местоположение създава риск за сигурността и поверителността.
GDPR Article 6 изисква правно основание за обработване, включително съгласие, договор, правно задължение, жизненоважни интереси, задача от обществен интерес или легитимни интереси. Когато данните се използват повторно за допълнителна цел, трябва да се вземат предвид съвместимостта и предпазни мерки като криптиране или псевдонимизация. При данни с по-висок риск тежестта за доказване нараства. GDPR Article 9 поставя строги ограничения върху специалните категории лични данни, като здравни данни, биометрични данни, използвани за идентификация, и друга чувствителна информация. Article 10 ограничава данните за присъди и нарушения.
За МСП Clarysec формулира третирането на риска на практически език:
„Контролите трябва да бъдат внедрени за намаляване на идентифицираните рискове, включително криптиране, анонимизация, сигурно унищожаване и ограничения на достъпа“
Източник: Политика за защита на данните и поверителност-sme, Третиране на риска и изключения, клауза на политиката 7.2.1. Политика за защита на данните и поверителност - SME
Това е силна базова линия за технически и организационни мерки. За да стане готова за одит, всяка контролна мярка трябва също да бъде свързана с риск, собственик, изискване на политика, доказателствен елемент и периодичност на прегледа.
ISO 27001:2022 е гръбнакът на доказателствата по Article 32
ISO 27001:2022 работи добре за GDPR Article 32, защото третира сигурността като система за управление, а не като отделен контролен списък. Стандартът изисква система за управление на информационната сигурност, или СУИС (ISMS), проектирана да запазва поверителността, целостта и наличността чрез управление на риска.
Първата критична стъпка е обхватът. Клаузи 4.1 до 4.4 на ISO 27001:2022 изискват организацията да разбира вътрешните и външните обстоятелства, да идентифицира заинтересованите страни и изискванията, да определи кои изисквания ще бъдат адресирани от СУИС и да дефинира обхвата на СУИС, включително интерфейси и зависимости с външни организации. За техническите и организационните мерки по Article 32 обхватът на СУИС трябва да отразява обработването на лични данни, задълженията към клиенти, обработващите лични данни, подизпълнителите по обработване, облачните платформи, дистанционната работа, функциите по поддръжка и продуктовите среди.
Втората стъпка е лидерството. Клаузи 5.1 до 5.3 изискват ангажимент на висшето ръководство, политика за информационна сигурност, ресурси, роли и отговорности и докладване на резултатите. Това е важно, защото GDPR Article 32, NIS2 и DORA разчитат на управление. Контрол без собственост, финансиране или преглед е слабо доказателство.
Корпоративната Политика за информационна сигурност на Clarysec прави това изрично:
„СУИС трябва да включва дефинирани граници на обхвата, методология за оценка на риска, измерими цели и документирани мерки, обосновани в Декларация за приложимост (SoA).“
Източник: Политика за информационна сигурност, Изисквания за внедряване на политиката, клауза на политиката 6.1.2. Политика за информационна сигурност
Същата политика определя очакването за доказателства:
„Всички внедрени контроли трябва да бъдат проверими при одит, подкрепени от документирани процедури и съхранени доказателства за функционирането им.“
Източник: Политика за информационна сигурност, Изисквания за внедряване на политиката, клауза на политиката 6.6.1.
След това клаузи 6.1.1 до 6.1.3 на ISO 27001:2022 изискват оценка на риска, третиране на риска, Декларация за приложимост, одобрение на остатъчния риск и отчетност на собственика на риска. Клауза 6.2 изисква измерими цели. Клаузи 7.5, 9.1, 9.2, 9.3 и 10.2 изискват документирана информация, мониторинг, вътрешен одит, преглед от ръководството и коригиращо действие.
За GDPR Article 32 това създава защитима структура.
| Доказателствен въпрос по GDPR Article 32 | Доказателствен отговор по ISO 27001:2022 |
|---|---|
| Как решихте кои технически и организационни мерки са подходящи? | Критерии за оценка на риска, регистър на риска, оценяване на вероятност и въздействие, план за третиране на риска |
| Кои контроли се прилагат и защо? | Декларация за приложимост с обосновки за включване и изключване |
| Кой одобри остатъчния риск? | Одобрение от собственик на риска и формално потвърждение от ръководството |
| Функционират ли контролите? | Журнали, заявки, записи от прегледи, резултати от тестове, отчети от мониторинг |
| Преглеждат ли се контролите? | Доклади от вътрешен одит, протоколи от преглед от ръководството, журнал на коригиращите действия |
| Отчитат ли се рисковете за личните данни? | Записи за рискове, свързани със защитата на данните, изисквания за поверителност в обхвата, DPIA или еквивалентна оценка, когато е приложимо |
ISO/IEC 27005:2022 подсилва тази структура. Той препоръчва организациите да идентифицират изисквания от Annex A на ISO 27001:2022, регулации, договори, секторни стандарти, вътрешни правила и съществуващи контроли, след което да ги включат в оценката и третирането на риска. Той също така изисква критерии за риска и критерии за приемане, които отчитат правни, регулаторни, оперативни, доставчически, технологични и човешки фактори, включително поверителност.
Политиката за управление на риска на Clarysec е пряко съгласувана с това:
„Трябва да се поддържа формален процес за управление на риска в съответствие с ISO/IEC 27005 и ISO 31000, обхващащ идентифициране, анализ, оценяване, третиране, наблюдение и комуникация на риска.“
Източник: Политика за управление на риска, Изисквания за управление, клауза на политиката 5.1. Политика за управление на риска
За МСП същото изискване става просто и приложимо:
„Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.“
Източник: Политика за управление на риска-sme, Изисквания за управление, клауза на политиката 5.1.2. Политика за управление на риска - SME
Това изречение е бърз тест за готовност за одит. Ако даден риск няма собственик или план за третиране, той все още не е готов като доказателство.
Мостът на Clarysec: риск, SoA, контроли и регулации
Clarysec Zenith Blueprint: 30-стъпкова пътна карта за одитор Zenith Blueprint третира съответствието като работа по проследимостта. В етапа „Управление на риска“ Step 13 се фокусира върху планиране на третирането на риска и Декларация за приложимост. Той обяснява, че организациите трябва да съпоставят контролите с рисковете, да добавят препратки към контролите от Annex A в записите за третиране на риска, да правят кръстосани препратки към външни регулации и да получават одобрение от ръководството.
Zenith Blueprint е директен относно ролята на SoA:
„SoA на практика е свързващ документ: той свързва вашата оценка/третиране на риска с реалните контроли, които имате. Като го попълвате, също проверявате дали не сте пропуснали някои контроли.“
Източник: Zenith Blueprint: 30-стъпкова пътна карта за одитор, етап „Управление на риска“, Step 13: Планиране на третирането на риска и Декларация за приложимост (SoA). Zenith Blueprint
Step 14 от Zenith Blueprint добавя слоя за кръстосани регулаторни препратки. Той препоръчва организациите да документират как изискванията на GDPR, NIS2 и DORA се покриват от политики и контроли. За GDPR той акцентира върху защитата на личните данни в оценките и третирането на риска, включително криптиране като техническа мярка и реагиране при нарушения като част от контролната среда. За NIS2 той подчертава оценката на риска, мрежовата сигурност, контрола на достъпа, обработването на инциденти и непрекъсваемостта на дейността. За DORA той насочва към управление на ИКТ риска, реагиране при инциденти, докладване и надзор върху ИКТ трети страни.
Това е същността на метода на Clarysec: една СУИС, един регистър на риска, една SoA, една библиотека с доказателства, множество резултати по съответствие.
Zenith Controls: Ръководство за кръстосано съответствие Zenith Controls подкрепя това, като помага на организациите да използват темите за контроли от ISO/IEC 27002:2022 ISO/IEC 27002:2022 като опорни точки за кръстосано съответствие. За GDPR Article 32 най-важните опорни точки често включват „Поверителност и защита на PII“, контрол 5.34; „Независим преглед на информационната сигурност“, контрол 5.35; и „Използване на криптография“, контрол 8.24.
| Опорна точка за контрол по ISO/IEC 27002:2022 в Zenith Controls | Защо е важна за техническите и организационните мерки по Article 32 | Примери за доказателства |
|---|---|---|
| 5.34 Поверителност и защита на PII | Свързва контролите за информационна сигурност с обработването на лични данни и задълженията за поверителност | Инвентаризация на данните, оценка на риска за поверителността, график за сроковете за съхранение, записи за DPA, прегледи на правата за достъп |
| 5.35 Независим преглед на информационната сигурност | Доказва обективно уверение, одитируемост и подобрение | Доклад от вътрешен одит, външна оценка, журнал на коригиращите действия, преглед от ръководството |
| 8.24 Използване на криптография | Защитава поверителността и целостта на данните при пренос, в покой и в резервни копия | Стандарт за криптиране, записи за управление на ключове, доказателства за дисково криптиране, TLS конфигурация, криптиране на резервни копия |
NIS2 превръща техническите и организационните мерки във въпрос на киберсигурност на ниво съвет
Много организации третират техническите и организационните мерки по GDPR като отговорност на екипа по защита на данните. NIS2 променя разговора.
NIS2 се прилага за много средни и големи субекти в изброени сектори, а в някои случаи — независимо от размера. Обхванатите цифрови и технологични сектори включват доставчици на облачни услуги, доставчици на центрове за данни, мрежи за доставка на съдържание, доставчици на DNS услуги, TLD регистри, доставчици на удостоверителни услуги, доставчици на публични електронни съобщителни услуги, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, онлайн пазари, търсачки и платформи за социални мрежи. Приложимостта за SaaS и технологични МСП зависи от сектора, размера, определянето от държава членка и системното или трансграничното въздействие.
NIS2 Article 20 възлага отговорност за киберсигурността на управителните органи. Те трябва да одобряват мерките за управление на риска в киберсигурността, да упражняват надзор върху внедряването и да преминават обучение. Съществени субекти могат да бъдат санкционирани с административни глоби от най-малко 10 милиона евро или най-малко 2 процента от световния годишен оборот. Важни субекти могат да бъдат санкционирани с глоби от най-малко 7 милиона евро или най-малко 1,4 процента.
NIS2 Article 21 е пряко релевантен за техническите и организационните мерки по Article 32, защото изисква подходящи и пропорционални технически, оперативни и организационни мерки. Тези мерки трябва да отчитат съвременното технологично ниво, европейските и международните стандарти, разходите, експозицията, размера, вероятността, степента на сериозност и общественото или икономическото въздействие. Изискваните области включват анализ на риска, политики за сигурност, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване и разработка, обработване на уязвимости, оценка на ефективността, киберхигиена, обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите, MFA или непрекъсната автентикация и сигурни комуникации, когато е подходящо.
NIS2 Article 23 добавя поетапно докладване на инциденти: ранно предупреждение в рамките на 24 часа, уведомление за инцидент в рамките на 72 часа, междинни актуализации при поискване и окончателен доклад не по-късно от един месец след 72-часовото уведомление. Ако нарушение на сигурността на личните данни също се квалифицира като значим инцидент по NIS2, вашият доказателствен файл трябва да подкрепя както решенията за докладване по защита на данните, така и тези по киберсигурност.
DORA повишава изискванията за финансова устойчивост и ИКТ доставчици
DORA се прилага от 17 януари 2025 г. и създава правила за финансовия сектор относно цифровата оперативна устойчивост. Той обхваща управление на ИКТ риска, докладване на съществени инциденти, свързани с ИКТ, тестване на оперативната устойчивост, споделяне на информация за киберзаплахи и уязвимости, риск от ИКТ трети страни, договорни изисквания към ИКТ доставчици, надзор върху критични доставчици на ИКТ услуги от трети страни и надзорни механизми.
За финансови субекти, които също са идентифицирани по националните правила за NIS2, DORA действа като секторно-специфичен правен акт на Съюза за припокриващите се задължения за управление на риска в киберсигурността и докладване на инциденти. На практика обхванатите финансови субекти следва да приоритизират DORA за тези припокриващи се области, като поддържат координация с компетентните органи по NIS2 и CSIRT, когато е релевантно.
За доказателствата по GDPR Article 32 DORA е важна по два начина. Първо, финтех дружествата може да попадат пряко в обхвата като финансови субекти, включително кредитни институции, платежни институции, доставчици на услуги по предоставяне на информация за сметка, дружества за електронни пари, инвестиционни посредници, доставчици на услуги за криптоактиви, места за търговия и доставчици на услуги за колективно финансиране. Второ, доставчици на SaaS, облачни услуги, данни, софтуер и управлявани услуги може да бъдат третирани от финансови клиенти като доставчици на ИКТ услуги от трети страни, защото DORA дефинира ИКТ услугите широко.
DORA Article 5 изисква управление и вътрешни контроли за управление на ИКТ риска, като управителният орган определя, одобрява, надзирава и остава отговорен за механизмите за ИКТ риск. Article 6 изисква документирана рамка за управление на ИКТ риска, включително стратегии, политики, процедури, ИКТ протоколи и инструменти за защита на информацията и ИКТ активите. Article 17 изисква процес за управление на инциденти, свързани с ИКТ, който обхваща откриване, управление, уведомяване, записване, първопричина, индикатори за ранно предупреждение, класификация, роли, комуникации, ескалация и реагиране. Article 19 изисква съществени инциденти, свързани с ИКТ, да се докладват на компетентните органи.
DORA Articles 28 and 30 превръщат риска от ИКТ трети страни в регулирана област на контрол. Финансовите субекти остават отговорни за съответствието, когато използват ИКТ услуги. Те се нуждаят от стратегия за риск от трети страни, договорни регистри, оценки на критичността, надлежна проверка, преглед на риска от концентрация, права на одит и инспекция, основания за прекратяване, стратегии за изход и договорни разпоредби, обхващащи местонахождение на данните, наличност, автентичност, целост, поверителност, съдействие при инциденти, възстановяване, нива на обслужване и сътрудничество с органите.
За Article 32 това означава, че доставчиците са част от файла с технически и организационни мерки. Не можете да докажете сигурност на обработването, ако критични обработващи лични данни, облачни платформи, доставчици на аналитични услуги, инструменти за поддръжка и ИКТ доставчици не са контролирани.
Практическо едноседмично изграждане на доказателства по Article 32
Силен доказателствен файл започва с един ясен рисков сценарий.
Използвайте този пример: „Неразрешен достъп до клиентски лични данни в продукционното приложение.“
Създайте или актуализирайте записа за риск. Включете описание, вероятност, въздействие, оценка, собственик и план за третиране. Назначете като собственик ръководителя на инженерния екип, мениджъра по сигурността или еквивалентна отчетна роля. Оценете вероятността въз основа на модела на достъп, експонираната атакуваема повърхност, известните уязвимости и предходните инциденти. Оценете въздействието въз основа на обема лични данни, чувствителността, клиентските договори, последиците по GDPR и възможното въздействие върху услугата по NIS2 или DORA.
Изберете мерки за третиране като MFA за привилегирован достъп, ролеви контрол на достъпа, тримесечни прегледи на правата за достъп, криптиране в покой, TLS, сканиране за уязвимости, журналиране, алармиране, сигурно резервно копиране, процедури за реагиране при инциденти и маскиране на данни в непроизводствени среди.
След това съпоставете риска със SoA. Добавете препратки към ISO/IEC 27002:2022, като 5.34 „Поверителност и защита на PII“, 8.24 „Използване на криптография“, 5.15 „Контрол на достъпа“, 5.18 „Права за достъп“, 8.13 „Резервно копиране на информацията“, 8.15 „Журналиране“, 8.16 „Дейности по мониторинг“, 8.8 „Управление на технически уязвимости“, 8.25 „Жизнен цикъл на сигурна разработка“ и 8.10 „Изтриване на информация“, когато е приложимо. Добавете бележки, които показват как тези контроли подкрепят GDPR Article 32, NIS2 Article 21 и управлението на ИКТ риска по DORA, когато е релевантно.
За регулаторното съпоставяне поддържайте имената на контролите точни и избягвайте принудително създаване на фалшива еквивалентност.
| Контрол по ISO/IEC 27002:2022 | Име на контрола | Защо е включен | Регулаторно съпоставяне |
|---|---|---|---|
| 8.24 | Използване на криптография | Защитава поверителността и целостта на личните данни при пренос, в покой и в резервни копия | GDPR Art. 32; NIS2 Art. 21(2)(h) |
| 5.20 | Отразяване на информационната сигурност в договорите с доставчици | Гарантира, че задълженията на доставчиците за сигурност са договорно определени и приложими | Контроли за обработващи по GDPR; NIS2 Art. 21(2)(d); DORA Art. 28 и Art. 30 |
| 5.24 | Планиране и подготовка за управление на инциденти по информационна сигурност | Установява готовност за откриване, ескалация, оценяване и докладване | Отчетност при нарушения по GDPR; NIS2 Art. 23; DORA Art. 17 и Art. 19 |
| 8.13 | Резервно копиране на информацията | Подкрепя наличността, възстановяването и устойчивостта след прекъсване или загуба на данни | GDPR Art. 32; NIS2 Art. 21(2)(c); очаквания на DORA за ИКТ непрекъсваемост |
| 8.10 | Изтриване на информация | Подкрепя сигурно унищожаване, прилагане на срокове за съхранение и минимизиране на данните | Ограничение на съхранението по GDPR и Art. 32; договорни изисквания на клиенти |
Сега изградете доказателствената папка. Политиката за одит и мониторинг на съответствието за МСП на Clarysec дава просто правило:
„Всички доказателства трябва да се съхраняват в централизирана одитна папка.“
Източник: Политика за одит и мониторинг на съответствието-sme, Изисквания за внедряване на политиката, клауза на политиката 6.2.1. Политика за одит и мониторинг на съответствието - SME
За този един рисков сценарий папката трябва да съдържа:
| Доказателствен елемент | Какво да се съхранява | Защо е важно |
|---|---|---|
| Запис за риск | Описание на риска, собственик, оценка, план за третиране и решение за остатъчния риск | Доказва риск-базиран избор на технически и организационни мерки |
| Извадка от SoA | Приложими контроли и бележки по GDPR, NIS2, DORA | Показва проследимост от риск към контрол |
| Преглед на достъпа | Прегледани потребители, решения, премахвания и изключения | Доказва функционирането на контрола на достъпа |
| Отчет за MFA | Експорт, показващ прилагане на MFA за привилегирован достъп | Подкрепя доказателства за автентикация |
| Доказателства за криптиране | Конфигурационен запис, архитектурна бележка или запис за управление на ключове | Подкрепя поверителността и целостта |
| Запис за уязвимости | Последно сканиране, заявки за отстраняване и приети изключения | Подкрепя намаляване на техническия риск |
| Доказателство за журналиране | Примерно SIEM събитие, правило за алармиране и настройка за съхранение | Подкрепя откриване и разследване |
| Тест на резервно копие | Резултат от тест за възстановяване и запис за покритие на резервните копия | Подкрепя наличност и устойчивост |
| Упражнение за инцидент | Бележки от настолно упражнение, тестов журнал на инциденти или запис за извлечени поуки | Подкрепя готовност за реагиране |
| Одобрение от ръководството | Протоколи от срещи, формално потвърждение или запис за приемане на риска | Подкрепя отчетност и пропорционалност |
Доказателствата за достъп не трябва да спират до екранни снимки. Политиката за контрол на достъпа за МСП добавя полезно оперативно изискване:
„ИТ мениджърът трябва да документира резултатите от прегледа и коригиращите действия.“
Източник: Политика за контрол на достъпа-sme, Изисквания за управление, клауза на политиката 5.5.3. Политика за контрол на достъпа - SME
Доказателствата за резервни копия трябва да доказват възстановимост, а не само успешно изпълнени задачи. Политиката за архивиране и възстановяване за МСП посочва:
„Тестове за възстановяване се провеждат поне на тримесечна база и резултатите се документират за проверка на възстановимостта“
Източник: Политика за архивиране и възстановяване-sme, Изисквания за управление, клауза на политиката 5.3.3. Политика за архивиране и възстановяване - SME
Това ви дава завършен доказателствен цикъл: регулацията създава изискването, рискът обяснява защо то е важно, SoA избира контрола, политиката определя функционирането, а съхранените доказателства доказват, че контролът работи.
Контроли в действие: превръщане на политиката в оперативно доказателство
Етапът „Контроли в действие“ на Zenith Blueprint, Step 19, се фокусира върху техническата проверка. Той препоръчва преглед на съответствието на сигурността на крайните точки, управление на идентичността и достъпа, конфигурации за автентикация, сигурност на контрола върху изходния код, капацитет и наличност, управление на уязвимостите и корекциите, сигурни базови конфигурации, защита от зловреден софтуер, изтриване и минимизиране на данните, маскиране и тестови данни, DLP, архивиране и възстановяване, резервираност, журналиране и мониторинг и синхронизация на времето.
За техническите и организационните мерки по GDPR Article 32 Step 19 е мястото, където абстрактният език на контролите става доказателство. Силен доказателствен файл трябва да показва, че:
- Криптирането на крайни устройства е активирано и се наблюдава.
- Привилегированите потребители имат MFA.
- Процесите за постъпващи, преместващи се и напускащи служители са съгласувани със записите на човешките ресурси.
- Служебните акаунти са документирани и ограничени.
- Хранилищата за код са с контролиран достъп и се извършва сканиране за тайни.
- Сканиранията за уязвимости се провеждат и се проследяват до отстраняване.
- Продукционни данни не се копират небрежно в тестови среди.
- Политиките за сигурно изтриване и срокове за съхранение се прилагат.
- DLP предупрежденията се преглеждат.
- Тестовете за възстановяване на резервни копия доказват възстановимост.
- Журналите са централизирани, съхранявани и преглеждани.
- Синхронизацията на времето подкрепя надеждно разследване на инциденти.
Ключът е връзката. Доклад за корекции без препратка към риск, политика и SoA е ИТ артефакт. Доклад за корекции, свързан с GDPR Article 32, NIS2 Article 21, управление на ИКТ риска по DORA и план за третиране на риска по ISO 27001:2022, е доказателство, готово за одит.
Един доказателствен файл, множество одитни перспективи
Едни и същи доказателства за технически и организационни мерки ще бъдат четени различно от различните заинтересовани страни. Преглеждащ по защита на данните може да се фокусира върху лични данни, необходимост, пропорционалност и отчетност. Одитор по ISO 27001 може да се фокусира върху обхват, третиране на риска, SoA и доказателства за функциониране. Орган по NIS2 може да се фокусира върху надзор от ръководството, мерки по Article 21 и готовност за докладване по Article 23. Надзорен орган по DORA или финансов клиент може да се фокусира върху управление на ИКТ риска, тестване на устойчивостта и зависимости от трети страни.
Clarysec използва Zenith Controls като ръководство за кръстосано съответствие за този превод.
| Аудитория | Какво ще попитат | Как трябва да отговорят доказателствата |
|---|---|---|
| Преглеждащ по защита на данните за GDPR | Подходящи ли са техническите и организационните мерки спрямо риска за личните данни и може ли да се докаже отчетност? | Регистър на риска, инвентаризация на данните, контроли за поверителност, записи за съхранение, ограничения на достъпа, доказателства за криптиране и записи за оценка на нарушения |
| Одитор по ISO 27001:2022 | Дали СУИС е с определен обхват, базирана на риска, внедрена, наблюдавана и подобрявана? | Обхват, методология за риска, SoA, вътрешен одит, преглед от ръководството и коригиращи действия |
| Преглеждащ по NIS2 | Одобрени ли са мерките за киберсигурност, пропорционални ли са и покриват ли областите по Article 21? | Одобрение от съвета, политики за сигурност, обработване на инциденти, непрекъсваемост, риск, свързан с доставчици, обучение, MFA и управление на уязвимостите |
| Надзорен орган по DORA или финансов клиент | Управлява ли се ИКТ рискът, тества ли се и устойчива ли е средата, включително рискът от ИКТ трети страни? | Рамка за ИКТ риск, стратегия за устойчивост, процес за инциденти, доказателства от тестване, регистър на доставчиците и планове за изход |
| Оценител, ориентиран към NIST | Може ли организацията да идентифицира, защитава, открива, реагира и възстановява чрез повторяеми доказателства? | Инвентаризация на активите и данните, защитни контроли, записи от мониторинг, журнали за реагиране и тестове за възстановяване |
| Одитор по COBIT 2019 или ISACA | Дали управлението е отчетно, измервано и съгласувано с корпоративните цели? | Роли, управленско докладване, апетит за риск, показатели за изпълнение, резултати от уверение и действия за подобрение |
Това предотвратява дублирана работа по съответствие. Вместо да изграждате отделни доказателствени пакети за GDPR, NIS2 и DORA, изградете един доказателствен файл за контролите и маркирайте всеки елемент според задълженията, които подкрепя.
Чести пропуски в програмите за технически и организационни мерки по Article 32
Най-честият пропуск е „осиротяването“ на контролите. Компанията има контрол, например криптиране, но не може да обясни кой риск третира, коя политика го изисква, кой е негов собственик или как се преглежда.
Вторият пропуск са слабите доказателства за доставчици. По GDPR обработващите лични данни и подизпълнителите по обработване са важни. По NIS2 сигурността на веригата на доставки е част от управлението на риска в киберсигурността. По DORA рискът от ИКТ трети страни е регулирана област с регистри, надлежна проверка, договорни предпазни мерки, права на одит и планиране на изход. Таблица с доставчици не е достатъчна, ако критичните зависимости не са оценени по риск и контролирани.
Третият пропуск са доказателствата за инциденти. Организациите често имат план за реагиране при инциденти, но нямат доказателство, че класификацията, ескалацията, докладването към органи и комуникацията с клиенти са тествани. NIS2 и DORA повишават очакванията тук, а оценката на нарушение на сигурността на личните данни по GDPR трябва да бъде интегрирана в същия работен поток.
Четвъртият пропуск са доказателствата за резервни копия. Успешна задача за архивиране не доказва възстановимост. Документиран тест за възстановяване доказва.
Петият пропуск е прегледът от ръководството. Техническите и организационните мерки по Article 32 трябва да са пропорционални на риска. Ако ръководството никога не преглежда рискове, инциденти, проблеми с доставчици, бюджет, одитни констатации и остатъчен риск, пропорционалността става трудна за доказване.
Финалният инструментариум, готов за одит
Етапът „Одит, преглед и подобрение“ на Zenith Blueprint, Step 30, предоставя финалния контролен списък за готовност. Той включва обхват и контекст на СУИС, подписана политика за информационна сигурност, документи за оценка и третиране на риска, SoA, политики и процедури по Annex A, записи за обучения, оперативни записи, доклад от вътрешен одит, журнал на коригиращите действия, протоколи от преглед от ръководството, доказателства за непрекъснато подобрение и записи за задължения по съответствие.
Корпоративната Политика за одит и мониторинг на съответствието на Clarysec посочва целта на тази дисциплина:
„Да се генерират защитими доказателства и одитна следа в подкрепа на регулаторни запитвания, съдебни производства или искания от клиенти за потвърждение на контролите.“
Източник: Политика за одит и мониторинг на съответствието, Цели, клауза на политиката 3.4. Политика за одит и мониторинг на съответствието
Зрял доказателствен файл за техническите и организационните мерки по Article 32 трябва да включва:
| Категория доказателства | Минимално съдържание, готово за одит |
|---|---|
| Управление | Обхват на СУИС, одобрение на политики, роли, цели, протоколи от преглед от ръководството |
| Риск | Методология за риска, регистър на риска, план за третиране, одобрения на остатъчния риск |
| SoA | Приложими контроли, изключения, обосновки и регулаторно съпоставяне |
| Защита на данните | Инвентаризация на данните, контроли за PII, доказателства за съхранение, DPIA или оценка на риска за поверителността, когато е приложимо |
| Технически контроли | MFA, прегледи на правата за достъп, криптиране, управление на уязвимостите, журналиране, мониторинг и доказателства за сигурна разработка |
| Устойчивост | Покритие на резервните копия, тестове за възстановяване, планове за непрекъсваемост, упражнения за инциденти и показатели за възстановяване |
| Уверение за доставчици | Регистър на доставчиците, надлежна проверка, договорни клаузи, мониторинг, права на одит и планиране на изход |
| Подобрение | Вътрешни одити, коригиращи действия, извлечени поуки и прегледи на ефективността на контролите |
Следващи стъпки: изградете доказателства за технически и организационни мерки по Article 32 с Clarysec
Ако трябва да докажете технически и организационни мерки по GDPR Article 32, не започвайте със събиране на произволни екранни снимки. Започнете с проследимост.
- Дефинирайте обхвата на СУИС и границите на обработването на лични данни.
- Идентифицирайте изискванията по GDPR, NIS2, DORA, договорите и клиентите.
- Изградете критерии за риска чрез ISO/IEC 27005:2022 и одобрен от ръководството апетит за риск.
- Създайте или актуализирайте регистъра на риска.
- Съпоставете всяко третиране с контролите по ISO 27001:2022 и SoA.
- Използвайте Zenith Controls за кръстосани препратки на контроли за поверителност, криптография, доставчици, инциденти и независим преглед спрямо очакванията за съответствие.
- Следвайте Zenith Blueprint Step 13 и Step 14, за да свържете рискове, контроли и регулаторни задължения.
- Използвайте Zenith Blueprint Step 19, за да проверите техническите контроли в действие.
- Използвайте Zenith Blueprint Step 30, за да сглобите финалния доказателствен файл, готов за одит.
- Съхранявайте всички доказателства централизирано, етикетирайте ги по риск и тема на контрол и поддържайте коригиращите действия видими.
Clarysec може да ви помогне да преобразувате GDPR Article 32 от неясно задължение по съответствие в защитима, риск-базирана доказателствена система, съгласувана с ISO 27001:2022, NIS2 и DORA.
Започнете със Zenith Blueprint, подсилете го с политики на Clarysec и използвайте Zenith Controls, за да направите всяка техническа и организационна мярка проследима, тестируема и готова за одит.
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
