本日のゴール
- CRAの最新動向にキャッチアップする
- CRA対応の要となる「リスク評価」の実務ポイントを理解する
- 自社がCRA対応に向けて何をすべきかを具体的にイメージできるようになる
本題であるリスク評価についてお話しし、後半では実際に皆様が取り組むべきセキュア開発や脆弱性管理について、弊社の支援内容を具体例とともにご紹介いたします。
CRA対応を成功に導くリスク評価
本題に入る前に、なぜ今これほどまでに製品セキュリティが重要視されているのか、その背景に触れたいと思います。
情報通信研究機構（NICT）の最新観測では、昨年2025年のサイバー攻撃パケット数が7,000億以上に達し、10年前の5倍以上に増えています。1つの製品に換算すると、毎日6,800回以上の攻撃を受けている計算になります。この数字を見て、皆様が使用したり製造したりする製品は、本当にセキュアだと言い切れるでしょうか。
さらに最新のIoT機器の観測状況を見ていきます。こちらは総務省とNICTが連携する「NOTICE（ノーチス）」の最新データです。毎月1億以上のIoT機器が観測され、その中には容易に推測可能なID・パスワードのままネットに接続されている機器が1万件以上あります。その内訳はルーターやネットワークカメラが多いですが、その他機器も40%ほどあります。容易なパスワードのままであるということは乗っ取られやすく、攻撃の踏み台にもなりますので注意が必要です。
ここで攻撃事例をいくつか紹介します。
- 2016年 Mirai（ミライ）： IoT機器をターゲットにしたマルウェアです。世界中の機器が感染し、特定のサーバーへ一斉にDDoS攻撃を仕掛けました。ソースコードが公開されたことで、日本でも亜種が猛威を振るいました。感染した機器自体は通常通り機能し、動きが少し遅くなる程度で気づかれにくかったことが被害拡大の一因です。
- 2022年 Apache Log4Shellの脆弱性： リモートで任意のコードが実行できる脆弱性であり、ランサムウェアの仕込みなどに悪用されました。
もし自社の製品が攻撃に関わってしまった場合、攻撃の「加害者」となり、信用の失墜につながってしまいます。
製品セキュリティ法規制の動向
世界中で製品セキュリティの法規制が整備されています。産業系制御システム、医療機器、自動車ではすでに義務化されており、IoT領域では英国のPSTI法、EUのCRA、日本のセキュリティ要件適合評価及びラベリング制度（JC-STAR）の運用が開始されています。「インターネットにつながる製品にはセキュリティが必須」という流れが国際的に確立されています。
CRA（欧州サイバーレジリエンス法）のおさらい
- 対象機器： デジタル要素を備え、ネットワークまたはデバイスへ接続する製品。
- 製造業者の義務： 1. リスク評価に基づいた適切なセキュリティ機能の実装（暗号化や認証など）。 2. 脆弱性管理。その手段としてのソフトウェア部品表（SBOM）の作成。SBOMをもとに脆弱性の監視を行い、発見時には速やかな対応が必要です。
- 制裁： 法律であるため、違反した場合は最高1,500万ユーロ、あるいは世界売上の2.5%（日本円で約27億円以上）の罰金が課される可能性があります。
- スケジュール： 脆弱性の報告義務が今年の9月11日から始まります。注意点は、現在販売している既存製品も対象となることです。そして、来年2027年12月にはCRAが全面適用されます。
CRAの主要要件
- 第13条（製造業者の義務）： 製品に対するセキュアな開発、暗号化や認証の実装が求められます。これらが要件に適合していることを「技術文書」で証明する必要があります。要件は付属書Iのパート1に記載されています。
- 第14条（報告義務）： 悪用された脆弱性を認識してから、24時間、72時間、14日という期限でそれぞれ報告が必要です。要件は付属書Iのパート2に記載されています。
参考となる「整合規格」と「ガイダンス」
CRAは法律であるため、具体的な手法までは書かれていません。そこで「整合規格（Harmonised Standards）」が参考になります。これに従って製品を作れば、CRAに適合しているとみなされます。
- 水平規格： 特定分野に依存しない共通規格。ドラフト版として「用語集」「サイバーレジリエンスの原則」「脆弱性ハンドリング」などが発行されています。
- 垂直規格： 製品カテゴリー固有の規格。今後、EN 50000シリーズやIEC 62443の改定が予定されています。
※注意点：整合規格が出揃うのが2027年10月末予定であり、全面適用の直前です。規格を待っていては対応が遅れます。
また、2026年3月上旬に欧州委員会から「CRAドラフト版ガイダンス」が公開されました。法的拘束力はありませんが、適用範囲やOSS（オープンソースソフトウェア）の扱い、サポート期間、リスクアセスメントなどの解釈が難しい部分が説明されています。
リスク評価の実務ポイント
2027年12月の全面適用に向け、リスク評価はセキュリティ対策の第一歩です。第13条第2項において、製品のライフサイクル全体（計画、設計から廃棄まで）でリスク評価を実施し、その結果を考慮することが義務付けられています。
リスク評価は以下の4ステップで進めます。
ステップ1：製品構成の整理 評価対象の全体像を可視化します。ハードウェア、基板、Wi-Fi、USBなどのコンポーネントを洗い出し、外部とのインターフェース、接続されるネットワークやクラウドを図に加えます。その後、責任範囲（評価範囲）を明確にし、保護資産（設定情報、ユーザー個人情報、製品機能など）を特定します。
- 実践ポイント： 最初から完璧を求めず、進めながら改善していく。
ステップ2：データフローの整理 構成図に外部から保護資産へのアクセス手段を矢印で記述します。これが攻撃パスになります。
- 実践ポイント： 通常運用時だけでなく、廃棄時（下取り時の情報漏洩リスクなど）を含めたライフサイクル全体を考慮する。
ステップ3：脅威の洗い出し セキュリティの三要素（機密性・完全性・可用性）が損なわれる「ダメージシナリオ」を具体化し、その原因となる「脅威シナリオ」を特定して、攻撃手順を整理します。
- 例： 監視カメラの映像漏洩（機密性の欠如）。初期パスワードでログインされ映像を盗み見られる、といったシナリオ。
- 実践ポイント： 悪意を持った攻撃者の視点を持つこと。IPA（情報処理推進機構）のガイドやテンプレートが参考になります。
ステップ4：リスク評価と対策方針の決定 影響度と攻撃の容易性からリスク値を決め、対策（暗号化など）の方針を立てます。
- 実践ポイント： 説明責任を果たせるよう、検討経緯を記録として残すこと。まずは実際に手を動かしてノウハウを溜めることが重要です。
日立ソリューションズグループの支援策
CRAは法律であるため、「何をどこまでやれば準拠と言えるか」が分かりにくいのが課題です。弊社は整合規格や国際規格（IEC 62443）のコンサル実績に基づき、プロセスの構築を支援します。
- プロセス策定コンサルティング： CRA要件と現行プロセスのギャップ分析から、対策計画の立案、教育まで実施します。
- 製品への適用支援： 実際のリスク評価の実施、暗号化の実装、SBOM作成支援なども、ご要望に応じて提案可能です。
- 関連ソリューション：
- 脆弱性詳細レポート： 英語の速報をアナリストが詳細に解説。
- SBOM導入支援： ツールの選定から導入まで。
- 脆弱性調査支援サービス： 生成AIを活用し、大量の脆弱性調査の工数を大幅に削減。
日立ソリューションズグループには、数多くのプロダクトセキュリティコンサルティングの実績がございます。4月から開始すれば、来年の全面適用に間に合うスケジュールでの支援が可能です。
まとめ
- 最新動向： ドラフト版EN40000シリーズや欧州委員会によるドラフトガイダンスを活用すること。
- リスク評価： 基本ステップ（製品構成、データフロー、脅威抽出、リスク評価）を確実に実施する。
- 具体的イメージ： ギャップ分析を起点に、段階的にプロセスを整備する。
専門家対談・質疑応答
ここからは日立ソリューションズの松本氏にも加わっていただき、対談形式で進めます。
写真：（左）松本氏、（中央）杉原氏（右）RYODEN社員
テーマ1：どこまでやれば十分と言えるのか？
- 杉原氏： 製品リスクに応じて必要十分な対策をすることが基本ですが、最も重要なのは「説明責任」です。「やらない」という判断も含め、合理的な説明ができる範囲で対応する必要があります。
- 松本氏： 整合規格が未確定の間は、デファクトスタンダードであるIEC 62443シリーズを参考にし、技術文書に「どの規格を根拠に、なぜこの対策をしたか」を明記するのが現時点でのベストです。
Q：報告義務の対象となる「実際に悪用された脆弱性」とはKEV（既知の悪用された脆弱性カタログ）を指すのか？
- 松本氏： CISAのKEVそのものを指すわけではないと考えています。CRAの文言では「悪用された確実な証拠があるもの」とされています。公開されていない脆弱性が悪用された場合でも報告対象になり、最終的にはEUの当局がデータベースに登録する流れになります。
テーマ2：攻撃の前提条件はどこまで厳しく置くべきか？（物理アクセスや高度な攻撃者など）
- 杉原氏： CRAには「合理的に予見可能な」という言葉が出てきます。マニュアル外であっても想定しうる使い方や、製品の用途・インターフェースに基づき現実的に起こりうる攻撃を前提にします。量子コンピュータによる暗号解読のような、現時点で極端な想定まで考慮する必要はありません。
- 松本氏： コストとのバランスが重要です。国家レベルの攻撃者にしか不可能な攻撃などは優先度を落とすなど、リスクベースで判断し、その判断根拠を記録に残すことが大切です。
テーマ3：罰則や不備とみなされるケースについて
- 松本氏： 結果だけでなく、プロセスも重視されます。妥当なプロセス（脆弱性管理やテストなど）を踏んでいないと判断されれば、是正措置やリコール、最悪の場合は罰金の対象となります。
テーマ4：部門横断での進め方
Q:どの部門から着手すべきか？
- 杉原氏： セキュア開発は設計部門、脆弱性管理は品質保証部門などが担うことが多いと思いますが、まずは各部門の代表が集まり、CRAの付属書にある要件を一つ一つ確認（ギャップ分析）し、役割分担を決めることから始めるのが有効です。
- 松本氏： まずは自分たちでギャップ分析や体制整備を行い、判断が難しい箇所に外部支援を活用するのが効率的です。
Q：過去に販売した製品も対象か？
- 松本氏： 脆弱性の報告義務については、過去に販売した製品も対象になります。2027年12月の全面適用（適合性評価）については、それ以降に販売する製品や、既存製品であっても大幅な変更を加えた場合に適用されます。ただし、あまりに古くてソースコードがないような製品の対応については、FAQなどで例外的なガイドが示されています。
Q：製品機能以外の対策（取扱説明書による注意喚起など）は有効か？
- 松本氏： CRAでは「多層防御」が考え方の基本です。まずは製品機能で可能な限り対策を行い、それでも技術的・現実的に困難な部分について、正当性を技術文書に残した上で、マニュアルや外部のファイアウォール運用に委ねる、という整理が必要です。
最後に
- 杉原氏： CRA対応には専任の担当者を置くことをお勧めします。通常業務との兼務は困難な場合が多いです。
- 松本氏： まずはCRAの要件を確認し、危機感を持って一歩を踏み出すことが重要です。
