サイバーレジリエンス法のBSIガイダンスを読む(SBOMとCVD)

サイバーレジリエンス法(「デジタル要素を有する製品の水平的サイバーセキュリティ要求事項及び規則」)(規則(EU) 2024/2847)(リンクは、こちら、)は、2024年11月20日付け官報に掲載されており、2027年12月11日から適用されます（14条は、2026年11月、第4章は、2026年6月11日）（71条）。

1 法規制概観

1.1 目的と枠組

同規則は、目的としては、

この規則は、ハードウェアおよびソフトウェア製品が市場に投入される際に脆弱性が少なく、製造者が製品のライフサイクル全体を通じてセキュリティを真剣に考慮するようにすることで、デジタル要素を含む安全な製品の開発のための境界条件を定めることを目的としています。また、市場に提供されるデジタル要素を含む製品に関するサポート期間に関する透明性を向上させるなど、ユーザーが製品を選択し使用する際にサイバーセキュリティを考慮できるようにする条件を整備することを目的としています。

です(前文(1)および(2)。具体的に定められている項目としては

(a)デジタル要素を含む製品の市場への供給に関する規則（当該製品のサイバーセキュリティを確保するため）；

(b)デジタル要素を含む製品の設計、開発、製造に関する基本的なサイバーセキュリティ要件、および当該製品に関する経済事業者のサイバーセキュリティに関する義務；

(c)製造者が、デジタル要素を含む製品の使用期間中に当該製品のサイバーセキュリティを確保するために行う脆弱性対応プロセスに関する基本的なサイバーセキュリティ要件、および当該プロセスに関する経済事業者の義務；

(d)市場監視（監視を含む）に関する規則、および本条で定める規則及び要件の執行に関する規則。

となります。

1.2 提案時と法との違い

サイバーレジリエンス法の内容については、

でふれています。

なお、上記提案と最終法案との違いや米国での議論については、

でふれています。

提案時との違いは、

  1. 製品カテゴリーの整理
  2. 報告義務の詳細化・明確化
  3. オープンソースソフトウエアに関する規定の明確化

になることはふれています。

個人的には、あまりに広範な規制であって、メリットよりも、対応コストのほうがかかってくるのではないか、という疑問はありますが、そうもいっていられないので、具体的に対応するためにどのようにしたらいいのか、という点について具体的なコンプライアンスのために、現時点で公開されているガイダンスをみていくことは有意義だろうと

2 公的なガイダンス

公的なガイダンスという観点からは、

  • ドイツ BSI（(連邦情報セキュリティ庁)） の技術資料
  • ENISA の標準マッピング
  • CECIMO（ (欧州製造技術協会)）
  • デジタルヨーロッパ

などをあげることができます。これらを具体的にみていこうと思いますが、まずは、BSIのガイダンスから。

2.1 BSI（(連邦情報セキュリティ庁)） の技術資料

Technical Guideline TR-03183:Cyber Resilience Requirements for Manufacturers and Products

です。まるちゃんのページばこちら。

具体的には、

  • Part1 l 一般的要求事項
  • Part2 SBOM
  • Part3  脆弱性報告および通知

の内容になります。

Part1 l 一般的要求事項

これについては、リスク評価(4)、セキュリティ要件(5)、文書作成義務(6)に分けて論じられています。これらの要件について見るには、まずは、サイバーレジリエンス法の附属書1の必須サイバーセキュリティ要件を確認することが有意義です。ということで、要件を引用します。

附属書 I 必須サイバーセキュリティ要件

第 I 部 デジタル要素を有する製品の特性に関するサイバーセキュリティ要件

(1)デジタル要素を有する製品は、リスクを踏まえて適切なレベルのサイバーセキュリティを確保するよう設計、開発、製造されなければならない。

(2)第 13 条(2)に言及するサイバーセキュリティリスク評価に基づき、また該当する場合には、デジタル要素を有する製品は、

(a)既知の悪用可能な脆弱性がない状態で市場に提供されること。

(b)デジタル要素を有する特注製品に関して製造業者と事業利用者との間で別段の合意がない限り、初期設定で安全な構成で市場に提供されること。これには、製品を初期状態にリセットする可能性も含む。

(c)セキュリティ更新により脆弱性に対処できることを保証すること。これには、デフォルト設定で有効化された適切な期間内にインストールされる自動セキュリティ更新（適用可能な場合）、明確で使いやすいオプトアウトの仕組み、利用可能な更新をユーザーに通知すること、および更新を一時的に延期するオプションが含まれる。

(d)認証、身元またはアクセス管理システムを含むがこれらに限定されない適切な管理メカニズムにより、不正アクセスからの保護を確保し、不正アクセスの可能性について報告すること。

(e)保管、送信、またはその他の方法で処理されたデータ（個人情報またはその他のデータ）の機密性を保護すること。例えば、保管中または送信中の関連データを最新のメカニズムで暗号化すること、およびその他の技術的手段を使用することなど。

(f)保存、送信、またはその他の方法で処理されたデータ、個人情報またはその他の情報、コマンド、プログラム、および構成の完全性を、ユーザーが許可していない操作や変更から保護し、破損に関する報告を行うこと。

(g)デジタル要素を含む製品が意図する目的に関連して必要とされるものに限定し、適切かつ関連性のあるデータ、個人情報またはその他の情報のみを処理すること（データ最小化）。

(h)不可欠な基本機能の可用性を保護し、サービス拒否攻撃に対する回復力および緩和策を含め、インシデント発生後もこれを維持する。

(i)他のデバイスまたはネットワークが提供するサービスの可用性に対する、製品自体または接続されたデバイスによる悪影響を最小限に抑える。

(j)外部インターフェースを含む攻撃対象領域を限定するように設計、開発、製造されていること。

(k)適切な悪用緩和メカニズムおよび技術を使用してインシデントの影響を低減するように設計、開発、製造されていること。

(l)データ、サービス、機能へのアクセスまたはそれらの変更を含む関連する内部活動を記録および監視することにより、セキュリティ関連情報を提供し、ユーザーがオプトアウトできる仕組みを備えていること。

(m)ユーザーがすべてのデータおよび設定を恒久的に安全かつ容易に削除できる可能性を提供し、そのようなデータが他の製品またはシステムに転送できる場合には、それが安全な方法で行われることを保証する。

(1)デジタル要素を有する製品は、リスクを踏まえて適切なレベルのサイバーセキュリティを確保するよう設計、開発、製造されなければならない。

という部分は、上のリスク評価(4)と「5.3.1 REQ_ER 1 – デザインによるセキュリティ」に展開されています。

5.3 製品特性の必須要求事項

「(2)第 13 条(2)に言及するサイバーセキュリティリスク評価に基づき、また該当する場合には、デジタル要素を有する製品は、」からの各要件は、5.3で展開されています。

この部分は、必須要求事項(essential requirement )とされていて、具体的には

  • REQ_ER 1 – Security by design
  • REQ_ER 2 – No known vulnerabilities.
  •  REQ_ER 3 – Secure default configuration
  • REQ_ER 4 – Security updates
  • REQ_ER 5 – Access control
  • REQ_ER 6 – Confidentiality protection
  • REQ_ER 7 – Integrity protection
  • REQ_ER 8 – Data minimisation
  • REQ_ER 9 – Availability of essential and basic functions
  • REQ_ER 10 – Minimising negative impact
  • REQ_ER 11 – Limit attack surfaces
  • REQ_ER 12 – Mitigation of incidents
  • REQ_ER 13 – Recording and monitoring
  • REQ_ER 14 – Deletion of data and settings

があげられています。

5.4 脆弱性の取扱に関する必須要求事項

脆弱性の取扱に関する必須要求事項(vulnerability handling)が、まとめられています。具体的な事項としては

  • REQ_VH 1 – Identify components and vurnerabilities
  • REQ_VH 2 – Address vulnerabilities
  • REQ_VH 3 – Regular testing
  • REQ_VH 4 – Publish addressed vulnerabilities.
  • REQ_VH 5 – Coordinated vulnerability disclosure policy
  • REQ_VH 6 – Secure distribution of updates
  • REQ_VH 7 – Dissemination of updates

があげられています。

これは、サイバーレジリエンス法の附属書Ⅰパート 2に対応するものです。

第 II 部 脆弱性ハンドリング要件

デジタル要素を含む製品の製造者は、次のことを行わなければならない：
(1) 少なくとも製品のトップレベルの依存関係を網羅する、一般的に使用され、機械が読み取り可能な形式のソフトウェア部品表を作成することを含め、デジタル要素を持つ製品に含まれる脆弱性及びコンポーネントを特定し、文書化すること

(2) デジタル要素を持つ製品にもたらされるリスクに関連して、セキュリティ更新プログラムを提供することを含め、脆弱性に遅滞なく対処し、是正すること；

(3)デジタル要素をもった製品に効果的かつ定期的なテストとレビューを行うこと

(4) セキュリティ・アップデートが利用可能になったら、修正された脆弱性に関する情報を共有し、公開すること。これには、脆弱性の説明、影響を受けるデジタル要素を搭載した製品をユーザが特定できる情報、脆弱性の影響、深刻度、ユーザが脆弱性を修正するのに役立つ明確でアクセス可能な情報などが含まれる。メーカーが、公開によるセキュリティ・リスクがセキュリティ上の利点を上回ると考える正当な理由がある場合には、修正された脆弱性に関する情報の公開を、ユーザが関連するパッチを適用する可能性が与えられるまで延期することができる；

(5) 協調された脆弱性開示のポリシーを定めて、実施すること

(6) デジタル要素付き製品で発見された脆弱性を報告するための連絡先を提供することを含め、デジタル要素付き製品およびその製品に含まれるサードパーティコンポーネントの潜在的な脆弱性に関する情報の共有を促進するための措置を講じること；

(7) 脆弱性が適時に、かつ、セキュリティアップデートに適用される場合には自動的 に修正又は緩和されることを確実にするために、デジタルエレメントを有する製品のアップデ ートを安全に配布する仕組みを提供すること。

(8) 特定されたセキュリティ上の問題に対処するためにセキュリティアップデートが利用可能な場合には、 遅滞なく、かつ、デジタルエレメントを有するオーダーメイド製品に関して製造事業者とビジネ スユーザとの間で別段の合意がない限り、ユーザが取るべき潜在的な措置を含む関連情報 をユーザに提供する勧告メッセージを伴って、無償で配布されることを確実にすること。

私のブログで日本での脆弱性の協調された開示をするものとしては 「脆弱性の開示の枠組を深く勉強したい人に-ワクチンの予約システムの報道に関して」をあげておきます。

6 文書作成義務

これはさらに技術文書(Technical Documents)と利用者文書(user documents)にわかれます。

6.1 技術文書(Technical Documents)

サイバーレジリエンス法 付属書VII は、以下のように定めています。

第31条の技術文書には，デジタル要素をもつ該当製品に適用される場合，少なくとも次の情報を含まな ければならない：

1 (a) 意図した目的
(b) 必須要件への適合に影響を及ぼすソフトウェアのバージョン
(c) デジタル要素をもつ製品がハードウェア製品である場合，外観の特徴，表示及び内部レイアウトを 示す写真又は図版
(d) 附属書Ⅱに定める使用者情報及び指示

2. デジタル要素を含む製品の設計、開発及び製造並びに脆弱性の取扱いプロセスに関する説明：
(a)デジタル要素を含む製品の設計及び開発に関する必要な情報（該当する場合、図面及び図式、並びにソフトウ ェアコンポーネントが相互にどのように構築され、又は相互にどのように供給され、全体的な処理に統合され るかを説明するシステムアーキテクチャの記述を含む）；
(b) ソフトウェアの部品表、調整された脆弱性開示方針、脆弱性を報告するための連絡先アドレスの提供の証拠、アップデートの安全な配布のために選択された技術的ソリューションの説明を含む、製造者が実施する脆弱性処理プロセスの必要な情報及び仕様
(c) デジタル要素を含む製品の製造及び監視プロセスの必要な情報及び仕様、並びにこれらのプロセスの検証

3. 本規則第 13 条に規定されているように、デジタル要素を含む製品が設計、開発、製造、引渡し及び保守される際のサイバーセキュリティリスクの評価（附属書 I、第 I 部に規定されている必須要件がどのように適用されるかを含む）

4. デジタル要素を含む製品の第 13 条(8)に言及されているサポート期間を決定するために考慮された関連情報

5. 欧州連合官報に参照先が公表されている全部または一部が適用される整合規格、本規則第27条に定める共通仕様、または本規則第27条(8)に基づき規則(EU)2019/881に従って採択された欧州サイバーセキュリティ認証制度のリスト、 また、これらの整合規格、共通仕様又は欧州サイバーセキュリティ認証制度が適用されていない場合は、適用された他の関連技術仕様のリストを含む、附属書Ⅰ、パートⅠ及びⅡに定める必須要件を満たすために採用された解決策の記述。整合規格、共通仕様または欧州サイバーセキュリティ認証スキームが部分的に適用されている場合、技術文書には適用された部分を明記すること。

6. 製品がデジタル要素および脆弱性の取り扱いプロセスが、附属書Iの第I部および第II部に定める適用される基本的なサイバーセキュリティ要件に適合していることを確認するための試験の実施に関する報告書;

7. EU適合宣言書の写し；

8. 市場監視当局から合理的な理由を付した要請があった場合、当該当局が附属書Iに定める必須サイバーセキュリティ要件への適合を確認するために必要である場合に限り、ソフトウェア部品表。

となっていて、具体的な要求事項としては

REQ_TD 1 – General documentation
REQ_TD 2 – Documentation of processes.
REQ_TD 3 – Documentation of cybersecurity risks.
REQ_TD 4 – Documentation of the support period
REQ_TD 5 – Documentation of performed tests
REQ_TD 6 – Documentation of components

6.2 利用者文書(user documents)

ここでいう利用者文書というのは、利用者に対する情報及び指示をいいます。

サイバーレジリエンス法 付属書Ⅱは、

デジタル要素を含む製品には、少なくとも以下のものが添付されなければなりません:

1. 製造者の名称、登録商号または登録商標、郵便番号、メールアドレスその他のデジタル連絡先、および、利用可能な場合、製造者に連絡可能なウェブサイト;

2. デジタル要素を含む製品の脆弱性に関する情報を報告および受け付けるための単一の連絡先、および製造者の協調的な脆弱性開示ポリシーが確認できる場所；

3. デジタル要素を含む製品の名称、種類、および製品を唯一無二に識別するための追加情報；

4. デジタル要素を含む製品の意図された用途（製造者が提供するセキュリティ環境を含む）および製品の主要な機能とセキュリティ特性に関する情報；

5. 製品のデジタル要素の使用が、その意図された目的または合理的に予見可能な誤用条件下で、重大なサイバーセキュリティリスクを引き起こす可能性のある、既知または予見可能な状況；

6.該当する場合、EU適合宣言書にアクセス可能なインターネットアドレス；

7. 製造者が提供する技術的セキュリティサポートの種類および、ユーザーが脆弱性の対応やセキュリティ更新を受けられるサポート期間の終了日；

8. 以下の事項に関する詳細な指示またはそのような詳細な指示へのインターネットアドレス：

(a) デジタル要素を含む製品の初期導入時および製品の使用期間中を通じて、その安全な使用を確保するための必要な措置；

(b) デジタル要素を含む製品の変更がデータのセキュリティに与える影響；

(c) セキュリティ関連の更新をインストールする方法；

(d) デジタル要素を含む製品の安全な廃棄方法、およびユーザーデータの安全な削除方法に関する情報；

(e) 附属書Iの第I部(2)(c)で要求されるセキュリティ更新の自動インストールを有効にするデフォルト設定を無効にする方法；

(f) デジタル要素を含む製品が他のデジタル要素を含む製品に統合される場合、統合者が附属書Iに定める必須のサイバーセキュリティ要件および附属書VIIに定める文書化要件に準拠するために必要な情報。

9. 製造者がユーザーにソフトウェア部品表を提供する場合、ソフトウェア部品表にアクセスできる場所に関する情報。

と定めています。要求事項としては

REQ_UD 1 – Documentation of the manufacturer.
REQ_UD 2 – Documentation of unique identifier
REQ_UD 3 – Documentation of intended purpose.
REQ_UD 4 – Documentation of the support period.
REQ_UD 5 – User guidance
REQ_UD 6 – Documentation of components.

が定められています。

Part2 SBOM

技術ガイドライン TR-03183: 製造業者および製品向けのサイバーレジリエンス要件 の「第2部: ソフトウェア部品表 (SBOM)」になります。SBOMは、きちんと勉強したいと思っています。ブログでは、

を纏めていますが、その後の進展については、まとめていないというのが、本音です。なので、とりあえずのウォーミングアップ(？)ということで、読んでいきます。

同ガイドラインの構造は、

  1. 序
  2. 要求事項用語
  3. 基礎
  4. SBOM様式
  5. 内容要求事項
  6. 明示仕様(Express speciafication)
  7. 移行システム
  8. 附属事項

となっています。

ここで、SBOM様式については、• CycloneDX ( バージョン1.5以上) • Software Package Data eXchange (SPDX) ,(バージョン 2.2.1 以上)となっています。

5 内容要求事項

これの項目を書き出すとこのようになります。

これらのデータが機会可読な形式で提供されるということになります。/cyclonedx-pythonPublic (GitHub) とかがあります。標準は、OWASP Software Component Verification Standard for Software Bill of Materials‘ criteria,があるとか、だそうです。BSIの標準よりも、これらのツールで生成されるほうを見たほうがいいだろうというのは、そのとおりですね。

CycloneDX Bill of Materials Specification (ECMA-424)の準拠が出てくるんですね。今後の宿題。

Part3  脆弱性報告および通知

パート3は、「脆弱性報告および通知(Vulnerability Reports and Notifications)」です。これの翻訳は、まるちゃんのところですと、ここになります。

このガイドラインの構成は、

  1. 序
  2. 要求事項用語
  3. 基礎
  4. 脆弱性報告を受領するためのサイバーセキュリティ要求事項
  5. 附属事項

となっています。

4 脆弱性報告を受領するためのサイバーセキュリティ要求事項

これは、さらに

  1. RFC 9116に準拠したSecurity.txtファイル
  2. CVDプロセスの予備的対策
  3. CVDポリシー
  4. 脆弱性報告の受信用ウェブページ

が展開されています。

  1. RFC 9116に準拠したSecurity.txtファイルについては、私のブログの「RFC9116 セキュリティ脆弱性開示支援のためのファイルフォーマット」でも纏めています。なので、むしろ、詳細は、ブログのほうがよいようにも思います。

ただし、このガイドラインで 4.1.12 ウェブ・クローラーからの視認性が論じられ、また、具体的な例があげられているのは、興味深かったたです。

4.2 CVDプロセスの予備的対策

これは、サイバーセキュリティ担当者、脆弱性報告用ウェブフォーム、脆弱性報告の受信用ウェブフォームから成り立っています。

サイバーセキュリティ担当者では、製造者の製品の脆弱性対応を担当するPSIRT 、製造者のインフラの脆弱性対応を担当するCSIRTの役割があること、それらは、わけて設けられなければならない(MUST)ことなどがのべられています。 

4.3 CVDポリシー

ここで、CVDポリシー要件として種々の事項があげられています。参考文献としては

があげられています。具体的な要件があげられています。個人的には、ETSIは、分析していたのですが、BSIとNIS Groupについては、事情により漏れていました。一方、これら以外にも、ISO/IEC、OECD、FIRST、CERTのガイドラインなどがあるところです。

このBSIで興味深いのは、CVDポリシーの記載事項を要求事項として整理していることかと思います。ISO/IEC 29147:2018（以下、ISO/IEC 29147）や同30111：2019（以下、ISO/IEC 30111）があるのですが、それらをまとめて要求事項として整理するのは、参考になるかと思います。纏めると以下のようになりますが、この表にあわせて、日本のポリシーも整理してみるといいかもしれません。

各企業様において、CVDポリシーを整理されている今日この頃ではないかと思いますが、これらをふまえてのCVDポリシーのレビューもいたしますので、ご用命を待ちしています(？)。

ということで、その他のガイドラインについては、またの機会に読みます。今年もエストニア・タリン(とアムステルダム、ヘルシンキ)を訪問したので、そのあたりも復習したいところです。

 

 

関連記事

  1. EMPACTとサイバー犯罪対策(Project Nova) (…

  2. 国際的なサイバーテロの用語についての追加

  3. (国際的な)「サイバーテロ」の用語について

  4. CyCon2017 travel memo 10) Day3

  5. コンタクトトレーシングについてのNHK BS1　キャッチのインタ…

  6. ドイツにおける端末監視ツール導入について

  7. CyCon2017 travel memo 8) Day2 午後…

  8. 「IoT・5G セキュリティ総合対策 2020」について
PAGE TOP