このブログは、「現場からの教訓：CRAから学んだこと」シリーズの第4回です。このシリーズの目的は、製造業者、ソフトウェアベンダー、コネクテッド製品の提供企業がCRAコンプライアンス・プログラムを実装する際の現実を理解できるよう支援することです。お客様との取り組みや業界リーダーとの対話を通じて得た教訓を紹介します。組織は、持続可能なコンプライアンスには、従来のサイバーセキュリティ活動を大きく超えるガバナンス、可視性、説明責任、ライフサイクル管理能力が必要であることを学んでいます。安全な製品を作るだけではCRAコンプライアンスは達成できません。
なぜ市場投入後のサイバーセキュリティがCRA対応力を決める課題になっているのか
何十年もの間、多くの製品開発組織は比較的単純なモデルで運営してきました。製品を設計し、テストし、発売し、次のリリースや次の製品へ進むというものです。
成功は、予定どおりに開発を完了し、性能要件を満たし、品質試験に合格し、すべての製品要件を実装できたかで測定されていました。
欧州連合のサイバーレジリエンス法（CRA）は、この成功の尺度を根本から変えました。
製品発売はもはやゴールではありません。出発点です。
従来、セキュアな製品開発では、セキュア開発、リスク評価、適合性評価、技術文書に重点が置かれていました。CRAの導入により、この考え方は変わりました。製造業者やソフトウェアベンダーは、最も重要なCRA義務の一部が製品を顧客へ届けた後に始まることを認識しつつあります。
企業は今、製品のサポート期間全体を通じて動き続けるプログラムを実装しなければなりません。これには脆弱性管理、調整された開示、セキュリティ更新、インシデント報告、ソフトウェアサプライチェーン監視、顧客コミュニケーション、長期的な製品サポートの約束が含まれます。
多くの組織にとって、これは大きな運用上の転換です。問うべきことは、もはや次ではありません。
「この製品は出荷できるほど安全か？」
代わりに、次の問いになります。
「今後5年、7年、あるいは10年にわたって、サイバーセキュリティ上の説明責任を維持できるか？」
経営層への示唆
多くの組織は当初、CRAコンプライアンスをほかのサイバーセキュリティ・コンプライアンス施策と同じく、製品開発の取り組みとして考えていました。セキュリティ評価を実施し、必要なセキュリティ機能を実装し、必要な試験を完了し、コンプライアンスを文書化すればよい単純なプロセスだと考えていたのです。しかし、この見方は規制の範囲を大きく過小評価していることを組織は学びつつあります。
CRAは、サイバーセキュリティ上の説明責任にライフサイクルモデルを導入します。製造業者には、脆弱性を管理・開示し、セキュリティ更新を提供し、脆弱性や問題について顧客へ通知することが求められます。また、脆弱性、ソフトウェア依存関係、セキュリティ更新、顧客通知、インシデント対応活動、サポートの約束、製品リスク状況を継続的に可視化しておく必要があります。
これは製品セキュリティ管理方法の大きな変化です。CRAの下では、エンジニアリングチームが次の製品リリースや新製品開発へ移った後も長期間続く運用能力へ投資しなければなりません。
CRA対応力は製品セキュリティだけの問題ではありません。製品ライフサイクルガバナンスも必要です。
リリース後の義務がなぜこれほど難しいのか
製品リリース後にサイバーセキュリティとCRA監査対応力を維持することは、多くの組織が当初予想していたよりはるかに困難です。いくつかの要因があります。
製品は進化し続ける
ソフトウェア更新、機能強化、サードパーティコンポーネントの更新、新しい顧客利用ケースによって、製品リスクプロファイルは常に変わります。製品開発中や発売時に完了したリスク評価は、すぐに古くなる可能性があります。
脆弱性は絶えず現れる
セキュリティ研究者や攻撃者は、OS、オープンソースコンポーネント、商用ソフトウェア、ハードウェアプラットフォームに影響する新たな脆弱性を見つけ続けます。組織は、それらがリリース済み製品へ影響するかを継続的に評価する必要があります。
製品チームは次へ進む
製品がリリースされると、エンジニアリングチームは次のリリースや新製品開発へ注力することがよくあります。一方、レガシー製品は何年も現場に残り、その間に組織内の知識が失われることがあります。正式なライフサイクルプロセスと強固な文書化がなければ、製品機能やセキュリティアーキテクチャに関する知識は失われます。
ソフトウェアサプライチェーンはより複雑になる
現代の製品には数十、時には数百のソフトウェアコンポーネントが含まれ、それぞれが脆弱性を持つ可能性があります。企業は各コンポーネントとその更新を可視化しておかなければなりません。
顧客通知要件
CRAは、新たに発見された脆弱性、セキュリティ更新、サポート条件の変更について顧客へ通知することを組織に求めます。これらの義務を満たすには、多くの組織がこれまで持っていなかった運用能力を構築する必要があります。
現実世界の課題
多くの企業は複数のシステムでソフトウェアコンポーネントを再利用しています。オープンソースまたは独自ソフトウェアライブラリに重大な脆弱性が見つかると、更新と顧客通知のプロセス管理が難しくなる場合があります。
1つの脆弱性が、複数製品の複数バージョンへ影響することもあります。影響を受ける製品を特定するには、複数製品を検索し、分散したシステムから文書を集め、過去のSoftware Bill of Materialsを確認し、エンジニアリングチーム間で調整する必要があるかもしれません。
脆弱性そのものへの対処は簡単でも、完全なSoftware Bill of Materials（SBOM）を含む一元化された文書リポジトリがなければ、どの製品が影響を受けるか判断することは困難です。
企業は組織構造上の問題によって、市場投入後のCRA要件を満たすことにも苦労します。
リリース後の脆弱性管理責任は、製品チーム、サポート組織、エンジニアリンググループに分散していることがよくあります。その結果、コンプライアンス監査向けの文書収集は予想以上に難しくなります。
複数の事業部門で複数製品ファミリーをサポートする企業にも同様の課題があります。多くの場合、各チームが更新、サポートプロセス、脆弱性追跡を異なる方法で管理しています。
CRA対応では、チーム横断で標準化されたプロセスと、コンプライアンス活動を調整する経営層の責任が必要です。
持続可能なCRAコンプライアンスのベストプラクティス
最も進展している組織は、市場投入後のサイバーセキュリティを単なるコンプライアンス作業ではなく、恒久的な運用規律として扱っています。
ライフサイクル・セキュリティプログラムを構築する
サイバーセキュリティ責任は製品の構想段階から始まり、製品がサポートされる限り続く必要があります。組織は脆弱性監視、セキュリティ更新、インシデント対応、顧客コミュニケーション、製品終了をカバーする正式なプロセスを確立すべきです。
継続的な製品可視性を維持する
組織には、製品インベントリ、ソフトウェアコンポーネント、サードパーティ依存関係、製品所有者、サポート状況について最新の可視性が必要です。
可視性がなければ、効果的な市場投入後管理は不可能です。
明確な責任者を定める
すべての製品について、セキュリティ監視、脆弱性評価、更新管理、コンプライアンス報告の責任を明確に定義すべきです。
責任が不明確だと、頻繁にギャップが生じます。
可能な限り自動化する
製品ポートフォリオが拡大すると、手作業はますます困難になります。自動化によって脆弱性追跡、エビデンス収集、SBOM管理、コンプライアンス報告、監査対応力を改善できます。
コンプライアンスを製品運用へ統合する
組織はCRA活動を個別のコンプライアンスプロジェクトとして扱うべきではありません。CRA要件を標準の製品管理・サポート運用の一部にする必要があります。
よくある落とし穴
市場投入後の義務への対応を始めると、多くの組織が似た障害に直面します。
コンプライアンスをリリース前の活動と考える
最も一般的な誤りは、コンプライアンスが発売時に終わると考えることです。実際、多くの義務は導入後に始まり、それらが最も対応の難しい義務であることも少なくありません。
長期サポート要件を過小評価する
組織は開発活動に集中する一方、継続的なセキュリティ上の約束を維持するためのリソースを見落としがちです。
不完全な製品インベントリを維持する
展開されている製品と含まれるソフトウェアを特定できなければ、脆弱性への対応は困難になります。
分断された文書に頼る
複数システムに散在するエビデンスは、運用効率を低下させ、コンプライアンスリスクを生みます。
セキュリティ更新をエンジニアリングだけの作業と考える
セキュリティ更新には、エンジニアリング、法務、サポート、製品管理、品質、経営層の調整が必要になることがよくあります。
OEMとソフトウェアベンダーのアクション項目
市場投入後のCRA対応力を強化したい組織は、次の対応を検討すべきです。
直近の優先事項
- 現在の製品サポート・保守プロセスを見直す。
- サポート中のすべての製品とソフトウェアプラットフォームを棚卸しする。
- 正式な脆弱性監視手順を確立する。
- 市場投入後のサイバーセキュリティ活動の責任者を特定する。
- ソフトウェアコンポーネントの可視性とSBOM運用を見直す。
- インシデント対応と開示の準備状況を評価する。
- 顧客コミュニケーションプロセスを評価する。
- エビデンス管理のギャップを特定する。
これらを早期に始める組織は、CRA施行期限が近づく中で、はるかに有利な位置に立てます。
OmniTrust Certifyが支援できること
CRA対応プログラムから繰り返し得られている教訓の一つは、初期評価そのものは比較的短時間で完了できることです。本当の課題は、製品が進化し、脆弱性が現れ、サプライヤーが変わり、規制が成熟し続ける中で情報を最新に保つことです。
OmniTrust Certifyは、このプロセスの自動化を支援します。Certifyは、製品ライフサイクル全体を通じて製品サイバーセキュリティとコンプライアンスを管理する一元的な記録システムを提供します。
OmniTrust Certifyを使うことで、製造業者とソフトウェアベンダーはすべてのコネクテッド製品を常に更新されるProduct Profileへ集約し、サイバーリスク、規制適合、エビデンス、所有者、製品変更を継続的に追跡できます。エンジニアリング、セキュリティ、製品、コンプライアンスの各チームが同じ最新情報に基づいて作業できます。
CRAコンプライアンスを一度きりのプロジェクトとして扱うのではなく、Certifyは組織がサイバーセキュリティガバナンスへ持続可能なライフサイクルアプローチを確立できるよう支援します。
まとめ
CRAの下で成功するのは、安全な製品を作れる組織だけではありません。製品の運用期間全体を通じて、そのセキュリティを継続的に維持、監視、文書化、防御できる組織です。
だからこそ、サイバーレジリエンス法の下では、本当の仕事は製品リリース後に始まります。
このシリーズの今後の記事の通知を受け取るには、ブログのホームページで購読してください。次回は「ブログ #5：24時間報告のカウントダウンは、本当は可視性の問題」です。
