EU Cyber Resilience Act (CRA): що робити і як бути в комплаєнсі

Про що цей регламент?

CRA (Regulation (EU) 2024/2847), Cyber Resilience Act) – це регламент, який встановлює обовʼязкові вимоги до безпеки обладнання (hardware) та програмного забезпечення (software), які виходять на європейський ринок. Іншими словами, цей акт мають враховувати виробники, імпортери, дистрибʼютори та інші економічні оператори, що планують, дизайнять, розробляються або підтримують “продукти з цифровими елементами” (products with digital elements). 

Дедлайн, до якого треба підготуватися – це 11 грудня 2027 року (ще півтора роки на підготовку!). Але навіщо відкладати так надовго, адже обовʼязків так багато! 

Що врегульовує CRA? 

CRA застосовується до products with digital elements (продуктів з цифровими елементами), які в свою чергу можуть також бути: 

• важливими продуктами з цифровими елементами (important products with digital elements), 
• високоризиковими ШІ-системами (high-risk AI systems)

“Прості” продукти з цифровими елементами можуть бути допущені на ринок ЄС за умов, що вони виконують достатній рівень кібербезпеки, в залежності від проведеної оцінки ризиків. Іншими словами, перш ніж виходити на ринок (за виключенням тестувань), компанії доведеться: 

1. Провести оцінку ризиків. 
2. В залежності від того, які ризики будуть виявлені під час оцінки – вбудувати в дизайн, розробку або виробництво продуктів (і софту, і хардверу) відповідні засоби захисту систем і даних, перераховані у Додатку І. 

Які засоби захисту вимагає CRA? 

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

До властивостей продукту можна віднести наступні вимоги: 

• налаштування продукту, що відразу виставлені на найбільш безпечні опції (secure by default); 
• стратегія оновлень (апдейтів), яка:
  • автоматизована (за можливості), і при цьому
  • увімкнена за замовчуванням, 
  • з можливістю легко відімкнути автоматичні оновлення, 
  • з повідомленням користувачів про оновлення, та 
  • опцією тимчасово відкласти це оновлення;  
• захист від неавторизованого доступу: аутентифікація, IAM, звіти про неавторизований доступ; 
• захист конфіденційності та цілісності даних (stored, transmitted or otherwise processed – тобто статичних у сховищах чи динамічних в процесі переміщення з одного сервісу в інший); при цьому це не лише персональні дані; 
• при цьому слід зберігати цілісніть не тільки даних, а й команд, програм та конфігурацій; 
• мінімізація даних (тобто допускати до обробки продуктом тільки ті дані, що необхідні для очікуваної цілі цього продукту); 
• особлива увага до доступності базових та істотних (essential) функцій, особливо у випадку інцидентів (наприклад, захист основної функціональності від підриву через DDoS-атаку); 
• менеджмент ресурсів: забезпечення роботи вашого продукту таким чином, щоб вони або їхні підʼєднані девайси не робили інші продукти або мережі недоступними; 
• мінімізація поверхні для атаки (особливо для зовнішніх інтерфейсів); 
• створення механізмів та технік для мінімізації впливу інцидентів на роботу продукту; 
• створення та надання інформації про безпеку: зокрема, через запис і моніторинг активностей “під капотом” продукту – доступ та зміни даних, сервісів чи функцій, – з можливістю для користувача відписатися від сповіщень; 
• надання опції для користувача безпечно і надійно видалити всі дані та налаштування, а якщо можливо – безпечно перенести ці дані або налаштування на інший продукт або систему. 

При цьому на всі продукти поширюється також обовʼязок створити ефективні процеси роботи з вразливостями продукту, зокрема:

• створити і підтримувати в актуальному стані перелік залежностей та компонентів продукту (dependencies and components) – зокрема, у формі SBOM (software bill of materials) і хоча б для найважливіших залежностей; 
• відразу опрацьовувати та закривати виявлені вразливості (через апдейти), і при цьому старатися надавати безпекові оновлення продуктів окремо від функціональних; 
• регулярно і старанно (буквально “ефективно”) тестувати безпеку; 
• після випуску апдейту з патчем надавати інформацію про виправлені вразливості:
  • опис вразливості, 
  • які продукти містили вразливості, 
  • вплив цих вразливостей, 
  • серйозність (severity) та способи закриття цієї вразливості; 
• створити, викласти і підтримувати політику з розкриття вразливостей, у тому числі – створювати канали для повідомлення про потенційні вразливості від власних чи сторонніх компонентів у продуктах; 
• створити механізми для безпечної і вчасної доставки апдейтів, бажано автоматизованої; 
• побудувати процес поширення доступних патчів для вразливостей, бажано безкоштовно і у супроводі інформації для користувача щодо наступних кроків. 

