Соблюдение Закона ЕС о киберустойчивости (CRA): комплексное руководство

Подключенные к сети продукты становятся частью практически каждой категории потребительских и промышленных товаров. Умная бытовая техника, камеры видеонаблюдения, носимые устройства, сетевое оборудование, мобильные приложения, встроенное программное обеспечение и продукты, подключенные к облаку, — все это может создавать риски кибербезопасности, если их конструкция, обслуживание и обновление не осуществляются безопасным образом.

Европейский союз ответил следующим образом: Закон о киберустойчивости, официально известный как Регламент (ЕС) 2024/2847.

Закон о киберустойчивости (Cyber ​​Resilience Act, CRA) вводит обязательные требования к кибербезопасности для аппаратных и программных продуктов, размещаемых на рынке Европейского союза. Он превращает кибербезопасность из преимущественно добровольной технической практики в формальное обязательство по соблюдению требований к продукции.

Производители обязаны оценивать риски кибербезопасности, внедрять средства защиты в продукцию, документировать соответствие требованиям, управлять уязвимостями, предоставлять обновления безопасности и, при необходимости, сообщать об активно используемых уязвимостях и серьезных инцидентах безопасности.

Для многих продуктов соответствие требованиям CRA также станет частью процесса маркировки CE.

Что такое Закон ЕС о киберустойчивости?

Закон о киберустойчивости — это универсальный регламент ЕС по кибербезопасности продукции. Он широко применяется к аппаратным и программным продуктам с цифровыми элементами, которые поставляются на рынок Европейского союза.

Его цель — обеспечить безопасную разработку продуктов и сохранение их безопасности на протяжении всего предполагаемого периода использования. Он также призван предоставлять пользователям более четкую информацию о безопасности продуктов, доступных обновлениях и продолжительности поддержки в области кибербезопасности.

Закон о реинвестировании в сообщества (CRA) решает две повторяющиеся проблемы на рынке цифровых продуктов:

1. Зачастую на рынок поступают товары с недостаточной защитой от киберугроз или с известными уязвимостями.
2. Производители могут предоставлять недостаточное количество обновлений безопасности, информации об уязвимостях или послепродажной поддержки после продажи продукта.

В соответствии с Законом о кибербезопасности (CRA) производители обязаны учитывать кибербезопасность на всех этапах планирования, проектирования, разработки, производства, поставки и обслуживания продукции. Таким образом, кибербезопасность больше не ограничивается заключительным тестированием на проникновение или предпусковой проверкой. Она должна быть интегрирована в жизненный цикл продукта.

Более подробная информация доступна в Краткое изложение Закона Европейской комиссии о киберустойчивости.

В каких случаях применяется Закон о киберустойчивости?

Закон о гражданстве вступил в силу с 10 декабря 2024 г., но его требования применяются поэтапно.

• 11 июня 2026 г.: Вступают в силу положения, касающиеся уведомления органов по оценке соответствия.
• 11 сентября 2026 г.: Вступают в силу обязательства по сообщению об активно используемых уязвимостях и серьезных инцидентах безопасности.
• 11 декабря 2027 г.: Большинство оставшихся требований CRA становятся полностью применимыми.

Продукция, выпущенная на рынок ЕС до 11 декабря 2027 года, как правило, подпадает под основные требования CRA только в том случае, если она претерпела существенные изменения после этой даты. Однако обязательства по отчетности, действующие с 11 сентября 2026 года, могут также затронуть продукцию, которая уже была представлена ​​на рынке ЕС.

Производителям не следует ждать декабря 2027 года, чтобы начать подготовку. Создание безопасного процесса разработки, составление спецификации программного обеспечения, проведение тестирования на кибербезопасность и внедрение процедур сообщения об уязвимостях могут занять значительное время.

На какие товары распространяется действие Закона о реинвестировании в сообщества (CRA)?

Закон о налоговых льготах (CRA) обычно применяется к продукт с цифровыми элементами К предполагаемому назначению или разумно предвидимому использованию относится прямое или косвенное логическое или физическое подключение к устройству или сети для передачи данных.

Продукт, содержащий цифровые элементы, может включать в себя:

• Аппаратный продукт
• Программный продукт
• Аппаратные или программные компоненты продаются отдельно.
• Встроенное микропрограммное обеспечение
• Решения для удаленной обработки данных, необходимые для выполнения продуктом одной из его функций.

Удалённая обработка данных может включать в себя облачный сервис, контролируемый производителем, отсутствие которого помешало бы продукту выполнять одну из его предполагаемых функций.

Примеры потенциально покрываемых страховкой продуктов

В зависимости от их функций и способа поставки, к товарам, подпадающим под действие Закона о защите прав потребителей, могут относиться:

• Устройства Интернета вещей
• Товары для умного дома
• Подключенная бытовая техника
• Интеллектуальные камеры видеонаблюдения и системы сигнализации
• Умные замки
• Игрушки с подключением к интернету
• Носимые устройства
• Маршрутизаторы, модемы и сетевые коммутаторы
• Компьютеры, смартфоны и планшеты
• Внешние устройства хранения данных
• Сетевые интерфейсные продукты
• Продукция промышленного контроля
• Подключенные датчики
• системы контроля доступа
• Операционные системы
• Мобильные и настольные приложения
• менеджеры паролей
• Программное обеспечение виртуальной частной сети
• Межсетевые экраны
• Антивирусное программное обеспечение и программное обеспечение для обнаружения вредоносных программ
• Встроенное программное обеспечение и микропрограммы
• Библиотеки программного обеспечения и коммерческие программные компоненты
• Видеоигры и другое автономное программное обеспечение

Определение намеренно широкое. Продукту не обязательно подключаться напрямую к интернету. Достаточно косвенного подключения к другому устройству или сети.

