ISMS Copilot Docs

Закон ЄС про кіберстійкість (CRA)

Закон ЄС про кіберстійкість (CRA) — це майбутнє законодавство ЄС, яке встановлює обов’язкові вимоги до кібербезпеки для продуктів з цифровими елементами…

Закон ЄС про кіберстійкість (CRA) — це майбутнє законодавство ЄС, яке встановлює обов’язкові вимоги до кібербезпеки для продуктів з цифровими елементами (апаратне та програмне забезпечення), що розміщуються на ринку ЄС. Очікується, що CRA повністю набуде чинності у 2027 році та має на меті забезпечити безпеку продуктів за дизайном, підтримку безпеки виробниками протягом усього життєвого циклу продукту та прозорість щодо безпеки для споживачів.

CRA ще не повністю набув чинності. Терміни виконання вимог відрізняються залежно від типу вимог, повна відповідність очікується до кінця 2027 року. Слідкуйте за офіційними публікаціями ЄС щодо остаточного тексту та термінів впровадження.

Хто потребує відповідності CRA?

CRA поширюється на:

  • Виробників: Суб’єктів, які проектують, розробляють або виготовляють продукти з цифровими елементами для розміщення на ринку ЄС
  • Імпортерів: Бізнеси, які ввозять продукти з цифровими елементами до ЄС
  • Дистриб’юторів: Суб’єктів, які роблять продукти доступними на ринку ЄС
  • Кураторів відкритого ПЗ: Організації, які надають комерційну підтримку для продуктів з відкритим вихідним кодом (за певних умов)

До продуктів з цифровими елементами належать:

  • Програмне забезпечення (додатки, операційні системи, прошивки)
  • Апаратне забезпечення з вбудованим ПЗ (пристрої IoT, маршрутизатори, розумні прилади)
  • Підключені продукти (носії, промислові системи керування)

Сфера дії та винятки

Під дію закону підпадають: Комерційні продукти з цифровими елементами, розміщені на ринку ЄС, включаючи SaaS та хмарні сервіси, якщо вони містять компоненти завантажуваного ПЗ.

Винятки:

  • Медичні пристрої, авіаційні системи та автомобільні компоненти, які вже охоплені галузевими нормативними актами
  • Виключно некомерційне відкрите програмне забезпечення, розроблене або надане поза комерційною діяльністю
  • Продукти, призначені виключно для національної безпеки або оборони

Якщо ви розповсюджуєте відкрите програмне забезпечення без монетизації або комерційної підтримки, ви, ймовірно, звільнені від дії CRA. Якщо ви надаєте платну підтримку, SLA або корпоративні функції, CRA може поширюватися на вас.

Класифікація продуктів

CRA класифікує продукти за рівнем кібербезпеки:

  • Стандартні (Клас I): Базові вимоги до кібербезпеки, дозволена самооцінка
  • Важливі (Клас II): Продукти з підвищеним ризиком (управління ідентифікацією, VPN, управління мережами), що потребують оцінки відповідності третьою стороною
  • Критичні: Продукти з найвищим ризиком (захищені елементи, смарт-карти, системи PKI), що потребують суворої сертифікації третьою стороною

Більшість комерційних програмних продуктів належать до стандартної категорії.

Основні вимоги

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

Безпека за дизайном:

  • Відсутність відомих вразливостей, які можна експлуатувати, на момент виходу на ринок
  • Безпека, вбудована в архітектуру продукту та процес розробки
  • Мінімізація поверхні атаки та безпечні налаштування за замовчуванням
  • Захист даних та шифрування, де це доречно
  • Автоматичне оновлення безпеки або сповіщення користувачів про оновлення

Управління вразливостями:

  • Виявлення, документування та усунення вразливостей протягом усього періоду підтримки
  • Повідомлення про активно експлуатовані вразливості до ENISA протягом 24 годин після виявлення
  • Надання оновлень безпеки протягом очікуваного терміну служби продукту (мінімум 5 років для багатьох продуктів)
  • Ведення публічної політики розкриття вразливостей