Іншими словами, багатьом компаніям необхідно буде переглянути свою ISMS та GDPR compliance program та включити туди нові процеси та інструменти. 

Що за “важливі продукти з цифровими елементами” (important products with digital elements)? 

Це особливий перелік софту або хардвера, який міститься у Додатку ІІІ регламенту. Спільного у них те, що це інструменти для безпеки або функціональні компоненти систем (наприклад, сервіси контейнеризації, віртуальні машини, мікроконтролери тощо). 

Вони поділяються на два класи: 

• клас 1: продукти для захисту інших продуктів, мереж чи сервісів, 
• клас 2: продукти, що забезпечують центральні функції систем, управління мережами, контроль конфігурацій, віртуалізацію або обробку персональних даних (так, це прямо в регламенті говориться!). 

До важливих продуктів з цифровими елементами класу 1 (продукти для захисту інших продуктів, мереж чи сервісів) регламент відносить: 

• системи управління правами доступу (ПЗ та обладнання), у тому числі біометричні рідери; 
• браузери (окремі та вбудовані), 
• менеджери паролів, 
• антивіруси / антималвар-програми, 
• продукти з функціями VPN, 
• системи управління мережами, 
• системи управління запуском операційних систем (boot systems), 
• системи управління безпековою інформацією та подіями (тобто SIEM),
• інфраструктура довірчих послуг (PKI, випуск цифрових сертифікатів), 
• фізичні та віртуальні мережеві інтерфейси, 
• операційні системи, 
• роутери, модеми для виходу в інтернет, світчі, 
• мікропроцесори та мікроконтролери з безпековими функціями, 
• безпекові ASIC та FPGA, 
• загальноцільові віртуальні асистенти для розумних будинків, інші продукти для розумних будинків (смарт-замки, камери, відеоняні, сповіщення про небезпеку), 
• підʼєднані до інтернету іграшки з функціями соціалізації (відеозапис, підтримка розмови) або геолокацією, 
• особисті натільні продукти (wearables), які носять на або у тілі з моніторингом здоровʼя (у тому числі трекінгом), які не підпадають під MDR, або для дітей. 

Важливі продукти з цифровими елементами класу 2 включають в себе чотири категорії:

• гіпервізори, контейнерні системи, які здатні містити і підтримувати операційні системи чи аналогічні середовища, 
• фейрволи, системи для виявлення та попередження вторгнень (IDS, IPS), 
• мікропроцесори та мікроконтролери з захистом від вторгнень.  

Якщо ж ваша компанія створює апаратні пристрої з блоками безпеки (hardware with security boxes), розумні шлюзи для смарт-лічильників, смарт-картки або інші схожі девайси – то ваша продукція буде вважатися критичним продуктом з цифровими елементами; це тягне за собою додаткові обовʼязки. 

Знайшли свої продукти серед заявлених? Тепер ви знаєте, що CRA compliance буде серед ваших планів на цей рік. 

Які обовʼязки створює CRA для компаній? 

Спочатку треба встановити вашу роль: 

• виробника продуктів (manufacturer), 
• імпортер, 
• дистрибʼютор, чи й взагалі
• стюард опенсорсу? 

Обовʼязки кожної з цих ролей будуть відрізнятися. 

Виробник (manufacturer) має наступні обовʼязки:

• мати докази, що у продуктах були втілені засоби захисту класів 1 та 2 з додатку 1 (детальніше у розділі “Які засоби захисту вимагає CRA?” цієї статті) у формі задокументованої оцінки ризиків, посилань на цю оцінку у документах щодо планування, дизайну, розробки, створення, виробництва, доставки та підтримки продуктів, 
• дати докази, що оцінка ризиків проводиться регулярно і враховує щонайменше наступні фактори:
  • очікувана ціль та способи використання продукту, 
  • умови та середовище, в яких буде використовуватися продукт, 
  • очікуваний час роботи продукту, 
  • перелік засобів з додатку 1 і висновок щодо їхньої застосовності до продукту та як вони втілені у продукті, 
  • опис налаштувань за замовчуванням та політика щодо розкриття і закриття вразливостей; 
