CVD за NIS2 и DORA: карта на доказателствата по ISO 27001

В 08:17 във вторник пощенската кутия за сигурност получава съобщение от независим изследовател. Темата е спокойна, почти учтива: „Потенциално превземане на акаунт във вашия клиентски портал.“ Съдържанието е по-притеснително. Изследователят твърди, че верижна уязвимост във вашето SaaS приложение позволява на един тенант да получи достъп до фактурните записи на друг тенант. Прикачено е proof-of-concept доказателство, криптирано с публикувания ви PGP ключ.

За Мария, новия CISO във FinanTechSaaS, моментът не би могъл да бъде по-неподходящ. Компанията ѝ току-що е подписала голям договор с водеща банка в ЕС. Екипът на клиента за надлежна проверка вече е поискал „Политика за координирано разкриване на уязвимости“ и доказателства за внедряване, с изрични препратки към NIS2 и DORA. Компанията има имейл адрес security@, но той се наблюдава от един разработчик. Няма формален регистър за приемане, няма дефиниран SLA за валидиране, няма път за ескалация към ръководството и няма одитна следа.

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

Първият е оперативен. Реална ли е уязвимостта? Експлоатируема ли е в продукционна среда? Злоупотребява ли вече някой с нея?

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

Третият е доказателствен. Шест месеца по-късно одитор по ISO/IEC 27001:2022, надзорен орган във финансовия сектор, екип за клиентско уверение или комитет по вътрешен одит може да попита: „Покажете ни как беше обработена тази уязвимост.“

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

Clarysec разглежда CVD като интегриран модел на контрол, а не като самостоятелна входяща кутия. В Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint обработването на уязвимости е във фазата „Контроли в действие“, стъпка 19: „Технологични контроли I“, където указанието е ясно: организациите не следва пасивно да архивират констатациите за уязвимости, а трябва да ги триажират, възлагат и проследяват до приключване. Същият стандарт важи и за външни разкривания. Ако някой ви съобщи как вашата услуга може да откаже, истинският въпрос става: можете ли да докажете, че сте получили, оценили, приоритизирали, отстранили, комуникирали и извлекли поуки от това?

Защо CVD вече е въпрос на ниво управителен съвет съгласно NIS2 и DORA

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

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

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

NIS2 Article 20 също изрично въвежда отчетност на ръководството. Управителните органи трябва да одобряват мерките за управление на риска за киберсигурността, да упражняват надзор върху внедряването и да преминават обучение. За CVD програма това означава, че управителният съвет или висшето ръководство трябва да разбира канала за докладване, екипа за реагиране при уязвимости, сроковете за валидиране, очакванията за отстраняване, зависимостите от доставчици и тригерите за докладване на инциденти.

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

Доклад за уязвимост може да започне като техническа констатация, да се превърне в събитие по сигурността, да ескалира в инцидент, да задейства оценка за нарушение на сигурността на личните данни по GDPR, да изисква действие от доставчик и по-късно да се появи в Декларация за приложимост по ISO/IEC 27001:2022. Затова CVD трябва да бъде проектиран като единен оперативен модел за сигурност, съответствие, инженеринг, правни въпроси, защита на личните данни, снабдяване и управление.

Основата в ISO 27001: от разкриване до доказателства за ISMS

ISO/IEC 27001:2022 предоставя на CISO и ръководителите по съответствието системата за управление, която прави CVD одитируем.

Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешните и външните обстоятелства, изискванията на заинтересованите страни, границите на ISMS и зависимостите с други организации. Именно тук NIS2, DORA, GDPR, клиентските договори, задълженията към доставчици и ангажиментите за разкриване на уязвимости влизат в ISMS.

Клаузи 5.1 до 5.3 създават отчетност на ръководството. Висшето ръководство трябва да съгласува информационната сигурност със стратегическата посока, да осигури ресурси, да възложи отговорности и да гарантира, че ISMS постига планираните резултати. За CVD това означава назначаване на екип за реагиране при уязвимости, дефиниране на правомощия за приемане на остатъчен риск и ескалиране на уязвимости с високо въздействие към ръководството.

Клаузи 6.1.1 до 6.1.3 предоставят механизма за риск. Организацията трябва да дефинира критерии за риск, да оценява рисковете за информационната сигурност, да възлага собственици на риска, да избира опции за третиране на риска, да сравнява контролите с Приложение A, да изготви Декларация за приложимост и да получи одобрение за остатъчния риск. Клаузи 8.1 до 8.3 след това изискват оперативен контрол, планирани промени, контрол върху процеси, предоставяни отвън, оценки на риска през планирани интервали или след значителни промени и доказателства за резултатите от третирането.

