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

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

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

Аппаратные и программные кошельки могут подпадать под действие CRA

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

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

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

Первый отчет необходимо подать в течение 24 часов

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

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

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

Активная эксплуатация запускает отсчет времени

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

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

Недавние публикации о Coldcard показывают, почему это различие важно. В предупреждении, опубликованном в июле и связанном с потенциально слабой генерацией seed-фраз, практический риск не ограничивался выявлением уязвимости. Затронутым пользователям требовалось определить, не были ли раскрыты их seed-фразы, и при необходимости перевести средства. Об этом сообщал Coindoo.

Отчеты направляются властям, а не автоматически публике

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

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

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

Кошельки с открытым исходным кодом не освобождаются автоматически

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

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

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

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

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

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

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

Исходный материал «EU Crypto Wallet Makers Now Have 24 Hours to Report Exploits» был опубликован изданием Coindoo.