Например, продукт с поддержкой Bluetooth, подключающийся к приложению на смартфоне, может подпадать под действие Закона о реинвестировании в сообщества (CRA), даже если сам продукт не подключается напрямую к интернету.

Распространяется ли Закон о реинвестировании в сообщества (CRA) на автономное программное обеспечение?

Да. Автономное программное обеспечение, доступное на рынке ЕС, может подпадать под действие Закона о защите прав потребителей.

Это может включать в себя:

• Мобильные приложения
• Настольные приложения
• Операционные системы
• Программное обеспечение для обеспечения безопасности
• Коммерческие программные библиотеки
• Программное обеспечение для управления устройствами
• Инструменты управления сетью
• Программное обеспечение продается через платформы для скачивания.
• Программное обеспечение поставляется без отдельного физического устройства.

Распространяется ли действие страхового покрытия на программное обеспечение, зависит от способа его поставки, от того, предоставляется ли оно в рамках коммерческой деятельности, и от того, применяется ли какое-либо конкретное исключение.

Программное обеспечение, предоставляемое исключительно в качестве услуги, может потребовать более детальной оценки. Закон о регулировании потребительских товаров (CRA) обычно не регулирует все схемы предоставления программного обеспечения как услуги, но функциональность удаленной обработки данных, необходимая для выполнения одной из функций продукта, подпадающего под действие закона, может являться частью продукта с цифровыми элементами.

Какие товары исключены из акции?

Некоторые категории товаров исключены из регулирования или регулируются другими отраслевыми законами ЕС.

В зависимости от обстоятельств, исключения могут применяться к товарам, на которые распространяется законодательство, регулирующее:

• Медицинские устройства
• Медицинские изделия для диагностики in vitro
• Гражданская авиация
• Автомобили
• Определенное морское оборудование
• Продукция, разработанная исключительно в целях национальной безопасности или обороны.
• Определенное свободное программное обеспечение с открытым исходным кодом, предоставляемое вне рамок коммерческой деятельности.

К вопросам, касающимся программного обеспечения с открытым исходным кодом, следует подходить с особой осторожностью. Программное обеспечение, распространяемое вне коммерческой деятельности, может быть исключено из сферы действия Закона о реинвестировании в сообщества (CRA), в то время как коммерчески поставляемые продукты с открытым исходным кодом и некоторые ответственные лица за программное обеспечение с открытым исходным кодом могут нести обязательства в соответствии с Законом о реинвестировании в сообщества (CRA).

Продукт не следует считать исключенным из действия законодательства только потому, что на него распространяется действие другого закона ЕС. Производители должны проверить, охватывает ли другое законодательство конкретные требования кибербезопасности и предусматривает ли Соглашение о кибербезопасности полное или частичное исключение.

Кто является производителем в соответствии с Законом о реинвестировании в сообщества (CRA)?

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

Таким образом, компания может считаться производителем даже в следующих случаях:

• Физический продукт изготавливается на заводе стороннего производителя.
• Программное обеспечение разработано сторонним подрядчиком.
• Прошивка предоставляется другой компанией.
• Компания импортирует готовую продукцию и продает ее под собственной торговой маркой.
• Разработка передается на аутсорсинг инженерам-программистам или компаниям, предоставляющим технические услуги.

Аутсорсинг разработки не означает передачу юридической ответственности производителю.

Компания, выпускающая продукт на рынок под своим именем или товарным знаком, должна гарантировать, что весь продукт, включая программное и аппаратное обеспечение сторонних производителей, соответствует требованиям CRA (Закона о реинвестировании в сообщества).

Каковы основные обязательства производителя в рамках соглашения о реагировании на чрезвычайные ситуации (CRA)?

Основная ответственность за соблюдение требований лежит на производителях.

Перед выпуском продукции с цифровыми элементами на рынок ЕС производитель, как правило, должен:

1. Определите, подпадает ли данный продукт под действие соглашения о реагировании на коммерческие предложения (CRA).
2. Определите, является ли данный продукт товаром по умолчанию, важным или критически важным.
3. Проведите оценку рисков кибербезопасности.
4. Разрабатывать, проектировать и производить продукт в соответствии с основными требованиями кибербезопасности.
5. Проявляйте должную осмотрительность при интеграции компонентов сторонних разработчиков.
6. Разработайте процессы обработки уязвимостей.
7. Определите и задокументируйте период технической поддержки продукта.
8. Подготовьте необходимую техническую документацию.
9. Проведите соответствующую оценку соответствия.
10. Подготовьте и подпишите Декларацию соответствия ЕС.
11. Нанесите маркировку CE.
12. Предоставьте необходимую информацию о продукте и инструкции по обеспечению безопасности.
13. Отслеживайте уязвимости и инциденты после выхода продукта на рынок.
14. Предоставляйте обновления безопасности в течение периода поддержки.
15. Принимайте корректирующие меры, если продукт не соответствует требованиям или представляет угрозу кибербезопасности.
16. Соблюдайте установленные сроки для сообщения об уязвимостях и инцидентах.

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

Основные требования кибербезопасности

Приложение I к Соглашению о кибербезопасности содержит основные требования к кибербезопасности.

Эти требования делятся на две основные области:

• Свойства кибербезопасности продукта
• Требования к обработке уязвимостей

Безопасность по умолчанию и по умолчанию

Продукция должна проектироваться, разрабатываться и производиться таким образом, чтобы обеспечивать надлежащий уровень кибербезопасности с учетом связанных с ней рисков.

В зависимости от продукта, это может потребовать принятия мер, направленных на решение следующих проблем:

• Надежные настройки по умолчанию
• Аутентификация
• контроль доступа
• Конфиденциальность
• Шифрование
• целостность данных
• Доступность сервиса и системы
• Защита от несанкционированного доступа
• Защита от манипуляций
• уменьшение поверхности атаки
• Ограничение открытых интерфейсов
• Безопасная связь
• Устойчивость к атакам типа «отказ в обслуживании»
• Ведение журналов и мониторинг безопасности
• Безопасное удаление данных
• Сокращение ненужной обработки данных
• Защита от известных методов атак
• Надежные механизмы обновления
• Восстановление после инцидентов в сфере безопасности

