Мы используем куки, чтобы пользоваться сайтом
было удобно.
Что же за птица такая — Cyber Resilience Act? В этой статье мы поговорим про закон, который выдвигает требования кибербезопасности к продуктам, поставляемым на европейский рынок. Как выглядят эти требования, какие определены штрафы за их несоблюдение — обо всём в этой статье.
Cyber Resilience Act (CRA) — это нормативно-правовой акт (или же закон), который предъявляет требования к производителям ПО, выпускающим свои продукты на рынок стран Евросоюза. Требования касаются кибербезопасности разрабатываемого продукта.
Создание закона было инициировано Европейской комиссией. Он вступил в силу 10 декабря 2024 года, а его основным требованиям необходимо начать соответствовать через 36 месяцев с момента вступления в силу, т.е. с 11 декабря 2027 года. Но в нём есть положения, у которых более ранние сроки соответствия:
В главе CONFIDENTIALITY AND PENALTIES, Article 64 (пункт 2) указано, что за несоблюдение требований CRA полагается штраф до 15 000 000 евро или, если нарушителем является предприятие, до 2,5 % его общего годового оборота за предыдущий финансовый год — выбирается большая сумма.
Причины для появления этого закона, исходя из его же формулировок, следующие:
А какое именно ПО необходимо разрабатывать в соответствии с CRA?
Ещё раз повторю, что CRA — это нормативно-правовой акт Евросоюза. Так что его требования распространяются на тех, кто поставляет своё ПО на рынок Евросоюза, даже если оно разрабатывается за его пределами.
А о каком именно ПО идёт речь? В самом стандарте требования выдвигаются относительно такого понятия, как "продукт с цифровыми элементами" ("product with digital elements"). Там же дано определение:
'product with digital elements' means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;
Продукт с цифровыми элементами — это программный или аппаратный продукт и его удалённые решения для обработки данных; связанные программные или аппаратные компоненты, поставляемые на рынок отдельно, также попадают под это определение.
Из этого складывается впечатление, что абсолютно любое ПО является продуктом с цифровым элементом. А как следствие — абсолютно любое ПО попадает под необходимость соответствия CRA. Однако в самом акте есть раздел Scope, содержащий следующее уточнение:
This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.
Регламент распространяется на продукты с цифровыми элементами, которые по своему назначению или ожидаемому способу использования подключаются к другим устройствам или сетям (напрямую или косвенно) для обмена данными.
Также в этом же разделе есть важное уточнение: в некоторых отраслевых категориях, таких как медицина, автомобилестроение, оборона, уже существуют собственные нормативные акты, определяющие требования к разрабатываемым программным продуктам. Именно они и продолжат устанавливать требования к разрабатываемому ПО — CRA на них не распространяется.
Если подытожить, то можно сказать, что требования из CRA распространяются на компании, разрабатывающие продукты с цифровыми элементами, которые:
Мы успели обсудить, кому может быть интересен этот стандарт, но до сих пор не рассмотрели, что это за требования. Пора это исправить.
Давайте теперь рассмотрим сами требования, которые стандарт предъявляет к кибербезопасности продукта. Они описываются в CHAPTER III. CONFORMITY OF THE PRODUCT WITH DIGITAL ELEMENTS, которая ссылается на Дополнение I.
Основные требования, предъявляемые к продукту с цифровыми элементами, поделены на две части:
Рассмотрим каждую из них.
Если обобщённо, то эта группа требований про то, что продукт должен обеспечивать надлежащий уровень кибербезопасности за счёт учёта рисков, которые могут возникнуть при его использовании.
Для удобства восприятия в этой статье я упрощу и сгруппирую эти требования. Оригинальное представление из CRA доступно здесь.
Требования, касающиеся безопасности и устойчивости продукта по умолчанию:
Требования к защите данных, обрабатываемых продуктом, и к надлежащему контролю доступа к ним:
Устойчивость и снижение последствий атак:
Мониторинг и контроль:
Так же, как и с предыдущей группой требований, здесь я их представил в упрощённом и сгруппированном формате. Оригинальное представление находится здесь.
Управление уязвимостями в продукте:
Информирование пользователей и раскрытие информации:
Взаимодействие с пользователями и обновления:
Глядя на них, кажется, что для удовлетворения отдельных требований нужно налаживать достаточно громоздкие процессы, но при этом как они должны выглядеть в точности, не очень понятно. Для упрощения взаимодействия с этим стандартом ENISA выпустила статью, в которой сопоставила требования из CRA с уже существующими стандартами.
Отдельное внимание я хотел бы уделить требованию к регулярному и полному тестированию продукта. Именно систематическое и всестороннее тестирование помогает придерживаться shift-left принципа: находить проблемы, ошибки и уязвимости в рамках цикла разработки как можно раньше. И, как следствие, их исправление для производителя ПО будет дешевле.
Неполное покрытие тестами увеличивает риск того, что ошибка просочится в итоговый продукт. Поскольку каждый метод тестирования имеет свою зону ответственности, важно использовать максимально полный набор, чтобы часть проблем не ушла в тень.
Говоря про shift-left принцип, важно уделить внимание статическому анализу. Он позволяет находить ошибки именно на этапе разработки — ещё до тестирования и уж тем более пост-релиза. Статический анализ является важной предтечей такого метода тестирования как SAST — тот же анализ исходного кода на наличие ошибок, но уже касающихся безопасности продукта. В рамках цикла разработки (SDLC) SAST является важным этапом. Про это у нас есть отдельная статья, рекомендую к ознакомлению.
Помимо вышесказанного, видно, что SAST-решение может отдельно помочь с реализацией некоторых требований, которые мы рассмотрели выше. На примере PVS-Studio перечислю, что SAST инструмент может уметь:
Подобные ошибки ищутся в соответствии со следующими стандартами и классификациями:
В контексте рассмотренных ранее требований не могу не упомянуть и про SCA — технологию, позволяющую обнаружить использование уязвимой библиотеки/компонента в составе разрабатываемого ПО. Именно SCA в том числе может помочь в достижении требования по отсутствию уязвимостей в выпущенном продукте.
Разработке безопасного ПО уделяется много внимания по всему миру. В этой статье мы краем глаза обозрели Европейский Cyber Resilience Act и какие требования к разрабатываемому продукту он предъявляет.
Однако не стоит забывать, что в рамках разработки ПО лучшей практикой является полное всестороннее тестирование. Помимо SAST-инструментов, необходимо также помнить и про модульное тестирование, и про функциональное, и про динамический анализ, и про всё-всё остальное, что поможет вашему продукту быть безопаснее.
Если затрагивать тему отечественного контроля за разработкой безопасного ПО, то, конечно же, речь пойдёт о ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования". Направлен этот стандарт на предотвращение программных недостатков и уязвимостей и содержит требования, предъявляемые к разработчикам и производителям ПО. Если есть желание ознакомиться с вопросом, можете обратиться к нашей статье, в которой собрана подборка различных материалов на тему разработки безопасного программного обеспечения (РБПО).
На этом будем с вами прощаться. Подписывайтесь на наш блог и до скорых встреч.
0
0
0
135
0
0