Споделяне на разузнавателна информация за киберзаплахи с ISO 27001 през 2026 г.

В 07:40 във вторник сутрин Мария, CISO на бързо развиваща се европейска платежна платформа, получава бюлетин с висока достоверност от ISAC за финансови услуги. Кампания за кражба на удостоверителни данни е насочена към доставчици на платежни услуги, които използват конкретна интеграция с доставчик на идентичност. Съобщението за сигурност включва command-and-control домейни, подозрителни имена на OAuth приложения, user-agent низове, наблюдавани тактики и препоръка за ротация на тайни за засегнатите tenants.

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

SOC иска незабавно да подаде индикаторите към SIEM. Правният отдел пита дали дружеството може да сподели собствената си телеметрия обратно към ISAC. DPO пита дали IP адреси, потребителски имена, извадки от тикети, журнали за автентикация или данни от крайни устройства включват лични данни. COO иска да знае дали клиентите трябва да бъдат предупредени. CEO, който току-що е преминал обучение за управление по NIS2, препраща предупреждението с два въпроса: „Нашият план?“

След това мениджърът по съответствието задава най-важния въпрос: „Ако надзорният орган попита следващия месец, можем ли да докажем, че нашето споделяне на разузнавателна информация за киберзаплахи е било законосъобразно, одобрено, полезно и контролирано?“

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

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

ISO/IEC 27001:2022 е управленската основа, която прави това възможно. Не като сертификат на стената, а като система за управление, която превръща споделянето на разузнавателна информация за киберзаплахи в повторяем, защитим и съвместим с GDPR оперативен модел.

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

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

• В кои ISAC, CERT, CSIRT, форуми на доставчици или доверени общности участвате?
• Кой е упълномощен да представлява организацията пред външни страни?
• Как решавате какво може да бъде споделено?
• Как предотвратявате разкриването на лични данни, клиентски тайни, подробности за уязвимости и чувствителна архитектура?
• Как входящата разузнавателна информация за киберзаплахи актуализира правилата за мониторинг, приоритетите за пачване, регистрите на риска, наръчниците за реагиране при инциденти, прегледите на доставчици и тестовете за устойчивост?
• Къде са доказателствата?

DORA е особено пряка за финансовите субекти. Тя третира цифровата оперативна устойчивост като система за управление на ИКТ риска, притежавана от управителния орган, а не като ИТ контролен списък. DORA се прилага от 17 януари 2025 г., затова през 2026 г. много финансови субекти се оценяват според това дали процесите им работят на практика.

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

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

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

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

ISO 27001 като център за съответствие при споделяне на разузнавателна информация за киберзаплахи

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

Клаузи 4.1 до 4.4 изискват организациите да разбират вътрешните и външните обстоятелства, да идентифицират заинтересованите страни и техните изисквания, да определят обхвата на ISMS и да поддържат системата за управление. За организация по DORA или NIS2 заинтересованите страни могат да включват компетентни органи, CSIRT, клиенти, доставчици на ИКТ, ISAC, секторни групи, обработващи лични данни, администратори, застрахователи, вътрешен одит и управителния орган.

Клаузи 5.1 до 5.3 изискват ангажираност на ръководството, посока на политиките, отчетност, ресурси и разпределени отговорности. Това е важно, защото споделянето на разузнавателна информация за киберзаплахи се проваля, когато бъде оставено на неформална техническа преценка. Ако SOC анализаторът, правният консултант, DPO, CISO, ръководителят по PR и собственикът на процеса прилагат различни допускания, организацията или ще споделя прекомерно, или ще блокира, или ще реагира твърде късно.

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

• Лични данни, споделени без правно основание или минимизиране.
• Поверителна клиентска информация, разкрита във форум.
• Подробности за уязвимост, публикувани преди да е налична мярка за смекчаване.
• Индикатори, които са приети, но никога не са превърнати в оперативни действия.
• Участие в ISAC, което не е отразено в реагирането при инциденти, журналирането, управлението на уязвимости или риска, свързан с доставчици.
• Липса на доказателства кой е одобрил разкриването и защо.
• Риск по правото на конкуренцията при споделяне на търговски чувствителна пазарна информация.
• Непоследователни регулаторни и клиентски комуникации по време на значим инцидент.

След това клауза 8.1 изисква планираните процеси да бъдат внедрени и контролирани с документирана информация, достатъчна да покаже, че процесите са функционирали както е планирано. Клаузи 9 и 10 изискват мониторинг, измерване, вътрешен одит, преглед от ръководството, обработване на несъответствия, коригиращо действие и непрекъснато подобрение. Накратко, ISO/IEC 27001:2022 превръща споделянето на разузнавателна информация за киберзаплахи в оперативен модел, който може да бъде одитиран.

Двата ISO контрола, които правят споделянето работещо

