CRAのギャップ分析

比較の法的根拠

比較の基準には、その製品に適用されるCRA要件を用います。第6条と第13条は製品要件とリスク評価の義務を定め、附属書はセキュリティ要件と提供すべき情報を示します。評価で根拠として用いた規格や技術仕様も含めてください。

• 第6条と附属書Iは、製品要件と脆弱性対応要件を定めます。
• 第13条は、サイバーセキュリティリスク評価とサポート期間の根拠を求めます。
• 附属書IIは、ユーザー向け情報と取扱説明を列挙します。
• 附属書VIIは、技術文書の記載事項を列挙します。
• 第32条は、分類後の適合性評価手続きを定めます。
• 整合規格やその他の技術仕様は、要件をどのように満たすかを示す助けになります。ただし、法的効果はそれらの位置付けによって異なります。

ギャップの意味

ギャップは、製品、製造業者のプロセス、または結論を裏付ける証拠に関する場合があります。たとえば、更新の仕組みに署名検証がない場合や、仕組み自体はあっても改ざんされたパッケージを拒否することを示す試験結果がない場合です。これらの検出事項には、それぞれ異なる対応が必要です。

例：安全な更新に関するギャップの解消

架空のコントローラーには署名付きファームウェア更新機能がありますが、信頼されていない鍵で署名されたイメージを機器が拒否するかは試験されていません。最初のギャップは証拠の不足です。試験でイメージが受け入れられると判明した場合は、実装上のギャップにもなります。

1. 根拠：該当する附属書Iの要件、リスク評価、安全な更新設計を関連付けます。正確な製品バージョンと構成を明記します。
2. 検出事項：不足している試験または観測された動作を説明します。未試験の前提と実証された不具合を区別してください。
3. 対応：必要な変更の実装をファームウェアチームに、影響を受ける更新経路の試験を検証チームに割り当てます。製品リリースの判断に合う完了日を設定します。
4. 解消の証拠：改訂した設計または変更の参照先、該当ビルドの試験結果、更新済みのリスク評価を添付します。既存の試験結果を引き続き有効とする場合は、その理由を示します。
5. レビュー：担当レビュアーが新しい証拠に照らして元のギャップを確認します。タスクの完了や報告書のアップロードだけでは、ギャップが解消されたことを示せません。

各ギャップについて、該当要件を特定し、不足している内容を説明します。作業を割り当て、レビュアーが是正を受け入れるために必要な結果を定めます。裏付けとなる証拠とともにレビュー結果を記録します。

完了率はチェックリストの項目数を示すもので、残るギャップの重大度を示したり、適合性を証明したりするものではありません。更新時の認証不備が未解決であれば、文書作成タスクが複数完了していることより重要な場合があります。

ギャップ分析への入力情報

ギャップ分析には、定義済みの製品対象範囲と、根拠のある分類および適合性評価手続きが必要です。これらがなければ、適用されない要件と比較したり、適用される要件を見落としたりする可能性があります。

附属書Iのどの製品要件が適用されるかを判断する主な入力情報はリスク評価です。結果と証拠は技術文書にまとめます。詳しくは サイバーセキュリティリスク評価 および 技術文書を参照してください。