サイバー・レジリエンス法への早期意見募集が開始

サイバー・レジリエンス法（CRA）は、問題が山積するコンピュータセキュリティ分野において、これまでで最大規模となる立法介入と言えるだろう。今回、前例のない規制手段として、検討中の詳細な標準規格が一般公開されている。本記事では、これらの標準規格案の概要を簡潔に紹介するとともに、製品メーカー（オープンソース開発チームを含む）やセキュリティ専門家が規格をレビューする際の提案を示す。

CRA の背景

Linux Professional Institute（LPI）は、CRA に関する提案が非常に初期段階だった頃から状況を追っており、1か月ほど前には法律の影響についてまとめた記事を公開している。LPI は法律の策定過程において専門家パネルも招集し、2024年時点での専門家のコメントも記録している。

高い視点からこの取り組みを捉えると、次のようにも言えるだろう。欧州連合（EU）は、他の地域では市場の自然な動きや歴史的経緯に任されるような分野でも、法的に—and しかも詳細に—介入することを自らの使命と考える傾向がある。しかし、もしそのような法律による対応が必要とされる公共の懸念事項があるとすれば、サイバーセキュリティはその最上位に位置する。サイバー攻撃によって病院が閉鎖に追い込まれ、何百万人もの個人情報が盗まれ、国家レベルのサービスが麻痺することさえあるのだ。

EU のアプローチは、一般データ保護規則（GDPR）に見られるように、EU 加盟国すべてに直接適用される「規則（Regulation）」を制定することである。CRA の広範な規則はセキュリティ上の目標を定め、「市場監視当局」（第109段落）を設置し、企業が遵守しているかを「同時かつ協調的な監視行動」（第114段落）によって確認する仕組みを整えている。

標準規格案について

CRA は非常に冗長な文書だが、セキュリティを規制するための枠組みを定めたにすぎず、具体的なツールやプログラミング実践については今後定義されることになっている。

今回公開された標準規格案は、米国の NIST（国立標準技術研究所）に相当する非営利団体 ETSI（欧州電気通信標準化機構）が作成したものだ。

興味深いことに、ETSI が下書き段階の標準を早期公開した理由は、コメントガイドに記されている。「ETSI は、通常の標準化プロセスよりもはるかに早い段階で、サイバー・レジリエンス法を支援する縦割り標準の非公式なパブリックコンサルテーションを試験的に実施している」。そしてその根拠として、「国際標準化の原則のひとつである“オープンネス（公開性）”を、より高いレベルで実践する」ことを掲げている。

筆者の意見としては、コンピュータ分野はこの姿勢を尊重し、これを良い機会と捉えて積極的に取り組むべきだと考える。

標準規格案は驚くほど長大かつ包括的だ。たとえば各規格の第4章では、「主要機能」や「アーキテクチャ」から「ユースケース」まで、あらゆる事項を列挙しようとしている。

細部への干渉ぶりを示す例として、PKI 規格（比較的内容が固まっている規格）の 4.7.2.2.2 節では、ログの種類を 3 種類に分類し（それぞれ例付き）、登録サービスイベント、証明書生成サービスイベント、失効管理サービスイベントとして定義している。

逆に、妙に曖昧な要件もある。たとえばパスワードマネージャ規格の 4.5.5.3 節（IETF の RFC 2119 に基づく用語を使用）では、「セキュリティ対策は、保護とユーザビリティおよびシステム性能とのバランスを取らなければならない（SHALL）」と記載されている。「バランス」をどう測定するのか？この要件への適合性をどう検証するのか？

多くの標準規格に共通する中心部は、第5章「要件」だと筆者は考える。多くの標準と同様、すでに広く受け入れられている実践を成文化しようとしており、SBOM（ソフトウェア部品表）や適切な暗号利用などが義務付けられている。

しかし、早期公開ゆえの欠点も目立つ。多くの規格の長いセクションが空欄のままだったり、「[to be defined]（後日定義）」の一言で済まされていたりする。この状況を踏まえ、記事の後半では専門家が現実的に活用できる余地について提案する。

