Управление на периодите на поддръжка на сигурността по EU CRA чрез ISO 27001

Вторник е, 08:20 ч., и собственикът на продукт за свързан B2B шлюз получава съобщение от регулиран клиент: „Моля, потвърдете периода на поддръжка на сигурността за версия 4.6 на фърмуера, SLA за реагиране при уязвимости и дали устройството ще продължи да отговаря на условията за актуализации за сигурност през петгодишния ни договор за услуги.“

До 09:00 ч. екипът по снабдяване е препратил въпросник за надлежна проверка по DORA. До 10:15 ч. правният отдел пита дали обявеният период на поддръжка съответства на договорите с клиенти. До 11:00 ч. директорът по информационна сигурност (CISO) е включен в преглед на риска от доставчици по NIS2, защото продуктът се използва от доставчик на управлявани услуги в ЕС. Следобед екипът по поверителност пита дали неподдържана API библиотека в продукта може да засегне сигурността на лични данни по GDPR.

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

Този пропуск е съществен. Съгласно EU Cyber Resilience Act периодът на поддръжка на сигурността не е просто етикет върху продукта. Той е ангажимент през жизнения цикъл, който засяга управлението на уязвимости, наличността на актуализации, управлението на зависимостите от доставчици, комуникацията с клиенти, договорните твърдения и наблюдението след пускане на пазара. За SaaS доставчици, производители на устройства, издатели на софтуер, доставчици на облачни услуги и доставчици на ИКТ услуги периодът на поддръжка се превръща в обект на съответствие, който одиторите и регулираните купувачи ще проверяват.

Практическото решение не е още една откъсната таблица за съответствие. Решението е периодът на поддръжка на сигурността да се управлява в рамките на Система за управление на информационната сигурност (СУИС) по ISO/IEC 27001:2022, след което същите доказателства да се съпоставят с NIS2, DORA, GDPR, NIST CSF 2.0 и одиторски очаквания в стил COBIT.

Това е оперативният модел на Clarysec: използвайте СУИС като двигател за доказателства, използвайте приложими политики за дефиниране на отговорности, използвайте Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint за изграждане на проследимост и използвайте Zenith Controls: The Cross-Compliance Guide Zenith Controls като ориентир за съответствие между рамки.

Защо периодът на поддръжка на сигурността вече е обект на одит

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

На практика този отговор зависи от много движещи се части:

• Архитектура и поддържаемост на продукта
• Поддръжка на компоненти от трети страни и зависимости с отворен код
• Ангажименти на доставчици и доставчици на облачни услуги
• Процеси за приемане на доклади за уязвимости, триаж, отстраняване и оповестяване
• Капацитет за инженеринг на версии и тестване
• Договорни условия с клиенти и регулаторни задължения
• Реагиране при инциденти и канали за уведомяване на получатели на услуги
• Съхраняване на доказателства и записи за одобрения

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

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

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

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

Ето защо периодът на поддръжка на сигурността по CRA трябва да се управлява като семейство контроли в СУИС, а не като изолирано поле в продуктовото управление.

ISO 27001 като контролна основа за периодите на поддръжка на сигурността по CRA

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

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

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

Zenith Controls определя три тематично свързани контроли по ISO/IEC 27002:2022 като централни опорни точки за този управленски проблем: 5.31 Правни, законови, регулаторни и договорни изисквания, 8.8 Управление на технически уязвимости и 8.25 Сигурен жизнен цикъл на разработка. Те не са единствените включени контроли, но са управленският гръбнак.

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

Zenith Blueprint, фаза „Управление на риска“, стъпка 13, описва директно тази дисциплина на проследимост:

„Кръстосано препращане към регулации: ако определени контроли са внедрени специално за съответствие с GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.“

Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Управление на риска“, стъпка 13: Планиране на третирането на риска и Декларация за приложимост Zenith Blueprint

За период на поддръжка на сигурността по CRA Декларацията за приложимост не трябва само да казва „управлението на уязвимостите е приложимо“. Тя следва да обяснява, че управлението на уязвимостите е приложимо, защото компанията има ангажименти по CRA през жизнения цикъл, очаквания по NIS2 за сигурна разработка и верига на доставки, изисквания от клиенти по DORA за надлежна проверка, задължения за сигурност по GDPR, когато се обработват лични данни, и договорни обещания за поддръжка.

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

Определеният от производителя период на поддръжка на сигурността следва да преминава през шест управленски проверки.

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

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

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

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

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

Шесто, той трябва да бъде доказуем. Ако одитор, регулатор или регулиран клиент поиска доказателства, организацията следва да покаже регистъра на съответствието, регистъра за поддръжка на продукти, оценката на риска, съпоставянето със SoA, Регистъра на уязвимостите, записите за корекции, прегледите на доставчици, одобренията на версии и уведомленията до клиенти.

