EUサイバーレジリエンス法とは~日本企業も無関係ではない?その影響を考察する
2024年にEUで新たに施行が予定されているセキュリティ規則「EUサイバーレジリエンス法(Cyber Resilience Act:CRA)」の内容や日本企業への影響を解説します。
公開日:2024年3月18日
更新日:2024年4月9日
※執筆時点で最新のCRA法を参照しておりますが、正式に可決するまでの間に、以後も法案の加筆修正が行われる可能性がございます。本ブログの内容は執筆時点の最新情報としてご理解いただき、CRA法の内容について参照される際は必ずご自身で内容をご確認ください。
日本企業にも関係する?EUサイバーレジリエンス法
EUで新たなセキュリティ規則が2024年に施行される予定であることを、皆さんはご存じでしょうか?
「EUサイバーレジリエンス法(Cyber Resilience Act、以下CRA)」と呼ばれるものです。
CRAは、適用範囲が非常に広く、日本企業にも影響する可能性があります。
セキュリティ対策基準としてもとても参考になるものですが、日本ではまだあまり認知されていないように感じます。
こちらの記事では、「EUサイバーレジリエンス法を初めて知った」という方へ向けて、法律の概要や日本への影響に加えて、CRAに関連するトレンドマイクロの取り組みなどをまとめました。
EUサイバーレジリエンス法とは?
CRAは、欧州連合(EU)が提唱する、デジタルインフラを保護するための法律および規制のことを指します。本章ではCRAの概要について記載します。
●施行の背景
近年、サイバー攻撃は増加の一途をたどっており、企業や政府機関への攻撃が頻発しています。これらの攻撃は、重大な経済的損失をもたらすだけでなく、国家のセキュリティや公共の安全にも脅威をもたらしています。EUによると、2021年までの年間サイバー犯罪対策コストが5.5兆ユーロ(約800兆円)に達すると推定されています※。
※2022年9月15日公開 「Cyber Resilience Act」 © European Union, 1995-2023より翻訳・引用。
これについて、EUは2つの大きな課題があるとしています。
1つが「脆弱性の多さに対し、セキュリティーアップデートの提供が不十分」であること。
もう1つがセキュリティに関する情報提供が不十分であり、
「ユーザが製品選定する際に、安全な製品を選択するための判断材料がない」ことです。
2019年にEUサイバーセキュリティ法という法律が施行されています。しかし、特定製品に対する記載はありますが、具体的な要件が含まれていないことが課題でした。このような問題を解決するために、CRAが必要とされています。
●CRAが目指すこと
この規制では、以下の具体的な4つの目標があります。
① メーカーがセキュアな開発ライフサイクルを確立することで、製品のセキュリティを向上させる
② サイバーセキュリティフレームワークを確保し、メーカーのコンプライアンスを促進する
③ 製品の透明性を強化する
④ 企業および消費者が製品を安全に使用できるようにする
2022年9月15日公開 「Cyber Resilience Act」 © European Union, 1995-2023 より翻訳・引用
これらを実現することで、デジタル製品に関するセキュリティインフラを強固にすることができると期待されています。
●CRAの対象について
CRAの対象は非常に広範に及び、デバイスやネットワークに直接的/間接的に接続されるものも含むデジタル要素を備えたすべての製品が対象となります。ただし、医療関係の機器や民間航空機、自動車などほかのEUセキュリティ規制の対象となっているものや安全保障関係、SaaSなどは対象外となります。
非常に幅広い製品が対象になるため、EUにデジタル機器やソフトウェアを販売している場合は、「自社に影響がありうる」という可能性に沿って進めた方がよいかもしれません。
●CRAの特徴
CRAには以下の通り、大きく4つの特徴があります。
① セキュリティ要件と脆弱性対応要件
CRAは、デジタル製品のセキュリティ要件と脆弱性対応要件を規定しており、製造者はこの要件に適合する必要があります。
セキュリティ要件のポイントは、Security by Design の考え方を導入して、デジタル製品の企画・設計段階からサイバーセキュリティ対策を考慮することが製造者に求められることと言えます。また、デジタル製品の販売後にも、脆弱性に対応したアップデートを速やかに提供することも必要であり、以前より重要とされてきたDevSecOpsの考え方が義務化されたともとれます。
参考記事:トレンドマイクロ製品の安全性・透明性向上のための5つの取り組み 第1回~製品開発の迅速性と安全性を両立するDevSecOps~
脆弱性対応要件のポイントは、SBOM(Software Bill of Materials: ソフトウェア部品表)を作成して、デジタル製品を構成するコンポーネントの種類や依存関係をリスト化することです。SBOMを作成することで、脆弱性情報が公表された際に、自社のデジタル製品に対する脆弱性の影響有無の確認や、利用者に対して脆弱性に対応したアップデートの提供が速やかに行えるようになります。
参考記事:トレンドマイクロ製品の安全性・透明性向上のための5つの取り組み 第3回~ソフトウェアの脆弱性のリスクを可視化するSBOM~
② 製造者の報告義務
製造者は、自社のデジタル製品の脆弱性が悪用されていることや、製品のセキュリティに影響を及ぼすインシデントを発見したら、24時間以内にENISA(European Network and Information Security Agency:欧州連合サイバーセキュリティ機関)に報告することが義務付けられています。
なお、EU 理事会のプレスリリースによると、報告先をENISAから各国のサイバーセキュリティ当局に変更する案が検討されています。
製造者は、インシデントの影響を緩和する是正措置を利用者に通知することも義務付けられています。
また、自社製品で使用しているOSSに脆弱性を発見した場合は、当該OSSの開発者や団体に対して報告することも、製造者の義務として規定されています
③ 適合性評価の実施
CRAは、規制対象のデジタル要素を有する製品を、大きく「重要なデジタル製品」と「重要なデジタル製品以外」に分類しています。
さらに、重要なデジタル製品は、サイバーセキュリティリスクのレベルを反映して「クラス I(低リスク)」と「クラス II(高リスク)」に分類されます。
クラス I とクラス II の対象製品は下記のとおりです。
CRAは、デジタル製品がセキュリティ要件に適合していることを求めていますので、製造者は適合性評価を実施する必要があります。
適合性評価は「自己適合宣言」、「第三者認証(形式認証)」、「第三者認証(全数検査)」の三種類があり、製造者は製品の分類によって実施する適合性評価を選択します。この適合性評価を行う評価機関は、今後EUと加盟各国で検討・決定を行うとされています。
製品分類 | 選択できる適合性評価の種類 | 備考 |
---|---|---|
クラス I | 第三者認証(形式認証) 第三者認証(全数検査) |
EUCC や EN 規格に準拠している場合は、第三者認証は不要 |
クラス II | 第三者認証(形式認証) 第三者認証(全数検査) |
|
重要なデジタル製品以外 | 自己適合宣言 第三者認証(形式認証) 第三者認証(全数検査) |
経済産業省「EUサイバーレジリエンス法(草案概要) p.9適合性評価方法」をもとにトレンドマイクロが加工して作成
④ 市場による監視と罰金
EU各国の市場監視機関による監視と、CRAに違反した際に罰金が科せられることが規定されています。違反内容により罰金額は変わりますが、非常に高額な罰金が科せられる場合があります。
例えば、CRAの第10条および第11条に規定されている、製造者の義務に違反した場合、最大で1500万ユーロ(約25億円)、または前年度の全世界売上高の2.5%のどちらか高額な方が罰金として科されます。
施行までのスケジュール
欧州委員会のプレスリリースによると、CRA施行後、デジタル製品の製造者等に対して、CRAが求めるセキュリティ要件に適応するために、36か月の猶予期間が与えられます。このことから、2024年に施行された場合は、CRAの適用開始時期は、2027年中になります。
ただし、脆弱性悪用やセキュリティインシデントが発生した際の製造者の報告義務は、CRA 施行後21か月の猶予期間となっています。
想定される日本への影響は?
CRAは、EU市場で販売されるデジタル製品を対象としているため、EU向けのデジタル製品を製造している製造者は、CRAに対応する必要があります。
特に上述した、CRAの特徴①と②への対応が重要と言えます。
トレンドマイクロは、お客様が当社製品を安全にご利用いただくために、以下の取り組みを実施しています。
以下に記載したものは、CRAに備えた対応を念頭に置いたものではありませんが、結果的にCRAの特徴①と②に関連していると考えられますので、紹介いたします。
●CRAの特徴①に関連した取り組み
Security by Designの実践として、製品の設計段階において、データフローやデータの格納場所を整理してシステムをモデル化し、STRIDE※を活用してどのような脅威が想定できるか検証を行っています。
また、「InnerSource(インナーソース)」という取り組みも実践しています。インナーソースは、オープンソースの開発手法に着想を得た取り組みで、ソースコードを開発部門内に公開するというものです。
多くの開発者がソースコードを閲覧できるようになることで、サプライチェーン攻撃や内部犯行による不正なコードの挿入を発見できるようになり、製品セキュリティの向上が期待されます。
さらに脆弱性への対応として、以下を実践しています。
ソフトウェア構成分析(SCA)ツールを使用し、当社製品で使用しているサードパーティ製モジュールに脆弱性が無いか定期的に検査しています。脆弱性を発見した場合には、速やかに対応できる体制を整備しています。
また、当社ZDI(Zero Day Initiative)のネットワークと知見を活用したバグバウンティプログラムの実施や、社内セキュリティリサーチャーによる脆弱性調査を行うことで、最新の脆弱性情報を収集し、当社製品に対する影響有無を確認しています。
※STRIDE:システムを開発する際にどのような脅威が想定されるか分析するために用いられる分析フレームワーク。「なりすまし (Spoofing)」、「改ざん (Tampering) 」、「否認(Repudiation) 」 、「情報漏えい (Information Disclosure) 」 、「サービス拒否 (Denial of Service) 」、「権限昇格 (Elevation of Privilege)」の6つの頭文字を取ったもの。
●CRAの特徴②に関連した取り組み
当社製品に脆弱性が発見された場合、積極的に脆弱性情報を公開しています。同時に、JPCERT/CCに対して脆弱性情報を通報しています。
このような活動を速やかに実施できるように、平時の内に、当社製品の脆弱性情報を収集し、情報公開を行える体制とプロセスを整備しています。
これら当社が実施している取り組み以外にも、自社で製造しているデジタル製品のセキュリティを向上させる方法として、PSIRT(Product Security Incident Response Team)を構築することが挙げられます。
PSIRTとは、自社で製造している製品のセキュリティ脆弱性に関連するリスクマネジメントを行う組織です。
CRAで求められている「SBOMの管理」や「報告義務」などに対応することが期待でき、CRAに対応する組織として適していると考えられます。
以上を踏まえて、組織の経営層は、CRAに違反した際は巨額の罰金が科せられることだけでなく、EU市場を失いかねないことを認識し、CRAへの対応に積極的に関与していくことも重要と考えられます。ビジネス状況や対応コストにもよりますが、比較的セキュリティ・コンプライアンスに対する法令・規制等が先行して議論されるEU市場に自社製品を適合させていくことで、いずれ他地域で同水準のセキュリティ・コンプライアンスが求められた場合にスムーズな対応が可能になるというメリットもあります。
特定の地域の規制によらず、可能な限りセキュリティの透明性や安全性を確保し、ユーザに安心を与える取り組みが今後も重要になるでしょう。
関連記事:
・GDPRへの対応
・ソフトウェア・サプライチェーンの脆弱性管理に求められるSBOMの必要性
・「モノ」を製造していない企業も参考にすべきPSIRTの役割と脆弱性管理のポイント
Security GO新着記事
ソブリンクラウドとは?プライベートクラウドやガバメントクラウドとの違いを解説
(2024年11月5日)
VPN機器の脆弱性はなぜ管理しづらいのか~ネットワークエンジニアの立場から探る
(2024年11月1日)