Надлежащие меры контроля зависят от продукта, его предполагаемого использования, разумно предвидимого неправомерного использования, условий эксплуатации и потенциальных последствий успешной кибератаки.

Известных уязвимостей, которые можно использовать, нет.

Продукт не должен выпускаться на рынок с известными уязвимостями, которые можно использовать в своих целях.

Для этого требуется нечто большее, чем просто проведение одноразового тестирования непосредственно перед запуском. Производителям необходим процесс выявления, оценки, определения приоритетов и устранения уязвимостей, затрагивающих:

• Фирменное программное обеспечение
• Прошивка
• Операционные системы
• Библиотеки с открытым исходным кодом
• Компоненты стороннего программного обеспечения
• Протоколы связи
• Аппаратные компоненты
• Зависимости от облачных сервисов
• Мобильные приложения
• Интерфейсы прикладного программирования

Безопасные обновления

В тех случаях, когда требуются обновления безопасности, производители обязаны предоставлять их незамедлительно и, как правило, бесплатно в течение периода технической поддержки.

Для многих продуктов обновления безопасности должны устанавливаться автоматически по умолчанию, если это технически возможно. Пользователи, как правило, должны иметь возможность отложить или отключить автоматическую установку с помощью понятного и доступного механизма.

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

Оценка рисков кибербезопасности

Оценка рисков кибербезопасности является одним из центральных документов CRA.

Это не должен быть общий контрольный список по информационной безопасности. Он должен относиться к конкретному продукту, его компонентам, предполагаемому использованию, прогнозируемому использованию, пользователям, данным, возможностям подключения и операционной среде.

Что должна включать оценка рисков?

При проведении надлежащей оценки рисков следует учитывать:

• Архитектура продукта
• Аппаратные и программные компоненты
• Коммуникационные технологии
• Сетевые интерфейсы
• Облачные сервисы
• Мобильные приложения
• Роли и привилегии пользователей
• Методы аутентификации
• Обрабатываемые или хранимые данные
• Шифрование и управление ключами
• Механизмы обновления
• Зависимости сторонних разработчиков
• Потенциальные субъекты угроз
• Векторы атаки
• Известные слабые места
• Предсказуемое злоупотребление
• Последствия компромисса
• Существующие меры безопасности
• Остаточные риски
• Необходимые испытания
• Меры по устранению уязвимостей
• Постмаркетинговый мониторинг

Когда следует обновлять оценку рисков?

Результаты оценки должны служить основой для проектирования и разработки продукта. Их также следует пересматривать при внесении существенных изменений, таких как:

• Крупное обновление программного обеспечения
• Новая функция продукта
• Изменение архитектуры продукта
• Интеграция нового стороннего компонента.
• Новая серьезная угроза
• Обнаружение активно используемой уязвимости
• Изменение предполагаемого назначения продукта
• Существенные изменения в облачной или сетевой инфраструктуре.

Оценка рисков является частью технической документации и может быть запрошена органами надзора за рынком.

Спецификация программного обеспечения

А Спецификация программного обеспечения, Обычно называемый SBOM (Subject Description of Materials – спецификация материалов), представляет собой структурированный перечень программных компонентов, входящих в состав продукта.

Информация, обычно включаемая в спецификацию материалов (SBOM).

В спецификации материалов могут быть указаны:

• Собственные программные модули
• Библиотеки с открытым исходным кодом
• Зависимости сторонних разработчиков
• Компоненты микропрограммы
• Названия компонентов
• Версии компонентов
• Поставщики
• Лицензии
• Зависимые отношения
• Ссылки на известные уязвимости
• Идентификаторы пакетов

Спецификация материалов (SBOM) помогает производителю определить, затрагивает ли обнаружение уязвимости в компоненте стороннего производителя его продукцию.

Почему необходимо вести учет материалов и спецификаций (SBOM)

Например, если в широко используемой программной библиотеке будет обнаружена критическая уязвимость, производитель должен иметь возможность быстро её выявить:

• Какие продукты используют данную библиотеку?
• Какие версии продукта затронуты?
• Доступна ли уязвимая функция или может быть использована злоумышленниками.
• Требуется ли корректирующее обновление?
• Какие клиенты или органы власти должны быть проинформированы
• Возникают ли обязательства по отчетности перед Канадским налоговым агентством (CRA)?

Спецификация материалов (SBOM) бесполезна, если она создана один раз и никогда не обновляется. Производителям необходим контроль версий и процесс ее поддержки по мере изменения программного обеспечения.

Требования к обработке уязвимостей

Соответствие требованиям CRA сохраняется и после того, как продукт выпущен на рынок.

Производители должны разработать процессы, позволяющие:

• Выявление уязвимостей
• Получайте отчеты об уязвимостях
• Уязвимости документов
• Оцените их серьезность и возможность эксплуатации.
• Отслеживайте уязвимости, затрагивающие компоненты сторонних разработчиков.
• Тестирование и проверка безопасности продукта.
• Незамедлительно устраняйте уязвимости
• Распространяйте обновления безопасности безопасным способом.
• Информируйте пользователей о доступных исправлениях.
• Публично раскрывать информацию об исправленных уязвимостях там, где это требуется.
• Сохраняйте конфиденциальность информации об уязвимостях до тех пор, пока не будет доступно исправление.
• Поддерживайте скоординированную политику раскрытия информации об уязвимостях.

Скоординированное раскрытие уязвимостей

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

В ходе процесса необходимо определить:

• Контактное лицо для сообщения о происшествии
• Информация, которую должны предоставлять журналисты.
• Процесс подтверждения производителем
• Ожидаемое время отклика
• Ожидания в отношении конфиденциальности
• Как производитель координирует раскрытие информации
• Как будут относиться к исследователям в области безопасности.
• Как будут публиковаться исправления и уведомления

Обязательства Канадской налоговой службы по отчетности (CRA) с сентября 2026 года

Обязательства по предоставлению отчетности в соответствии со статьей 14 вступают в силу с 11 сентября 2026 г..

Производители обязаны сообщать об определенных активно используемых уязвимостях и серьезных инцидентах через Единую платформу отчетности CRA, поддерживаемую Агентством Европейского союза по кибербезопасности (ENISA).

Сроки подачи отчетов

Процесс составления отчетов, как правило, включает в себя:

• Уведомление о раннем предупреждении в течение 24 часов
• Более подробное уведомление будет отправлено в течение 72 часов.
• Итоговый отчет должен быть представлен в установленный законом срок.

Активно используемые уязвимости

В случае активно используемой уязвимости окончательный отчет, как правило, требуется предоставить не позднее чем через 14 дней после того, как станут доступны корректирующие или смягчающие меры.

Серьезные инциденты в сфере безопасности

В случае серьезного инцидента, связанного с безопасностью, окончательный отчет, как правило, требуется представить в течение одного месяца после 72-часового уведомления.

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

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

Что такое активно используемая уязвимость?

Активно используемая уязвимость — это не просто теоретическая слабость или каждая запись в базе данных уязвимостей.

На практике производитель должен оценить, имеются ли достоверные доказательства того, что злоумышленник использовал уязвимость в системе без разрешения владельца системы.

Это различие важно, поскольку обязанность CRA по отчетности связана с активной эксплуатацией, а не просто с существованием каждой потенциальной уязвимости.

Однако производители по-прежнему обязаны выявлять, оценивать и устранять уязвимости, которые не используются активно, в рамках своих общих обязательств по обработке уязвимостей.

Период поддержки и обновления безопасности

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

Факторы, влияющие на период поддержки

Период поддержки должен учитывать такие факторы, как:

• Предполагаемый срок использования
• Характер и предназначение продукта
• Разумные ожидания пользователей
• Операционная среда
• Продолжительность, в течение которой обычно предоставляется поддержка аналогичных продуктов.
• Наличие запасных частей или сопутствующих услуг
• Риски кибербезопасности, связанные с прекращением поддержки.

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

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

Долгосрочные соглашения с поставщиками

Это может потребовать долгосрочных договоренностей со следующими сторонами:

• разработчики программного обеспечения
• Поставщики прошивки
• Поставщики облачных услуг
• Производители компонентов
• разработчики мобильных приложений
• услуги мониторинга кибербезопасности
• Испытательные лаборатории
• Поставщики услуг хостинга и инфраструктуры

Информация о продукте и инструкция по эксплуатации

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

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

• Официальное наименование производителя
• Зарегистрированное торговое наименование или товарный знак
• Почтовый адрес
• Адрес электронной почты или другой цифровой контакт
• Тип продукта, партия, серийный номер или другой идентификатор
• Назначение
• Основные функции продукта
• Свойства кибербезопасности
• Инструкции по безопасной установке
• Инструкции по безопасной настройке
• Инструкция по безопасной эксплуатации
• Информация о соответствующих обновлениях безопасности
• Инструкции по установке обновлений
• Информация об автоматических обновлениях
• Инструкции по отключению автоматических обновлений, если таковые имеются.
• Дата окончания периода поддержки
• Контактная информация для сообщения об уязвимостях
• Скоординированная информация о раскрытии уязвимостей
• Инструкции по безопасному удалению пользовательских данных
• Соответствующие предупреждения или ограничения в области кибербезопасности

Инструкции должны быть ясными, понятными, разборчивыми и разборчивыми. Они должны быть предоставлены на языке, который пользователи и соответствующие органы власти в государстве-члене, где продается продукт, могут легко понять.

Техническая документация

Производители обязаны подготовить техническую документацию до вывода на рынок продукции, подпадающей под действие данного соглашения.

Техническая документация должна демонстрировать соответствие продукта требованиям CRA и, как правило, должна включать в себя:

• Общее описание продукта
• Идентификация продукта
• Назначение
• Целевые пользователи
• Версии продукта
• Аппаратная архитектура
• Архитектура программного обеспечения
• Версии прошивки и программного обеспечения
• Коммуникационные интерфейсы
• Сетевая архитектура
• Зависимости удаленной обработки данных
• Информация о проектировании и разработке
• оценка рисков кибербезопасности
• Оценка основных требований
• Применяемые стандарты или технические спецификации
• Описание мер безопасности
• Планы испытаний и отчеты об испытаниях
• Оценка уязвимости
• Отчеты о результатах испытаний на проникновение, если таковые имеются.
• Спецификация программного обеспечения
• Записи о безопасной разработке
• Процедуры обновления и управления исправлениями
• Процедура обработки уязвимостей
• Скоординированная политика раскрытия информации об уязвимостях
• Обоснование периода поддержки
• Этикетки продукции
• Инструкция для пользователя
• Протоколы оценки соответствия
• Декларация соответствия ЕС
• Сведения об уполномоченном органе, если таковой имеется.

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

Набор сертификатов, не имеющих четкой связи с продуктом, рисками и требованиями CRA, как правило, не будет считаться адекватным техническим досье.

Классификация продукции в соответствии с Законом о реинвестировании в сообщества (CRA)

В зависимости от типа продукта и профиля риска CRA использует различные методы оценки соответствия.

Как правило, продукция относится к одной из следующих групп:

• Товары по умолчанию
• Важные товары, класс I
• Важные товары, класс II
• Критически важные продукты