Документація та прозорість:

  • Надання користувачам чіткої документації з безпеки
  • Публікація Декларації про відповідність ЄС
  • Нанесення маркування CE на відповідні продукти
  • Зберігання технічної документації протягом 10 років

Звітність про інциденти:

  • Повідомлення про активно експлуатовані вразливості та серйозні інциденти до ENISA
  • Сповіщення уражених користувачів про проблеми безпеки та доступні заходи захисту

Оцінка відповідності

Залежно від класу продукту, виробники повинні продемонструвати відповідність через:

  • Самооцінку (Клас I): Виробник проводить внутрішнє тестування та документування
  • Оцінку третьою стороною (Клас II/Критичні): Уповноважений орган оцінює відповідність перед виходом на ринок

Усі виробники повинні вести технічну документацію, що підтверджує відповідність, включаючи оцінки ризиків, результати тестування безпеки та записи про процес розробки.

Зобов’язання щодо підтримки

Виробники повинні забезпечувати підтримку безпеки протягом:

  • Очікуваного терміну служби продукту, АБО
  • Мінімум 5 років з моменту виходу на ринок (для більшості продуктів)

Це включає виправлення вразливостей, оновлення безпеки та реагування на інциденти. Продукти без постійної підтримки не можуть легально залишатися на ринку ЄС.

Штрафи

CRA встановлює значні фінансові штрафи:

  • Серйозні порушення (невідповідні продукти, відсутність маркування CE): До 15 мільйонів євро або 2,5% річного глобального обороту
  • Інші порушення (неповна документація, неспівпраця): До 10 мільйонів євро або 2% річного глобального обороту
  • Подання неправдивої інформації: До 5 мільйонів євро або 1% річного глобального обороту

Графік впровадження

Очікувані етапи виконання (можуть змінюватися залежно від публікації остаточного тексту регуляції):

  1. 2024-2025: Публікація регуляції, початок пільгового періоду
  2. 2026: Набуття чинності зобов’язань щодо звітності про вразливості
  3. 2027: Повна відповідність для нових продуктів, розміщених на ринку
  4. Після 2027: Існуючі продукти повинні дотримуватися зобов’язань щодо підтримки

Почніть готуватися вже зараз, впроваджуючи практики безпечної розробки, створюючи процеси управління вразливостями та документуючи архітектуру безпеки.

Як ISMS Copilot допомагає

ISMS Copilot може підтримати підготовку до відповідності CRA:

  • Загальні рекомендації з кібербезпеки: Дізнайтеся про практики безпечної розробки, управління вразливостями та безпеку протягом життєвого циклу
  • Розробка політик: Створення політик життєвого циклу безпечної розробки (SDLC) та політик розкриття вразливостей
  • Оцінка ризиків: Генерація оцінок ризиків безпеки продуктів відповідно до основних вимог
  • Шаблони документації: Розробка структур документації з безпеки для оцінки відповідності
  • Аналіз прогалин: Завантажте існуючі політики розробки для виявлення прогалин щодо принципів CRA

Хоча ISMS Copilot не має спеціалізованих знань щодо CRA (регуляція ще доопрацьовується), ви можете запитати про контролюючі заходи безпечної розробки ISO 27001 та загальні найкращі практики безпеки продуктів, які відповідають цілям CRA.

Спробуйте запитати: "Створіть політику розкриття вразливостей для програмного продукту" або "Які принципи безпеки за дизайном для розробки продуктів?"

Початок роботи

Для підготовки до відповідності CRA:

  1. Оцініть, чи підпадають ваші продукти під дію CRA та визначте їхню класифікацію
  2. Впровадьте практики життєвого циклу безпечної розробки (моделювання загроз, тестування безпеки, перевірка коду)
  3. Створіть процеси управління та розкриття вразливостей
  4. Сплануйте довгострокову підтримку безпеки (5+ років)
  5. Документуйте архітектуру безпеки та оцінки ризиків
  6. Слідкуйте за публікаціями ENISA та офіційними джерелами ЄС щодо остаточних вимог і рекомендацій

Пов’язані ресурси

На цій сторінці