В Zenith Blueprint, фазата „Управление на риска“, стъпка 13, Декларацията за приложимост е описана като нещо повече от таблица за съответствие:

„SoA на практика е свързващ документ: тя свързва вашата оценка/третиране на риска с реалните контроли, с които разполагате.“
Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Управление на риска“, стъпка 13: „Планиране на третирането на риска и Декларация за приложимост (SoA)“ Zenith Blueprint

За координирано разкриване на уязвимости SoA трябва да свързва регулаторни задължения, бизнес риск, контроли от Приложение A, клаузи на политики и оперативни доказателства.

Целта не е да се създават паралелни силози за съответствие. CVD политиката трябва да бъде контролиран процес в ISMS, който едновременно подпомага сертификация по ISO/IEC 27001:2022, съответствие с NIS2, готовност по DORA, клиентско уверение и операции по сигурността.

Базова политика: какво трябва да съдържа вашата CVD политика

Първият видим контрол е публичният канал за разкриване. Изследователите, клиентите, доставчиците и партньорите трябва да знаят къде да докладват уязвимости и как да защитят чувствителните доказателства.

Политика за координирано разкриване на уязвимости на Clarysec Политика за координирано разкриване на уязвимости предоставя корпоративната основа:

„Публични канали за разкриване: Организацията трябва да поддържа ясен канал за докладване на уязвимости, като например отделен имейл адрес за контакт по сигурността (например security@company.com) или уеб формуляр. Тази информация трябва да бъде публикувана на страницата за сигурност на уебсайта на компанията заедно с публичния PGP ключ на организацията, за да се осигури подаване в криптиран вид.“
Източник: Политика за координирано разкриване на уязвимости, изисквания за внедряване, клауза 6.1

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

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

„Триаж и потвърждение: При получаване на доклад VRT трябва да го регистрира и да изпрати потвърждение до докладващото лице в рамките на 2 работни дни, като присвои референтен номер за проследяване. VRT трябва да извърши предварителна оценка на тежестта, например чрез CVSS точкова оценка, и да валидира проблема, включително със съдействие от ИТ и екипите за разработка, когато е необходимо, в целеви срок от 5 работни дни. Критичните уязвимости, като тези, които позволяват отдалечено изпълнение на код или съществено нарушение на сигурността на данните, трябва да бъдат обработвани приоритетно.“
Източник: Политика за координирано разкриване на уязвимости, изисквания за внедряване, клауза 6.4

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

За МСП Clarysec използва същата логика с пропорционално внедряване. Политика за изискванията за сигурност на приложенията за МСП Политика за изискванията за сигурност на приложенията - МСП изисква организациите да:

„посочат задължения за разкриване на уязвимости, срокове за реагиране и прилагане на корекции.“
Източник: Политика за изискванията за сигурност на приложенията за МСП, управленски изисквания, клауза 5.3.2

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

Работен процес за приемане на CVD: от имейл на изследовател до запис за решение

Добър работен процес за приемане е достатъчно прост, за да работи под натиск, и достатъчно пълен, за да удовлетвори одитор. Той трябва да започва с отделен канал като security@[company], уеб формуляр или публикуван файл security.txt. Маршрутът за подаване трябва да позволява криптирани доказателства, засегнат продукт или крайна точка, стъпки за възпроизвеждане, данни за контакт с докладващото лице, предпочитан момент за разкриване и всякакви индикации за експониране на данни или активна експлоатация.

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

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

1. Приемане: докладът се получава чрез публичния канал и се регистрира автоматично или ръчно.
2. Потвърждение: VRT отговаря в рамките на 2 работни дни и присвоява референтен номер за проследяване.
3. Валидиране: техническият екип възпроизвежда проблема, потвърждава засегнатите системи и извършва предварителна точкова оценка на тежестта.
4. Оценка на събитието: VRT определя дали уязвимостта е само слабост, събитие по информационна сигурност или инцидент.
5. Ескалация: проблеми с висока или критична тежест се изпращат към собственици на система, CISO, функцията по защита на личните данни, правния отдел, доставчици и ръководството според необходимостта.
6. Отстраняване: отговорният екип прилага корекция, смекчаване, компенсиращ контрол или временно ограничение.
7. Приключване: VRT проверява корекцията, комуникира с докладващото лице, актуализира файла с доказателства и записва извлечените поуки.

