CRA読み解き(その1) - ついに、CRAという「黒船」がやってくる

はじめに

組込みシステムのシニアエンジニアをしているNoricです。バックナンバーは :

• 「IoTでは、セキュリティは主役になれない」
  
• 「IoTでは、絶妙な「バランス」のセキュリティが必要だ」
  

今回は、「ついに、CRAという「黒船」がやってくる」 の話です。

欧州理事会は2024年10月10日、「サイバーレジリエンス法（Cyber Resilience Act）」 を承認し、デジタル製品の安全性要件に関する新たな法律を採択しました。IoTデジタル製品の界隈では既にざわつき始めています。

Cyber resilience act: Council adopts new law on security requirements for digital products

で、何が「ざわつく」のかというと、このサイバーセキュリティ法規対応が、かなり強制力のあるもので、ネットワークにつながるデジタル製品 全て に及ぶためです。わかりやすく例で例えると、今まで自由だったIoTデジタル製品のマーケットに、サイバーセキュリティの「黒船」が乗り込んできて、これから脆弱な製品は市場から追い出すから、ヨロシクな、的な感じです。

この法規対応は、欧州市場での法規対応なので、自社の製品はそこにリリースしていないからいいや、と思っていると多分乗り遅れます。勿論、納入先のOEMが欧州市場を仕向け地として出荷しているなら、間違いなく影響を受けますし、実は日本でもこのサイバーセキュリティの法規対応の流れを受けて、その導入の検討が始められています。むしろ、日本は遅い方で、米国や中国では既にサイバーセキュリティの法規対応は急ピッチで構築されていまけどね。

この「サイバーレジリエンス法（Cyber Resilience Act）」(以下、CRA )は、一体何者なのかを知る必要があります。欧州市場を仕向け地に出荷する自社の製品が、この法律に従わなかったら、どんなペナルティを課せられるのか、など。

CRA とは何者か？

欧州サイバーレジリエンス法（Cyber Resilience Act, CRA）は、EU内で販売されるデジタル製品のサイバーセキュリティを強化するために策定された規制です。

1. CRAの目的
   CRAの主な目的は、デジタル製品やサービスのセキュリティを強化し、サイバーリスクを抑えることで、EUデジタル単一市場の信頼性向上を目指すことです。具体的には、製品ライフサイクル全体におけるセキュリティ要件の遵守を求め、消費者と企業を保護することを目指しています。

2. CRAの対象範囲
   CRAは、デジタル要素を含むほぼすべての製品に適用されますが、医療機器や自動車など、既存の規制で管理されている分野は除外されています。製品はリスクに応じて分類されており、一般製品（低リスク）から高リスク製品（例：産業用ファイアウォールやIoT製品）まで幅広くカバーされています。 基本的に、ネットワークに接続できるデジタル製品全般に及びます

3. CRAの運用までの流れと対応期限
   CRAは2024年から段階的に施行される予定です。今年10月に採択されたので、数か月以内に交付され、そこから36ヶ月以内に対応が完了する必要があります。実質、27年度末までの猶予はありますが、認証を取るなどの準備期間を踏まえると、そんなに時間もありません。対象製品の製造業者は、設計から市場投入までの段階でセキュリティ対策を講じ、製品のサイバーセキュリティ適合性を確認する必要があります。特に、リスクの高い製品には第三者機関による認証が求められ、EUの適合要件を満たすことで「CE」マークが付与される仕組みです。

4. CRAに従わなかった場合のペナルティ
   CRAに違反した場合、1,500万ユーロまたは企業の年間売上高の2.5％のいずれか高い方が罰金として科される可能性があります。これは、EU市場で流通する製品のセキュリティを厳格に保つための措置です。IoTデジタル製品の業界を「ざわつかせた」のは、この厳しいペナルティです。

