От сканиране към доказателства: ISO 27001:2022, NIS2, DORA

Понеделник е, 08:16. В таблото за мониторинг на сървър за приложение, достъпен от интернет, току-що се е появила критична уязвимост за отдалечено изпълнение на код. Екипът по инфраструктура съобщава, че корекцията от доставчика е налична. Собственикът на приложението предупреждава, че сървърът поддържа клиентски работен процес с критично значение за приходите. Правният отдел пита дали евентуална експлоатация може да задейства задължения за докладване по NIS2, DORA или GDPR. CISO Мария отваря одитния календар и вижда реалния проблем: надзорният одит по ISO 27001:2022 започва следващата седмица, прегледът на готовността за NIS2 вече е в ход, а голям клиент от финтех сектора е поискал доказателства по DORA.

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

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

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

Подходът на Clarysec е ясен: не третирайте управлението на уязвимостите като месечен технически ритуал. Третирайте го като управляван работен поток за доказателства.

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

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

Одиторът ще зададе различни въпроси:

• Засегнатият актив попадаше ли в обхвата?
• Кой е собственикът на актива и на бизнес услугата?
• Оценена ли беше уязвимостта според експонирането, експлоатируемостта, въздействието върху бизнеса и чувствителността на данните?
• Завършено ли беше отстраняването в определения срок?
• Ако отстраняването беше забавено, кой прие остатъчния риск?
• Внедрена ли беше корекцията чрез контролиран процес за управление на промените?
• Проверена ли беше корекцията чрез повторно сканиране или техническо валидиране?
• Съхранени ли бяха доказателствата и прегледани ли бяха от ръководството?

Папка с експорти от скенера рядко отговаря на тези въпроси. При одит по ISO 27001:2022 одиторът проверява дали СУИС функционира така, както е проектирана. По NIS2 органите на управление трябва да одобряват и упражняват надзор върху мерките за управление на риска за киберсигурността. По DORA финансовите субекти се нуждаят от документирана рамка за управление на ИКТ риска, жизнен цикъл за инциденти, тестване на устойчивостта и контроли за ИКТ риска от трети страни. По GDPR въпросът е дали подходящи технически и организационни мерки са защитили личните данни и дали отчетността може да бъде доказана.

ISO/IEC 27001:2022 клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, заинтересованите страни, изискванията и обхвата на СУИС. Управлението на уязвимости и корекции не може да бъде проектирано изолирано. То трябва да отразява клиентски договори, регулатори, зависимости от облачни услуги, външно възложени ИКТ услуги, задължения за защита на данните и критични услуги.

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

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

Регулаторният натиск зад доказателствата за корекции

Съвременната регулация на киберсигурността е по-малко толерантна към неформално прилагане на корекции.

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

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

DORA създава пряко приложим набор от правила за цифрова оперативна устойчивост за финансови субекти от 17 януари 2025 г. Той обхваща управление на ИКТ риска, докладване на значителни ИКТ инциденти, тестване на оперативната устойчивост, споделяне на разузнавателна информация за киберзаплахи, управление на ИКТ риска от трети страни и надзор върху критични доставчици на ИКТ услуги от трети страни. Articles 5 и 6 поставят управлението на ИКТ риска под отговорността на органа на управление и изискват документирана, интегрирана и редовно преглеждана рамка за управление на ИКТ риска. Article 8 засилва необходимостта от идентифициране на бизнес функции, поддържани от ИКТ, информационни активи, ИКТ активи и зависимости. Articles 17 до 20 изискват откриване, записване, класификация, ескалация, докладване, комуникация, отстраняване и извличане на поуки за ИКТ-свързани инциденти. Articles 28 до 30 изискват ИКТ рискът от трети страни да бъде контролиран чрез регистри, надлежна проверка, договорни предпазни мерки, права на одит, планиране на изход и надзор.

За финансови субекти, обхванати от DORA, DORA по правило заменя еквивалентните задължения на NIS2 за управление на риска и докладване. Но NIS2 остава важна за координацията в екосистемата и за субекти извън обхвата на DORA. За доставчици на SaaS, MSP и MSSP, обслужващи финансови клиенти, практическата реалност е пряка: клиентите може да изискват вашите доказателства за уязвимости, за да изпълнят собствените си задължения по DORA.

GDPR добавя още един слой. Articles 2 и 3 могат да се прилагат за организации, установени в ЕС, и за организации извън ЕС, които предлагат стоки или услуги на лица в ЕС или наблюдават тяхното поведение. Article 5 изисква защита на личните данни и отчетност за съответствието. Article 4 определя нарушение на сигурността на личните данни като инцидент по сигурността, водещ до случайна или незаконосъобразна загуба, унищожаване, промяна, неразрешено разкриване на или достъп до лични данни. Забавена корекция на база данни, платформа за идентичност или клиентски портал може да се превърне във въпрос на отчетност по поверителността.