Clarysec картографира тази оперативна стъпка към контрол A.5.25 от ISO/IEC 27002:2022, „Оценка и решение по събития по информационна сигурност“, и контрол A.8.8, „Управление на технически уязвимости“, чрез Zenith Controls: The Cross-Compliance Guide Zenith Controls. За A.5.25 Zenith Controls обяснява, че оценката на събитията е триажната функция между необработените предупреждения от мониторинга и формалното обработване на инциденти, като използва журнали, прагове и критерии за решение, за да определи ескалацията. За A.8.8 Zenith Controls свързва техническото управление на уязвимости със защита от зловреден софтуер, управление на конфигурацията, управление на промените, сигурност на крайните точки, разузнаване за заплахи, мониторинг, сигурна разработка, оценка на събитията и реагиране при инциденти.

Един откъс от Zenith Controls е особено полезен, когато се подозира активна експлоатация:

„Разузнаването за заплахи информира кои уязвимости се експлоатират активно и насочва приоритизацията на прилагането на корекции.“
Източник: Zenith Controls: The Cross-Compliance Guide, контрол 8.8 от ISO/IEC 27002:2022, връзка с контрол 5.7 „Разузнаване за заплахи“ Zenith Controls

Това е важен управленски въпрос. Тежестта не е само CVSS. Уязвимост със средна оценка, активно експлоатирана срещу вашия сектор, може да изпревари теоретичен критичен проблем в неекспонирана тестова система.

Кога уязвимостта се превръща в инцидент

Не всеки доклад за уязвимост е инцидент. Липсваща заглавка за сигурност в тестова среда не е същото като експлоатирано заобикаляне на оторизация, което разкрива клиентски фактури. Но всеки достоверен доклад за уязвимост трябва да преминава през контролна точка за решение относно инцидент.

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

DORA Articles 17 to 20 изискват финансовите субекти да откриват, управляват, записват, класифицират, ескалират, уведомяват и комуникират инциденти, свързани с ИКТ, и значими киберзаплахи. Съществените инциденти, свързани с ИКТ, трябва да бъдат ескалирани към висшето ръководство и управителния орган. Може да се изисква комуникация с клиенти, когато са засегнати финансови интереси.

За МСП културата на докладване трябва да бъде също толкова ясна. Политика за реагиране при инциденти за МСП на Clarysec Политика за реагиране при инциденти - МСП гласи:

„Персоналът трябва да докладва всяка подозрителна дейност или потвърден инцидент на incident@[company] или устно на управител (GM) или доставчика на ИТ услуги.“
Източник: Политика за реагиране при инциденти за МСП, изисквания за прилагане на политиката, клауза 6.2.1

В Zenith Blueprint, фаза „Контроли в действие“, стъпка 16: „Контроли, свързани с хора II“, принципът е още по-прост:

„При съмнение — докладвай.“
Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Контроли в действие“, стъпка 16: „Контроли, свързани с хора II“ (A.6.5 to A.6.8)

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

Отстраняване, прилагане на корекции и компенсиращи контроли

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

Политика за координирано разкриване на уязвимости задава корпоративното очакване:

„План за отстраняване: За всички потвърдени уязвимости трябва да бъде разработен план за отстраняване или смекчаване. Прилагането на корекцията трябва да бъде приоритизирано според тежестта. Например критичните уязвимости трябва да бъдат отстранени или смекчени в рамките на 14 дни, когато това е приложимо, или по-рано, когато се установи активна експлоатация, докато проблемите с по-ниска тежест трябва да бъдат обработени в разумен срок. Когато пълното отстраняване се забави, трябва да бъдат внедрени компенсиращи контроли или временни мерки за смекчаване, като деактивиране на уязвима функционалност или засилване на мониторинга.“
Източник: Политика за координирано разкриване на уязвимости, изисквания за внедряване, клауза 6.6

За дисциплината при прилагане на корекции в МСП Политика за управление на уязвимости и корекции за МСП Политика за управление на уязвимости и корекции - МСП гласи:

„Критичните корекции трябва да бъдат приложени в рамките на 3 дни от публикуването им, особено за интернет-достъпни системи“
Източник: Политика за управление на уязвимости и корекции за МСП, изисквания за прилагане на политиката, клауза 6.1.1

Тези срокове не си противоречат. Корекция от доставчик за интернет-достъпна система може да изисква много бързо внедряване. Уязвимост в продукт, която изисква промени в кода, регресионно тестване, координация с клиенти и поетапно издание, може да изисква план за отстраняване с междинни смекчаващи мерки. Ключовото е решението да бъде документирано, да има собственик на риска и да бъде одобрено, когато остава остатъчен риск.