欧州理事会はこの欧州CRAを承認・採択したのですが、実のところ、詳しい要件が定められているわけではなく、最上位の「何を守らないといけないか」が述べられているだけの状態です。現在、サイバーセキュリティに敏感なIoT製品の製造業者は、自社製品が展開する分野のサイバーセキュリティの法規対応に準拠し、或いはそのルールを読み解いているところです。

筆者も、その界隈にいるので、CRAの全体像(何を、どのようにしなければいけないのか)を早急に理解する必要があったのですが、最初はあまりに広範なサイバーセキュリティのルールを目の当たりにして、すぐ眩暈がしました。

しかし、欧州CRAは、公布文書としてヒントを出しました。それが下記のドキュメントです。

Cyber resilience act requirements standards mapping

この公式ドキュメントは、CRAに関連する、それぞれのサイバーセキュリティ法令の要件を有識者が分析、その要件をマッピングしたものです。このサイトでは筆者の勉強と、来る欧州CRAの要件を読み解くために、このドキュメントを読み、筆者なりに理解したことを何回かにわたってまとめたいと思います。

CRA の概要

CRAは、デジタル機能を持つすべての製品が対象で、製品の設計から廃棄に至るまでの「ライフサイクル全体」を通じたセキュリティ管理を義務付けています。これにより、製品の利用時や廃棄時までサイバー攻撃への備えが求められ、消費者の信頼向上や市場競争力強化が期待されます。

CRAの対象製品

CRAの対象となるのは、次のようなデジタル製品やソリューションです：

• ネットワーク対応製品：インターネットやネットワークに接続可能な機器やソフトウェア。
• ハードウェアおよびソフトウェア：製品の基本構成要素。
• リモートデータ処理ソリューション：クラウドサービスの一形態であるSaaS（Software as a Service）など。

ただし、医療機器や自動車といった、すでに別の規制で管理されている分野はCRAの対象外です。

製品のリスクに応じた評価方法

CRAでは、製品のリスクレベルに応じて次の3つの方法で評価が行われます：

1. 自己評価：一般的な製品には、製造者が自ら安全性を評価する「自己評価」が適用されます。
2. 標準準拠：リスクが中程度の製品には、特定の安全基準（標準）に従うことが求められます。
3. 第三者評価：最もリスクが高い製品については、第三者機関がセキュリティ基準に適合しているかを確認します。

ライフサイクル全体でのセキュリティ対策

CRAの規定は、製品が市場に出てから廃棄されるまで、次の各段階で適用されます：

• 開発段階：設計時にセキュリティ要件を組み込みます。
• 製造段階：製造過程で標準に従った管理が必要です。
• 運用段階：製品が市場で使用される際、定期的なセキュリティ維持が求められます。
• 廃棄段階：使用済み製品の処分時にも、情報漏洩の防止が重要です。

CRA導入による影響と課題

CRAの導入により、特にIoT機器の製造企業にはセキュリティ対策が強く求められるようになりました。これにより、製造企業はセキュリティ対策の強化や維持のコストが増加する一方、消費者の信頼を得やすくなると期待されています。

「概要」のまとめ

• 既にサイバーセキュリティ規制のある製品分野を除き、ネットワークに接続する機能を有する デジタル製品 及びその ソリューション に及ぶ
• その製品のリスクレベルに応じ、自己、又は第三者による評価(認証)を受けなければならない。
• その製品まライフサイクル全般(開発、製造、運用、廃棄)に及び、そのセキュリティを構築されなければならない。

用語集

• IoT（Internet of Things）：インターネットに接続された機器やデバイスの総称。
• SaaS（Software as a Service）：インターネット経由で提供されるクラウド型ソフトウェア。
• 自己評価：製造者が自身で製品のセキュリティ基準を確認する方法。
• 標準準拠：定められたセキュリティ基準に従うこと。
• 第三者評価：第三者機関が製品のセキュリティ基準適合性を確認すること。
• ライフサイクル：製品の設計、製造、使用、廃棄までの一連の過程。