Политиките на Clarysec правят това практично. Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy изисква:

„Всички правни и регулаторни задължения трябва да бъдат съпоставени с конкретни политики, контроли и собственици в рамките на Системата за управление на информационната сигурност (СУИС).“

Източник: Legal and Regulatory Compliance Policy, Изисквания за прилагане на политиката, клауза 6.2.1 Legal and Regulatory Compliance Policy

За МСП еквивалентната дисциплина започва с по-опростен регистър. SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME посочва:

„Управителят трябва да поддържа прост, структуриран Регистър на съответствието, който включва:“

Източник: Legal and Regulatory Compliance Policy-sme, Изисквания за управление, клауза 5.1.1 Legal and Regulatory Compliance Policy - SME

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

Изграждане на регистър на периодите на поддръжка на сигурността по CRA в една работна среща

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

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

Стъпка 1: Създайте регистър на периодите на поддръжка

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

• Продукт и версия
• Дата на издаване
• Начална дата на поддръжката
• Стандартна крайна дата на поддръжката на сигурността
• Вариант за разширена поддръжка
• Метод за доставка на актуализации
• Канал за оповестяване на уязвимости
• Целеви срок за критична корекция
• Роля при обработването на данни, например администратор, обработващ лични данни или и двете
• Критични доставчици и компоненти
• Засегнати клиентски сектори
• Собственик на риска
• Дата на одобрение
• Местоположение на доказателствата

Този регистър става документирана информация в рамките на СУИС. Zenith Blueprint, фаза „Основа и ръководство на СУИС“, стъпка 6, задава очакването за контрол на документите:

„Документите трябва да имат подходяща идентификация (заглавие, евентуално номер на документ или уникален идентификатор, автор), подходящ формат и преглед и одобрение за пригодност преди използване.“

Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Основа и ръководство на СУИС“, стъпка 6: Документирана информация и изграждане на библиотеката на СУИС Zenith Blueprint

Enterprise PIMS Documented Information Evidence Management Policy на Clarysec PIMS Documented Information Evidence Management Policy прилага сходни принципи за доказателства към документацията за поверителност:

„[All] Ръководителят по поверителност / Мениджърът на PIMS ТРЯБВА да присвои идентификатор на документ, собственик, номер на версия, статус на одобрение, дата на влизане в сила и дата за преглед в REG12 преди публикуване на документирана информация на PIMS.“

Източник: PIMS Documented Information Evidence Management Policy, Създаване, одобряване, управление на версиите и публикуване, клауза 4.2.1 PIMS Documented Information Evidence Management Policy

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

Стъпка 2: Свържете обещанията за поддръжка с третирането на риска

За всяка версия на продукт създайте рискови сценарии, например:

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

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

За риска „неподдържан компонент преди крайната дата на поддръжката“ записът за риска следва да включва контроли 5.31, 8.8 и 8.25 по ISO/IEC 27002:2022, плюс контроли за доставчици като 5.19 Информационна сигурност във взаимоотношенията с доставчици, 5.20 Адресиране на информационната сигурност в споразуменията с доставчици, 5.21 Управление на информационната сигурност в ИКТ веригата на доставки и 5.22 Мониторинг, преглед и управление на промените в услугите на доставчици.

Стъпка 3: Определете правила за доказателства при уязвимости и корекции

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

SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME задава строго изискване за спешна експозиция:

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

Източник: Vulnerability and Patch Management Policy-sme, Изисквания за прилагане на политиката, клауза 6.1.1 Vulnerability and Patch Management Policy - SME

Тя изисква и записи, готови за одит:

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

Източник: Vulnerability and Patch Management Policy-sme, Изисквания за управление, клауза 5.4.1 Vulnerability and Patch Management Policy - SME

За корпоративни среди Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy изисква:

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

Източник: Vulnerability and Patch Management Policy, Изисквания за управление, клауза 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, фаза „Контроли в действие“, стъпка 19, обяснява оперативното очакване зад контрол 8.8 по ISO/IEC 27002:2022:

„Бъдете информирани за нови слабости в сигурността (чрез предупреждения от доставчици, CVE потоци и др.) за вашия софтуер и хардуер. Оценявайте кои са релевантни (използваме ли този софтуер? колко критична е слабостта?) и своевременно прилагайте корекции или мерки за смекчаване.“

Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Контроли в действие“, стъпка 19: Технологични контроли I Zenith Blueprint

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

Стъпка 4: Свържете сигурната разработка с продължителността на поддръжката

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

