概要

CRAは、EU域に出荷される製品に関わる法令です。これまでの製品セキュリティに関わる法規制や業界規格と大きく異なる点は、CEマークの取得に直結するという強制力と、「デジタル要素を含む製品」が対象とする影響範囲の広さにあります。対象製品の定義については、CRAの用語集を読み解くと、電子回路が搭載されるような機器に関しては対象となる可能性が高い、と解釈しておくのがよいかと考えます。

条文・付属書が掲げる要件

製品メーカーとして対応が必要な要件としては13条・14条が挙げられます。内容の詳細については附属書に落とし込まれており、大きく「セキュリティ特性要件」「脆弱性対応要件」「技術文書化要件」の3種類に分かれています。

これらの要件への対応を進めておくことが目下の製品メーカーの取り組みとなります。が、産業機器等を始めとしたこれまで強くセキュリティ対応を市場から求められてこなかった製品群を抱えるメーカーは、対応にご苦労をされるケースが多く見られるのが現状です。

製品セキュリティに取り組む体制の整備

情報セキュリティのように対応すべき部門が決まっている分野と異なり、製品セキュリティは社内でも様々な部門に跨っての対応となります。開発部門が当事者の一つとなるのは当然ですが、その他にも、社内規定の整備や出荷前検査、出荷後製品の脆弱性管理等、開発工程以外での実施事項が存在します。
ここで問題となるのが、「どの部門がやるべきか」です。製品がリリースされるまでの通常の工程を考えると、品質部門が規定整備や検査に積極的に関わるべきとの考え方もあります。しかしながら、組込みソフトウェアやセキュリティについて十分な知見を持っている
品質部門はまだ多くないというのが実態です。この実態への対処方法を考えることなく、要件化されているからという考えのみで対応を進めてしまうことで、次のような状態に陥るケースが多く発生しています。

• 例1）開発部門だけで対応を進めようとした結果、本来新製品のプロジェクトに割きたいリソースまで検査や脆弱性管理といった工程に割り当てられてしまっている
• 例2）開発部門で実施した取り組みが正しいものかどうかのレビューを行えていない
• 例3）品質部門に開発工程以外の実施事項が割り振られたが、遂行できる知見を持ち合わせておらず、開発部門にしわ寄せが発生している

こういった状態を改善するためには、各個社の風土やリソース状況に沿ったマネジメント体制を確立することが必要不可欠です。例えば、製品セキュリティを品質問題と同等に捉え三線モデルを敷き、品質部門だけでなく専任組織(PSIRT)も新たに設置しガバナンス体制を整えているような事例もあります。

こういった体制のパターンでは、情報セキュリティ部門や開発部門でセキュリティ知見を持つ人材を専任組織にアサインする等の動きを取ることが多く見られます。
この体制が必ずしも正解ということではなく、自社に合った取り組み体制を構築することが重要です。

既存開発プロセスに対するセキュリティ業務の組み込み

組織体制の部分でも少し触れましたが、製品セキュリティにおいて最も負担が増加するのは開発部門です。現在構築されている開発プロセスの各工程(企画~運用保守)で、製品セキュリティの観点で新たな業務が発生していくこととなります。これをセキュア開発プロセスと呼びます。
下図が実際の取り組み例ですが、取り組みは「セキュリティ対策の検討・実装」「対策の正しさ検証」「脆弱性の継続管理」の3つに分類ができます。これらを確実に遂行していくことが重要ですが、いずれも実施するうえでは課題が存在します。

• セキュリティ対策の検討・実装

  このステップは、リスクを網羅的に可視化し、対策すべきか受容可能かの判断を行い、その結果に応じた技術対策を施すという流れを指していて、セキュリティにかけるコストの最小化といった効果も見込むことができます。リスク可視化の段階では、脅威分析と呼ばれる机上分析を行うことが一般的ですが、自社製品の使用環境に関する知識と、製品セキュリティの専門知見の双方を有している必要があるため、開発部門が未経験の状態から実施するには高いハードルが存在します。

• 対策の正しさ検証

  対策が正しく実装できているかの機能テスト、及び、製品に脆弱性が残されていないかのセキュリティテストをこのステップで実施します。中でも、対策の十分性を検証する目的で実施するペネトレーションテストは、テストシナリオの作成やシナリオを遂行可能な技術力の確保等、より高度なセキュリティ専門知見が問われます。

• 脆弱性の継続管理

  他のステップと比べ、ツール等を活用した自動化が可能な領域になりますが、難しい点として挙げられるのが、発見された脆弱性の影響度判断です。この影響度判断には、①該当ソフトウェアコンポーネントの使用有無、②自社製品での脆弱性の再現可能性、の2つの観点があります。

  ①については自社製品のSBOMの生成・管理が出来ているかどうかで判断の正確性が決まってきます。一方、②については、発見された脆弱性が製品仕様上再現できるのかどうか、動的な検査も用いながら判断する必要があるため、セキュリティの深い知識が必要です。

3つの取り組みそれぞれをお話ししましたが、まとめとしては、自社製品の知識と製品セキュリティの専門知見を充分に揃えることが、セキュア開発プロセスの目指すべきところとなります。