Zenith Blueprint: 30-стъпкова пътна карта за одитори на Clarysec Zenith Blueprint разглежда тази тема като част от фазата „Контроли в действие“, стъпка 22: Организационни контроли. Два контрола по ISO/IEC 27002:2022 са централни: 5.6, Контакт с групи със специален интерес, и 5.7, Разузнавателна информация за заплахи.

Zenith Blueprint ясно посочва, че участието в ISAC не е символично изграждане на мрежа от контакти:

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

За контрол 5.6 групите със специален интерес могат да включват национални или секторни мрежи за разузнавателна информация за киберзаплахи, ISAC, регулаторни форуми, групи на доставчици за съобщения за сигурност, open-source общности и академични работни групи. Но външното споделяне трябва да бъде целенасочено, законосъобразно и одобрено. Zenith Blueprint добавя очакването за зрялост:

Зрелите внедрявания на ISMS третират участието в SIG като управлявана дейност, а не като неформална полза.

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

Контрол 5.7 превръща външната информация в действие. Zenith Blueprint посочва:

Организацията не може да се защити от това, което не разбира.

Той също така предупреждава да не се смесват потоци за корекции с разузнавателна информация за заплахи. Реалната разузнавателна информация включва профилиране на участници в заплахи, тактики, техники и процедури, индикатори за компрометиране, секторни предупреждения, контекст на уязвимости и стратегическо въздействие върху бизнеса. Полезната разузнавателна информация комбинира вътрешен мониторинг, външни партньорства, взаимоотношения с CERT или ISAC, търговски потоци и open-source източници, но само когато някой я преглежда, приоритизира и превежда в действие.

Zenith Controls: Ръководство за кръстосано съответствие на Clarysec Zenith Controls подсилва стойността за кръстосано съответствие. То картографира контрол 5.6 като превантивен и коригиращ, подпомагащ поверителност, цялостност и наличност, като управлението е основната оперативна способност. Свързва 5.6 с 5.7 Разузнавателна информация за заплахи, 5.5 Контакт с органи, 5.31 Правни, законови, регулаторни и договорни изисквания и 8.8 Управление на технически уязвимости. Картографира 5.7 като превантивен, откриващ и коригиращ, свързан с Identify, Detect и Respond, с оперативна способност в управлението на заплахи и уязвимости.

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

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

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

Clarysec обичайно внедрява това като лек, но формален работен поток:

1. Приемане и класифициране на разузнавателната информация.
2. Валидиране на релевантността спрямо активи, доставчици, услуги, географии и клиенти.
3. Превръщане на разузнавателната информация в действие, например правила за мониторинг, тикети за уязвимости, предупреждения към потребители, запитвания към доставчици или актуализации на риска.
4. Решение дали изходящото споделяне е необходимо, законосъобразно, безопасно и разрешено от правилата за членство.
5. Прилагане на редактиране, агрегиране, псевдонимизация или анонимизация.
6. Получаване на необходимите одобрения.
7. Споделяне чрез одобрен канал.
8. Записване какво е споделено, с кого, защо, кога и под чии правомощия.
9. Преглед на резултатите и актуализиране на контролите.

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

DORA Article 45: контролирано споделяне без загуба на поверителност

За финансовите субекти DORA Article 45 следва да бъде преведен във вътрешен стандарт за споделяне на разузнавателна информация за киберзаплахи. Практическото тълкуване включва пет условия.

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

Второ, общността трябва да бъде доверена. Това означава ясни правила за членство, задължения за поверителност, сигурни канали, контрол на достъпа и ограничения за последващо разкриване. ISO/IEC 27010:2015 подпомага сигурния обмен на информация в доверени общности, включително правила за поверителност, реципрочност и доверени комуникационни канали. ISO/IEC 27032:2023 подпомага споделянето на информация за киберсигурност и ситуационната осведоменост. ISO/IEC 27035-2:2023 свързва споделянето на информация с планирането на реагиране при инциденти, включително участие в CERT и индустриални групи.

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

Външното споделяне трябва да бъде изрично разрешено и регистрирано.

Това изречение е принципът на контрол зад работния поток по DORA Article 45. Организацията трябва да знае каква класификация се прилага, кой е одобрил разкриването и къде се съхранява записът.

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

Могат да се събират и обработват само данните, необходими за конкретна, легитимна бизнес цел.

SME еквивалентът, Политика за защита на данните и поверителност - SME Политика за защита на данните и поверителност - SME, посочва:

Трябва да се събират и съхраняват само минимално необходимите лични данни.

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

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

Сътрудничество по NIS2: от правен обхват към оперативни взаимоотношения

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

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

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