От политика към доказване

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

За корпоративни среди Политиката за управление на уязвимости и корекции изрично свързва техническото прилагане на корекции с междурегулаторното съответствие:

Тази политика подпомага съответствието с ISO/IEC 27001 Приложение A, контрол 8.8 и указанията на ISO/IEC 27002, и адресира регулаторните изисквания по DORA Article 8, NIS2 Article 21, GDPR Article 32 и домейните DSS и APO на COBIT 2019.

От раздел „Цел“.

Същата политика задава управленското очакване за основния доказателствен артефакт:

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

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

Тя определя и честотата на сканиране:

Всички системи трябва да се сканират най-малко ежемесечно; активите с висок риск или външно експонираните активи трябва да се сканират ежеседмично.

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

И предотвратява превръщането на спешното прилагане на корекции в неконтролирана техническа дейност:

Всички дейности по отстраняване трябва да се координират чрез процеса за управление на промените (съгласно P5 - Change Management Policy), за да се гарантира стабилност и запазване на одитната следа.

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

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

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

От раздел „Цели“, клауза 3.4 на политиката.

След това тя дефинира журнала за корекции като доказателство за одит:

Трябва да се поддържа журнал за корекции и той да се преглежда по време на одити и дейности по реагиране при инциденти

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

И уточнява минималното съдържание:

Журналите трябва да включват името на устройството, приложената актуализация, датата на прилагане на корекцията и причината за всяко забавяне

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

За спешно експониране към интернет политиката за МСП задава измеримо изискване:

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

От Политика за управление на уязвимости и корекции за МСП, раздел „Изисквания за прилагане на политиката“, клауза 6.1.1 на политиката.

Тези клаузи превръщат техническата работа в доказателства. Политиката дефинира очакванията. Регистърът записва констатациите. Тикетът възлага работата. Записът за промяна контролира внедряването. Журналът за корекции доказва действието. Регистърът на риска улавя изключенията. Протоколите от прегледа доказват надзора.

Моделът на Clarysec, ориентиран към доказателства

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

В Zenith Blueprint: 30-стъпкова пътна карта за одитора фазата „Контроли в действие“, стъпка 19: „Технологични контролни мерки I“, разглежда управлението на уязвимостите като повторяем контрол, а не като теоретично изискване:

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

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

Контролът не е свързан със съвършенство, а с наличието на организиран, прозрачен и отчетен процес.

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

Zenith Blueprint също предупреждава, че одиторите ще разгледат тази област задълбочено:

Това е контрол с висок приоритет за одиторите и те обикновено навлизат в детайли. Очаквайте въпроси колко често системите се коригират, какъв процес следвате при обявяване на zero-day уязвимост и кои системи са най-трудни за коригиране.

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

Картиране на контролите на ISO 27002 към доказателства за одит

Zenith Controls: Ръководство за междурегулаторно съответствие действа като компас за междурегулаторно съответствие, като картира контролите на ISO/IEC 27002:2022 и показва как те се отнасят към одитните очаквания. За управлението на уязвимости и корекции три контрола на ISO/IEC 27002:2022 формират оперативния триъгълник.

ISO/IEC 27002:2022 control 8.8, Управление на техническите уязвимости, е централният контрол. Той е превантивен, подпомага поверителността, целостта и наличността, съгласува се с концепциите за киберсигурност Identify и Protect и се свързва с управление на заплахи и уязвимости.

ISO/IEC 27002:2022 control 8.32, Управление на промените, също е превантивен. Той свързва прилагането на корекции с контролирано внедряване, тестване, одобрение, връщане към предишно състояние и одитируемост.

ISO/IEC 27002:2022 control 5.36, Съответствие с политики, правила и стандарти за информационна сигурност, гарантира, че процесът не е опционален или зависим от индивидуален героизъм. Той свързва управлението на уязвимостите със спазване на политиките, уверение и надзор.

Това картиране избягва често срещан одитен провал. Сигурността казва: „Приложихме корекцията.“ Операциите казват: „Внедрихме я.“ Съответствието казва: „Не можем да докажем последователността.“ Картирана верига от доказателства дава на трите екипа една и съща история.

Веригата от доказателства, която одиторите очакват

Защитима верига от доказателства за управление на уязвимостите има седем етапа.

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

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

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

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