Практическият ход на случая изглежда така:

1. Изследовател докладва заобикаляне на оторизация в API за клиентско фактуриране.
2. VRT регистрира CVD-2026-014 с времеви маркер и потвърждава в рамките на 2 работни дни.
3. Екипът по сигурността на продукта валидира дефекта за 24 часа и определя висока тежест поради достъп до данни между тенанти.
4. Функцията по защита на личните данни извършва оценка за нарушение по GDPR, защото фактурните записи може да съдържат лични данни.
5. Мениджърът по инциденти открива оценка на събитие съгласно контрол A.5.25 от ISO/IEC 27002:2022.
6. Собственик на система деактивира уязвимата крайна точка чрез временен флаг за функционалност.
7. Инженерингът създава спешна корекция съгласно контрол A.8.32 от ISO/IEC 27002:2022, „Управление на промените“.
8. Добавят се правила за мониторинг за индикатори за експлоатация, свързани с A.8.15, „Журнализиране“, и A.8.16, „Дейности по мониторинг“.
9. CISO информира висшето ръководство, защото проблемът е високорисков.
10. VRT координира с изследователя повторното тестване и времето за разкриване.
11. Собственикът на риска одобрява приключването само след проверочно тестване и преглед на въздействието върху клиентите.
12. SoA, Регистърът на риска, билетът, журналите, уведомлението до ръководството и извлечените поуки се актуализират.

Това е разликата между „поправихме го“ и „можем да докажем, че го управлявахме“.

Зависимости от доставчици и облачни услуги: скритата точка на отказ

Много провали в CVD всъщност са прикрити провали на доставчици. Уязвимостта може да засяга SaaS компонент, облачна услуга, доставчик на управлявана сигурност, платежен шлюз, брокер за автентикация, библиотека с отворен код, екип за външна разработка или подизпълнител.

NIS2 Article 21 изисква сигурност на веригата на доставки, включително отношенията с преки доставчици и доставчици на услуги. Мерките за веригата на доставки трябва да отчитат уязвимости на доставчици, качество на продуктите, практики за киберсигурност и процедури за сигурна разработка.

DORA Articles 28 to 30 навлизат по-задълбочено за финансовите субекти. Те изискват рискът от трети страни в областта на ИКТ да се управлява като част от рамката за ИКТ риск, с регистри на договори за ИКТ услуги, разграничение между критични и важни функции, надлежна проверка преди сключване на договор, договорни изисквания за сигурност, съдействие при инциденти, сътрудничество с органи, права на одит, права за прекратяване и стратегии за изход. Финансовите субекти остават изцяло отговорни за съответствие с DORA дори когато използват доставчици от трети страни в областта на ИКТ.

Политика за сигурност на трети страни и доставчици за МСП на Clarysec Политика за сигурност на трети страни и доставчици - МСП включва просто правило за ескалация:

„Трябва незабавно да уведомява GM за всяко нарушение на сигурността, промяна или инцидент“
Източник: Политика за сигурност на трети страни и доставчици за МСП, роли и отговорности, клауза 4.4.3

За корпоративни договори с доставчици Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, препоръчва включване на задължения за поверителност, отговорности за контрол на достъпа, технически и организационни мерки, срокове за докладване на инциденти, права на одит, контроли за подизпълнители и разпоредби при приключване на договора. В него се посочва:

„Важно е те да съществуват и да са разбрани и приети и от двете страни.“
Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Контроли в действие“, стъпка 23: „Организационни контроли“ (5.19 to 5.37)

Готовността на доставчиците за CVD трябва да отговаря на тези въпроси:

• Публикува ли доставчикът канал за докладване на уязвимости?
• Дефинирани ли са в договора срокове за уведомяване за уязвимости?
• Докладват ли се критичните уязвимости на доставчика без неоправдано забавяне?
• Свързани ли са слабостите, които засягат клиентите, със задължения за съдействие при инциденти?
• Може ли доставчикът да предостави доказателства за отстраняване или съобщения за сигурност?
• Прехвърлени ли са задълженията за уязвимости към подизпълнителите?
• Има ли стратегия за изход, ако отстраняването е недостатъчно?

Тук NIS2, DORA и ISO/IEC 27001:2022 се срещат. Управлението на уязвимости на доставчици не е отметка в процеса по снабдяване. То е част от оперативната устойчивост.

Картографиране на доказателства за ISO 27001, NIS2, DORA, GDPR и COBIT

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