Zenith Blueprint разглежда това във фазата „Основи и лидерство на ISMS“, стъпка 5, „Комуникация, осведоменост и компетентност“. Той препоръчва планиране на външни комуникации, което идентифицира клиенти, регулатори, партньори и обществеността, след което определя какво се комуникира, кога, от кого и с какво одобрение. Дава практически пример с процедура за комуникация при инцидент, при която CISO изготвя уведомление, правният отдел го преглежда, а CEO го одобрява преди изпращане.

SME Политика за реагиране при инциденти Политика за реагиране при инциденти - SME посочва:

Управителят (GM) носи отчетност за разрешаване на всички решения за ескалация на инциденти, регулаторни уведомления и външни комуникации.

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

Всички инциденти трябва да бъдат записвани в Системата за управление на инциденти по сигурността (SIMS), включително:

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

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

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

• IP адреси, свързани с потребителска дейност.
• Имейл адреси, използвани при опити за фишинг.
• Потребителски имена, имена на устройства, идентификатори на крайни устройства или клиентски tenant идентификатори.
• Журнали за автентикация.
• Тикети за поддръжка.
• Екранни снимки.
• Бележки от разследвания на измами.
• Образци на зловреден софтуер, съдържащи документи или лични файлове.
• Доклади за уязвимости, които включват експозиция на клиентски данни.

В модела на Clarysec всяко решение за изходящо споделяне преминава през филтър за поверителност и конфиденциалност.

В Zenith Controls контрол 5.34 по ISO/IEC 27002:2022, Поверителност и защита на PII, е картографиран като превантивен и свързан с класификация, инвентар на активите, маскиране на данни, сигурност на облачни услуги, трансфер на информация, контрол на достъпа, управление на идентичности и преглед на проект или промяна. Той също така се картографира към GDPR Articles 25 и 32 чрез поверителност още при проектирането, сигурност на обработването, шифроване, псевдонимизация, контрол на достъпа и доказуемо управление. Поддържащите стандарти включват ISO/IEC 27701:2021 за управление на информацията за поверителност, ISO/IEC 27018:2019 за защита на PII в среди на обработващ лични данни в публичен облак и ISO/IEC 29100:2011 за принципи на поверителност.

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

Практически пример: предупреждение от ISAC се превръща в устойчивост, основана на доказателства

Да се върнем към платежната платформа на Мария. Съобщението от ISAC включва злонамерени домейни, подозрителни имена на OAuth приложения, user-agent низове и бележка, че няколко членове са наблюдавали опити за превземане на акаунти срещу потребители във финансовите операции. Дружеството също открива три подозрителни опита за вписване в собствените си журнали.

Ето как Clarysec би превърнал реакцията в оперативни действия чрез ISO/IEC 27001:2022, Zenith Blueprint, Zenith Controls и набора от политики.

Първоначално изходящото съобщение включва времеви маркери, изходни IP адреси, целеви потребителски имена, клиентски tenant идентификатори и екранни снимки. След преглед от DPO и правния отдел то се свежда до:

• Времеви прозорец в UTC.
• Модел на атака.
• Наблюдаван злонамерен домейн.
• Общ засегнат тип роля, например потребители от финансовите операции.
• Без потребителски имена.
• Без клиентски tenant идентификатори.
• Без екранни снимки.
• Без имена на клиенти.
• Без сурови журнали, освен ако не бъдат поискани чрез контролиран канал.

Ако дейността се превърне в инцидент, контролите от Политика за реагиране при инциденти поемат управлението. Ако се събират форензични артефакти, се прилага Политика за събиране на доказателства и форензика - SME Политика за събиране на доказателства и форензика - SME:

Всеки елемент на цифрови доказателства трябва да бъде регистриран с:

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

Оповестяването на уязвимости не е същото като споделянето на разузнавателна информация за киберзаплахи

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

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

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

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

Същата политика също посочва:

Поверителност: До публичното оповестяване цялата информация, свързана с докладвана уязвимост, трябва да се третира като Строго поверителна. Подробностите трябва да се споделят вътрешно само на принципа „необходимост да се знае“ с персонала, необходим за валидиране или отстраняване на проблема. Самоличността на докладващото лице трябва да се пази поверителна, когато това е поискано. Всички комуникации с докладващото лице следва да бъдат криптирани, включително чрез използване на PGP ключа на организацията, за да се защитят чувствителните подробности за уязвимостта.

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

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

Картографиране на кръстосано съответствие: един работен поток, много задължения

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

NIST CSF 2.0 е полезен като неутрален организационен слой, защото функцията му GOVERN разглежда заинтересовани страни, правни задължения, зависимости, апетит за риск, роли, политики и надзор. Функциите DETECT и RESPOND очакват мониторинг, интегриране на разузнавателна информация за киберзаплахи, обявяване на инцидент, запазване на доказателства, уведомяване и външна комуникация.