Классификация зависит от того, обладает ли продукт основными функциональными возможностями категории, указанной в Приложении III или Приложении IV.

Товары по умолчанию

Для товаров, не отнесенных к категории важных или критически важных, обычно используется стандартный порядок обработки.

Производители данной продукции обычно могут использовать внутренний контроль, также известный как Модуль А, для оценки соответствия.

Это не означает, что оценка или тестирование не требуются. Производитель по-прежнему должен:

• Завершите оценку рисков кибербезопасности.
• Соответствовать основным требованиям кибербезопасности
• Подготовка технической документации
• Получите соответствующие технические доказательства.
• Проведите необходимые испытания.
• Разработать процедуры управления уязвимостями
• Подготовьте Декларацию соответствия ЕС.
• Нанесите маркировку CE.

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

Важные товары, класс I

В класс I входят определенные продукты, обладающие важными функциями кибербезопасности или компрометация которых может создать более широкие риски для безопасности.

В зависимости от их основной функциональности, примерами могут служить следующие:

• Системы управления идентификацией
• Продукты для управления привилегированным доступом
• Браузеры
• менеджеры паролей
• Антивирусные продукты
• Продукты виртуальных частных сетей
• Системы управления сетью
• Системы управления информацией и событиями безопасности
• менеджеры загрузки
• Продукты инфраструктуры открытых ключей
• Операционные системы
• Маршрутизаторы, модемы и коммутаторы
• Товары для умного дома с функциями безопасности
• Микропроцессоры и микроконтроллеры с функциями, связанными с безопасностью.

Для продукции класса I внутренний контроль может оставаться возможным, если производитель в полной мере применяет соответствующие гармонизированные стандарты, общие спецификации или применимую европейскую схему сертификации кибербезопасности.

В тех случаях, когда эти маршруты недоступны или используются не в полной мере, может потребоваться независимая оценка соответствия, проводимая уполномоченным органом.

Важные товары, класс II

К классу II относятся важные товары, представляющие повышенный риск.

В зависимости от их основной функциональности, примерами могут служить следующие:

• Гипервизоры
• Системы выполнения контейнеров
• Межсетевые экраны
• Системы обнаружения вторжений
• Системы предотвращения вторжений
• Микропроцессоры с защитой от несанкционированного доступа
• Микроконтроллеры с защитой от несанкционированного доступа

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

Критически важные продукты

Критически важная продукция перечислена отдельно в Приложении IV и подлежит самым строгим требованиям к оценке соответствия.

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

Оценка соответствия

Перед выпуском продукции на рынок производитель должен пройти соответствующую процедуру оценки соответствия.

В зависимости от классификации, могут применяться следующие варианты:

• Внутренний контроль
• Экспертиза по типу ЕС с последующим подтверждением соответствия типу.
• Полная гарантия качества
• Независимая оценка, проведенная уполномоченным органом.
• Применимая европейская схема сертификации в области кибербезопасности

Возможность проведения самооценки зависит от категории продукции и, для некоторых товаров класса I, от того, были ли в полной мере применены соответствующие гармонизированные стандарты или другие признанные пути соответствия.

Производителям следует определить порядок проведения оценки соответствия на раннем этапе. Выявление необходимости привлечения уполномоченного органа на поздних стадиях разработки продукта может отсрочить выход на рынок.

Гармонизированные стандарты

Ожидается, что гармонизированные европейские стандарты будут играть важную роль в обеспечении соответствия требованиям CRA.

Если соответствующий согласованный стандарт цитируется в Официальном журнале Европейского союза и применяется надлежащим образом, это может создать презумпцию соответствия соответствующим правовым требованиям.

До тех пор, пока не будут разработаны соответствующие стандарты, производители должны будут демонстрировать их соответствие с помощью надлежащих технических методов и доказательств.

В зависимости от продукта, подготовка может осуществляться с использованием существующих стандартов и рамок кибербезопасности. Однако использование признанного стандарта не гарантирует автоматического соответствия всем обязательствам CRA, если он не имеет необходимого правового статуса и не охватывает соответствующие требования.

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

Производители должны задокументировать следующее:

• Какой стандарт или спецификация были использованы?
• Какая версия была применена?
• Какие требования CRA оно охватывает?
• Было ли оно применено полностью или частично
• Как были удовлетворены все выявленные требования?
• Какие тесты или оценки были проведены?

Декларация соответствия ЕС

После подтверждения соответствия производитель должен подготовить и подписать Декларацию соответствия ЕС.

В декларации подтверждается, что производитель берет на себя ответственность за соответствие продукции применимым требованиям ЕС.

Она должна включать информацию, требуемую в соответствии с Приложением V, такую ​​как:

• Название и идентификационные данные продукта
• Наименование и адрес производителя
• Заявление об ответственности
• Предмет декларации
• Применимое законодательство ЕС
• Соответствующие согласованные стандарты или спецификации
• Информация об уполномоченном органе, где это применимо.
• Дополнительная информация о соответствии
• Место и дата выпуска
• Имя, должность и подпись уполномоченного лица

В случаях, когда к одному и тому же продукту применяются несколько законов ЕС, производитель, как правило, может подготовить единую декларацию соответствия ЕС, охватывающую все применимые законодательные акты.

Например, подключенное беспроводное устройство может также подпадать под действие Директивы о радиооборудовании, Директивы RoHS, требований электромагнитной совместимости и других законодательных актов, касающихся конкретных продуктов.

Обязательства импортера

Импортер из ЕС, размещающий на рынке Европейского союза продукцию производителя, не входящего в ЕС, должен убедиться, что производитель выполнил применимые обязательства в соответствии с Законом о реинвестировании в сообщества (CRA).

В числе прочего, импортер должен проверить следующее:

• Соответствующая оценка соответствия была завершена.
• Была подготовлена ​​техническая документация.
• Декларация соответствия ЕС доступна для ознакомления.
• Изделие имеет маркировку CE.
• Идентификационные данные продукта присутствуют.
• Предоставляется информация от производителя.
• Необходимая инструкция прилагается к изделию.
• Указан период поддержки.
• Внедрены процессы обработки уязвимостей.

Если импортер считает, что продукт не соответствует требованиям или представляет собой существенный риск в сфере кибербезопасности, он не должен выпускать продукт на рынок до тех пор, пока проблема не будет решена.

Импортеры также обязаны сотрудничать с властями и могут нести обязательства, когда им становится известно об уязвимостях, затрагивающих продукт.

Обязанности дистрибьютора

Дистрибьюторы должны проявлять должную осмотрительность при предоставлении своей продукции на рынке ЕС.

Они должны проверить соответствующие элементы формального соответствия, в том числе:

• Идентификация продукта
• Информация о производителе и импортере
• Необходимая информация о пользователе
• Инструкции по безопасности
• Информация о периоде поддержки

Дистрибьютор не должен продолжать поставлять продукцию, в отношении которой у него есть основания полагать, что она не соответствует требованиям. Ему также может потребоваться уведомить производителя или импортера и сотрудничать с органами надзора за рынком.

Уполномоченный представитель ЕС

Производитель, зарегистрированный за пределами Европейского союза, может назначить Уполномоченный представитель ЕС посредством письменного поручения.

Уполномоченный представитель может выполнять от имени производителя определенные задачи по регулированию, такие как:

• Сохранение доступности Декларации соответствия ЕС
• Обеспечение доступности технической документации для регулирующих органов.
• Ответ на обоснованные запросы властей.
• Предоставление информации о соответствии требованиям.
• Сотрудничество с органами надзора за рынком
• Поддержка отслеживаемости и нормативного информирования
• Информирование производителя о запросах регулирующих органов.

Однако назначение уполномоченного представителя не влечет за собой передачу производителю основной ответственности за продукт.

Обязанности, которые остаются за производителем.

Производитель по-прежнему несет ответственность за:

• Безопасное проектирование и разработка продукта
• оценка рисков кибербезопасности
• Соответствие основным требованиям
• Техническая документация
• Оценка соответствия
• Управление уязвимостями
• Обновления безопасности
• Сообщение об инцидентах
• Корректирующие действия
• Постоянное соответствие продукции требованиям

Существенные изменения

Лицо, внесшее существенные изменения в продукт и затем выпустившее этот продукт на рынок, может взять на себя обязанности производителя.

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

Примеры потенциально существенных изменений

• Добавление основных функций подключения.
• Изменение архитектуры аутентификации
• Замена операционной системы
• Представляем новую облачную платформу.
• Добавление функциональности дистанционного управления.
• Включение новых сетевых интерфейсов
• Внесение существенных изменений в критически важное для безопасности программное обеспечение.
• Изменение целевой группы пользователей или операционной среды

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

Постмаркетинговый мониторинг и корректирующие действия

Соблюдение требований CRA является постоянной обязанностью.

После выпуска продукции на рынок производитель должен продолжать отслеживать соответствующую информацию в области кибербезопасности.

Потенциальные источники мониторинга

В качестве источников могут выступать:

• Внутреннее тестирование безопасности
• Жалобы клиентов
• Отчеты об уязвимостях
• исследователи безопасности
• Поставщики компонентов
• Рекомендации по безопасности для проектов с открытым исходным кодом
• Базы данных уязвимостей
• службы анализа угроз
• Импортеры и дистрибьюторы
• Органы по надзору за рынком
• Группы реагирования на инциденты компьютерной безопасности
• ENISA communications

Возможные корректирующие меры

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

• Исправьте продукт
• Выпустить обновление безопасности
• Предложите обходное решение.
• Уведомить затронутых пользователей
• Проинформируйте импортеров и дистрибьюторов.
• Уведомить соответствующие органы
• Ограничить доступность товара
• Изъять товар
• Отозвать продукт

Ответные меры должны быть соразмерны риску, но бездействие не является приемлемой стратегией обеспечения соответствия требованиям.

Сохранение записей

Производители обязаны хранить необходимую техническую документацию и декларацию соответствия ЕС в течение соответствующего периода в соответствии с Соглашением о реинвестировании в сообщества.

Надежная система хранения документов должна обеспечивать сохранность:

• Версии продукта
• Версии программного обеспечения
• версии SBOM
• Версии оценки рисков
• Отчеты об испытаниях
• Решения об уязвимости
• Уведомления о безопасности
• Записи о корректирующих действиях
• Обновить историю
• Отчеты об инцидентах
• Коммуникации органа власти
• Декларации соответствия

Контроль версий имеет особое значение. Власти могут нуждаться в определении того, какое программное обеспечение, компоненты и документы, подтверждающие соответствие требованиям, относились к конкретной версии продукта в конкретный момент времени.

Штрафы за несоблюдение требований

Закон о налоговом администрировании предусматривает существенные административные штрафы.

В зависимости от нарушения, штрафные санкции могут достигать следующих размеров:

• До €15 миллион или 2,5% от общего годового оборота в мире, выбирается более высокая ставка в случае определенных серьезных нарушений.
• До €10 миллион или 2% от мирового годового оборота, выбирается более высокая из них для других обязательств.
• До €5 миллион или 1% от мирового годового оборота, выбирается более высокая из двух сумм за предоставление неверной, неполной или вводящей в заблуждение информации уполномоченным органам или органам по надзору за рынком.

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

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

Практическая дорожная карта соответствия требованиям CRA

Шаг 1: Подтвердите область применения продукта.

Определите, является ли данный продукт продуктом, содержащим цифровые элементы, и применяется ли к нему какое-либо исключение.

Документ:

• Продукт
• Программное обеспечение и микропрограммы
• Подключение
• Функции удаленной обработки данных
• Назначение
• Коммерческая модель поставок
• Применимые исключения