• постійно підтримувати продукт у стані комплаєнсу з вимогами, особливо якщо він знає чи має підстави вважати, що продукт не в комплаєнсі, і якщо не може виправити невідповідність у найкоротші строки – відкликати продукт з ринку,
• створити зрозумілі та доступні мануали та інші інформаційні матеріали для користувачів, 
• створити технічну документацію для продукту перед розміщенням на ринку, і за необхідності – провести оцінку відповідності (conformity assessment), 
• чітко повідомити користувачів про дату завершення періоду підтримки, якщо це можливо – розмістивши дату прямо на продукті,
• надати копію оцінки відповідності (або посилання на сторінку, де можна побачити цю оцінку), 
• зберігати технічну документацію (та оцінку відповідності) і матеріали для користувачів не менш ніж 10 років з моменту розміщення продукту на ринку, але точно до кінця періоду підтримки; 
• зробити оцінку ризиків частиною технічної документації продукту, яка готується для виходу на ринок, 
• мати докази проведеної оцінки інтегрованих у продукт сторонніх компонентів (у тому числі опенсорсу), 
• мати докази того, що виробник (а) повідомив виробнику або підтримувачу стороннього компонента (у тому числі опенсорс-стюарду) про виявлені у компоненті вразливості, (б) що всі виявлені вразливості були закриті виробником, а (в) код чи документація з описом цієї модифікації були надані власнику компонента; 
• мати докази того, що заходи для закриття вразливостей є ефективними і охоплюють як час перебування продукту на ринку, так і час підтримки продукту (і що час обіцяної підтримки відповідає очікуванням користувачів; при цьому цей строк зазвичай не може бути меншим 5 років, за деякими винятками), 
• включити задокументовану оцінку часу підтримки продукту у технічну документацію, 
• мати необхідні політики та процедури для роботи зі вразливостями, 
• забезпечити доступ до безпекових апдейтів (якщо були видані вже під час періоду підтримки – не менш ніж 10 років після випуску чи до кінця періоду підтримки), 
• дбати про відповідність вимогам безпеки щодо всіх версій продукту у випадку його суттєвої модифікації; обмежити цей обовʼязок тільки до останньої версії можна тільки у тому випадку, якщо оця остання модифікація доступна користувачам попередніх версій, є безкоштовною для них і при цьому не вимагає змін у хардвері чи софті порівняно з оригінальною версією, 
• якщо у виробника є архів з історичними версіями – повідомити користувачів про небезпеку використання продуктів, строк підтримки яких завершився, 
• присвоювати і розміщувати на продуктах якийсь ідентифікатор (наприклад, серійний номер) та інформацію про виробника – зокрема, його назву, контактні деталі та сайт для звʼязку, 
• призначити контактну особу для спілкування з користувачами продуктів та отримання звітів про вразливості, дати контактні дані цієї особи користувачам та можливість вибору каналів комунікації з нею (заборонено використовуватия для цього виключно автоматизовані інструменти), та представника для спілкування з наглядовим органом, 
• виконувати вимоги наглядового органу (надавати документи та співпрацювати), 
• заздалегідь повідомити про вихід з ринку або припинення діяльності наглядовий орган та, якщо це можливо – користувачів, 
• повідомляти CSIRT або ENISA та користувачів про використовувану вразливість їхнього продукту та надавати потрібну для реагування інформацію про продукт, вразливість та обставини інциденту і кроки щодо виправлення ситуації та співпрацювати з призначеним координатором. 

Обовʼязки імпортерів: 

• ввозити на ринок тільки ті продукти, що відповідають регламенту: де є особливості дизайну і роботи, передбачені класом 1, і підтримка виробника у роботі з вразливостями, передбачена класом 2, 
• провести (і задокументувати) оцінку продукту перед розміщенням на ринку, зокрема:
  • чи виробник провів conformity assessment, 
  • чи виробник склав технічну документацію, 
  • що conformity assessment та інструкції для користувачів викладені мовою, зрозумілою для користувачів та наглядового органу, 
  • на продуктах є серійний номер чи інший ідентифікатор, інформація про виробника та спосіб звʼязку з ним, та дата припинення підтримки продукту виробником,
• не розміщувати на ринку продукт, у якому є відомі імпортеру вразливості чи інші порушення регламенту, допоки виробник не виправить ці недоліки,
• після розміщення на ринку вживати заходів для приведення продукту назад у стан відповідності з регламентом, якщо виявить недоліки або матиме ґрунтові підозри у наявності таких недоліків – наприклад, повідомляти про це виробника або відкликати з ринку продукт, 
• повідомити наглядовий орган, якщо імпортер має підстави вважати, що продукт становить серйозний ризик кібербезпеці,у тому числі з нетехнічних причин, 
• вказати інформацію про себе як про імпортера та свої контактні дані зрозумілою для користувача і наглядового органу мовою, 
• зберігати до кінця періоду підтримки (але не менше 10 років) інформацію про оцінку відповідності та технічну документацію – і надавати їх на вимогу наглядовому органові, 
• повідомляти наглядовий орган та користувачів, якщо стало відомо, що продукт або виробник припинив діяльність і не буде надалі підтримувати комплаєнс з регламентом.