COBIT 2019 добавя управленска отчетност. Практики като DSS05.04 Manage security threats, APO12 Manage risk, MEA03 Managed compliance with external requirements и APO13 Managed security помагат на одиторите да тестват дали разузнавателната информация подобрява резултатността на контрола и управленското докладване.

Как одиторите ще тестват вашата програма за споделяне

Одитор по ISO/IEC 27001:2022 ще започне със системата за управление. Той ще попита как са идентифицирани правните, регулаторните, договорните изисквания и изискванията на заинтересованите страни съгласно клаузи 4.1 и 4.2. Ще провери дали споделянето на разузнавателна информация за киберзаплахи е в обхват, дали рисковете са оценени, дали контроли 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15 и 8.16 са включени или обосновани в Декларацията за приложимост и дали доказателствата показват, че процесът е функционирал както е планирано.

Одитор или надзорен орган с фокус върху DORA ще търси управление, отчетност на управителния орган, интеграция на ИКТ риска, класификация на инциденти, тестване на устойчивостта, последици за трети страни и условията по Article 45. Ще попита дали участието в механизми за споделяне на информация е документирано, дали чувствителните и личните данни са защитени, дали разузнавателната информация актуализира рамката за управление на ИКТ риска и дали влияе върху сценариите за тестване.

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

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

Добрите доказателства включват:

• Одобрен регистър на ISAC или SIG.
• Поименно определени участници и заместници.
• Условия за членство и задължения за поверителност.
• Журнал за приемане на разузнавателна информация за киберзаплахи.
• Оценки за триаж и релевантност.
• Тикети за инженеринг на откриването.
• Промени в приоритизирането на уязвимости.
• Ескалации на риск, свързан с доставчици.
• Записи за одобрение на разкриване.
• Бележки от преглед от DPO или по поверителност.
• Редактирани изходящи съобщения.
• Записи за инциденти в SIMS.
• Журнали за верига на съхранение на доказателства.
• Протоколи от преглед от ръководството.
• Констатации от вътрешен одит и коригиращи действия.

Чести грешки, които Clarysec вижда на практика

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

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

Третият провал е споделянето на сурови журнали. Екипите изпращат екранни снимки, експорти от SIEM, имейл заглавки или packet captures към външни страни без минимизиране. Това може да разкрие лични данни, клиентски идентификатори, вътрешни hostnames, токени или поверителна архитектура.

Четвъртият провал е смесването на връзките с обществеността с регулирана комуникация. Публикация в LinkedIn за тенденция при атаки не е същото като предупреждение към клиент, уведомление до регулатор, актуализация към CSIRT или координирано съобщение. Clarysec разделя тези канали, назначава собственици на одобренията и изисква записи.

Петият провал е игнорирането на доставчиците. Много предупреждения от разузнавателна информация засягат софтуер от трети страни, облачни платформи, доставчици на управлявани услуги или интеграции за идентичност. Съгласно DORA, NIS2, NIST CSF, COBIT 2019 и контролите за доставчици в ISO/IEC 27002:2022 разузнавателната информация за киберзаплахи трябва да захранва управлението на риска, свързан с доставчици.

Изградете своя пакет за споделяне на разузнавателна информация за киберзаплахи за 2026 г.

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

• Процедура за споделяне на разузнавателна информация за киберзаплахи.
• Регистър на одобрените общности за споделяне.
• Формуляр за приемане и триаж на разузнавателна информация за киберзаплахи.
• Формуляр за одобрение на изходящо разкриване.
• Контролен списък за преглед на поверителността и конфиденциалността.
• Матрица за външни комуникации.
• Шаблон за резюме от среща на ISAC.
• Правила за връзка между доказателства и инциденти.
• Информационно табло за показатели.
• План за тестове на вътрешния одит.

Процедурата следва да препраща към клаузите на ISO/IEC 27001:2022 за управление на риска, комуникации, оперативен контрол, оценка на изпълнението, вътрешен одит и непрекъснато подобрение. Тя следва да се картографира към контроли 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, 8.16 по ISO/IEC 27002:2022 и към релевантните контроли за доставчици. Тя следва също да препраща към DORA Article 45, задълженията за сътрудничество и комуникация при инциденти по NIS2 и принципите на GDPR.

Най-важното е процедурата да бъде използваема под натиск. Ако процесът изисква среща с 12 участници преди споделяне на злонамерен домейн с доверен ISAC, той ще се провали. Ако позволява сурови клиентски журнали да бъдат поставяни в портал на общност, също ще се провали. Целта е контролирана скорост.

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

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

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

Ако вашата организация участва в ISAC, получава съобщения за киберсигурност, споделя индикатори с партньори, докладва на органи или обработва оповестяване на уязвимости, сега е моментът да формализирате работния поток. Започнете с едночасов преглед на текущите си механизми за споделяне, след което ги картографирайте към ISO/IEC 27001:2022, DORA Article 45, NIS2 и GDPR.

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