Шаг 2: Классификация продукта

Определите, является ли продукт:

• Продукт по умолчанию
• Важный класс I
• Важный класс II
• Критический

Классификация определяет порядок проведения оценки соответствия.

Шаг 3: Составление карты цепочки поставок и распределение обязанностей.

Идентифицировать:

• Законный производитель
• разработчики программного обеспечения
• производители оборудования
• Поставщики компонентов
• Поставщики облачных услуг
• импортер из ЕС
• Дистрибьюторы
• Уполномоченный представитель ЕС
• Поставщики услуг тестирования
• Уполномоченный орган, где это необходимо

Договорные обязательства должны соответствовать юридическим обязательствам производителя.

Шаг 4: Проведите оценку рисков кибербезопасности.

Выявление угроз кибербезопасности, уязвимостей, возможных последствий и необходимых мер контроля.

Оценка должна охватывать весь продукт, включая внешние компоненты и зависимости от облачных сервисов.

Шаг 5: Составьте карту основных требований

Создайте матрицу соответствия, связывающую каждое применимое требование CRA со следующими факторами:

• Контроль продукции
• Техническое задание
• Процедура
• Результат теста
• Технический документ
• Ответственное лицо
• Выдающееся действие

Шаг 6: Создание безопасного жизненного цикла разработки.

Опишите, как обеспечивается кибербезопасность в следующих случаях:

• Определение требований
• Архитектура
• Разработка
• Проверка кода
• Выбор компонентов
• Тестирование
• Выпускать
• Обслуживание
• Устранение уязвимостей
• Конец жизни

Шаг 7: Подготовка и ведение спецификации материалов (SBOM).

Определите все соответствующие программные компоненты и разработайте процесс мониторинга уязвимостей, затрагивающих их.

Шаг 8: Завершение технического тестирования

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

• Сканирование уязвимостей
• Тестирование на проникновение
• Анализ исходного кода
• анализ состава программного обеспечения
• Тестирование аутентификации
• Обзор шифрования
• тестирование интерфейса
• тестирование механизма обновления
• Фазз-тестирование
• Тестирование сетевой безопасности
• Тестирование на устойчивость
• Проверка безопасной конфигурации

Проведение испытаний должно основываться на оценке рисков и проверке соответствия.

Шаг 9: Разработка процедур реагирования на уязвимости и инциденты.

Подготовьте процедуры для:

• Получение отчетов
• Сортировка пациентов
• Оценка степени тяжести
• Эскалация
• Очистка
• Раскрытие информации
• Взаимодействие пользователей
• ENISA сообщает
• Коммуникация авторитета
• Корректирующие действия

Шаг 10: Определите период поддержки.

Определите и обоснуйте, как долго производитель будет предоставлять обновления для устранения уязвимостей и обеспечения безопасности.

Обеспечьте наличие технических поставщиков и ресурсов для разработки на этот период.

Шаг 11: Подготовка информации о пользователе и маркировки.

Обзор:

• Идентификация продукта
• Информация от производителя
• Информация об импортере
• Маркировка CE
• Инструкции по безопасности
• Инструкции по обновлению
• Контактная информация об уязвимости
• Дата окончания поддержки
• Инструкции по безопасному удалению данных

Шаг 12: Составление технической документации

Организуйте доказательства в структурированный технический файл CRA.

Шаг 13: Завершите оценку соответствия.

Используйте внутренний контроль, уполномоченный орган или другой разрешенный путь в соответствии с классификацией продукта.

Шаг 14: Подпишите Декларацию соответствия ЕС.

Производитель должен подписать декларацию только после завершения соответствующей оценки и подтверждения соответствия.

Шаг 15: Обеспечение соблюдения требований после выхода продукции на рынок.

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

Распространенные ошибки при соблюдении требований CRA (Комиссия по реинвестированию в сообщества).

Рассмотрение CRA как разовой сертификации

В соответствии с Законом о защите данных (CRA) требуется постоянное устранение уязвимостей, обновление систем безопасности, мониторинг и принятие корректирующих мер.

Предполагается, что вся продукция может пройти самосертификацию.

Важные изделия класса II и критически важные продукты, как правило, требуют оценки независимой третьей стороной. Для изделий класса I также может потребоваться участие уполномоченного органа, если соответствующие признанные спецификации не применяются в полной мере.

Полагаться только на тестирование на проникновение

Тестирование на проникновение может предоставить полезные доказательства, но оно не заменяет оценку рисков, процесс безопасной разработки, процедуры выявления уязвимостей, техническую документацию или обязательства по поддержке.

Игнорирование сторонних компонентов

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

Создание спецификации материалов без мониторинга.

Устаревший список компонентов не обеспечивает эффективную систему управления уязвимостями.

Объявление нереалистичного периода поддержки

Производитель должен иметь возможность предоставлять обновления безопасности и устранять уязвимости в течение всего заявленного периода.

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

24-часовой срок для предоставления отчетов требует оперативной внутренней коммуникации. Отделы обслуживания клиентов, проектирования, юриспруденции, соблюдения нормативных требований и управления должны понимать порядок эскалации проблем.

Ожидание согласованных стандартов перед принятием мер

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

Как EaseCert помогает соблюдать требования CRA (Закона о реинвестировании в сообщества).

EaseCert предоставляет Уполномоченный представитель и служба по обеспечению соответствия требованиям Закона ЕС о киберустойчивости для производителей продукции с цифровыми элементами.

Данная услуга разработана специально для производителей, зарегистрированных за пределами Европейского союза, которым необходима поддержка в соблюдении нормативных требований и наличие уполномоченного представителя в ЕС.

Услуги EaseCert по обеспечению соответствия требованиям CRA

Наши услуги включают в себя:

