第6回では、CRAとIEC 62443の具体的な連携と実現技術を解説します。CRAのセキュリティ強化に向けた取り組みとして、セキュリティ・バイ・デザインや脆弱性管理の重要性を強調し、IEC 62443の各規格がCRA遵守の実装ガイドとして活用可能であることを示します。また、ICS研究所のeラーニングサービス「eICS」やコンサルティングを活用した具体的な支援例を紹介し、CRA準拠を効率的かつ実践的に進める方法を考察します。
これまでの第1回から第5回では、欧州サイバーレジリエンス法（CRA）の概要や製造業界にもたらす影響、適用範囲と対象製品、要求事項のポイント、そして組織的な取り組みや人材育成を中心とした対応戦略（その1）を解説してきました。今回の第6回では、前回の組織面やプロセス面の準備に加え、実際の製品開発やシステム構築において焦点となるキーテクノロジーと、IEC 62443との具体的な関連性に踏み込んで解説します。さらに、ICS研究所が提供しているeラーニングサービス「eICS」やコンサルティングを活用した具体的な支援例をご紹介しながら、CRA準拠をより効率的かつ実践的に進める方法を考察します。
CRAでは、セキュリティ強化に向けた取り組みとして、セキュリティ・バイ・デザイン（Security By Design）や脆弱性管理の徹底が求められます。これは市場投入前の段階から脆弱性を極力排除し、適切なライフサイクル管理を行うための基本方針ですが、実務的には多層防御(defense in depth)や運用面を視野に入れた包括的なアプローチを取らないと、IEC 62443が示すような産業分野のセキュリティ要件を満たすのは難しくなります。特に製造業の装置・機械メーカーやFA機器メーカー、システムインテグレーターが抱える大きな課題は、「どうやって現場レベルで実践可能なセキュリティを構築し、運用し続けるか」にあります。
CRAの要求事項は、多層防御を施した状態で製品を市場投入するだけでなく、運用開始後も脆弱性が見つかった際には迅速に対策・修正を行うことを想定しています。いわゆる脅威リスクアセスメントやサードパーティ部品の安全性評価、SBOM管理などを継続的に行う仕組みこそが、IEC 62443の思想とも合致する「運用しながらのセキュリティ管理」の要となります。
CRAは「EU市場で流通するデジタル製品のセキュリティ要件を明確に定める」法整備であり、IEC 62443が提唱するセキュリティ要求事項やプロセスをベースにしている部分が多いといえます。つまり、IEC 62443の各規格が示す開発フレームワークや運用上の要件が、そのままCRA遵守の実装ガイドとして活用可能です。具体的には以下の例が挙げられます。
ただし、EUサイバーレジリエンス法はITネットワークのセキュリティデバイス製品を対象にしており、現実的復旧対策を含めた法規制になっていない部分があります。つまり、攻撃を受けた際の縮退動作や回復動作を具体的にどう設計するか、という点までは深く踏み込んでいないのです。一方、IEC 62443-4-2のFR7（可用性）やFR3（システムの完全性）は、インシデント発生時の継続稼働や復旧プロセスをカバーしています。現場の生産設備や産業オートメーションでは、インシデントの影響を最小化しながら早期復旧する仕組みが求められるため、IEC 62443を踏まえた多層防御こそが重要な役割を果たします。
また、CRAは認証・証明の取得を要請するような方向性を示す可能性がありますが、第三者認証を取得するだけでは防御できるかどうかの保障はないことに留意が必要です。認証は一定時点での準拠を担保しますが、新たな脆弱性や攻撃手法に対しては、継続的な運用とアップデートが不可欠です。
ここからは、CRAとIEC 62443を組み合わせて、実際にセキュリティを実装・運用する上で考慮すべき技術的側面を整理します。特に以下に挙げるキーワードを軸に、多層防御の具体像を探ってみましょう。
IEC 62443-3-2で定義される脅威リスクアセスメントは、対象システムの構成要素や通信経路を分析し、潜在的な攻撃手法と影響度を評価するプロセスです。
CRA対応でも、IEC 62443-3-2に記載している開発初期段階から脅威リスクアセスメントを行い、開発リソースの配分や対策優先度を明確にしておくことが欠かせません。
多層防御の設計方針や、被害発生時の事業インパクト評価にも直結するため、一度きりで終わらずに継続的に更新していく必要があります。
脅威リスクアセスメントの手順を踏まえて、そこで重要となる脅威リスクモデル設計の手順を解説します。
重要インフラの制御システムや一般産業における製造システムやそれらの上に構築していくDXシステムにおいても、最初にすることは、システムのネットワークのセグメント・ゾーン設計です。セグメント・ゾーン設計は、制御コンジットの制御ループの時間軸演算周期を維持するように設計します。情報コンジットは、指令コードに対してリターンコードが一定周期時間を越えないように設計します。
セグメント単位もしくはゾーン単に、事業継続の重要度によって、IEC 62443-3-3のAnnex Aで記載のセキュリティレベル(SL)区分でセキュリティレベルを特定します。
産業用オートメーションおよび制御システム（IACS）のセキュリティリスクアセスメントに関する要件を規定しています。
IACSのセキュリティ要件とセキュリティレベル（SL）を規定しています。
その特定したセキュリティレベルにおけるそれぞれの脅威リスクアセスメントを実施していきます。
脅威リスクアセスメントを実施する上で必要となるのが、サイバー攻撃モデル設計です。
最初に揃えるのが、サイバー攻撃手法モデル表である。サイバー攻撃手法モデルは既知のサイバー攻撃の攻撃手法の違いを踏まえて、作成したものを用意します。
このサイバー攻撃モデルは最新のサイバー攻撃も含めて作成し管理する必要があります。
対象となるシステムのアーキテクチャ図を用意し、それをベースにサイバー攻撃の侵入口や攻撃標的や攻撃手順を書いたサイバー攻撃シナリオを作成していきます。
次に特定したセキュリティレベルに相当するIEC 62443-3-3のセキュリティ要件を具体的に実現する防御モデル（リスク低減対策表）を用意して、システムのアーキテクチャの上に必要となる防御セキュリティ要件を整理して脅威リスクモデル設計管理表を作成します。
この脅威リスクモデル設計管理表は、特定したセグメントやゾーンのシステムを構成する制御製品やデバイス製品のセキュリティ要件仕様になります。それは、システム構成製品の製品仕様書やガイドラインやセキュリティトレーサビリティ体系図やセキュリティ品質検査時の試験方案や試験結果の評価のチェックリスト作成時の基準にもなります。
防御モデルをシステムアーキテクチャに展開する時に、多層防御設計を実施することになります。Security By Design for System
脅威リスクアセスメントは、システムの基本設計を実施する時とセキュリティ要件をまとめた製品仕様書に基づいて調達採用することにした製品をシステム構成した時の2回実施することをIEC 62443-3-2では推奨しています。
製品開発においては、製品のアーキテクチャを対象に、サイバー攻撃手法モデルやサイバー攻撃シナリオや防御モデルを作成し、脅威リスクモデル設計を実施していきます。
この一連の作業の実現方法をICS研究所のオンデマンドビデオ講座eICSで習得することができます。
製品やシステムの多くが、他社製コンポーネントやオープンソースソフトウェアに依存しています。
IEC 62443-4-1のSM9(外部提供コンポーネントのセキュリティ要件)、SM10(サードパーティサプライヤーにてカスタム開発されたコンポーネント)などが示すように、サードパーティ部品にもセキュリティ要件を明確に課し、脆弱性管理を徹底する仕組みが不可欠です。
「Security By Design」を徹底するためには、自社開発部分だけでなく、外部から調達するモジュールの信頼性やサプライチェーンの評価が求められます。
IEC 62443-4-2のCR7.8（コンポーネントインベントリ（資産目録））と3-3のSR7.8（制御システムコンポーネントインベントリ（資産目録））に関連するSBOM（Software Bill of Materials）管理は、含まれるソフトウェアコンポーネントを一元的に把握し、脆弱性情報を追跡できる状態を維持する仕組みです。
CRAではメーカーに脆弱性やセキュリティ更新の責任を明確化する方向があり、SBOM管理をしていないと脆弱性対応が遅れ、法令違反リスクに直結する可能性があります。
産業用オートメーションおよび制御システム（IACS）のセキュアな製品開発ライフサイクル要件を規定しています。
IACSコンポーネントに対する技術的なセキュリティ要件を詳細に規定しています。
SM（Security Management）
セキュアな製品開発ライフサイクルを確立し、維持するための13の要求が規定されています。
FR（Foundational Requirements）
7つの基礎的な要求が規定されています。
- FR1: 識別と認証制御
- FR2: 使用制御
- FR3: システムの完全性
- FR4: データの機密性
- FR5: 制限されたデータフロー
- FR6: イベントへの適時対応
- FR7: 資源の可用性
SR（System Requirements）
制御システムのセキュリティ要件として、50件以上の具体的な項目が規定されています。
CR（Component Requirements）
コンポーネントのセキュリティ要件として50件以上の具体的な項目が規定されています。
SD（Secure by design）
製品の設計段階からセキュリティを組み込むことを目的に4つの実践的な方策が示されています。
SL（Security Level）
IACSのセキュリティ強度が4段階のレベルで定義されています。
- SL1: 操作ミスなど偶発的なセキュリティ違反からの保護
- SL2: 一般的な個人レベルの単純な攻撃からの保護
- SL3: 中程度の動機をもつ組織レベルの攻撃からの保護
IEC 62443-4-2のCR1.1(人間ユーザーの識別と認証), CR1.2（ソフトウェアプロセスおよびデバイスの識別と認証）, CR1.5（認証管理）, CR2.1（認可の実施）などで要求される通り、デバイスやユーザーが正当な権限を持つか検証する仕組みが必須です。
これは機密性(Confidentiality)を維持する上で基本となる技術領域ですが、産業システムは人間だけでなく多様な自動化機器やPLCなどとも通信を行うため、認証・認可の設計が複雑化しがちです。
そこで「Security By Integrate」の考え方を用い、アクセス制御を複数レイヤーで連携させながら、多層防御を実現する必要があります。
IEC 62443-4-2のFR3（システムの完全性）は、システムの完全性(Integrity)を維持するために、許可されていない変更や改ざんが行われていないかを検証できる仕組みを求めています。
具体的にはファームウェアアップデート時の署名検証や、設定ファイルのハッシュ確認などが挙げられます。
アップデート機能を安全に行うためにも、完全性チェックが欠かせません。
IEC 62443-4-2のFR7（リソースの可用性）に示される通り、万が一の障害や攻撃があってもサービスを継続できるような設計、または縮退動作(一部機能を制限して稼働し続けるモード)が重要です。
実際の工場や生産ラインでは長時間停止が許されないため、縮退動作、回復動作をどう設計するかが現場の最重要課題になります。
CRA単体では具体的な「現実的復旧対策」を義務づける内容が弱いとも指摘されていますが、製造業にとっては不可欠な要素といえます。
IEC 62443-4-2のCR1.9（公開鍵認証の強度）, CR1.10(認証フィードバック), CR1.14（対称鍵認証の強度）などで要求される機密性確保には、暗号化通信やデータ保護が挙げられます。
CRAに準拠する場合、ユーザーデータや知的財産を扱うケースでは厳格な機密性確保が求められるでしょう。
脅威リスクアセスメントを通じて、どの通信やデータに暗号化を適用すべきかを明確にしましょう。
IEC 62443-4-1のSD1（セキュア設計原則）やIEC 62443-4-2のCR2.8（監査可能なイベント）が示すように、ロギング機能によるインシデント分析はセキュリティ対策の重要要素です。
産業システムはリアルタイム制御も多いため、ログの取得量やタイミング設定に工夫が必要ですが、ログを元にフォレンジック調査を行うことで、原因究明と再発防止につなげられます。
この観点から、ICS研究所はフォレンジック調査技術研修を提供しており、実際にどのレベルまでログを残すべきか、現場でどのように分析すべきかといったノウハウを学ぶことができます。
IEC 62443-4-1のPractice7(SUM:セキュリティの更新管理)やIEC 62443-4-2のCR3.10(Support for updates:アップデートのサポート)では、製品やシステムを安全に更新するための仕組み（更新パッケージの署名や配布方法）を定義しています。
CRAでも脆弱性発見時にはアップデート提供を義務づける動きがあるため、SBOM管理と合わせてどのモジュールを更新すべきか把握できるようにしておく必要があります。
CRAは「すべてのデジタル製品に対して最低限のセキュリティ要件を課す」ことを目的としていますが、現実には業種や工場の設備によって求められる要件が異なります。そこで、システム設計でのセキュリティ多層防御設計と、それを構成するコーポレーション製品やデジタル製品に関する多層防御設計のやり方を産業別に実現する必要があるのです。医薬品や食品、自動車部品など、各分野で法規制や品質管理が異なるため、それぞれに合ったセキュリティ導入方法を考慮しなければなりません。
また、システム設計においても製品開発においても、制御システムにおいては、制御コンジットの演算周期と制御パフォーマンスの維持が優先されます。それも産業別に条件が異なっていますので、詳細確認をする必要があります。
また、前述のように第三者認証を取得するだけでは防御できるかどうかの保障はないため、認証取得後も脆弱性管理や運用監視体制の継続が重要です。CRAは法整備としての強制力を持ちますが、攻撃者との「イタチごっこ」であるサイバー脅威に対処するには、常に最新の情報を反映する運用体制がカギとなります。
EUサイバーレジリエンス法はITネットワーク製品を中心に規制するため、インシデント発生後の具体的な復旧支援を必ずしも強く求めているわけではありません。しかし、産業界では一度停止すると生産ロスが大きく、顧客企業への納期を直撃するリスクがあります。そのため、万が一インシデントが発生した場合に備えて、
といった観点で事前に準備しておくことが欠かせません。実際にインシデントが起こってから復旧方法を考えるのでは遅すぎるケースが多いため、あらかじめシステムや製品の縮退動作、復旧動作を設計・検証し、運用ルールに落とし込むことが重要です。
欧州サイバーレジリエンス法は、機械規則やAI法や産業用IoT無線機器などの法規制と重複しないように法律として立法化されています。その対応をすれば、重要インフラの制御システムや一般産業の工場がサイバー攻撃を受けても操業再開まで実現できるかというと、それらでは不足しています。
CRAには、サイバー攻撃の検知と検知した時の報告義務と防御を目的にしたセキュリティ要件までありますが、具体的な防御手法については規定していません。
何が不足しているかというと、インシデント検知から緊急対応、復旧・操業再開までの事業としてのサイバーレジリエンスです。
石油・化学プラントの工場では、生産する製品別にプラントシステムが異なります。その異なるプラントシステムの制御システムが異なる制御ベンダ製品で構成されているとシステム内で使用している制御ネットワークの通信仕様も異なります。プラント設備は30年から40年使用していても、そこで使われている制御システムは7年から12年ほどで中には15年周期で入れ替わっているのが現状です。その制御システムを入れ替える時に制御システムセキュリティ強化対策ができることになりますが、投資した制御システムの減価償却が終わっていないタイミングでセキュリティ強化をするにはできる範囲に限りがあります。
既知のサイバー攻撃に襲われても、その攻撃マルウェアに対処できなければ、検知も防御も不可能になります。その時の復旧作業は、被害の程度によって、実施する手順や復旧に必要な装備品や人材能力トレーニングが異なります。
工作機械が縦列に数ライン並んでいるFMS式製造システムラインと、ロボットやマシンがセル単位に構成された製造システムでは、復旧させる手順も違えば、単位も違います。それに、工作機械メーカーによって、コンピュータ部分のフォーマット機能の有り無し、インストール作業の仕組みが異なります。そのためのツールの準備や手順が異なります。
Warｍや標的型マルウェアの場合は、インシデント検知後、ログデータファイルを取り出して解析が可能ですが、ランサムウェアの場合ログデータ取り出し作業に感染リスクがあるため、基本、ネットワークの切り離し後、コンピュータ部分のフォーマットから始まります。
そういう具体的サイバーレジリエンス設計作業における課題解決が重要です。
ICS研究所では、CRAやIEC 62443に関する幅広い知見を活かし、セキュリティ教育プラットフォーム「eICS」を通じたトレーニングや、各企業の状況に合わせたコンサルティングを行っています。たとえば:
これらのサービスを総合的に活用することで、「Security By Design」と「Security By Integrate」を両立した現場対応力を高め、CRAやIEC 62443の要求を効率的かつ実践的に満たすことが期待できます。
次回の第7回では、CRAと他の国際規格（IEC 62443以外にも、AI法やEN 18031など）との関係や、認証取得に向けた留意点を詳しく解説します。ICS研究所が提供する認証取得支援サービスを活用することで、どのように効率的かつ効果的にCRAへの準拠を進められるか、具体的なプロセスを紹介する予定です。
第3回解説「CRAの適用範囲と対象製品」に対するアンケートで質問をいただきました。
“「パブリックコメント等を踏まえて最終案では“重要なデジタル製品”から除外された製品群があります。」と記載がありますが、除外されたのはいつでしょうか？
ご教示いただけると幸いです。”
ご回答いたします。
2023年7月13日 の審議にて ANNEX III のカテゴリーが見直され、
2024年10月10日に理事会で採択されました。
ICS研究所は、製造業のためのセキュリティ認証と人材育成のスペシャリストです。
ICS研究所は、制御システムセキュリティ対策（IEC62443等）の
国際認証取得支援を始めとした人材育成を中心に、企業の事業活性化（DX対応等）を支援します。
なぜCRAが提案されたのか、どのようなゴール（製品セキュリティの強化や市場信頼性向上）があるのか。
「CRAが製造業に与える影響」を中心に、企業が直面する具体的なインパクトを多方面から考察します。
CRAで具体的にどのような製品が対象となるのか？どこまでが適用範囲で、どこが除外なのか？
CRAに明記された要求事項を整理し、実務でどのように実践するかに焦点を当てます。
「CRAへの対応戦略 その1」として、組織体制強化と人材育成を中心とした実務的アプローチを解説します。
「CRAへの対応戦略 その2」として、キーテクノロジーやIEC 62443との連携について、事例を交えて解説します。
※詳細は後日公開
※詳細は後日公開
〒160-0004 東京都新宿区四谷1-15
アーバンビルサカス8 A棟2階