В отличие от большинства нормативных актов по кибербезопасности, Закон ЕС о киберустойчивости (Cyber Resilience Act) касается безопасности продукции, а не процессов или сертификации. Он распространяет действие знака СЕ с физической стороны продуктов на программное обеспечение, прошивку, серверные службы и все, что имеет сетевое подключение. Он кодифицирует существующие лучшие практики, устанавливает минимальные сроки поддержки продуктов и может потребовать выстраивания более тесных отношений с проектами открытого исходного кода, от которых зависит ваша организация. И у него есть крайний срок: к 11 сентября этого года у вас должны быть внедрены процессы отчетности об уязвимостях и инцидентах.
Даже для организаций, которые уже используют ведомости материалов программного обеспечения (SBOM), соблюдение новых обязательств CRA по сообщению об активно эксплуатируемой уязвимости в продукте в течение 24 часов и предоставление полного отчета в течение трех дней может оказаться сложной задачей.
Хотя почти все участники рынка, опрошенные в недавнем отчете компании Cloudsmith, занимающейся альтернативами SaaS, о управлении артефактами (Artifact Management Report), генерируют SBOM, только четверть делает это автоматически, а не вручную или по запросу. Более половины заявили, что исчерпывающий отчет потребует значительного времени и усилий, в то время как менее трети были очень уверены, что смогут пройти проверку цепочки поставок программного обеспечения, которую потребуют внезапные проверки CRA.
«Многие организации не соблюдали лучшие практики в отношении цепочки поставок программного обеспечения», — говорит Элисон Сикелка, вице-президент по продуктам в Cloudsmith. «И это отражается в том, что людям приходится судорожно выяснять, как они собираются генерировать SBOM, вести отчетность и обеспечить все это вовремя». SBOM и возможность аудита, которые иногда рассматривались как бремя, замедляющее разработку программного обеспечения, теперь стали необходимостью, добавляет она.
Однако для многих ИТ-директоров CRA даже не стоит на повестке дня. «Они могут думать, что это почти формальность», — говорит Оли Венн, инженер-менеджер в компании-поставщике решений по безопасности WatchGuard, — а не широкомасштабное регулирование с агрессивными требованиями к отчетности, охватывающее весь жизненный цикл продукта: от планирования и проектирования до поддержки и обслуживания.
«Если вы являетесь каким-либо поставщиком, или производите/поставляете любую цифровую систему, будь то умные термостаты, кофемашины или что-либо еще, что может быть подключено к Интернету или сети, это подпадает под регулирование», — добавляет он. «Если у вас есть разработчики и потребители, использующие это каким-либо образом, то вы подпадаете под действие CRA».
Сферы влияния
CRA применяется к программному обеспечению и устройствам, таким как мобильные телефоны, встроенные операционные системы, базы данных, игры, сетевое оборудование, устройства IoT и даже билеты, доставляемые через приложение. Однако он не применяется к некоммерческому открытому исходному коду, но у фондов открытого исходного кода есть некоторые обязательства. И если ваш продукт включает элементы открытого исходного кода, вы несете ответственность за обеспечение их соответствия. Чистый SaaS не подпадает под действие закона, но клиентское программное обеспечение, приборы или устройства, использующие SaaS в качестве серверной части, подпадают.
«CRA включает в себя серверные компоненты, то, что мы называем решениями для удаленной обработки данных, если у вашего продукта есть серверная часть», — говорит Дэниел Эренберг, инженер по стандартам в комитете ETSI по кибербезопасности EUSR.
Продукты, уже продаваемые в ЕС, не обязаны полностью соответствовать CRA, если они не подвергаются существенным обновлениям, хотя компании по-прежнему должны сообщать об инцидентах и уязвимостях. Однако закон признает, что устранить их может быть невозможно. В противном случае единственными исключениями являются продукты, на которые уже распространяются более строгие правила в таких секторах, как автомобильная промышленность и медицина.
Безопасность продукта
CRA требует, чтобы цифровые продукты были безопасными по замыслу и по умолчанию, и не поставлялись с известными уязвимостями, такими как очевидные пароли по умолчанию, которые могут быть использованы. Они также должны быть обновляемыми, если такие уязвимости обнаруживаются позже, а также минимизировать их воздействие путем ограничения поверхности атаки и защиты конфиденциальности и целостности с помощью шифрования и сокращения сбора данных. Это, по сути, предписание о том, что коммерческое программное обеспечение должно хорошо справляться с этими вопросами, объясняет Эренберг, имея эффективный процесс для приема сообщений об ошибках.
«Было много надежд, что этого как-то удастся избежать, но это послужит тревожным звонком, чтобы рассмотреть все требования, начиная с оценки рисков», — говорит он. «Когда вы выводите продукт на рынок, вы должны провести оценку рисков кибербезопасности и осуществлять непрерывный аудит, чтобы знать о ваших текущих зависимостях, чтобы вы могли оценить, нуждаются ли они в обновлении».
Это включает в себя компоненты от поставщиков. «Убедитесь, что они соблюдают требования и сообщают о любых уязвимостях в области безопасности», — говорит Венн. Требования к SBOM разумны, а не обременительны, добавляет Найджел Дуглас, руководитель отдела по связям с разработчиками в Cloudsmith. «Есть ли у вас видимость названий пакетов и идентификаторов, чтобы вы могли определить, несут ли версия в вашей цепочке поставок программного обеспечения и кодовая база, которую используют и за которую платят пользователи, потенциально вредоносный код, который может им навредить?» — спрашивает он. «Главное — иметь возможность доказать, что вы можете быстро отреагировать на инцидент».
Для открытого исходного кода это также означает оценку проектов, от которых вы зависите. «CRA предписывает знать и понимать состояние проекта и принимать обоснованные, разумные решения об используемых проектах с открытым исходным кодом», — отмечает член управляющего комитета Kubernetes Кат Косгроув. Организации, которые обнаруживают и устраняют уязвимости в проектах с открытым исходным кодом, будут обязаны передавать эти исправления вверх по течению, указывает Венн. «Они больше не могут быть просто потребителями этих технологий», — говорит он. «Если они хотят их использовать, они должны стать частью сообщества».
Не похож на другие
В отличие от традиционных нормативных актов по кибербезопасности, CRA фокусируется не на практиках разработки программного обеспечения и сертификации, которые, как предупреждает Эренберг, могут не соответствовать новым требованиям, а на продаваемом продукте. «Достигли ли вы продукта, который минимизирует объем обрабатываемых данных, чтобы снизить риски, связанные с данными, если они управляются ненадлежащим образом?» — спрашивает он. «Защищаете ли вы данные, когда они находятся под угрозой и передаются?»
ИТ-директорам необходимо рассматривать продукты, которые продает их организация, с позиции «сверху вниз», оценивая, как они соответствуют требованиям безопасности, а не то, соответствует ли способ их создания всем пунктам. «Это смена ответственности», — добавляет он. «Вы несете ответственность за конечный продукт, а не просто за то, чтобы шаги были правильными».
Требования также предписывают поддержку продукта, обновления и жизненные циклы, в большинстве случаев — минимум пять лет бесплатных обновлений безопасности, все это должно быть отражено в декларации о соответствии, которая потребуется для цифровых продуктов с декабря 2027 года. Декларация и документация должны оставаться доступными в течение 10 лет после начала продаж продукта, но SBOM не обязательно должен быть публичным, а лишь доступным органам надзора за рынком по их запросу.
Стандарты на практике
Различные классы продуктов привлекают разные уровни контроля. Большинство цифровых продуктов подпадают под стандартное регулирование на основе горизонтальных стандартов по кибербезопасности и обработке уязвимостей, проект которых уже доступен от европейских стандартизирующих организаций.
Однако важные продукты, такие как системы управления идентификацией, веб-браузеры, менеджеры паролей, VPN и маршрутизаторы доступа к сети, а также критически важные продукты, такие как гипервизоры, инфраструктура PKI, аппаратные модули безопасности и промышленные брандмауэры, потребуют более строгих оценок соответствия.
Они охватываются вертикальными стандартами, разрабатываемыми для анализа конкретных рисков, в которых перечислены потенциальные меры смягчения последствий, например, написание веб-браузера на языке с безопасным управлением памятью. «CRA не требует от вас перехода на языки с безопасным управлением памятью или отказа от COBOL или чего-либо подобного», — говорит Эренберг.
Сроки и штрафы
Поскольку CRA является регламентом, а не директивой, он применяется без принятия новых законов отдельными странами Европы, а механизмы его администрирования настраиваются этим летом. «Органы надзора за рынком начинают работать со своими возможностями по обзору и утверждению, а затем подключаются отдельные органы по оценке соответствия», — говорит Эренберг. Агентство Европейского союза по кибербезопасности (ENISA) будет управлять единой платформой для отчетности об активно эксплуатируемых уязвимостях и инцидентах.
Хотя CRA вступает в полную силу с 11 декабря 2027 года, правоприменение будет вводиться постепенно и зависеть от технической готовности органов надзора за рынком, говорит Эренберг. Они могут потребовать приведения продуктов в соответствие, ограничить их продажу или потребовать их изъятия или даже отзыва, а также наложить штрафы до 15 миллионов евро или 2,5% от оборота.
«В будущем, вероятно, будут судебные разбирательства для толкования этого закона», — говорит Эренберг, поскольку некоторые аспекты уже подверглись критике за излишнюю расплывчатость и слабость. Но организации, рассчитывающие на ограниченное правоприменение, упускают возможность улучшить свои продукты и собственную безопасность.
Просто лучшая безопасность
С ростом числа атак на цепочки поставок, требования CRA обеспечат реальную выгоду в плане безопасности, заставляя предприятия отслеживать использование открытого исходного кода и оперативно уведомлять конечных пользователей о проблемах, говорит Нил Левин, старший вице-президент по продуктам в компании-поставщике решений по кибербезопасности Anchore. Он предлагает принять SBOM к сентябрю, чтобы помочь соблюсти требования к отчетности, а не ждать крайнего срока в 2027 году.
Опытные ИТ-директора также могут использовать эту возможность, чтобы получить ресурсы для внедрения улучшений. «Большинство ИТ-директоров в любом случае хотели бы сделать это, но у них просто не хватает пропускной способности», — говорит Венн. «Так что это, вероятно, инструмент для них, чтобы обратиться к совету директоров и потребовать бюджет и время».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Mary Branscombe
