Разузнавателна информация за заплахи по ISO 27001 за NIS2 и DORA
В 07:42 във вторник сутринта CISO на европейска финтех компания получава четири съобщения още преди кафето.
Първото е предупреждение от национален CERT, че уязвимост в отдалечения достъп се експлоатира активно. Второто е бюлетин от доставчик, който потвърждава, че засегнатият компонент се използва в управлявана услуга за прехвърляне на файлове. Третото е уведомление от услуга за управлявано откриване и реагиране (MDR), което отчита необичаен изходящ трафик от непроизводствена подмрежа. Четвъртото е от CFO: „Това засяга ли нашия пакет за готовност по DORA и трябва ли да уведомим някого по NIS2?“
Това е предизвикателството при разузнавателната информация за заплахи през 2026 г. Не става дума за събиране на още потоци от данни. Става дума за доказване, че релевантната разузнавателна информация за киберзаплахи се получава, валидира, насочва, обработва и превръща в доказателства за риск, откриване, уязвимости, инциденти, доставчици и управителен орган.
Много организации вече са абонирани за препоръки от доставчици, предупреждения на CISA, актуализации на ENISA, уведомления от национални CERT, бюлетини на ISAC, уведомления за сигурност от доставчици на облачни услуги, CVE потоци, MDR отчети, бази данни за експлоатируемост и мониторинг на тъмната мрежа. Въпреки това, когато пристигне реално предупреждение, екипите все още реагират на пожар. SOC пише правило за откриване. Инфраструктурният екип търси в инвентари на активите, които може да не са актуални. Екипът по съответствие пита дали събитието засяга NIS2 или DORA. Ръководството иска ясен отговор още преди организацията да знае дали уязвимият компонент е в продукционна среда.
Проблемът не е липсата на данни. Проблемът е липсата на одитируем оперативен модел.
Поток с информация за заплахи, който никой не използва, не е контролна мярка. Предупреждение за уязвимост, което не променя приоритета за прилагане на корекции, не е доказателство. Уведомление от доставчик, което никога не достига до регистъра на риска, не е сигурност на веригата на доставки. Предупреждение от CSIRT, което не актуализира мониторинга, триажа на инциденти или управленското докладване, е просто шум във входящата поща.
Подходът на Clarysec е ясен: разузнавателната информация за заплахи трябва да се превърне в операционна система за решения за риск. Тя трябва да бъде вградена в обхвата на СУИС, оценката на риска, Декларацията за приложимост, процедурите за реагиране при инциденти, триажа на уязвимости, регистрирането и мониторинга, управлението на доставчици, управленското докладване и пакета с доказателства за одит.
Защо разузнавателната информация за заплахи вече е контролна мярка на ниво управителен орган
NIS2 промени тона на управлението на киберсигурността. В нейния обхват попадат много SaaS доставчици, доставчици на облачни услуги, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, организации за цифрова инфраструктура и доставчици на цифрови услуги като съществени или важни субекти в зависимост от сектора, размера и определянето от държавата членка.
NIS2 Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки за управление на рисковете. Те включват анализ на риска, управление на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурност при придобиване, разработка и поддръжка, включително обработване и оповестяване на уязвимости, оценка на ефективността, базова киберхигиена и обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите и MFA или непрекъсната автентикация, когато е приложимо.
NIS2 Article 20 също изисква управителните органи да одобряват мерките за управление на риска в киберсигурността, да упражняват надзор върху внедряването и да преминават обучение. За съществените субекти максималната административна глоба може да достигне най-малко 10 милиона евро или 2 процента от годишния световен оборот, в зависимост от това коя стойност е по-висока. За важните субекти тя може да достигне най-малко 7 милиона евро или 1,4 процента.
За разузнавателната информация за заплахи въпросът на ниво управителен орган става: как знаем, че нововъзникващите заплахи променят нашите контролни мерки, преди да се превърнат в инциденти?
DORA добавя още един слой за финансовите субекти и съответните външни доставчици на ИКТ услуги. Тя се прилага от 17 януари 2025 г. и изисква надеждна, всеобхватна и добре документирана рамка за управление на ИКТ риска, интегрирана в общата система за управление на риска. Рамката на DORA очаква организациите да идентифицират и класифицират бизнес функции и активи, поддържани от ИКТ, да защитават и предотвратяват, да откриват аномална дейност, да реагират и да се възстановяват, да управляват резервни копия и възстановяване, да извличат поуки от ИКТ инциденти, да комуникират по време на кризи и да управляват ИКТ риска от трети страни.
DORA също изисква управление, класификация и докладване на инциденти, свързани с ИКТ. Articles 17, 18 and 19 обхващат процесите за управление на инциденти, класификацията на инциденти, свързани с ИКТ, и киберзаплахи, както и докладването на съществени инциденти, свързани с ИКТ. Article 10 се фокусира върху откриването на аномални дейности. Articles 6 to 11 описват рамката за управление на ИКТ риска, както и очакванията за идентификация, защита, превенция, откриване, реагиране и възстановяване.
Казано просто, DORA очаква устойчивост, съобразена със заплахите. Не статична устойчивост. Не устойчивост, основана на политика, актуализирана веднъж годишно. Устойчивост, съобразена със заплахите.
ISO/IEC 27001:2022 предоставя управленския механизъм, който свързва тези очаквания. Клаузи 4.1 до 4.4 изискват организацията да разбира своя вътрешен и външен контекст, заинтересованите страни, правните и регулаторните задължения, обхвата на СУИС, зависимостите и взаимодействащите процеси. Клаузи 6.1.1 до 6.1.3 изискват повторяем процес за оценка на риска и третиране на риска, избор на контролни мерки, сравнение с Приложение A, Декларация за приложимост, планиране на третирането и одобрение на остатъчния риск от собственика на риска.
Разузнавателната информация за заплахи принадлежи именно там — не като странично табло, а като вход към контекста, риска, избора на контролни мерки, третирането, мониторинга, прегледа от ръководството и непрекъснатото подобрение.
Капанът на съответствието: потоци за заплахи без проследимост на решенията
Най-честият модел на неуспех е привидно прост: организацията получава разузнавателна информация за заплахи, но не може да докаже как тя променя решенията.
Слабата верига от доказателства обикновено изглежда така:
| Получен сигнал | Слаб отговор | Загриженост на одитора |
|---|---|---|
| Предупреждение от CERT за активна експлоатация | Препратено към ИТ пощенска кутия | Няма доказателства за оценка на риска, собственост или действие |
| Бюлетин от доставчик за критична корекция | Добавен към работната опашка с билети | Няма приоритизация според критичността на актива или активността по експлоатация |
| MDR откриване на подозрителен команден ред | Затворено като фалшиво положителен резултат | Няма документирани критерии за триаж или цикъл за извличане на поуки |
| Уведомление от доставчик за компрометирана зависимост | Архивирано в папка на екипа по снабдяване | Няма актуализация на риска, свързан с доставчика, или преглед на компенсиращи контролни мерки |
| Предупреждение от ISAC за секторна кампания | Споменато на среща на SOC | Няма актуализация на мониторинга, осведомеността или процедурата за реагиране при инциденти |
Тук методът за внедряване на Clarysec помага на организациите да преминат от „получаваме разузнавателна информация“ към „операционализираме разузнавателната информация“.
В Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint фазата Controls in Action изрично превръща разузнавателната информация за заплахи в одитируема практика. Стъпка 22, Организационни контролни мерки, посочва:
Създайте документиран списък с източници на разузнавателна информация за заплахи (5.7) — от доставчици, ISAC или отворени източници — и определете как информацията се валидира и интегрира във вземането на решения. Определете кой получава актуализации за заплахи и как те се прилагат (например приоритизация на корекции, обучение за осведоменост). Създайте кратък брифинг за тенденциите при заплахите, който да се разпространява на тримесечна база до ключови заинтересовани страни.
Тази инструкция е мостът между данните за заплахи и доказателствата за съответствие. Регистърът на разузнавателната информация за заплахи не е просто списък с източници. Той доказва релевантност, собственост, валидиране, маршрутизиране, интеграция и бизнес използване.
Контролната логика на ISO 27001: веригата на разузнавателната информация за заплахи
ISO/IEC 27002:2022 control 5.7, Разузнавателна информация за заплахи, изисква организациите да събират и анализират информация, свързана със заплахи за информационната сигурност, и да я използват за създаване на разузнавателна информация за заплахи. В Zenith Controls: The Cross-Compliance Guide Zenith Controls control 5.7 е класифицирана като превантивна, откриваща и коригираща контролна мярка. Тя подпомага поверителност, цялостност и наличност, съгласува се с концепциите за киберсигурност Identify, Detect и Respond и е част от управлението на заплахи и уязвимости като оперативна способност.
Тази класификация е важна. Разузнавателната информация за заплахи предотвратява, като информира укрепването, прилагането на корекции, обучението и контролните мерки за доставчици. Тя открива, като оформя мониторинга, правилата в SIEM и задачите за лов на заплахи. Тя коригира, като подобрява реагирането при инциденти, извлечените поуки и третирането на риска.
Zenith Controls също съпоставя ISO/IEC 27002:2022 control 5.7 с поддържащи контролни мерки:
| Връзка с контролна мярка по ISO/IEC 27002:2022 | Защо е важно на практика |
|---|---|
| 5.6 Контакт със специални групи по интереси | ISAC, CERT, професионални форуми и секторни общности са източници на разузнавателна информация, а не просто допълнителни мрежи за контакти |
| 8.7 Защита срещу зловреден софтуер | Индикатори за компрометиране, злонамерени URL адреси, хешове, command-and-control инфраструктура и модели на атаки актуализират защитите на крайните точки и електронната поща |
| 8.8 Управление на технически уязвимости | Информация за реална експлоатация променя приоритета на уязвимостите и спешността на корекциите |
| 8.15 Регистриране | Журналите предоставят фактическия запис, необходим за търсене на индикатори и реконструиране на дейност |
| 8.16 Дейности по мониторинг | Разузнавателната информация за заплахи казва на SOC какво да наблюдава, а мониторингът създава вътрешна разузнавателна информация |
| 5.25 Оценка и решение по събития, свързани с информационната сигурност | Триажът, подкрепен с разузнавателна информация, помага да се реши дали дадено събитие е инцидент по сигурността |
Връзката с уязвимостите е особено важна. Zenith Controls разглежда control 8.8, Управление на технически уязвимости, като превантивна и пряко свързана с control 5.7, защото реалната разузнавателна информация за заплахи показва кои уязвимости се експлоатират активно. Той също свързва 8.8 с 8.16, Дейности по мониторинг, защото наблюдаваните опити за експлоатация трябва да повишават спешността на прилагането на корекции.
Така се създава практична верига на разузнавателната информация за заплахи:
- Пристига външна или вътрешна разузнавателна информация.
- Релевантността се валидира спрямо активи, доставчици, география, сектор, бизнес услуги и данни.
- Рискът се актуализира.
- Приоритетите за корекции и конфигурации се променят.
- Логиката за откриване се настройва.
- Процедурите за инциденти и праговете за класификация се преглеждат.
- Проверяват се зависимостите от доставчици и облачни услуги.
- Ръководството получава докладване за тенденции.
- Доказателствата се съхраняват за одитори, регулатори и клиенти.
Политики, които превръщат разузнавателната информация в отчетно поведение
Политиките са мястото, където контролната логика се превръща в отчетност, базирана на роли. Наборите от политики на Clarysec за МСП и предприятия включват връзки към разузнавателната информация за заплахи в управлението на риска, защитата на крайните точки, управлението на уязвимости, регистрирането, мониторинга и одитните доказателства.
За МСП Endpoint Protection - Malware Policy Endpoint Protection - Malware Policy - SME задава пряко очакване в клауза 5.4.1 от изискванията за управление:
Доставчикът на ИТ поддръжка трябва да наблюдава надеждни източници на разузнавателна информация за заплахи (например CISA, ENISA, основни доставчици на антивирусен софтуер) и да гарантира, че сигнатурите за откриване остават актуални
Стойността на тази клауза е в разпределянето на отговорност. Разузнавателната информация за заплахи не е „някой в ИТ трябва да проверява алармите“. Тя е изрично задължение на доставчика.
Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy - SME подсилва същия модел в клауза 4.2.1 от Роли и отговорности:
Наблюдава системите за уязвимости и налични корекции чрез предупреждения от доставчици, препоръки от разузнавателна информация за заплахи и уведомления от операционната система
Тя също посочва в клауза 6.2.1.3 от изискванията за внедряване на политиката типа източник, който трябва да задейства действие:
Доверени препоръки от разузнавателна информация за заплахи (например CISA, ENISA, предупреждения от национален CERT)
За предприятия Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy посочва в клауза 4.5.1 от Роли и отговорности:
Наблюдавайте препоръките за заплахи (например CVE, CISA KEV, бюлетини от доставчици) и ескалирайте критичните уязвимости.
Изискването за ескалация е ключово. Уязвимостта става спешна, когато експлоатируемостта, експозицията, бизнес критичността, чувствителността на данните и активността на заплахите се пресекат.
Risk Management Policy Risk Management Policy вгражда разузнавателната информация за заплахи в анализа. Клауза 6.2.2 от изискванията за внедряване на политиката посочва:
Анализът трябва да взема предвид ефективността на съществуващите контролни мерки, релевантната разузнавателна информация за заплахи, критичността на активите и степента на сериозност на уязвимостите.
Тази клауза е сърцевината на разузнавателната информация за заплахи, готова за одит. Тя доказва, че анализът на риска не е теоретичен.
Logging and Monitoring Policy Logging and Monitoring Policy превръща разузнавателната информация в откриване. Клауза 1.2 от целта ѝ посочва:
Одитното регистриране, мониторингът и откриването на заплахи са критични за откриване на аномалии, реагиране на заплахи, форензичен преглед, готовност за одит и правно съответствие. Тази политика гарантира, че всички събития, генерирани от системите, се записват, съхраняват и корелират правилно с точност на синхронизираното време.
Накрая Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy обяснява защо дисциплината при доказателствата е важна. Клауза 3.4 от целите изисква организацията да генерира доказателства:
Да генерира защитими доказателства и одитна следа в подкрепа на регулаторни запитвания, съдебни производства или искания от клиенти за потвърждение на контролните мерки.
Когато NIS2, DORA, клиент или ISO одитор попита какво сте знаели, кога сте го знаели, кой е взел решението и какво се е променило, тази одитна следа е разликата между зряло уверение и защитна реакция на пожар.
Изградете регистър на разузнавателната информация за заплахи
Зрелият регистър има два слоя: управление на източниците и проследяване на събития. Управлението на източниците определя на какво се доверява организацията, кой е собственикът, как се валидира и какво действие може да задейства.
| Име на източник | Тип | Процес на валидиране | Точка на интеграция | Собственик |
|---|---|---|---|---|
| CISA KEV Catalog | Оперативен | Кръстосано съпоставяне с инвентара на активите и експозицията | Задейства приоритизация на аварийна корекция | Управление на уязвимостите |
| Препоръки на ENISA | Стратегически | Преглед от собственик на риска или комитет по риска | Актуализира рискови сценарии и управленски брифинг | CISO |
| Секторен ISAC | Тактически | Анализ на IOC за релевантност към технологичния стек | Актуализира SIEM, EDR и задачи за лов на заплахи | Ръководител на SOC |
| Бюлетини от доставчик на облачни услуги | Оперативен | Проверка на засегнатите услуги и региони | Ескалация към облачно инженерство | Ръководител DevOps |
| Уведомления за корекции от доставчици | Оперативен | Потвърждение на продукт, версия и обхват на внедряване | Добавяне към цикъла за корекции или аварийна промяна | ИТ операции |
| MDR уведомления | Тактически и оперативен | Триаж спрямо журнали, активи и известни базови стойности | Отваряне на случай за откриване, разследване или инцидент | Операции по сигурността |
| Уведомления за сигурност от доставчици | Оперативен | Съпоставяне с договорени услуги и потоци от данни | Актуализация на риска, свързан с доставчици, и компенсиращи контролни мерки | Собственик на доставчика |
Проследяването на събития улавя как конкретна препоръка се превръща в доказателство. Ако се върнем към сценария от вторник сутрин с прехвърлянето на файлове, записът в регистъра трябва да съдържа достатъчно информация, за да подкрепи решенията за риск, реагиране и съответствие.
| Поле | Примерен запис |
|---|---|
| Дата и час на получаване | 2026-05-26 07:42 UTC |
| Източник | Предупреждение от национален CERT, бюлетин от доставчик, MDR уведомление |
| Тип източник | Държавна препоръка, препоръка от доставчик, вътрешно откриване |
| Засегната технология | Управлявана услуга за прехвърляне на файлове, диапазон от версии, зависими библиотеки |
| Собственик на бизнес процеса | Ръководител „Платформени операции“ |
| Собственик на риска | CISO |
| Връзка с актив | Външен шлюз за прехвърляне на файлове, работен процес за клиентско докладване |
| Първоначална степен на сериозност | Висока, очаква валидиране на експозицията |
| Изисквани действия | Проверка на експозицията, статус на корекцията, преглед на откриването, потвърждение от доставчик |
| Релевантност за съответствието | NIS2 Article 21, NIS2 Article 23, ако са изпълнени критериите за съществен инцидент, жизнен цикъл на ИКТ риск и инциденти по DORA, ако е приложимо |
| Местоположение на доказателствата | Билет, актуализация на регистъра на риска, промяна в SIEM, управленска бележка |
Това не е бюрокрация. Това е фактическият запис, който доказва, че организацията има дефиниран процес за приемане, валидиране, триаж, ескалация и управление на доказателства.
От препоръка до одитно доказателство: практичен работен процес
Работният процес за разузнавателна информация за заплахи трябва бързо да отговори на шест въпроса: изложени ли сме, колко сериозно е, какво трябва да се промени, кой е собственикът, трябва ли да докладваме и какви доказателства трябва да се съхранят?
1. Валидирайте експозицията и бизнес въздействието
Клаузи 4.1 до 4.4 на ISO/IEC 27001:2022 изискват СУИС да отразява действителния контекст, задължения и зависимости на организацията. Първата задача не е сляпо прилагане на корекции. Първата задача е валидиране на експозицията.
Попитайте:
- Използваме ли засегнатата технология?
- Достъпна ли е от интернет?
- Използва ли се от критична бизнес услуга?
- Обработва ли лични данни?
- Управлява ли се от доставчик или доставчик на управлявани услуги?
- Релевантна ли е за критична или важна функция по DORA?
- Релевантна ли е за услуги в обхвата на NIS2?
- Има ли договорни задължения за уведомяване на клиенти?
- Налични, пълни и синхронизирани по време ли са журналите?
Ако лични данни може да са засегнати, принципът на отчетност по GDPR също влиза в анализа. GDPR изисква подходяща сигурност на обработването и доказуема отчетност, включително способност да се оцени дали е настъпило нарушение на сигурността на личните данни и дали се изисква уведомяване.
2. Актуализирайте регистъра на риска
Risk Management Policy Risk Management Policy - SME дава просто правило за срокове в клауза 5.1.3 от изискванията за управление:
Рисковете трябва да се преглеждат на тримесечна база и да се актуализират при настъпване на съществени събития.
Надеждна препоръка за активна експлоатация е съществено събитие. Актуализацията не трябва да чака следващия тримесечен преглед.
| Елемент на риска | Актуализирана оценка |
|---|---|
| Заплаха | Активна експлоатация на уязвимост в управлявана услуга за прехвърляне на файлове |
| Уязвимост | Засегната версия, експониран интерфейс, слаба конфигурация, липсваща корекция |
| Актив | Платформа за обмен на клиентски данни |
| Последица | Прекъсване на услуга, неоторизиран достъп до данни, регулаторно докладване, въздействие върху доверието на клиентите |
| Вероятност | Повишена поради активна експлоатация в реална среда |
| Съществуващи контролни мерки | MFA, WAF, защита на крайните точки, SIEM мониторинг, резервни копия, SLA с доставчик |
| Пропуски в контролните мерки | Корекцията не е потвърдена, откриването не е настроено, доказателства от доставчика се очакват |
| Третиране | Аварийна корекция, временно мрежово ограничение, лов на IOC, удостоверение от доставчик, оценка на въздействието върху клиентите |
| Собственик на остатъчния риск | CISO и собственик „Платформени операции“ |
Това се свързва пряко с клаузи 6.1.1-6.1.3 на ISO/IEC 27001:2022. Организацията идентифицира риска, анализира вероятността и последствията, приоритизира третирането, избира контролни мерки, поддържа Декларация за приложимост, създава план за третиране и получава одобрение на остатъчния риск.
3. Приоритизирайте третирането на уязвимости чрез разузнавателна информация за експлойти
Zenith Blueprint, фазата Controls in Action, стъпка 19, Технологични контролни мерки I, обяснява защо управлението на уязвимости е основна киберхигиена:
Управлението на уязвимости е една от най-критичните области на съвременната киберхигиена. Въпреки че защитните стени и антивирусните инструменти предоставят защита, те могат да бъдат обезсилени, ако некоригирани системи или неправилно конфигурирани услуги останат изложени. За да изпълнят тази контролна мярка, организациите трябва да внедрят структуриран и повторяем процес за идентифициране, оценяване и обработване на уязвимости.
Само CVSS не е достатъчен. Уязвимост със средна оценка, която се експлоатира активно в система, достъпна от интернет, може да е по-спешна от уязвимост с висока оценка, скрита в сегментирана лабораторна среда.
| Фактор | Въпрос | Доказателства |
|---|---|---|
| Активност по експлоатация | Наблюдавана или докладвана ли е експлоатация от доверени източници? | Предупреждение от CERT, референция към CISA KEV, бюлетин от доставчик, MDR отчет |
| Експозиция | Достъпен ли е активът от интернет или достижим ли е от доставчици? | Инвентар на активите, рискова позиция на облачната сигурност, мрежово сканиране |
| Бизнес критичност | Поддържа ли съществени услуги или критични функции? | Анализ на въздействието върху бизнеса, картиране на функции по DORA |
| Чувствителност на данните | Обработва ли лични данни, регулирани финансови данни или поверителни клиентски данни? | Инвентар на данните, DPIA, записи за дейностите по обработване |
| Компенсиращи контролни мерки | Могат ли WAF, правила на защитната стена, сегментиране, EDR или деактивиране на функция да намалят риска? | Билет за промяна, правило на защитната стена, EDR политика |
| Оперативен риск | Може ли аварийното прилагане на корекция да наруши критично предоставяне на услуга? | Оценка на промяната, план за връщане към предходно състояние, план за непрекъсваемост |
Това създава защитимо решение. То също подпомага NIS2 Article 21(2)(e) за обработване на уязвимости, NIS2 Article 21(2)(g) за киберхигиена и очакванията на DORA за управление на ИКТ риска.
4. Превърнете разузнавателната информация в мониторинг и откриване
Разузнавателната информация за заплахи трябва да достигне до регистрирането и мониторинга. Logging and Monitoring Policy Logging and Monitoring Policy - SME посочва в клауза 6.2.1 от изискванията за внедряване на политиката:
Инструментите за сигурност (например антивирусен софтуер, защитни стени, VPN) трябва да бъдат конфигурирани да генерират предупреждения за дефинирани сценарии на заплахи, включително:
Откъсът ясно задава намерението на контролната мярка: дефинираните сценарии на заплахи трябва да определят предупреждаването.
Zenith Blueprint, фазата Controls in Action, стъпка 19, описва дейностите по мониторинг така:
Ако регистрирането е действието по записване на това, което се случва във вашата среда, мониторингът е действието по наблюдение, разбиране и реагиране на тези събития. Тази контролна мярка се отнася до активно наблюдение на мрежи, системи и приложения за откриване на необичайна дейност — не само след факта, а в реално време или почти в реално време, когато е възможно.
За сценария с прехвърлянето на файлове SOC или доставчикът на ИТ услуги трябва да:
- Добави или валидира IOC от CERT и препоръката на доставчика.
- Претърси журналите за известни пътища на експлойта, подозрителни качвания, индикатори за web shell, необичайно изпълнение на процеси и неочаквани изходящи връзки.
- Потвърди, че журналите за автентикация, административна дейност, достъп до файлове, API и мрежови журнали се съхраняват.
- Настрои SIEM предупреждения за модела на експлойта.
- Създаде бележка по случая, която обяснява какво е търсено, какво е открито и кой го е прегледал.
- Ескалира към класификация на инцидент, ако индикаторите показват компрометиране, експозиция на данни или въздействие върху услуга.
Тук докладването на инциденти става практично. NIS2 Article 23 изисква поетапно докладване на съществени инциденти, включително ранно предупреждение в рамките на 24 часа, уведомяване в рамките на 72 часа, междинни актуализации при поискване и окончателен доклад не по-късно от един месец след уведомлението. DORA изисква финансовите субекти да откриват, управляват, класифицират и докладват съществени инциденти, свързани с ИКТ, чрез поетапния процес, определен в регламента и свързаните технически стандарти.
Разузнавателната информация за заплахи помага да се определи дали организацията все още е в режим на реакция към уязвимост, оценка на събитие по сигурността или регулаторно докладване на инцидент.
Един работен процес, множество задължения за съответствие
Разузнавателната информация за заплахи е идеален интегриран работен процес за съответствие, защото едни и същи доказателства подпомагат няколко режима.
| Рамка или регулация | Какво очаква | Доказателства от разузнавателната информация за заплахи |
|---|---|---|
| ISO/IEC 27001:2022 | СУИС, съобразена с контекста, оценка на риска, избор на контролни мерки, планиране на третирането, непрекъснато подобрение | Обхват на СУИС, регистър на риска, Декларация за приложимост, план за третиране, входни данни за преглед от ръководството |
| ISO/IEC 27002:2022 | Разузнавателна информация за заплахи, управление на уязвимости, регистриране, мониторинг, оценка на инциденти, защита от зловреден софтуер | Регистър на разузнавателната информация за заплахи, актуализации на IOC, SIEM правила, билети за корекции, бележки от триаж на инциденти |
| NIS2 | Управление на риска, управление на инциденти, киберхигиена, обработване на уязвимости, сигурност на веригата на доставки, управленски надзор | Доказателства по Article 20 и 21, управленски брифинги, CSIRT работен процес, последващи действия по препоръки от доставчици |
| DORA | Рамка за ИКТ риск, откриване, непрекъсваемост, жизнен цикъл на инциденти, тестове за устойчивост, ИКТ риск от трети страни | Класификация на ИКТ активи, случаи на откриване, записи за класификация на инциденти, входни данни за тестове за устойчивост, записи за ИКТ доставчици |
| GDPR | Сигурност на обработването, отчетност, подкрепа за откриване и уведомяване при нарушение | Оценка на въздействието върху данните, журнали за достъп, доказателства от мониторинг, запис от оценка на нарушение |
| NIST CSF 2.0 | Резултати Govern, Identify, Protect, Detect, Respond, Recover | Current Profile, Target Profile, приоритизиран план за действие, комуникации за риска |
| COBIT 2019 одитна перспектива | Управление на риска, контролните мерки, изпълнението, увереността и отчетността | Собственост на контролни мерки, управленски показатели, доказателства за увереност, проследяване на отстраняване на проблеми |
NIST CSF 2.0 е особено полезен за комуникация с ръководството. Неговите основни функции Govern, Identify, Protect, Detect, Respond и Recover превръщат техническата разузнавателна информация в разбираем за управителния орган разказ:
- Govern: източниците на разузнавателна информация за заплахи, собствениците и линиите за докладване са дефинирани.
- Identify: засегнатите активи, доставчици, бизнес услуги и данни са картографирани.
- Protect: корекциите, укрепването, сегментирането и сигнатурите за крайни точки са актуализирани.
- Detect: правилата за мониторинг, IOC и задачите за лов на заплахи са внедрени.
- Respond: процедурите за инциденти, правилата за триаж и праговете за уведомяване са прегледани.
- Recover: резервните копия, приоритетите за възстановяване и извлечените поуки са валидирани.
Това превръща суровата разузнавателна информация за киберзаплахи в управление на риска.
Погледът на одитора: какво ще поискат
Силен процес за разузнавателна информация за заплахи трябва да издържи на различни стилове на одит. ISO одитор, преглеждащ по NIS2, надзорен орган по DORA, оценител по NIST CSF, одитор с ориентация към COBIT 2019, професионалист от ISACA или специалист по поверителност може да използва различен език, но всички се фокусират върху доказателствата.
| Одиторска перспектива | Вероятен одиторски въпрос | Доказателства, които отговарят |
|---|---|---|
| ISO/IEC 27001:2022 одитор | Как външният и вътрешният контекст влияят върху рисковете и контролните мерки в СУИС? | Регистър на разузнавателната информация за заплахи, методология за риска, актуализиран регистър на риска, обосновка в Декларацията за приложимост |
| Преглеждащ контролни мерки по ISO/IEC 27002:2022 | Как са свързани контролните мерки 5.7, 8.8, 8.16, 8.15, 8.7 и 5.25? | Списък на източници, триаж на уязвимости, настройка на SIEM, актуализации на сигнатури за зловреден софтуер, записи от оценка на събития |
| Преглеждащ по NIS2 | Как изпълнявате управленски надзор, киберхигиена, обработване на уязвимости, управление на инциденти и сигурност на веригата на доставки? | Съпоставка по Article 20 и 21, управленски брифинги, процедура за докладване към CSIRT, работен процес за препоръки от доставчици |
| Надзорен орган по DORA | Как разузнавателната информация за заплахи актуализира ИКТ риска, откриването, тестовете за устойчивост и класификацията на инциденти? | Рамка за ИКТ риск, картографиране на критични функции, случаи на откриване, записи за класификация на инциденти, обхват на тестове за устойчивост |
| Оценител по NIST CSF | Какви са вашите Current Profile, Target Profile и приоритизиран план за действие? | CSF профил, оценка на пропуските, план за действие, журнал за непрекъснати актуализации |
| COBIT 2019 или ISACA одитор | Кой е собственик на контролната мярка, как се измерва изпълнението и как се отстраняват изключенията? | RACI, KPI, KRI, регистър на изключенията, билети за отстраняване, потвърждение от ръководството |
| GDPR одитор или специалист по поверителност | Как мониторингът и управлението на уязвимости защитиха личните данни и подпомогнаха оценката на нарушение? | Карта на обработването на данни, журнали, оценка на нарушение, доказателства за технически и организационни мерки |
Zenith Controls предоставя cross-compliance тълкуването за тези дискусии. За control 8.16, Дейности по мониторинг, ръководството свързва мониторинга със сигурността и отчетността при нарушения по GDPR, управлението и докладването на инциденти по NIS2 и очакванията на DORA за откриване и реагиране. За control 8.8, Управление на технически уязвимости, то свързва обработването на уязвимости със сигурността на обработването по GDPR, NIS2 Article 21(2)(e) и проактивното управление на ИКТ риска по DORA.
Това е конвергенцията на доказателствата, която одиторите искат да видят.
Управленско докладване: тримесечен брифинг за тенденциите при заплахите
Регистърът на разузнавателната информация за заплахи не трябва да остава само в SOC. Zenith Blueprint препоръчва кратък тримесечен брифинг за тенденциите при заплахите за ключови заинтересовани страни. Clarysec препоръчва едностраничен управленски доклад с пет раздела:
- Трите най-значими релевантни тенденции при заплахите според бизнес въздействието.
- Най-експонираните технологии или доставчици.
- Критични уязвимости, за които са приложени корекции, смекчаване или е приет риск.
- Подобрения в откриването и реагирането.
- Решения, изисквани от ръководството.
Силният управленски брифинг не изброява 400 CVE. Той обяснява движението на риска. Например:
- Ransomware, насочен към доставчици на управлявани услуги, повиши приоритета на прегледа на доставчици.
- Експлоатацията на платформи за прехвърляне на файлове задейства аварийно прилагане на корекция и компенсиращо правило на защитната стена.
- Атаки срещу облачни идентичности доведоха до преглед на изключенията за MFA и укрепване на условния достъп.
- Разузнавателна информация от секторен ISAC доведе до нови фишинг симулации за финансовите и поддържащите екипи.
- Картографирането на критични функции по DORA разкри един пропуск в мониторинга в работен процес на трета страна.
Този брифинг подпомага управленската отчетност по NIS2, управлението на ИКТ риска по DORA, прегледа от ръководството по ISO/IEC 27001:2022 и увереността за клиенти.
Чести модели на неуспех
Програмите за разузнавателна информация за заплахи често изглеждат зрели в презентации, но са слаби при одит. Най-честите модели на неуспех са:
- Твърде много потоци и липса на критерии за валидиране.
- Липса на връзка между разузнавателната информация и инвентара на активите.
- Липса на документирана актуализация на риска след съществени препоръки.
- Приоритет за корекции, основан само на степента на сериозност от скенер.
- Препоръки от доставчици, обработвани извън СУИС.
- Актуализирани SOC правила без записи за промяна.
- Прагове за инциденти, които не са съгласувани с работните процеси за докладване по NIS2 или DORA.
- Докладване към управителния орган, фокусирано върху обем на алармите вместо върху бизнес риск.
- Липса на доказателства, че извлечените поуки са променили контролните мерки.
- Липса на собственик за поддържане на регистъра на разузнавателната информация за заплахи.
Решението не е закупуване на още един поток. Решението е интеграция на контролните мерки.
Контролен списък от 10 точки за готовност през 2026 г.
Използвайте този контролен списък като практичен вътрешен преглед.
| Въпрос за готовност | Да или не |
|---|---|
| Поддържаме ли одобрен регистър на разузнавателната информация за заплахи със собственици на източници и правила за валидиране? | |
| Насочват ли се препоръките от CERT, CSIRT, ISAC, доставчици, облачни услуги, MDR и доставчици към именувани роли? | |
| Задействат ли съществените препоръки преглед на регистъра на риска извън тримесечния цикъл? | |
| Включва ли приоритизацията на уязвимости активност по експлоатация, критичност на активите, чувствителност на данните и експозиция? | |
| Превръщат ли се IOC и сценариите на заплахи в правила за мониторинг или задачи за лов на заплахи? | |
| Проверяват ли се сигнатурите за крайни точки, облачните откривания и динамичните потоци от разузнавателна информация за заплахи за актуалност? | |
| Оценяват ли се уведомленията от доставчици спрямо риска във веригата на доставки и договорните задължения? | |
| Съгласувани ли са критериите за класификация на инциденти с работните процеси за докладване по NIS2 и DORA, когато е приложимо? | |
| Получава ли ръководството тримесечен брифинг за тенденциите при заплахите? | |
| Можем ли да изготвим пакет с доказателства за одитор, регулатор или клиент в рамките на един работен ден? |
Ако отговорът на някой от тези въпроси е „не“, организацията няма просто проблем с разузнавателната информация за заплахи. Тя има проблем с интеграцията в СУИС.
Как Clarysec помага да превърнете разузнавателната информация за заплахи в доказателства
Методът на Clarysec е предназначен за организации, които се нуждаят едновременно от практична сигурност и надеждно съответствие.
Zenith Blueprint предоставя 30-стъпковия маршрут за внедряване, включително стъпка 22 за регистъра на разузнавателната информация за заплахи и стъпка 19 за управление на уязвимости и дейности по мониторинг. Политиките на Clarysec за предприятия и МСП превръщат тези очаквания в ролево базирани процедури за управление на риска, обработване на уязвимости, защита на крайните точки, регистриране, мониторинг и одитни доказателства. След това Zenith Controls предоставя cross-compliance тълкуването, като показва как контролните мерки по ISO/IEC 27002:2022 се свързват с NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 и доказателствата за одит.
За CISO от вторник сутринта отговорът към CFO става ясен:
„Получихме препоръката, валидирахме експозицията, актуализирахме регистъра на риска, приоритизирахме корекциите според активната експлоатация, настроихме мониторинга, проверихме зависимостта от доставчик, оценихме праговете за докладване на инциденти, информирахме ръководството и съхранихме доказателствата. Не гадаем. Следваме нашата СУИС.“
Така трябва да изглежда разузнавателната информация за заплахи по ISO 27001 за киберхигиена по NIS2 и доказателства за ИКТ риск по DORA през 2026 г.
Следващи стъпки
Ако вашата организация получава разузнавателна информация за заплахи, но не може да докаже как тя променя решенията за риск, контролните мерки, откриването, реагирането при инциденти, управлението на доставчици и регулаторните доказателства, започнете с три действия тази седмица:
- Изградете или актуализирайте своя регистър на разузнавателната информация за заплахи с помощта на Zenith Blueprint, фазата Controls in Action, стъпка 22.
- Съпоставете текущия си процес с ISO/IEC 27002:2022 controls 5.7, 8.8, 8.15, 8.16, 8.7 и 5.25 с помощта на Zenith Controls.
- Съгласувайте политиките си, особено Risk Management Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy и Audit and Compliance Monitoring Policy, така че всяка препоръка да може да се превърне в защитими доказателства.
Clarysec може да ви помогне да превърнете потоци за заплахи, препоръки, уведомления от доставчици, разузнавателна информация за уязвимости и сигнали за откриване в оперативен модел, съгласуван с ISO/IEC 27001:2022, готов за NIS2 и съобразен с DORA.
Изтеглете инструментариумите на Clarysec, заявете демонстрационен преглед или резервирайте оценка на готовността, за да видите как текущият ви процес за разузнавателна информация за заплахи би издържал пред ISO одитор, преглеждащ по NIS2, надзорен орган по DORA или искане от клиент за потвърждение на контролните мерки.
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
