サイバーレジリエンス法（CRA）は、産業用機器に組み込む通信機能の維持・管理のあり方を根本から変えます。デバイスメーカーにとって、通信機能の実装は、もはや技術上の課題だけではありません。製品の一部として規制の対象となり、セキュアな開発、継続的な脆弱性管理、ファームウェアの更新機能、文書の整備、長期的なライフサイクルサポートが求められます。
通信チップとプロトコルスタックを組み合わせた自社開発の通信ソリューションを採用しているデバイスメーカーにとって、これは継続的なCRA対応の大きな負担となります。従来は通信機能の実装に必要だったスキル、プロセス、リソースを、製品の市場投入時だけでなく、製品ライフサイクル全体を通じた規制対応にまで拡充する必要があります。
Anybus CompactComは、この課題の解決を支援します。自社開発の通信機能を、HMSが開発・試験・文書化・保守を行う既製の通信インターフェースに置き換えることで、デバイスメーカーは製品全体に対する管理とCRAへの適合責任を維持しながら、通信層に関わるサイバーセキュリティ業務の多くをHMSに任せることができます。
本資料では、HMSが提供する支援、CRA対応の負担を軽減する具体的な方法、デバイスメーカーが引き続き担う責任について説明します。
Anybus CompactComを採用しても、製品全体のCRA適合に対するデバイスメーカーの責任は変わりません。通信インターフェースに関わる対応業務の範囲、工数、リスクを軽減できます。
以下の表では、CRA対応の主な項目ごとに、HMSがAnybus CompactComを通じて提供する支援と、デバイスメーカーが引き続き担う責任を整理しています。
CRA対応項目 | HMSが提供する支援 | デバイスメーカーが担う責任 |
| 1. 開発プロセスと証拠資料 | Anybus製品は、認証を受けたセキュアな開発プロセスに基づいて開発されています。
通信層には、認証、暗号化、セキュアブートなどのセキュリティ機能が組み込まれています。 | ホストアプリケーションとデバイス全体に対するセキュアな開発プロセスの整備・運用。 |
| 2. 脆弱性の監視と開示 | HMSは、製品セキュリティに関する専任の体制を整え、以下の取り組みを行っています。
| ホストアプリケーションとその他のデバイス構成要素に対する脆弱性の監視・対応。Anybus CompactComの脆弱性を発見した場合のHMSへの報告。 |
| 3. 通信機能の対応範囲と責任分担 | Anybus CompactComは、そのまま組み込める産業用ネットワークインターフェースを提供するため、プロトコルスタックを自社で開発・保守する必要がありません。HMSは、通信インターフェースのセキュリティと継続的な保守を担います。 | ホストアプリケーション、設定、リスクアセスメント、CRAへの適合など、デバイス全体に対する責任。 |
| 4. 更新とパッチの管理 | Anybus CompactCom 40は、HMSがデジタル署名したファームウェアのみを受け入れ、更新時の完全性を確保します。IIoT Secureモデルでは、起動のたびにファームウェアの完全性をさらに検証します。 HMSは、デバイスのファームウェアを更新する3つの方法をサポートしています。詳しくは、後述のファームウェア更新に関するセクションをご覧ください。 | ホストアプリケーションのファームウェア更新機能の実装。バージョン間の整合性を保つための、ホストとABCCのファームウェア更新の調整。機械メーカー向けの更新手順の文書化。 |
| 5. サードパーティ製コンポーネントへの依存関係 | HMSは、オープンソースを含む組み込みソフトウェアコンポーネントの検証と保守を行っています。対象となるAnybus CompactComファームウェアのSBOM（ソフトウェア部品表）も、ご要望に応じて提供します。 | ホストアプリケーションとその他のデバイスソフトウェアのSBOMの維持・管理、およびサードパーティ製コンポーネントの追跡。 |
| 6. 文書の整備とライフサイクル全体の追跡可能性 | HMSは、以下を含む包括的なセキュリティ関連文書を提供しています。
統合ガイドでは、想定する使用目的、信頼できるネットワーク構成、セキュリティの初期設定、未使用のポートやサービスの無効化、利用可能なセキュアな通信経路について説明しています。 | ユーザーマニュアル、設置手順書、使用目的を記載した文書、および機械メーカーがデバイスを組み込む際のCRA適合を支援する手順書の作成。 |
| 7. 既存製品への対応と将来の戦略 | Anybus CompactComを採用することで、製品の世代を超えて組み込み通信機能を維持・更新し、セキュリティを確保するための長期的な負担を軽減できます。HMSが通信機能のライフサイクルを管理するため、デバイスメーカーが製品ライフサイクル全体を通じて、その維持・管理を自社だけで担う必要はありません。 | デバイス全体に対する長期的なCRA適合計画の策定と文書化。 |
すでにAnybus CompactComを採用しているデバイスメーカーにとって、CRAへの対応は、より多くの製品や派生モデル、将来のプラットフォームへ採用を広げ、通信インターフェースを標準化する明確な理由となります。
一貫した通信戦略がなければ、製品の派生モデルやプラットフォームの世代ごとに、個別のセキュリティプロセス、文書、更新機能が必要となり、時間の経過とともにCRA対応の負担が増大する可能性があります。Anybus CompactComを標準採用すれば、製品ごとに個別の体制を維持する負担を抑えながら、HMSの実績ある共通のライフサイクル管理を通じて、通信機能のセキュリティ、更新、関連文書を管理できます。
CRAへの対応において、実績があり、継続的に保守される通信インターフェースを一貫して採用する価値は、これまで以上に高まっています。
デバイスメーカーにとって、CRA対応で特に複雑な課題の一つが脆弱性管理です。自社製品だけでなく、サプライチェーン全体の一員として対応する必要があります。
CRAの下では、機械メーカー、デバイスメーカー、通信ソリューションの提供企業が、それぞれデジタル要素を備えた製品の製造業者としての役割を担います。各社には、自社製品に存在する、悪用可能な既知の脆弱性に対処する義務があります。実務上は、以下のように各社が連携して対応します。
図1. CRAにおける脆弱性管理の連携。産業施設の所有者から通信ソリューションの提供企業へと脆弱性情報が報告され、セキュリティアドバイザリや更新プログラムがサプライチェーンを通じて利用者側に届けられます。
CRAでは脆弱性対応に厳しい期限が設けられているため、メーカーは、受け取った報告に迅速に対応できる製品セキュリティインシデント対応チーム（PSIRT）を整備する必要があります。また、顧客からの報告に対応するだけでなく、自社製品に使用するコンポーネントの脆弱性も監視する必要があります。
これはデバイスメーカーにとって大きな運用負担となります。特に、既存のセキュリティプロセスや専任の担当者がいないメーカーでは、その影響が大きくなります。
HMSでは、Anybus CompactComの脆弱性を管理するための体制がすでに整っています。
デバイスメーカーは、Anybus CompactComを採用することで、この体制を活用できます。通信層の脆弱性監視や開示の仕組みを独自に構築・維持する負担を抑え、HMSによる管理の下で、脆弱性が特定された際に整理された情報を適時に受け取ることができます。
脆弱性管理は、CRA対応の中でも特に運用負担の大きい業務の一つです。通信層に関わる対応はHMSが担います。
ファームウェア更新の管理も、CRA対応に伴ってデバイスメーカーの実務が複雑になる分野です。特に、デバイスが機械に組み込まれている場合は、対応が難しくなります。
Anybus CompactComを搭載したデバイスには、通常、更新が必要なファームウェアが少なくとも2つあります。
多くのデバイスメーカーは、ホストファームウェアとABCCファームウェアを組み合わせて試験し、互換性を確認したバージョンの組み合わせで使用するよう求めています。個別に更新した場合の互換性は保証されないため、通常は更新のタイミングを調整し、互換性が確認された組み合わせで両方を更新する必要があります。
HMSは、以下の3つの更新方法をすべてサポートしています。
図2. Anybus CompactComを搭載したデバイスには、Anybus CompactComとホストCPUの2つのファームウェアが含まれます。それぞれのファームウェアは、コンソールポート、イーサネットインターフェース、または両者を組み合わせて更新できます。
機械全体では、課題はさらに複雑になります。デバイスメーカーがリリース前にホストとABCCのファームウェアの互換性を試験するのと同様に、機械メーカーも更新プログラムの適用前に、機械を構成するすべてのデバイスのファームウェアの互換性を検証する必要があります。そのため、通常はデバイスごとに個別に更新するのではなく、すべての構成要素をまとめた一つの更新パッケージとして提供します。
使いやすさの観点からも、機械全体を一括して更新できる共通のインターフェースが必要です。稼働中の機械では、エンドユーザーが個々のデバイスのコンソールポートにアクセスできないことも少なくありません。そのため、機械全体を更新するには、イーサネットインターフェースを通じてホストとABCCの両方のファームウェアを更新する必要があります。
HMSは、この更新方法をサポートしています。ABCCファームウェアはイーサネットインターフェース経由で更新できるため、ホストファームウェアとともに、機械全体の更新に組み込むことができます。これにより、個々のデバイスに物理的にアクセスすることなく、すべての構成要素間でバージョンの整合性を維持できます。
図3. 機械全体のファームウェア更新は、共通の更新インターフェースを通じて一括して実施します。PLC、接続されたデバイス、各デバイスに組み込まれた通信インターフェースをまとめて更新することで、すべての構成要素間でバージョンの整合性を維持できます。
イーサネットインターフェースを通じて機械全体のファームウェアを更新できることは、稼働中の機械でCRA対応を進めるうえで不可欠です。HMSは、この更新方法を標準でサポートしています。
HMSは、Anybus CompactCom 40に2つの主要モデルを用意しています。デバイスの使用目的と動作環境に応じて、適切なモデルを選択してください。
Anybus CompactCom 40の標準モデルは、アクセスが制限され、動作条件が明確に定められた、信頼できるセグメント化済みの産業用ネットワークで使用するデバイスに適しています。『セキュアなデバイス統合ガイド（Security Device Integration Guide）』に記載された使用目的と指針に従って組み込むことで、OT環境におけるCRA対応に必要な通信セキュリティを提供します。
図4. Anybus CompactCom 40は、信頼できるOT環境において、CRA対応に必要な通信セキュリティを提供します。
IT／IIoTへの接続、Webアクセス、または信頼できるネットワークの外部とのセキュアな通信が必要なデバイスには、Anybus CompactCom 40 IIoT Secureを推奨します。このモデルは、以下の追加の保護機能を備えています。
図5. Anybus CompactCom IIoT Secureは、IT／IIoT接続を利用するアプリケーションにおいて、CRA対応に必要な通信セキュリティを提供します。
IIoT Secureは、ファイアウォールなどの外部セキュリティ対策への依存を減らし、IT／IIoT接続を利用するアプリケーションでのセキュアな通信を可能にします。TÜVによるIEC 62443-4-2認証の取得は、2026年中を予定しています。
信頼できるOTネットワークからIT／IIoT接続環境まで、動作環境に応じて、CRAの通信関連要件を満たすことを目指して設計されたAnybus CompactComのモデルを選択できます。
Anybus CompactComを採用すると、通信機能に関わるCRA対応業務の範囲を大幅に縮小できます。ただし、製品全体に対するデバイスメーカーの責任は変わりません。以下の項目は、採用する通信方式にかかわらず、引き続きデバイスメーカーが担います。
HMSが提供する『セキュアなデバイス統合ガイド』には、使用目的、セキュアな初期設定、組み込み方法に関する実践的な推奨事項が記載されています。デバイスメーカーがこれらの責任を効率的に果たせるよう支援します。
Anybus CompactComの採用により、デバイスメーカーが製品全体への責任を果たしながら、CRAに適合する通信機能を維持するための対応範囲、工数、長期的なリスクを軽減することを目指します。
イェンス・ヤコブセン博士
HMS Networks 製品セキュリティマネージャー
イェンス・ヤコブセン博士は、HMS Networksの製品セキュリティマネージャーとして、産業用通信製品のサイバーセキュリティを強化し、ネットワークに接続された機器を新たな脅威から守る取り組みを主導しています。HMS Networks、Schneider Electric、Motorola Solutionsで技術職や管理職を歴任し、産業用通信とサイバーセキュリティの分野で豊富な経験を有しています。電気通信および産業用通信技術に関する7件の特許を取得しています。