За МСП Политиката за одит и мониторинг на съответствието за МСП дефинира проверката на техническите контроли в практически термини:

Проверка на технически контроли (напр. статус на резервни копия, конфигурация на контрола на достъпа, записи за корекции)

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

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

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

Ежеседмичното външно сканиране на Мария идентифицира CVE-2026-12345 на платежен API шлюз, достъпен от интернет. Скенерът я оценява като критична. Услугата обработва клиентска идентичност и транзакционни метаданни, така че са възможни последствия по GDPR и DORA. Шлюзът е собственост на екипа по платформено инженерство, но корекцията изисква кратко прекъсване.

Ето одитно готовия работен поток.

1. Създаване на запис в регистъра на уязвимостите

Екипът по сигурността записва констатацията в централния регистър:

• Идентификатор на констатацията: VULN-2026-0142
• Източник: ежеседмично външно сканиране
• Дата и час на откриване
• Актив: api-gw-prod-01
• Собственик: Платформено инженерство
• Експониране: достъпен от интернет
• Контекст на данните: клиентска идентичност и транзакционни метаданни
• Степен на сериозност: критична
• SLA: 72 часа или по-строг срок според политиката
• Тикет: SEC-4821
• Запис за промяна: CHG-10988
• Статус: планирано отстраняване

2. Триаж според бизнес и регулаторния контекст

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

ISO/IEC 27005:2022 клаузи 7.1 до 7.4 подпомагат идентифициране на риска, собственост, последици, вероятност и приоритизиране. Клаузи 8.2 до 8.6 подпомагат избора на третиране, определянето на контролите, връзката със SoA, планирането на третирането и одобрението на остатъчния риск.

3. Откриване на контролирана аварийна промяна

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

Това пряко подпомага ISO/IEC 27002:2022 control 8.32 и корпоративното изискване на политиката отстраняването да се координира чрез управление на промените.

4. Прилагане на корекцията и актуализиране на журнала за корекции

Журналът за корекции записва името на устройството, приложената актуализация, датата на прилагане на корекцията и причината за забавяне, ако има такава. Ако прилагането на корекцията беше забавено, екипът би документирал компенсиращи контроли, като правила на защитна стена за уеб приложения (WAF), временни ограничения на достъпа, засилено регистриране, изолация или разширен мониторинг.

5. Проверка и закриване

Сигурността сканира повторно API шлюза. Уязвимостта вече не се появява. Тикетът се актуализира с доказателства от чисто сканиране, версия на корекцията, времеви маркер на внедряването и връзка към записа за промяна. Статусът в регистъра на уязвимостите се променя на „Закрито, проверено“.

6. Преглед на въздействието върху докладването

Ако няма експлоатация и няма прекъсване на услугата, може да не се задейства докладване на инцидент по NIS2 или DORA. Ако бъдат открити индикатори за компрометиране (IOC), процесът за инциденти трябва да класифицира въздействието и ескалацията. По NIS2 значим инцидент може да изисква ранно предупреждение и поетапно докладване. По DORA значителен ИКТ-свързан инцидент изисква класификация и докладване чрез приложимия процес към компетентния орган.

7. Включване на изводите в прегледа от ръководството

В края на месеца прегледът от CISO отбелязва, че уязвимостта е открита чрез ежеседмично външно сканиране, отстранена е в рамките на SLA, проверена е чрез повторно сканиране и е закрита без инцидент. Ако подобни проблеми се повтарят, планът за третиране може да включва сигурни базови конфигурации, автоматизирано внедряване на корекции, ескалация към доставчик или модернизация на приложението.

Когато одитор попита за CVE-2026-12345, Мария може да представи подготвен пакет вместо имейли и екранни снимки.

Това е одитна готовност. Не защото организацията няма уязвимости, а защото има контрол.

Един набор доказателства, множество задължения

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

За ISO 27001:2022 доказателствата подпомагат риск-базираната СУИС, внедряването на контролите от Приложение A, декларацията за приложимост, плановете за третиране на риска, вътрешния одит и непрекъснатото подобрение. Ако ISO/IEC 27002:2022 control 8.8 е приложим в SoA, организацията трябва да може да покаже правната, регулаторната, рисковата или бизнес обосновка. Тази обосновка често включва NIS2 Article 21, задълженията на DORA за ИКТ риск, отчетност по GDPR, клиентски договори и потребности от оперативна устойчивост.

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

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

За GDPR същите доказателства подпомагат отчетността по Article 5 и рисковата позиция по отношение на сигурността, очаквана по Article 32. Ако уязвимост доведе до неразрешен достъп, промяна, загуба или разкриване на лични данни, хронологията на уязвимостта, записите за корекции, журналите за мониторинг и бележките от оценката на нарушението стават съществени.

