Що не можна робити згідно з Актом про кіберстійкість ЄС та як адаптуватися

Я вже кілька разів писав про Акт про кіберстійкість ЄС (CRA) у блозі Canonical. Зараз ідеальний час обговорити наслідки цього нового регулювання та його вплив на виробників IoT-пристроїв. Особливо важливо розглянути практичні аспекти проектування та створення Продуктів з Цифровими Елементами (PDE).

У цій статті я надам детальний огляд поширених практик виробників IoT та розробників PDE, які потребують негайної уваги. Також розгляну, як змінити або покращити ці практики, щоб ваші продукти залишилися на ринку ЄС з повною відповідністю CRA.

Що заборонено згідно з CRA (і що робити натомість)

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

Однак, незалежно від конкретних класифікацій, Акт про кіберстійкість вводить надзвичайно широкий набір змін у кібербезпеці IoT та PDE, які вплинуть на всіх учасників ринку.

Більше неможливо перекладати відповідальність на інших

Неможливо перекладати відповідальність за безпеку на користувачів або очікувати, що постачальники вирішать проблеми з вразливостями. Створення та продаж продуктів означає, що вас класифікуватимуть як виробника. Це накладає на вас підвищений рівень відповідальності щодо оцінки відповідності та вищі вимоги до PDE.

Якщо ви не хочете нести тягар відповідності як виробник, знайдіть постачальника, готового взяти цю відповідальність на себе.

Більше не можна ховатися за документацією або вважати її необов’язковою

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

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

Щодо документації, Акт про кіберстійкість встановлює суворіші вимоги до її підготовки та доступності. Загалом, CRA вимагає нових вимог до документації, з кращою комунікацією щодо доступу до неї. Ви повинні створювати ланцюг постачання програмного забезпечення та формальний перелік матеріалів програмного забезпечення (SBOM), який має бути доступним та машинозчитуваним.

Як мінімум, ви повинні мати наступні документи, доступні для громадськості та органів ЄС:

• Опис процесу проектування, розробки та усунення вразливостей
• Оцінка ризиків кібербезпеки
• Перелік гармонізованих стандартів кібербезпеки ЄС, яким відповідає продукт
• Підписана декларація відповідності ЄС про те, що основні вимоги виконано
• Перелік матеріалів програмного забезпечення (SBOM), що документує вразливості та компоненти продукту

Більше неможливо ховатися за наміром

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

Основи безпеки більше не є необов’язковими

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

Деякі основи кібербезпеки включають:

• Забезпечення максимальної безпеки продукту. Він повинен мати мінімальні поверхні атаки.
• Укріплення вашого пристрою або продукту. Його дані мають бути зашифровані або захищені, а несанкціонований доступ – заблокований.
• Запобігання простоям. Ваш пристрій повинен продовжувати працювати навіть під DDoS-атакою і не переривати роботу інших пристроїв.
• Відстеження активності. Ваш пристрій повинен надавати дані безпеки шляхом моніторингу або реєстрації змін.
• Проактивне виправлення. Ваш продукт повинен мати можливість отримувати оновлення безпеки або відкати. Це включає прямі чи віддалені оновлення, сповіщення користувачів про оновлення та можливість відкату оновлень.

Навіть без CRA ви повинні відповідати цим основним стандартам безпеки. Ось кілька кроків, які можна вжити для забезпечення надійності та безпеки ваших PDE:

• Впровадити