Политика за одит и мониторинг на съответствието за МСП на Clarysec Политика за одит и мониторинг на съответствието - МСП улавя детайл, който много екипи пропускат:

„Метаданните (напр. кой ги е събрал, кога и от коя система) трябва да бъдат документирани.“
Източник: Политика за одит и мониторинг на съответствието за МСП, изисквания за прилагане на политиката, клауза 6.2.3

Екранна снимка на коригиран сървър е слабо доказателство, ако никой не знае кой я е заснел, кога, от коя система и как тя се свързва с уязвимостта. Билет с времеви маркери, резултат от скенер, заявка за сливане, одобрение на промяна, журнали за внедряване, заявка за мониторинг, потвърждение от повторно тестване и метаданни е много по-силен.

По-подробна матрица за проследимост помага при клиентска надлежна проверка и вътрешен одит.

Различните одитори ще тестват един и същ процес през различни призми.

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

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

Рецензент по GDPR ще се фокусира върху личните данни. Бяха ли включени лични данни? Имаше ли неоторизиран достъп, загуба, изменение или разкриване? Бяха ли ясни ролите на администратор и обработващ лични данни? Беше ли оценен прагът за нарушение? Бяха ли релевантни предпазни мерки като шифроване, контрол на достъпа, журнализиране и минимизиране?

Одитор по COBIT 2019 или ISACA ще се фокусира върху управлението, отчетността, резултатността и увереността. Той ще търси дефинирана собственост, показатели, ескалация, цели на контролите, надзор от ръководството и проследяване на изключения. Просрочена критична уязвимост не е само технически проблем. Тя е управленски проблем, освен ако не е формално ескалирана и приета като риск.

Оценител, ориентиран към NIST, ще мисли в категориите Identify, Protect, Detect, Respond и Recover. Той ще очаква собственост върху активи, идентифициране на уязвимости, приоритизация, защитна промяна, откриване на експлоатация, координация на реагирането и валидиране на възстановяването.

Предимството на интегрирания CVD модел е, че една и съща доказателствена основа може да подкрепи всички тези прегледи.

Месечният контролен цикъл: показатели, които ръководството може да използва

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

„VRT трябва да поддържа журнал за разкриване на уязвимости, който проследява всеки доклад от получаването до приключването. Журналът трябва да се преглежда ежемесечно, за да се гарантира своевременно придвижване на отворените елементи. Просрочените елементи трябва да се ескалират.“
Източник: Политика за координирано разкриване на уязвимости, мониторинг и одит, клауза 9.1

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

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

Изградете процеса преди да пристигне сериозният доклад

Най-лошият момент за проектиране на координирано разкриване на уязвимости е след като изследовател вече е публикувал вашата слабост или критичен банков клиент е спрял внедряването. NIS2, DORA, GDPR, ISO/IEC 27001:2022, очакванията за устойчивост в стил NIST и управлението по COBIT 2019 сочат в една и съща посока: разкриването на уязвимости трябва да бъде планирано, да има собственик, да се тества, да се доказва и да се подобрява.

Започнете с тези пет действия:

1. Приемете или адаптирайте Политика за координирано разкриване на уязвимости.
2. Изградете работния процес за приемане и триаж чрез Zenith Blueprint, особено стъпка 13 за проследимост на SoA, стъпка 16 за култура на докладване, стъпка 19 за техническо управление на уязвимости и стъпка 23 за споразумения с доставчици.
3. Картографирайте работния процес чрез Zenith Controls, с фокус върху контролите A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 и A.8.32 от ISO/IEC 27002:2022.
4. Добавете клаузи, готови за МСП, от Политика за реагиране при инциденти за МСП, Политика за управление на уязвимости и корекции за МСП, Политика за сигурност на трети страни и доставчици за МСП, Политика за изискванията за сигурност на приложенията за МСП и Политика за одит и мониторинг на съответствието за МСП, когато пропорционалността е важна.
5. Проведете настолно упражнение, което симулира доклад от изследовател, засягащ лични данни и компонент, хостван при доставчик, след което тествайте потвърждение, триаж, класификация на инцидент, прилагане на корекции, комуникация с клиенти, събиране на доказателства и ескалация към ръководството.

Clarysec може да ви помогне да превърнете това в работеща CVD политика, регистър за приемане, карта на доказателствата по ISO/IEC 27001:2022, дърво за решения по NIS2 и DORA, модел за ескалация към доставчици и контролен пакет, готов за одит. Целта е проста: когато пристигне следващият доклад за уязвимост, вашият екип не трябва да импровизира. Той трябва да действа уверено, с доказателства и контрол.