Обовʼязки дистрибʼюторів: 

• діяти добросовісно (act with due care), 
• верифікувати CE marking, 
• переконатися, що виробник і дистрибʼютор виконали свої обовʼязки за регламентом та надали дистрибʼютору всі необхідні документи, 
• не реалізовувати продукти, у яких є порушення регламента (принаймні допоки виробник не виправить ситуацію), 
• за потреби повідомляти наглядовий орган про ризик, невідповідність продукта регламенту, а також дії для виправлення ситуації, 
• співпрацювати з наглядовим органом, у тому числі надавати потрібну інформацію, 
• повідомляти регулятора та користувачів, що продукт або виробник припинили діяльність і не будуть підтримувати комплаєнс. 

Імпортер або дистрибʼютор (та і будь-яка інша особа) можуть стати виробником, якщо розміщують продукт на ринку від власного імені або суттєво модифікують продукт після його розміщення на ринку. 

Особливі обовʼязки також виникають у стюардів опенсорсу: 

• створити та розмістити політику кібербезпеки для допомоги розробникам продуктів, і у цій політиці висвітлити:
  • документування та роботу з вразливостями, та 
  • заохочувати до обміну інформацією щодо знайдених вразливостей. 
• співпрацювати з наглядовими органами, у тому числі повідомляти CSIRT/ENISA/наглядовий орган/користувачів, якщо були виявлені особливо серйозні інциденти.

Але ці обовʼязки поширюються на них тільки до того степеня, до якого вони залучені в розробку продукту з цифровим елементом. 

А що буде, якщо порушувати CRA? 

Штрафи!

За порушення вимог до виробників продуктів: 15 млн євро або до 2,5% річного глобального обороту.

За порушення під час:

• призначення авторизованого представника відповідно до статті 18, 
• виконання обовʼязків імпортерів, дистрибʼюторів, інших економічних операторів (статті 19-23), 
• складання і підтримки декларацій відповідності, 
• накладання СЕ-маркування, 
• створення технічної документації та деякі інші порушення, 

10 млн євро або 2%. 

Надання неточної, неповної або умисно неправдивої інформації регулятору на його запит: 5 млн євро або 1%. 

То що робити? 

Чеклист дій схожий з іншими комплаєнс-системами, але є і свої особливості: 

1. Зрозуміти, чи компанія – або хоча б якийсь з її продуктів, – підпадає під CRA:
   1. Чи є продукт “продуктом з цифровим елементом”? 
   2. Чи потрапляє продукт під “важливий” або “критичний” критерій? 
   3. Чи є у виробника намір вийти на європейський ринок? 
   4. Яку роль виконує компанія – виробник, дистрибʼютор, імпортер, опенсорс-стюард, інший економічний агент? 
2. Зрозуміти стан кібербезпеки:
   1. Чи виконується перелік вимог до мінімального рівня кібербезпеки (з класу 1)? 
   2. Чи існує процес роботи з вразливостями (з класу 2)?
   3. Чи створені інструкції для користувача? Чи прикладені вони до продукту? 
   4. Чи існує вся потрібна технічна документація? 
   5. Чи призначені потрібні представники або контактні особи? 
   6. Чи складено декларацію про відповідність / проставлено СЕ-маркування? 
   7.  Чи позначено період підтримки? 
   8. Чи складено перелік залежностей і чи всі опенсорс-елементи містять потрібну документацію? 
3. Зрозуміти, чи вся складена документація відповідає вимогам CRA, і якщо ні – поправити це. 
4. Зрозуміти, чи потребує декларація відповідності сертифікації, і якщо так – то чи існує уже порядок і призначений сертифікаційний орган, та які вимоги до сертифікації у цього органу. 
5. Якщо компанія належить до SME – чи може вона скористатися пільгами від держави на прохоження сертифікації. 

А далі – бути уважними і приділяти увагу скаргам від користувачів, повідомленням від партнерів / опенсорс-стюардів, листам від органів та CSIRT/ENISA, та запитам від органів захисту персональних даних; а якщо бізнес припиняє свою роботу – не забувати повідомити про це користувачів напряму або через орган, щоб сприяти загальному стану безпеки.