現在の CRA の立ち位置

現在、欧州サイバーレジリエンス法（CRA）の要件に対応するための標準化が進められていますが、2024年9月時点で、1つの既存標準のみで全要件を満たすことはまだできていません。この背景には、CRAの全体的な基準を一貫して満たすために既存の標準を統合・補完する必要があることが挙げられます。

CRA対応に向けた課題と解決ステップ

CRA要件を満たすには、以下のような課題をクリアし、既存の標準を活用・補完していくことが重要です：

1. 既存の標準のギャップ
   現在のサイバーセキュリティ標準の多くは、特定の用途や分野（例：IoTや産業用制御システム）に特化しているため、すべてのデジタル製品に適用可能ではありません。このため、CRAの要件を網羅するための標準には、より幅広い適用範囲が求められます。

2. 水平的なカバレッジの必要性
   CRAの要件を包括的にカバーするためには、ユースケースや製品カテゴリに依存しない「水平標準」を統一的に策定することが必要です。これにより、さまざまなデジタル製品に共通のセキュリティ基準を提供することが可能になります。

CRA対応に向けた推奨アプローチ

CRAの要件に対応するため、次のアプローチが推奨されています：

• 既存標準の活用
  CRAの要件に適合するために、現在存在するサイバーセキュリティ標準を参考にすることで効率的に対応が可能です。

• 標準のギャップを認識
  現行の標準がカバーしきれていない要件については、新たな標準化や追加のセキュリティ対策による補完が求められます。

• 製品設計へのセキュリティ組み込み
  CRAは、製品開発の初期からセキュリティを考慮することを求めています。したがって、セキュリティ要件を設計段階で統合し、全体の開発プロセスに組み込むことが重要です。

用語集

• CRA（欧州サイバーレジリエンス法）：デジタル製品全般にサイバーセキュリティ要件を義務付ける欧州の法律。
• 標準化：特定の基準やプロセスを統一し、技術や手順の一貫性を確保すること。
• 水平標準：特定の用途に依存せず、幅広い製品やシステムに適用できる一般的な標準。
• ギャップ：既存の標準や基準がカバーできていない部分や領域。

CRA の最上位の「製品のサイバーセキュリティ要件」

この要件は、製品がサイバー攻撃に強く、個人情報や機密データの保護が徹底されるよう設計されています。製品のライフサイクル全体を通して、外部からの脅威からファームウェアやデータを守ることが求められます。以下は、製品のサイバーセキュリティを実現するための具体的な要件項目です。

要件項目	要件の説明
(1) サイバーセキュリティ設計	製品は設計段階からサイバー攻撃への耐性が考慮され、適切なサイバーセキュリティ対策を講じる必要があります。
(2) 脆弱性の排除	製品は、既知の脆弱性がない状態で市場に提供されなければなりません。
(3a) セキュア・バイ・デフォルト	製品はリスク評価に基づき、安全な初期設定で提供され、必要に応じて出荷時設定に戻す機能を備えるべきです。
(3b) 不正アクセス防止	適切な制御メカニズムを通じて製品が不正アクセスから守られることが必要です。
(3c) データ機密性保護	データは保存・送信・処理中に外部から読み取られないように保護する必要があります。
(3d) データ完全性保護	データの改ざんが防止され、正確な状態が維持されるよう保護することが重要です。
(3e) データ最小化	必要最低限のデータのみを処理し、データの収集・保持を最小限に抑えるべきです。
(3f) 可用性保護	製品の重要な機能が使用可能な状態を維持し、サービス拒否攻撃などに対抗する対策が求められます。
(3g) 可用性への悪影響最小化	他のデバイスやネットワークの影響で可用性が損なわれないように設計する必要があります。
(3h) 外部インターフェース最小化	攻撃のリスクを減らすため、外部インターフェースは必要最低限に抑えます。
(3i) インシデント影響軽減	インシデントの影響を最小化するための対応策を実装することが重要です。
(3j) セキュリティ情報提供	内部活動の記録やモニタリングを通じて、セキュリティに関する情報を提供し、適切な監視を行うべきです。
(3k) セキュリティアップデート	必要な場合にはセキュリティアップデートを提供し、自動更新機能があると望ましいです。

