このブログは、「現場からの教訓：CRAから学んだこと」シリーズの第2回です。このシリーズの目的は、製造業者、ソフトウェアベンダー、コネクテッド製品の提供企業がCRAコンプライアンス・プログラムを実装する際の現実を理解できるよう支援することです。お客様との取り組みや業界リーダーとの対話を通じて得た教訓を紹介します。組織は、持続可能なコンプライアンスには、従来のサイバーセキュリティ活動を大きく超えるガバナンス、可視性、説明責任、ライフサイクル管理能力が必要であることを学んでいます。安全な製品を作るだけではCRAコンプライアンスは達成できません。
CRAコンプライアンスは製品分類から始まる：スコープとセキュリティレベルの定義が、なぜ製造業者にとって予想外の課題なのか。
経営層への示唆
組織がサイバーレジリエンス法（CRA）コンプライアンス・プログラムを加速する中、多くの経営層が予想外の現実に気づいています。最初の課題はセキュリティコントロールの実装ではありません。どの製品が対象で、どう分類すべきか、それぞれにどのサイバーセキュリティ義務が適用されるかを理解することです。
CRAが初めて導入されたとき、多くの組織は、主な作業は脆弱性管理、セキュア開発、SBOM、インシデント報告、市場投入後のセキュリティ活動になると考えていました。これらの要件は今も重要ですが、製造業者は、すべてがより根本的な問いから始まることに気づいています。どの製品が対象で、どう分類すべきか？
CRA製品のスコープ設定と分類
どの製品が対象で、どのように分類すべきか？
大規模な製品ポートフォリオを持つ企業にとって、この問いに答えることは驚くほど難しい場合があります。典型的な製造業者は、数百、場合によっては数千の現行製品、レガシー製品、組み込みソフトウェアプラットフォーム、クラウドサービス、モバイルアプリ、OEM製品、M&Aで取得したソリューションを抱えています。どの製品がデジタル要素を含む製品（PDE）に該当するかを判断し、リスクプロファイルを理解し、適切なセキュリティ義務を割り当てること自体が大規模な取り組みになっています。
分類の正確さは非常に重要です。なぜなら、分類判断は、必要なセキュリティコントロール、文書要件、脆弱性管理義務、規制報告要件、市場投入後の監視活動など、ほぼすべての後続CRAコンプライアンス活動を左右するからです。
製品を本来より低いセキュリティ階層へ分類すれば、今後何年にもわたるコンプライアンスリスクを生みます。逆に必要以上に高い階層へ分類すれば、不必要で高コストな作業を生みます。
多くの組織にとって、これがその後すべてのCRA活動の基盤になります。製品分類は、サイバーリスク評価、必要文書、適合性評価の経路、市場投入後の義務、経営報告、そして最終的にはコンプライアンス達成に必要なコストと複雑さに影響します。製品スコープ設定の段階での誤りは、コンプライアンス・プログラム全体へ連鎖することがよくあります。
製品分類がなぜこれほど難しいのか
多くの組織は、製品分類を単純な管理作業だと考えています。実際には、エンジニアリング、製品管理、法務、コンプライアンス、サイバーセキュリティ、経営層の広範な連携が必要になることがよくあります。
複雑さには、いくつかの要因があります。
ハードウェアとソフトウェアが混在するエコシステム
今日の製品が独立したデバイスだけで存在することはほとんどありません。コネクテッド産業用コントローラーには、組み込みファームウェア、モバイルアプリ、クラウド管理プラットフォーム、API、分析サービス、サードパーティ製ソフトウェアコンポーネントが含まれる場合があります。
組織は、これらのコンポーネントを個別製品、支援サービス、あるいはより大きな製品エコシステムの要素として扱うべきかを判断する必要があります。
レガシー製品ポートフォリオ
多くの製造業者は、何十年にもわたり進化してきた製品を維持しています。文書が不完全で、所有者が変わり、セキュリティ上の前提がもはや有効でないこともあります。分類の前に、組織は実際に何を販売・サポートしているのかを正確に棚卸ししなければならないことがよくあります。レガシー製品では、ユーザーガイドやエンジニアリング文書を探し出す必要があります。最悪の場合、それらの文書を作り直さなければなりません。
買収と製品統合
買収によって成長した企業は、異なるプロセス、アーキテクチャ、セキュリティモデルで開発された製品を引き継ぐことがよくあります。その結果、似た製品でもサイバーセキュリティ成熟度や文書化の水準が大きく異なり、一貫したCRA分類の確立が複雑になります。
適切なセキュリティレベルの判断
CRAの対象製品を特定した後にも、もう一つ難しい問いがあります。適切なCRA製品分類と、それに伴うサイバーセキュリティ義務を判断することです。
すべての製品が同じリスクプロファイルを持つわけではありません。消費者向けIoTデバイス、産業オートメーションコントローラー、クラウドベース管理プラットフォーム、安全性が重要な組み込みシステムは、CRAの下で異なるセキュリティ階層に分類される可能性があります。各階層には大きく異なるセキュリティコントロールと保証レベルが求められます。
適切なセキュリティ姿勢を判断するには、製品機能、接続特性、侵害時の潜在的影響、顧客環境、運用ライフサイクル要件を評価する必要があります。
多くの組織は、これらの評価に当初予想したよりはるかに多くの時間、構造、エビデンスが必要であることに気づいています。CRAでは、各製品にどのCRAセキュリティレベルを割り当てたかというすべての判断を裏付ける文書が必要です。
多くのOEMは、評価が必要な製品数が初期想定を大幅に上回ることにも気づいています。経営チームは、まず販売中の主要製品ラインを特定することがよくあります。しかし詳細な製品インベントリを作成すると、各製品ラインが複数のサポート中バージョンからなり、固有のソフトウェア・ハードウェア製品、OEMブランド製品、クラウドサービス、モバイルアプリの組み合わせで構成されていることが分かります。その結果、対象製品数が5倍以上になることも珍しくありません。
もう一つの課題は、製品分類方法に一貫性がないことです。標準化された分類フレームワークがなければ、事業部門ごとの製品チームが異なるリスク・セキュリティ重要度の定義を適用しがちです。その結果、似た製品に大きく異なるセキュリティ分類が付けられ、組織全体でコンプライアンスの不整合が生じます。
製品分類とセキュリティレベル決定のベストプラクティス
成熟したCRAコンプライアンス・プログラムを持つ組織は、いくつかの共通した取り組みを採用しています。
正式な製品分類体系を確立する
製品、ソフトウェア、サービス、支援コンポーネントを分類する標準フレームワークを作ります。一貫した用語と判断基準によって混乱を減らし、事業部門横断の意思決定を改善します。
部門横断の分類チームを作る
分類をコンプライアンスやセキュリティチームだけの責任にすべきではありません。成功している組織は、製品管理、エンジニアリング、サイバーセキュリティ、法務、規制対応、品質保証を関与させます。
リスクベースのセキュリティ階層を導入する
リスク露出と事業影響に基づく明確なセキュリティ階層を定義します。これにより、すべての製品を同一に扱うのではなく、事業・製品リスクに基づいて認証作業の優先順位を付けられます。
常に更新される製品インベントリを維持する
静的なスプレッドシートはすぐに古くなります。組織には、製品所有者、ソフトウェア構成、セキュリティ分類、ライフサイクル状態、規制上の義務を追跡し、継続的に保守されるインベントリが必要です。
分類判断を文書化する
規制当局は、結論だけでなく、その結論に至った根拠も説明するよう組織へますます求めるでしょう。分類判断を裏付けるエビデンスの維持は不可欠です。
Product Profileに適切な文書をそろえる
評価前に技術文書をまとめておくと、評価品質が一貫して向上します。製品仕様、アーキテクチャ図、SBOM、技術リファレンスマニュアル、セキュリティ文書、関連エンジニアリング資料は、評価精度を大幅に向上させ、後工程の不要な修復作業を減らします。
よくある落とし穴
お客様との取り組みを通じて、回避可能な共通の誤りをいくつか見てきました。
製品チームがすでに自分たちのインベントリを把握していると思い込む
多くの組織は、CRA対応活動の中で、隠れた製品、サポート終了バージョン、買収技術、文書化されていないソフトウェアコンポーネントを発見します。
分類を一度きりの活動として扱う
製品は進化し、機能は変わり、接続範囲は広がり、サプライヤーは製品に使うコンポーネントを更新します。製品ライフサイクル全体で適切なセキュリティ姿勢を維持するには、分類を継続的に見直す必要があります。
すべての製品に同じセキュリティ要件を適用する
一律のセキュリティモデルは、低リスク製品へ過度に厳しい要件を適用して不要なコストを生む一方、高リスク製品へリソースを集中できなくなることがあります。CRAは、リスクに基づいてセキュリティ姿勢を調整できるよう複数のセキュリティレベルを定義しています。
すべての製品に単一モデルを適用する代わりに、CRA製品セキュリティ分類階層へ対応付けられた複数のセキュリティ階層を持つ共通フレームワークを採用すべきです。
サプライヤーコンポーネントを無視する
サードパーティのハードウェア・ソフトウェアコンポーネント、OEM技術、オープンソースソフトウェアは、製品分類やセキュリティ義務に大きな影響を与える可能性があります。企業は、サプライヤーがCRA要件へ適合し、それらのコンポーネントを使う最終製品のCRAコンプライアンス・プログラムを支える適切な文書を提供することを確認する必要があります。
OEMとソフトウェアベンダーのアクション項目
CRAへの取り組みを始める組織は、次の直近アクションを検討すべきです。
- すべての製品、ソフトウェア、サービス、デジタル資産の完全なインベントリを作成する。
- デジタル要素を含む製品に該当する可能性が高い製品を特定する。
- 正式な分類方法論と承認プロセスを開発する。
- リスクベースのセキュリティ階層モデルを作る。
- すべての製品とプラットフォームの所有者を定める。
- サプライヤーとソフトウェア依存関係をマッピングする。
- すべての分類判断とその根拠を文書化する。
- 分類を長期にわたって最新に保つガバナンスプロセスを導入する。
分類課題へ早期に対処する企業は、その後のコンプライアンスコストと運用上の混乱を大幅に減らせます。
OmniTrust Certifyが支援できること
組織が直面する最大の課題の一つは、最初のCRA評価を実施することではありません。製品が時間とともに進化する中で、正確な製品情報、サイバーリスク評価、規制エビデンス、分類判断を維持することです。
Certifyは、すべてのコネクテッド製品に常に更新されるProduct Profileを作成し、繰り返し可能なプロセスを確立できるよう支援します。この基盤から、セキュリティチームは一貫してサイバーリスク評価を実施し、CRA義務を評価し、関連エビデンスを維持し、文書、アーキテクチャ、脆弱性、規制が変わるたびに製品を再評価できます。
分断されたスプレッドシートや文書に頼る代わりに、組織は製品ライフサイクル全体で製品分類、サイバーリスクガバナンス、規制適合、エビデンス管理、監査対応力を支える共同作業用の記録システムを得られます。
初期導入企業が学んでいるように、成功するCRAコンプライアンスは脆弱性管理やインシデント報告よりはるか前から始まります。自社がどの製品を持ち、それらがどのリスクを持ち、それぞれどのレベルのセキュリティ説明責任を必要とするかを正確に理解することから始まります。
製品分類を正しく行うことは、持続可能なCRAコンプライアンス・プログラムを構築する上で最も重要なステップかもしれません。Certifyと当社のコンプライアンスソリューションの詳細はこちら。
このシリーズの今後の記事の通知を受け取るには、ブログのホームページで購読してください。次回は「ブログ #3：CRA対応にはセキュリティ成熟度だけでは足りない理由」です。