FOSS（フリー／オープンソースソフトウェア）への影響

読者の多くがフリー／オープンソースソフトウェアに関わっているため、CRA の潜在的影響については LPI の最近の記事も参考になる。自由・オープンソースライセンスで提供されるソフトウェアは多くの要件や罰則の対象外だが、一部の条文（第24条など）はオープンソースにも直接適用される。

幸い、第14条（および任意遵守を定める第15条）のうちオープンソースソフトウェアに適用される部分は、既に多くのフリーソフトウェアプロジェクトが実施している監視や報告のベストプラクティスを主に文書化したものとなっている。（ただし、脆弱性を中央政府機関に報告するという新たな義務は導入される。）

また、オープンソースにとって厄介になりうる奇妙な要件として、「最終版リリース後にはアルファ版・ベータ版を削除すること」（第37段落）がある。これは専有ソフト企業なら可能だろうが、オープンソースのリリースを特定の日時に一斉に回収することなどできない。

製品記述に関する所見

前述の通り、規格には驚くほど細かい記述がある。筆者は、各製品分野についてここまで深く記述する理由を2つあると考えている。

1. 製品とは何かを定義するため
   　実際の製品が、標準規格で定義された構成や内容に一致しているか。

2. 保護すべき対象を明確にするため
   　つまり、この細部に潜む攻撃ベクトルは何か。

細部が膨れ上がっていることから、評価や報告が自動化される前提であることも示唆される。記述は精密で重複を排したものでなければならず、ある製品カテゴリの異なる製品間で報告が自動化されたときに整合性が保たれる必要がある。

製品記述は階層（オントロジー）構造にもなっている。例えば SIEM（セキュリティ情報・イベント管理）システムは「自社運用型」と「マネージドサービス型」の2種類に分かれ、それぞれがさらに細分化される。もし実際の製品がこのカテゴリにすっきり分類されない場合、そのサイバーセキュリティ特性の収集・評価が妨げられかねない。

コメント提出への提案

では、私たちはコミュニティ／業界として、この膨大（あるいは混乱）とも言える文書群にどう対処すべきだろうか。

控えめながら、ここにいくつかのアプローチを示す。コンピュータ製品を開発・管理する人向けと、セキュリティ専門家向けの両方だ。

まず両者に共通するのは、今回の早期レビューを活用し、文書全体の構造や範囲についてコメントすることだ。（筆者が編集者である以上、こうした助言は予想されるかもしれない。）章立ては有用か？内容は適切な場所に配置されているか？用語は現場の開発者が使うものと整合しているか？

開発者やマネージャは、自分たちの製品に焦点を合わせるべきだ。
まず、自分の製品が規格の定義に当てはまるか確認すること。CRA は最終的にあらゆる製品に何らかの形で関係してくるため、関連規格で定義された製品記述が自分の製品を正確に表しているかを確認したい。各規格の構成要素や機能は詳細にリスト化されているので、注意深く精査すべきだ。規格によっては「適用範囲外」とされる製品もあり、自社製品がそこに該当する可能性も確認する必要がある。

セキュリティ専門家は、各標準の第5章「要件」に注目すべきだ。
ここでは、要件が時代遅れでないか、あるいは特定の脅威に対する対応策が抜けていないかを指摘できる。

筆者としては、オペレーティングシステム規格については、脅威や対策が OS ごとにあまりに多様で、十分に網羅できるとは悲観的に見ている。他の種類の製品であれば、もっと実現可能かもしれない。

標準規格案は CRA の現実的な試金石である

脅威とその対策は常に進化しているため、今回のサイバー標準案のように詳細な規制を導入するのであれば、継続的な見直しと改訂が不可欠となる。この早期レビュー段階は、コンピュータ分野全体の専門家が CRA によって何が実現できるのかを見極め、その目標達成を支援するための機会である。