• оценка применимости CRA
• Обзор объема работ по продукту и программному обеспечению.
• обзор классификации продукции
• Обзор методики оценки соответствия
• Обзор существующей технической документации
• Обзор документации по кибербезопасности
• Анализ пробелов в обеспечении соответствия требованиям кибербезопасности
• Обзор жизненного цикла безопасной разработки программного обеспечения.
• Обзор идентификации и отслеживаемости продукции
• Обзор этикеток и информации о маркировке CE.
• Проверка пользовательской документации и инструкций по безопасности.
• Обзор процедур обработки уязвимостей
• Обзор процедур обновления и обслуживания программного обеспечения.
• Обзор спецификации программного обеспечения
• Проверка документации за период оказания поддержки.
• Обзор декларации соответствия ЕС
• Письменный отчет о соответствии требованиям и рекомендации
• Письменный мандат уполномоченного представителя ЕС
• Назначение компании EaseCert GmbH уполномоченным представителем в ЕС.
• Сохранение Декларации соответствия ЕС и технической документации.
• контактное лицо по вопросам регулирования в ЕС
• Поддержка в обработке запросов в органы надзора за рынком.
• Нормативно-правовое сопровождение на протяжении всего проекта.

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

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

Роль уполномоченного представителя EaseCert в ЕС

Для продукции, произведенной за пределами Европейского союза и соответствующей требованиям, компания EaseCert GmbH может выступать в качестве уполномоченного органа. Уполномоченный представитель ЕС.

В рамках согласованных полномочий EaseCert может:

• Сохраните Декларацию соответствия ЕС в открытом доступе для органов власти.
• Держите необходимую техническую документацию под рукой.
• Отвечать на обоснованные запросы о предоставлении информации о соблюдении требований.
• Сотрудничать с органами надзора за рынком.
• Поддержка проверок отслеживаемости
• Поддержка коммуникаций с регулирующими органами
• Уведомите производителя о соответствующих запросах регулирующих органов.

Договор вступает в силу после завершения проверки документации, приемки продукции компанией EaseCert и подписания письменного соглашения обеими сторонами.

Получите поддержку в вопросах соответствия требованиям CRA и представительства в ЕС.

Начните подготовку к CRA

Закон о киберустойчивости создает новую систему соответствия требованиям для подключенного оборудования, автономного программного обеспечения, встроенного программного обеспечения и цифровых компонентов.

Для производителей наибольшая сложность заключается не просто в подготовке Декларации соответствия. Соответствие требованиям требует координации между отделами разработки продукции, кибербезопасности, обеспечения качества, регулирования, поддержки клиентов, управления цепочкой поставок и высшим руководством.

Четыре вопроса, на которые должны ответить производители.

1. Распространяется ли действие Закона о реинвестировании в сообщества (CRA) на наш продукт?
2. Какой способ классификации продукции и оценки соответствия применим?
3. Достаточно ли у нас доказательств и технической документации в области кибербезопасности?
4. Можем ли мы отслеживать, обновлять и поддерживать продукт в течение всего заявленного периода поддержки?

Производителям, зарегистрированным за пределами Европейского союза, также следует определить, нужен ли им уполномоченный представитель ЕС и как они будут обрабатывать запросы от органов надзора за рынком ЕС.

Компания EaseCert оказывает поддержку международным производителям в проведении проверок на соответствие требованиям CRA, оценке пробелов в соответствии с требованиями, проверке технической документации и предоставлении услуг уполномоченного представителя в ЕС.

Ознакомьтесь с информацией об уполномоченном представителе EaseCert по вопросам киберустойчивости в ЕС и услугах по обеспечению соответствия нормативным требованиям.

Официальные источники и дополнительная литература

Следующие официальные источники Европейского союза содержат юридический текст, руководство по применению и вспомогательную информацию, касающуюся Закона ЕС о киберустойчивости:

• Регламент (ЕС) 2024/2847, Закон о киберустойчивости
  Официальный и юридически обязательный текст Закона о киберустойчивости, опубликованный в Официальном журнале Европейского союза.
• Европейская комиссия: Закон о киберустойчивости
  Основная страница Европейской комиссии, посвященная политике в этой области, содержит информацию о целях, сфере применения, реализации и ожидаемых последствиях Закона о киберустойчивости.
• Европейская комиссия: Краткое изложение текста закона о киберустойчивости
  Официальное краткое изложение требований CRA, включая сферу применения продукта, обязательства экономических операторов, оценку соответствия и сроки внедрения.
• Европейская комиссия: Часто задаваемые вопросы о реализации Закона о киберустойчивости
  Официальные ответы на практические вопросы, касающиеся области применения продукта, программного обеспечения, удаленной обработки данных, сроков поддержки, отчетности и внедрения.
• Европейская комиссия: Реализация Закона о киберустойчивости
  Обзор процесса внедрения CRA, включая рекомендации, мероприятия по стандартизации и ресурсы для производителей и других заинтересованных сторон.
• ENISA: Единая платформа отчетности в рамках Закона о киберустойчивости
  Официальная информация о платформе, которую производители будут использовать для сообщения об активно используемых уязвимостях и серьезных инцидентах безопасности начиная с 11 сентября 2026 года.
• ENISA: Сопоставление требований и стандартов Закона о киберустойчивости
  Исследование ENISA, сопоставляющее существующие стандарты кибербезопасности с требованиями CRA и определяющее области, требующие дальнейшей стандартизации.
• ENISA: Внедрение Закона о киберустойчивости посредством схемы сертификации кибербезопасности ЕС.
  Официальное исследование, изучающее, как Европейская схема сертификации кибербезопасности на основе общих критериев может способствовать оценке соответствия требованиям CRA.

Данная статья содержит общую информацию о нормативных требованиях и не является юридической консультацией. Область применения, классификация, оценка соответствия и требования к документации должны оцениваться для каждого продукта индивидуально.