用語集

• サイバーセキュリティ設計：製品の開発段階からサイバー攻撃を防ぐための仕組みを組み込むこと。
• 脆弱性：製品やシステムの弱点で、攻撃者に悪用されるリスクのある部分。
• セキュア・バイ・デフォルト：製品が初期設定のままで安全に使用できる状態で提供されること。
• 不正アクセス：許可されていない人がシステムにアクセスする行為。
• 機密性：データが許可された人以外に閲覧されないよう保護すること。
• 完全性：データが改ざんされず正確な状態を維持すること。
• データ最小化：必要最小限のデータだけを収集し、使用すること。
• 可用性：システムやサービスが必要なときに利用可能であること。

CRA の最上位の「脆弱性の処理プロセス要件」

この要件は、製品に脆弱性（セキュリティ上の欠陥や不具合）が発見された際に、迅速かつ適切に対応するためのプロセスを整えるものです。製品のファームウェアやソフトウェアのセキュリティを維持するために、脆弱性が見つかった場合には修正・更新することが求められます。また、脆弱性を監視し、ライフサイクル全体を通じて安全な状態を保つための体制を整えておくことが重要です。以下は、脆弱性処理プロセスの各要件の具体的な説明です。

要件項目	要件の説明
(1) 脆弱性とコンポーネントの特定	製品に含まれる脆弱性やコンポーネント（使用されているソフトウェアの部分）を特定し、ソフトウェア構成表を作成します。
(2) 脆弱性の特定とアップデート提供	製品に脆弱性が見つかった際には、その脆弱性を修正するためにセキュリティアップデートを提供します。
(3) セキュリティテストとレビュー	製品のセキュリティを保つため、定期的なテストとレビューを実施し、継続的に安全性を確認します。
(4) 脆弱性情報の公開	セキュリティアップデートが実施された場合には、その脆弱性に関する情報をユーザーに公開します。
(5) 脆弱性開示ポリシーの実施	脆弱性開示ポリシー（CVDポリシー）に基づき、脆弱性の情報を調整して公開する手順を整えます。
(6) 情報共有と報告用連絡先提供	脆弱性情報の共有を促進し、発見した脆弱性を報告するための連絡先をユーザーに提供します。
(7) アップデートの安全な配信	脆弱性修正のためのアップデートが安全に配信されるようにします。
(8) 無料のセキュリティパッチ提供	セキュリティパッチやアップデートを無料で提供し、ユーザーに通知します。

用語集

• 脆弱性：ソフトウェアやシステムの欠陥で、攻撃者に悪用されるリスクがある部分。
• ソフトウェア構成表：製品に含まれるソフトウェアやそのバージョンなどを記載したリスト。
• セキュリティアップデート：発見された脆弱性を修正し、システムの安全性を維持するための更新プログラム。
• セキュリティテスト：製品が安全であるかを確認するために行うテスト。
• 脆弱性開示ポリシー（CVDポリシー）：脆弱性情報を公開する際に、事前調整のもとで公開する手順を定めたルール。
• セキュリティパッチ：脆弱性を修正するためのソフトウェアの修正プログラム。

さいごに

欧州CRA の要件は、製品ライフサイクル全体のセキュリティを構築するための対応だけではなく、その製品のソフトウェア自身の脆弱性まで担保することが要求されるようになりました。組込み製品エンジニアならば、これらがいかに重たい要求であるかはお分かりになるかと思います。しかし、私たちはそれに対応しなければならなくなるので、それぞれの要件(全部で21要件も・・・)について、更にブレークダウンをしていこうと思います。