SME Secure Development Policy-sme Secure Development Policy - SME посочва:

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

Източник: Secure Development Policy-sme, Изисквания за прилагане на политиката, клауза 6.6.3 Secure Development Policy - SME

SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME изисква договорите и изискванията да:

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

Източник: Application Security Requirements Policy-sme, Изисквания за управление, клауза 5.3.2 Application Security Requirements Policy - SME

Ако компанията обещава поддръжка до 2031 г., архитектурата трябва да поддържа изпълними актуализации, замяна на зависимости, сигурни пайплайни за компилация, регресионно тестване и аварийни версии. Контролите по ISO/IEC 27002:2022 за сигурна разработка, сигурна архитектура, сигурно програмиране, тестване на сигурността, външна разработка, разделяне на среди и управление на промените се превръщат във фактори, които правят периода на поддръжка изпълним.

Един набор от доказателства за CRA, NIS2, DORA и GDPR

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

Зависимостта от доставчици често е мястото, където ангажиментите за поддръжка се провалят. Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy изисква:

„Регистър на зависимостите от доставчици: VMO трябва да поддържа актуален регистър на всички критични доставчици, включително подробности като предоставяни услуги/продукти; дали доставчикът е единствен източник; налични алтернативни доставчици или възможност за замяна; текущи договорни условия; и оценка на въздействието, ако доставчикът откаже или бъде компрометиран.“

Източник: Supplier Dependency Risk Management Policy, Изисквания за внедряване, клауза 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, предупреждава, че одиторите ще проверяват споразуменията с доставчици и доказателствата за мониторинг на доставчици:

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

Източник: Zenith Blueprint: An Auditor’s 30-Step Roadmap, фаза „Контроли в действие“, стъпка 23: Организационни контроли Zenith Blueprint

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

Съпоставка на контролите за готово за одит управление на периода на поддръжка

Тази съпоставка позволява на екипите по сигурност, правни въпроси, продукт и продажби да говорят на един език. Регистърът на периодите на поддръжка не е само доказателство по CRA. Той е уверение от доставчици за NIS2, уверение от трети страни за DORA, подкрепа за сигурността на обработването по GDPR и управленски артефакт за сертификация по ISO 27001.

Ъгълът на поверителността: когато неподдържаното става небезопасно

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

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

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

Enterprise PII Security Access Control Policy на Clarysec PII Security Access Control Policy изисква:

„[Both] Собственикът на системата / собственикът на приложението ТРЯБВА да записва покритието на оценките на уязвимости за системи, обработващи PII, в REG12 поне на тримесечна база и след съществена техническа промяна.“

Източник: PII Security Access Control Policy, Сигурна конфигурация и управление на уязвимости, клауза 4.7.4 PII Security Access Control Policy

Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy добавя текущ мониторинг за високорискови взаимоотношения, свързани с поверителността:

„[All] Собственикът по доставчици / снабдяване ТРЯБВА да наблюдава активните високорискови взаимоотношения с обработващи лични данни и подизпълнители по обработване на тримесечна база, а другите активни взаимоотношения с обработващи PII и подизпълнители по обработване — ежегодно, спрямо условията на надлежна проверка, статуса на договора, статуса на уверението, отворените въпроси и датите за преглед в REG08.“

Източник: Processor Subprocessor Third Party Privacy Management Policy, Текущ мониторинг, съдействие, интерфейс за разкриване и изход, клауза 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Когато уязвимост се превърне в инцидент, Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy изисква оценка на критерии за задействане по множество рамки:

„[Conditional] Ръководителят по поверителност / Мениджърът на PIMS ТРЯБВА да оцени приложимите правни, секторни, финансово-секторни, киберсигурностни, договорни, клиентски и свързани с получатели на услуги критерии за докладване за всеки инцидент с лични данни с високо въздействие и да запише резултата за приложимост в REG01, REG08 и REG10.“

Източник: PII Incident Breach Management Policy, Класификация и оценка на нарушение, клауза 4.2.6 PII Incident Breach Management Policy

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

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

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

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

Одиторите в стил COBIT и ISACA често се фокусират върху дизайна на управлението: кой притежава решението, какъв процес е дефиниран, какви показатели показват резултатност, как се одобряват изключенията и как се управлява непрекъснатото подобрение.

Enterprise Information Security Policy на Clarysec Information Security Policy формулира принципа за одитируемост:

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

Източник: Information Security Policy, Изисквания за прилагане на политиката, клауза 6.6.1 Information Security Policy

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

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

Най-трудните управленски моменти не са при старта на продукта. Те настъпват, когато реалността се промени.

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

Контролирана промяна на периода на поддръжка следва да включва:

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

Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy е полезна, когато промяната е предизвикана от уязвимост:

