CRA要件は、CRA付属書Iに記載されています。テストチームは、これらの管理策をテストシステムに適用する方法を理解する必要があります。EUサイバーレジリエンス法は、european-cyber-resilience-act.com/で公開されている一連のドキュメントに詳しく記載されています。この法律は、57の条文にわたる記述があります。幸いにも、技術要件は主に付属書Iに記載されています。
欧州のCRA要件は主に付属書Iで定義されています。さらに4つの付属書文書もあります:
欧州連合共同研究センター (JRC) と欧州連合サイバーセキュリティ機関 (ENISA) は、CRAの要件が既存の業界標準、特にEN IEC 62443にどのように適合するかを概説する文書を発行しました。enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mappingに掲載の無料の文書は、これらの標準のいずれかを既に採用している企業にとって有益な指針になります。
付属書Iは2部構成になっています。第1部では、製品の特性、第2部では、サプライヤが脆弱性を発見した場合の対応について述べています。
(1) デジタル要素を備えた製品は、リスクに基づいて適切なレベルのサイバーセキュリティを確保するように設計、開発、製造する、
(2) デジタル要素を含む製品は、既知の悪用可能な脆弱性なしで提供する、
(3) 第10条第2項に記載されたリスク評価に基づき、該当する場合には、デジタル要素を備えた製品は次のことを行わなければならない:
(a) デフォルトで安全な設定が施された状態で納品され、製品を元の状態にリセットする機能を備える、
(b) 認証、アイデンティティまたはアクセス管理システムなど、適切な制御メカニズムにより、不正アクセスからの保護を確保する、
(c) 最新の暗号化技術を用いて、保存中または送信中の関連データを暗号化するなどして、保存、送信、またはその他の方法で処理されるデータ (個人データやその他のデータ) の機密性を保護する、
(d) ユーザによって承認されていない操作や変更から、保存、送信、またはその他の方法で処理されたデータ (個人情報を含む)、コマンド、プログラム、構成の整合性を保護し、破損について報告する、
(e) 製品の用途に関連して必要な範囲に限定された適切で関連性のあるデータ (個人データやその他のデータ) のみを処理する (「データの最小化」)、
(f) サービス拒否攻撃に対するレジリエンスおよび軽減策を含む、基本機能の可用性を保護する、
(g) 他のデバイスまたはネットワークが提供するサービスの可用性への悪影響を最小限に抑える、
(h) 外部インタフェースを含む攻撃面を制限するように設計、開発、および制作する、
(i) 適切な脆弱性攻撃緩和の仕組みおよび技術を利用して、インシデントの影響を軽減するように設計、開発、制作する、
(j) データ、サービス、または機能へのアクセスや変更を含む関連する内部活動を記録および/または監視することにより、セキュリティ関連情報を提供する、
(k) セキュリティアップデート (該当する場合、自動更新や利用可能なアップデートのユーザへの通知など) によって脆弱性に対処できるようにする。
これらの要件が適用されるテストシステムを開発している場合、最初の要件を満たす開発プロセスを採用する必要があります。Microsoft Secure Development Lifecycleや、NIST 800-218に記載された米国政府のSecure Software Development Frameworkをはじめ、複数のセキュリティ開発フレームワークが利用可能です。これらはLabVIEWやTestStandなどのテストシステムまたは製品用に開発されたものではありませんが、すべてのシステム開発に適用される一般的な原則が含まれています。これらを用いて、CRAの要件を満たすプロセスをチームのために作成することができます。
テストシステムの機能を計画する際は、CRAの追加要件を考慮する必要があります。ユーザと外部システムの両方によるテストシステムへのアクセスを制御する計画を立てる必要があります。暗号化によって保護する必要があるデータおよびそのデータを暗号化する方法を特定する必要があります。攻撃に対する防御策を開発する必要があります。アクティビティを監査ログに記録する必要があります。システムのコンポーネントに対するセキュリティアップデートの計画を立てる必要があります。
この作業は開発チームに追加の負担をかけることになり、プロジェクト計画の段階で追加のコストを慎重に考慮する必要があります。お客様と協力して、セキュリティのオプションを理解し、システムのセキュリティを維持するために導入後のシステム更新の責任者を決定します。
セキュリティはシステムレベルで考慮する必要があることに注意してください。コンポーネントによっては、これらすべての要件を単独で満たすことはできません。しかし、システムの他の部分と組み合わせて、それらのギャップを保護し、全体として完全なシステムセキュリティを示すことができるようにするべきです。
最後に、詳細なセキュリティ文書を提供することの価値と努力を過小評価しないでください。システムがCRAの要件を満たす方法を文書化する必要があります。さらに、システムをセキュアな構成に復元するための文書を含めておく必要があります。これが、万が一攻撃でシステムが無効化された際に重要な資料となります。また、それはシステムがそのセキュアな構成から変更されないようにするためにも活用されます。
デジタル要素を含む製品の製造業者は次のことを行う必要があります:
(1) 製品に含まれる脆弱性およびコンポーネントを特定し、文書化すること、これには製品の少なくとも最上位の依存関係を網羅する、一般的に使用される機械可読形式でソフトウェア部品表を作成することを含む、
(2) デジタル要素を含む製品に対するリスクに関連して、脆弱性に迅速に対処し、修正すること、これにはセキュリティ更新の提供を含む、
(3) デジタル要素を含む製品のセキュリティに関して、効果的かつ定期的なテストおよびレビューを実施する、
(4) セキュリティアップデートが利用可能になったら、修正された脆弱性に関する情報を公開すること。これには、脆弱性の説明、影響を受けるデジタル要素を含む製品を特定するための情報、脆弱性の影響、深刻度、およびユーザが脆弱性を修正するための支援情報が含まれる、
(5) 協調的な脆弱性開示に関する方針を策定し、実施する、
(6) デジタル要素を含む製品およびその製品に含まれる他社製品に関する潜在的な脆弱性に関する情報の共有を促進するための措置を講じる。これには、デジタル要素を含む製品で検出された脆弱性を報告するための連絡先住所を記載することも含まれる、
(7) デジタル要素を含む製品の更新を安全に配布する仕組みを提供し、悪用可能な脆弱性が適時に修正または緩和されることを保証する、
(8) セキュリティ問題に対応するためのセキュリティパッチやアップデートが利用可能な場合、それらが遅滞なく、かつ無償で提供され、ユーザが取るべき可能性のある対応を含む関連情報を提供する勧告メッセージを添付する。
システムとともに提供する文書には、SBOMを含める必要がある場合があります。SBOMには、システムのすべてのソフトウェアコンポーネントが含まれます。最近の攻撃では、企業は脆弱性のあるソフトウェアを含むシステムを特定するために、緊急のコンポーネント調査を行う必要に迫られています。SBOMは、ソフトウェアの一覧を管理し、その一覧を報告された問題と比較し、問題を含むシステムを管理する手段を提供します。
SBOMを増やすことで、エンドユーザは自分のシステムがどのような攻撃に対して脆弱であるかをより明確に把握できるようになります。サプライヤは、セキュリティ更新の提供を求められる頻度が増えることになります。サプライヤは、製品またはシステムの納入後5年間、これらの更新を提供するようにCRAから要求されます。そのため、チームはそのサポートを提供する計画を作成する必要があります。
これらのCRA要件を総合すると、テストシステムのセキュリティ防御が強化されることになります。しかし、それによりシステム開発者の作業量が増加し、NIのようなサプライヤに対する期待も高まります。
NIがどのようにリソースを提供し、お客様のチームがこれらの期待に応えられるよう支援しているかをご確認ください。