За COBIT 2019 и уверение в стил ISACA управлението на уязвимостите се оценява чрез оперативна сигурност, мониторинг на контролите, подпомагане на промените и управленска отчетност. Препратките за междурегулаторно съответствие в Zenith Blueprint посочват COBIT 2019 DSS05.04 и BAI09.02, както и очакванията за уверение по ITAF относно управление на уязвимости, прилагане на корекции и сигурно управление на промените.

Поддържащите ISO стандарти укрепват оперативния модел. ISO/IEC 27005:2022 подпомага оценката и третирането на риска. ISO/IEC 27035:2023 подпомага реагирането при инциденти, когато уязвимостите бъдат експлоатирани. ISO/IEC 30111 подпомага процесите за обработване на уязвимости. ISO/IEC 29147 подпомага оповестяването на уязвимости и съобщенията. ISO/IEC 27017 подпомага управлението на уязвимости в облачни услуги. ISO 22301 подпомага планирането на непрекъсваемостта, когато технически уязвимости биха могли да прекъснат бизнес услуги.

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

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

Политиката казва какво трябва да се случи. Оперативните доказателства показват какво действително се е случило. Записите от преглед показват, че ръководството е знаело, поставяло е въпроси и е действало.

Чести причини управлението на корекции да не издържи одит

Повечето констатации не са причинени от липса на скенер. Те са причинени от прекъсната проследимост.

Инвентарът на активите е непълен.
Ако скенер открие активи, които липсват от CMDB или регистъра на активите, собствеността и въздействието върху бизнеса не могат да бъдат оценени надеждно. Това подкопава обхвата, оценката на риска и третирането по ISO 27001:2022.

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

Критичните констатации нямат доказателства за SLA.
Политиката може да казва, че критичните уязвимости се отстраняват в рамките на три дни. Одитният въпрос е дали записите доказват, че това се е случило.

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

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

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

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

Одитният пакет на Clarysec за уязвимости

За предстоящ преглед на готовността по ISO 27001:2022, NIS2 или DORA Clarysec помага на организациите да съставят одитен пакет за управление на уязвимости и корекции със следното:

• Политика за управление на уязвимости и корекции, включително обхват, роли, честота на сканиране, SLA за корекции и правила за изключения
• Извлечение от инвентара на активите, показващо системите в обхвата, собствениците, критичността и експонирането
• Последни вътрешни и външни отчети от сканиране за уязвимости
• Централен регистър на уязвимостите с отворени, закрити и изключени позиции
• Журнали за корекции, показващи устройство, актуализация, дата на корекция и причини за забавяне
• Записи за промени за извадка от критични и високи уязвимости
• Доказателства за повторни сканирания или валидиране след отстраняване
• Одобрения на изключения и остатъчен риск за забавени или некоригируеми системи
• Процес за мониторинг на съобщения за сигурност от доставчици, библиотеки и облачни услуги
• Ежемесечни протоколи от преглед от CISO или ръководството
• Съпоставка към задълженията по ISO 27001:2022, NIS2, DORA, GDPR и COBIT 2019
• Резултати от вътрешен одит или проверка на технически контроли

В Zenith Blueprint, фазата „Одит, преглед и подобрение“, стъпка 24, Clarysec подчертава проследимостта между декларацията за приложимост, регистъра на риска и плана за третиране на риска:

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

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

30-дневен спринт за готовност

Ако одитът ви наближава, не започвайте с пренаписване на всичко. Започнете с бързо изграждане на доказателства.

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

Преминете от сканирания към защитими доказателства

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

Zenith Blueprint, Zenith Controls, Политиката за управление на уязвимости и корекции, Политиката за управление на уязвимости и корекции за МСП, Политиката за одит и мониторинг на съответствието и Политиката за одит и мониторинг на съответствието за МСП на Clarysec предоставят структурата за изграждане на този работен поток за доказателства.

Ако вашата организация се подготвя за сертификация по ISO 27001:2022, готовност за NIS2, цифрова оперативна устойчивост по DORA, надлежна проверка от клиенти или вътрешен одит, започнете с един въпрос:

Може ли всяка критична уязвимост да бъде проследена от сканирането до закриването?

Ако отговорът е „не“, Clarysec може да ви помогне да изградите регистъра, набора от политики, картата за междурегулаторно съответствие, пакета за преглед от ръководството и работния поток с одитно готови доказателства, който превръща техническото сканиране в защитимо управление.