„За всички потвърдени уязвимости следва да бъде разработен план за отстраняване или смекчаване. Внедряването на корекцията следва да се приоритизира според степента на сериозност. Например критичните уязвимости следва да бъдат отстранени или смекчени в рамките на 14 дни, когато е осъществимо, или по-рано при установена активна експлоатация, докато проблемите с по-ниска степен на сериозност следва да бъдат адресирани в разумен срок.“

Източник: Coordinated Vulnerability Disclosure Policy, Изисквания за внедряване, клауза 6.6 Coordinated Vulnerability Disclosure Policy

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

Практически контролен списък на Clarysec за готовност на периода на поддръжка

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

• Вписани ли са продуктът и версията в регистъра на периодите на поддръжка?
• Одобрена ли е крайната дата на поддръжката от продукта, сигурността и отчетното ръководство?
• Съпоставени ли са правните, регулаторните и договорните основания в регистъра на съответствието?
• Включен ли е рисковият сценарий за периода на поддръжка в Регистъра на риска?
• Съпоставени ли са контролите в Декларацията за приложимост, включително 5.31, 8.8 и 8.25, когато са приложими?
• Съпоставени ли са критичните доставчици и компоненти в регистъра на зависимостите от доставчици?
• Има ли доказателства, че компонентите могат да бъдат коригирани или заменени през периода на поддръжка?
• Дефинирани ли са отговорностите за приемане, триаж, отстраняване и оповестяване на уязвимости?
• Съгласувани ли са SLA за критични корекции с политиката и договорите с клиенти?
• Съхраняват ли се журнали за корекции, записи за версии и решения за уязвимости?
• Покрити ли са системите с лични данни от доказателства за оценка на уязвимости, когато се обработва PII?
• Последователни ли са уведомленията до клиенти, декларациите за поддръжка и договорните условия?
• Има ли процес за удължаване, съкращаване или прекратяване на поддръжката с одобрение по риска?
• Получават ли прегледите от ръководството входни данни за риска по периода на поддръжка, доставчици, уязвимости и инциденти?
• Могат ли доказателствата да бъдат предоставени в рамките на 48 часа за клиентски одит или запитване от регулатор?

Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy засилва дисциплината на прегледите от ръководството за програми за поверителност:

„[Both] Висшето ръководство ТРЯБВА да преглежда несъответствията в PIMS, коригиращите действия, резултатите от мониторинга, резултатите от одитите, риска за поверителността, уверението от доставчици и входните данни за промени при заинтересованите страни в REG12 по време на всеки преглед от ръководството.“

Източник: PIMS Monitoring Audit Improvement Policy, Преглед от ръководството на PIMS, клауза 4.3.5 PIMS Monitoring Audit Improvement Policy

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

Направете периода на поддръжка на сигурността защитим

EU Cyber Resilience Act променя начина на мислене за сигурността на продуктите. Той насочва производителите и доставчиците на софтуер да мислят отвъд деня на издаване. Периодът на поддръжка на сигурността се превръща в обещание през жизнения цикъл, което трябва да бъде инженерно осигурено, управлявано, наблюдавано и доказано.

За CISO изводът е ясен: не оставяйте периода на поддръжка само в продуктовия маркетинг. За мениджърите по съответствие: не изграждайте отделен силоз за доказателства по CRA. За одиторите: тествайте дали ангажиментите за поддръжка са проследими до риск, контроли, доставчици, инциденти и документирани одобрения. За собствениците на бизнеса: помнете, че надеждният период на поддръжка може да се превърне в пазарно предимство, особено при продажби към сектори, регулирани по NIS2, финансови субекти по DORA и клиенти с висока чувствителност към поверителността.

Clarysec помага на организациите да операционализират това чрез:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint за изграждане на проследимост в СУИС, документирана информация, съпоставяне със SoA и готовност за одит
• Zenith Controls: The Cross-Compliance Guide Zenith Controls за съпоставяне на контроли по ISO/IEC 27002:2022 с NIS2, DORA, GDPR, NIST CSF 2.0 и одиторски очаквания
• Пакети с политики за големи предприятия и МСП за управление на уязвимости, сигурна разработка, правно съответствие, зависимост от доставчици, доказателства за поверителност и реагиране при инциденти
• Практически регистри и работни потоци за доказателства, които превръщат обещанията за периоди на поддръжка в одитируемо управление

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

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

Изтеглете Zenith Blueprint, използвайте Zenith Controls, за да съпоставите доказателствата си, или поискайте оценка на готовността от Clarysec, за да превърнете периодите на поддръжка на сигурността по CRA в готово за одит управление по ISO 27001.