CRAへの対応戦略 その1 ～組織体制強化と人材育成を中心とした実務的アプローチ～ 第5回 作成日
要約 第5回 CRA解説の狙いCRA（サイバーレジリエンス法）への対応には、組織体制の整備・プロセス設計・人材育成が不可欠です。単にPSIRT（製品セキュリティインシデント対応チーム）を設立するだけでは不十分で、実務対応力を持ち、継続的に改善できる体制を社内に根付かせることが重要です。また、製品開発・セキュリティテスト環境の整備とISO/IEC 27001・27002との整合性も求められます。
目次 1. 前回までのおさらいと本稿の狙い これまでの連載（第1～第4回）では、欧州サイバーレジリエンス法（CRA）の概要と製造業への影響、対象となる製品の範囲やリスク分類、さらにはCRAの要求事項や遵守のポイントについて解説してきました。特に第4回では、セキュリティ・バイ・デザインやセキュリティ・バイ・インテグレートといった概念とともに、脆弱性対応や製品ライフサイクル全体でのセキュリティ管理が不可欠であることを強調しました。
今回の第5回では、「CRAへの対応戦略 その1」として、具体的な組織体制の整備やプロセス設計、人材育成などのソフト面に焦点を当てます。これは、単にPSIRT（製品セキュリティインシデント対応チーム）を立ち上げるだけでなく、実務能力を備え、継続的に改善を図れる体制を社内で根付かせることが鍵となるからです。また、製品開発環境やセキュリティテスト環境をどのように整備し、ISO/IEC 27001・27002との整合を図っていくかにも触れます。
本稿の内容は、CRAやIEC 62443に対応した機械装置や産業機器を開発しなければならないメーカーの開発マネージャー 、あるいはCRAやIEC62443に対応した生産システムを構築するシステムインテグレーター 、さらにこれらメーカーやSIerに対してコンサルティングを行う専門家 の皆様に、実践的な示唆を提供することを狙いとしています。
2. CRA対応における組織体制の重要性 2-1. PSIRTの位置づけと実務能力の必要性 前回（第4回）までで触れたとおり、CRAは対象製品における脆弱性管理と情報開示を強く求めています。これに対応するため、多くのメーカーやシステムインテグレーターではPSIRT（Product Security Incident Response Team） の設立を進めています。しかし、単にPSIRT組織を作るだけでは不十分 であり、実際に脆弱性を発見・分析し、迅速かつ適切に修正や情報公開を行い、顧客からの問い合わせに的確に対応できる“実務力”を持ったチームへと成長させる必要があります。
具体的には下記の役割・能力が求められます。
顧客の工場の設備と納品した製品のセキュリティ問題を解決する専門チーム 納品済みの製品から新たな脆弱性が見つかった場合、顧客への影響調査や顧客の工場にある製品のアップデート展開を迅速かつ正確に行うべくサポート。 顧客側に存在する製品のサイバーレジリエンス対応チームとも連携し、CISA(アメリカ)やENISA(欧州) など国際機関への脆弱性通知義務をサポート。 自社製品のサイバーレジリエンス対応チーム 社内の標準化を進める。ISO9001に基づく業務品質基準と手順書の整備とトレーニングの実施。 社内で自社製品の脆弱性確認セキュリティテスト環境 を構築・維持し、常に最新の脆弱性に対して検証を行う。注：セキュリティテスト環境は業務ネットワークから隔離すること。理由：セキュリティテスト環境ではサイバー攻撃ツールを使用するので、業務ネットワークに影響を与えないように独立ネットワーク環境とする。 フォレンジック調査結果から具体的なリスク低減策を検討し、組み込み機器や制御装置などの現場レベルでどのように対策を施すか設計サポートができる能力が求められる。 脆弱性テストができる環境を整備し、維持するチーム 製品開発環境・セキュリティテスト環境・出荷後の脆弱性テスト環境を統合的に管理し、ISO/IEC 27001・27002 基準によるセキュリティ管理を実施。 サプライチェーン全体から調達したソフトウェア/コンポーネントを対象に、テスト手順書に基づいて脆弱性評価を繰り返し実施する。 脆弱性が発見されたら、CISA(アメリカ Cybersecurity and Infrastructure Security Agency)やENISA(欧州 European Union Agency for Cybersecurity) などの国際機関へ報告注：積極的に取り組むことで顧客からの信頼を得ることができる。市場で脆弱性が発見されて国際機関に報告がされて、国際機関からメーカーに通知文書が送られて、45日間経過すると「Alerts」として公開される。この情報をもとにサイバーハッカーが攻撃ツールを開発し、顧客の工場を攻撃して顧客に被害が出た場合、顧客は該当メーカーに対して損害賠償を請求することが想定される。また、工場オーナーは、メーカーから脆弱性情報の報告があった場合は、24時間以内に国際機関へ報告しなければならないが、その義務違反で罰則を顧客が受けた場合、顧客はメーカーへ罰則金＋工場の損害金をまとめてメーカーへ請求する可能性が高い。 2-2. PSIRT業務フローとISO9001対応 PSIRTが安定して業務を回すためには、ISO9001 をはじめとする品質マネジメントシステムとも整合性を持った運用フローが必要です。
PSIRT業務フロー 脆弱性の情報収集 → 分析 → 修正措置の検討 → 顧客や公的機関への情報公開・連絡 → 対策の実装 → フィードバックと振り返り ISO 9001対応の業務品質基準と手順書の整備 各フェーズで求められる成果物（レポート、パッチ、コミュニケーション記録など）を規格に沿って管理し、監査可能な状態を保つ。 フローのどこかに不備・遅延・ミスが生じても早期に検知できる仕組みを持ち、継続的改善（ISO 9001に基づいたPDCAサイクル）を回せるようにする。 トレーニング PSIRTのメンバーだけでなく、製品開発組織やセキュリティ品質評価テストを行う組織の人員にも、セキュリティ関連の基礎知識と脆弱性対応フローを習得させる。 こうした体制整備のためには、「人材育成プログラム」の構築が必須となります。次の章では、この人材育成の重要性と具体策について掘り下げます。
図1 PSIRTの標準業務フロー 3. 人材育成と組織設計：実務力を支える鍵 3-1. 製品開発組織とセキュリティ品質評価組織の関係 CRAやIEC62443への対応を実務として進めるには、製品開発組織が設計段階からセキュリティ・バイ・デザインやセキュリティ・バイ・インテグレート の考え方を徹底することが不可欠です。同時に、セキュリティ品質評価テストを担当する組織は、製品開発組織と独立 していることが望ましいとされています。これは、客観的かつ中立的な視点からセキュリティリスクを評価し、開発側の見落としやバイアスを排除するためです。
組織の役割分担 製品開発組織 新規機能開発やプロダクトアーキテクチャの設計段階で、どこにセキュリティ機能を盛り込み、多層防御構造を構築するかを検討する。 実装後は基本的な脆弱性テストや単体テストを実施し、想定する攻撃シナリオに対して耐性を確認する。 セキュリティ品質評価組織 製品開発組織から独立し、脆弱性スキャナやペネトレーションテストなどのツールを活用して、追加のテストを実施。 フォレンジック調査技術 を活用し、実際に侵害が起きた場合の痕跡分析や原因追及が可能な体制を備える。分析結果に基づき、セキュリティ上の脆弱点をフィードバックし、多層防御構造がしっかり機能するよう修正を提案する。 多層防御（Defense in Depth) は、IEC 62443-3-3ではシステム設計上で、IEC 62443-4-2では製品の構造設計上で実現することが求められています。
システム設計上での多層防御は、一つの対策が破られても別の層が攻撃を食い止めるように、複数レイヤーでセキュリティ対策を重ねる考え方です。たとえば工場やシステム全体を“外部からのネットワーク侵入防止”、“内部システムの認証・権限管理”、“エンドポイント防御”などの層に分け、さらに監視やログ分析の層も加えることで、攻撃がどこかの層を突破しても最終的な侵入や被害の拡大を防ぎます。実現するべき具体的セキュリティ要件は、IEC62443-3-3に記載されています。実際にシステム設計上で殿にどのようなセキュリティ多層防御を設計するかは、対象となるシステム構造によって異なります。セキュリティ要件に対してどのような実装を実現すれば良いかは、ICS研究所のオンデマンドビデオ講座eICSやeICSジャーナルなどで学ぶことができます。
製品の構造設計上での多層防御は、製品内部構造の要所要所に必要となるセキュリティ要件を満たすセキュリティ機能を実装することになります。どのようなセキュリティ要件にどのような実装を実現すれば良いかは、ICS研究所のオンデマンドビデオ講座eICSやeICSジャーナルなどで学ぶことができます。
多層防御設計を行う場合、システム設計でも製品設計でも、サイバー攻撃による脅威リスクモデル設計を行い、リスクアセスメントを実施することがIEC 62443-4-1、IEC 62443-3-3、IEC 62443-4-2で求められております。脅威リスクモデル設計やリスクアセスメントの手順は、IEC62443-3-2に記載されております。
脅威リスクモデル設計は、起き得る具体的サイバー攻撃事例をもとに、サイバー攻撃モデルを作成し、IEC 62443-3-3やIEC 62443-4-2のセキュリティ要件に基づいた防御機能や製品構造上特有の防御手法などを考慮してサイバー防御モデルを作成していきます。そして、対象となるシステムや製品のサイバー攻撃の侵入口を特定して、具体的なサイバー攻撃シナリオを整理していきます。サイバー攻撃モデルと防御モデルと攻撃シナリオをもとに、脅威リスクモデル設計表を作成します。ここで作成した脅威リスクモデル設計表に基づいて、システムや製品のリスクアセスメントでの残留リスクや運用時の許容リスクを評価する時に使用したり、セキュリティ設計仕様書やセキュリティ品質テストの試験方案や評価基準表を作成して行くことになります。この脅威リスクモデル設計のやり方は、ICS研究所のオンデマンドビデオ講座eICSやeICSジャーナルなどで学ぶことができます。
リスクアセスメントは、OTセキュリティではIEC 62443-3-2、ITセキュリティではISO/IEC 27005に記載されております。それらの基本となるリスクマネジメントはIEC 31000-2018に記載されております。
また、フォレンジック調査 とは、不正アクセスやマルウェア感染などのセキュリティインシデントが起こった後、その原因や侵入経路、被害範囲を詳細に突き止める調査のことです。システムのログ情報やメモリ、ディスク上のデータなどを専門ツールで解析し、「いつ・どのような経路で攻撃されたのか」「どのくらい被害が及んだか」を明らかにします。こうした調査結果を踏まえることで、再発防止策を講じられるのが大きな利点です。このフォレンジック調査技術についても、ICS研究所のオンデマンドビデオ講座eICSやeICSジャーナルなどで学ぶことができますし、座学や実機を使ったトレーニングによる人材育成研修にも対応しております。
3-2. セキュリティ人材の育成プログラム CRA対応を成功させるうえで、単にマニュアルやツールを導入するだけでは不十分です。組織と人材の総合力 が問われます。具体的には次のような育成プログラムが考えられます。
セキュリティエンジニア育成プログラム 制御装置や搬送機、産業用ロボットなどの制御構造から、コンピュータ内のソフトウェア構造までを総合的に理解し、どこにセキュリティ機能を実装すべきかを判断できる能力を養う。 フォレンジック調査結果を分析し、多層防御構造のどの層に新たな対策を施すか検討できる実践力を身につける。 セキュリティテストエンジニア育成プログラム 脆弱性スキャンやペネトレーションテストのツールの使い方だけでなく、企業や工場の制御システム固有のリスクシナリオを把握し、テストケースを柔軟に設計できる力を習得する。 フォレンジック調査技術も学び、潜在的な侵入経路や攻撃パターンを再現・検証できる。 PSIRT対応組織やマネジメントシステム内部監査組織の人材育成 ISO/IEC 27001やISO9001の規格運用を理解し、PSIRT業務フローと品質基準の整合を監査・評価できるスキルを鍛える。 組織のマネジメントサイクル（計画・実行・監査・改善）において、脆弱性管理業務を適切に回すための知見を身につける。 これらのプログラムを通じて、次に説明する、製品開発環境・セキュリティテスト環境・出荷後の脆弱性対応環境 などさまざまな側面で高度な専門性を持つ人材を確保することが、CRAに対する実効性の高い防御体制の要になります。
4. 製品開発環境とセキュリティテスト環境の整備 4-1. 環境整備のポイント CRA対応には、「製品のライフサイクルを通じたセキュリティ管理」が求められるため、開発段階からリリース後まで一貫した環境整備が欠かせません。
製品開発組織 ソフトウェアコンポーネントのバージョン管理とSBOM（ソフトウェア部品表）の整備。 ISO/IEC 27001・27002を踏まえたアクセス制御や変更管理プロセスの導入。 コードレビューや検証ツールによる自動脆弱性検知の仕組み。 セキュリティテスト環境 産業用制御システムを模したテストベッドを持ち、顧客工場の実機構成に近い形 で脆弱性検証できるようにする。 物理的隔離やネットワークのセグメンテーションによる多層防御 を適用しつつ、実際の攻撃シナリオを再現可能にする。 フォレンジック調査 のためのログ収集・監視基盤を用意し、攻撃があった際の痕跡を分析するシミュレーションを行う。出荷後の脆弱性テスト環境 製品がリリースされた後も、継続的な脆弱性スキャン・テストを行うプロセスを保有し、CISAやENISAなどから連絡がある脆弱性 に対してすぐに検証・対策ができるようにする。 顧客へのリモートサービス で脆弱性を修正・パッチ適用する際、通信経路やリモートアクセスのサイバーセキュリティレベルを常に維持管理できる体制を構築する。4-2. 環境整備の課題と解決策 課題 : 専用の実機や制御ネットワークを用いたテストにはコストがかかり、実際の生産ラインを止めずにどこまで検証できるかが問題になる。解決策 : シミュレータや仮想環境による再現度の高いテストベッド構築、またクラウド上の仮想ICS環境を活用し、コストと実行性のバランスをとる。さらに、人材育成プログラム で学んだエンジニアがこうした環境を構築・維持管理する中でノウハウを蓄積し、組織全体のCRA対応能力を継続的に底上げすることが期待されます。
5. 生産システム設計および制御システム設計における組織と人材育成 5-1. 人材育成の要点 重要インフラにおける制御システム設計や工場における生産システムの制御システムセキュリティ対策の人材育成プログラム でサイバーレジリエンスを実現するためにどのような要素やレベルが求められるかについて以下に述べておきます。
まず、過去のサイバー攻撃手法を具体的事例をもとに学びます。攻撃対象となるシステムの構造に、どのようなマルウェアを使ってどこから侵入し、どこに展開し、標的をどのように確認し、どうこうげきしてどのような影響被害があったかを確認していきます。
ISA-95(IEC 62264)をベースに、最初に対象となるシステムのセグメント設計を行います。そして、制御コンジットや情報コンジットの条件を考慮してゾーン設計を行います。
ISA-95(IEC 62264)とは 製造現場（OT）と生産管理・経営層（IT）間の情報交換や機能階層を標準化する国際規格であり、生産管理体制の効率化と統合を支援し、オペレーション管理の可視化にも寄与します。ISA-95では、生産システム・企業システムをレベル0からレベル4までの5つの階層で定義しています。また最近では、サプライチェーン管理(SCM)などの企業間連携が重要になっているため、新たにレベル5を加えて議論されることが増えています。
図2 ESA95/IEC 62264 コンジットとは IEC 62443において、IACS（産業用オートメーション制御システム）内でセキュリティを確保しつつ、データや制御信号を伝送するための通信路、経路、またはネットワーク接続を指します. 特に、異なるセキュリティレベルのゾーン間を接続する際に、その役割が重要になります。
次に、各セグメントやゾーン単位のセキュリティレベルを設定します。リスクアセスメントで使用する脅威リスクモデル設計表の作成方法を学び、残留リスクと許容リスクの比較表の作り方を学び、システム設計上のセキュリティ要件を具体的に出して、システムを構成するデジタル製品のセキュリティ要件仕様書をまとめていきます。
運用時のインシデント検知機能やインシデント情報の警報システムも設計範囲に入れて、インシデント業務フローを整理します。インシデント検知機能は、起き得るサイバー攻撃の様々な現象や兆候を考慮してどこにどのような検知機能が必要になるかを設計していきます。
運用時の現場の人材能力設定も重要な要素になります。どのようなトレーニングが必要になるか、インシデント発生時の緊急対処や復旧手順や復旧条件なども運用時の現場の人材能力を考慮して設計しなければなりません。
学んだエンジニアがこうした環境を構築・維持管理する中でノウハウを蓄積し、組織全体のCRA対応能力を継続的に底上げすることが期待されます。
具体的なシステム設計要素については、ICS研究所のオンデマンドビデオ講座eICSやeICSジャーナルなどで学ぶことができます。
5.2 システムのセキュリティ認証と組織体制 システム認証は、システム設計をする組織認証として、IEC 62443-4-1組織認証を取得して、その組織がシステム設計をした対象システムが現地に据え付けられてから、対象システムの審査をすることになります。その基準は、IEC 62443-3-3システム認証です。
工場のオーナーから受注して新規工場の建設発注を担当する企業および工場の保守管理や設備運用を担当するエンジニアリング会社の組織認証基準は、IEC 62443-2-4になります。
運用する工場のセキュリティ管理基準は、IEC 62443-2-1になります。
注: 企業組織の業務品質基準は、ISO 9001ですが、ISO9001認証を取得している企業は、業務管理基本はPDCA管理になります。よって、PDCA管理が出来ていないことが認証審査で判明しますとISO 9001認証一時停止もしくは認証取り消しになることがあります。 実践トピック その1 システムの認証取得の有無にかかわらず、セキュリティレベル3（SL3）で設計したシステムの中に、IEC 62443-4-2のSL3を満たしていないデバイスやデジタル製品が含まれていると、それらはサイバー攻撃側から見ると“脆弱性”になってしまいます。つまり、攻撃者にとって侵入しやすい標的となり、システムを標的とする攻撃の入り口となり得るのです。より詳しい内容は、次回(第6回)で解説します。
実践トピック その2 たとえば、セキュリティレベル3のシステムにセキュリティ監視目的で“セキュリティネットワーク”を追加する場合、そのネットワーク自体のセキュリティレベルも3以上を確保しなければなりません。そうでないと、そのネットワークを構成するセキュリティデバイスやデジタル製品がシステム全体の脆弱性となり、サイバー攻撃側の攻撃侵入口になりかねないのです。さらに「セキュリティベンダーの製品だから安心」という保証はなく、セキュリティレベルの要件を満たしているかが重要なポイントとなります。より詳しい内容は、次回(第6回)で解説します。
6. ISO/IEC 27001・27002との関連 CRAは製品のセキュリティ品質を求める法規制ですが、開発や運用に携わる組織全体のセキュリティマネジメント がしっかりしていなければ、抜け漏れが生じる可能性が高まります。この点で、ISO/IEC 27001・27002 の実践は大いに参考になります。
ISO/IEC 27001：情報セキュリティマネジメントシステム（ISMS） リスクアセスメントや情報資産の分類、管理策の選定など、セキュリティ対策の全般フレームワークが規定されている。 製品開発環境やセキュリティテスト環境だけでなく、自社工場のサイバーセキュリティ／レジリエンス対応のリスクアセスメント にも役立つ考え方を含む。 ISO/IEC 27002：情報セキュリティ管理の実践規範 より具体的な管理策やベストプラクティスを示す。物理的・技術的・運用的なコントロール策を製造現場にも適用可能。 たとえば、顧客の工場のサイバーセキュリティ／レジリエンス対応のリスクアセスメント を行う場合、製品納入後の脆弱性対応プロセスやログ管理・インシデント対応計画など、27001/27002が提供する実践規範との整合が重要になります。ISO/IEC 27001を社内・顧客側の両面で導入・運用することで、CRAで求められる“製品のセキュリティ品質”を強化するだけでなく、“事業継続”や“リスク低減”にも大きく貢献できるでしょう。
7. ICS研究所による支援コンサルティングとeラーニング（eICS） CRAの要求に対応した組織設計やPSIRT構築、人材育成などを社内だけで完結しようとすると、膨大なリソースとノウハウが必要になります。そこで、ICS研究所は、以下の形で支援サービスを提供しています。
eラーニング「eICS」 IEC62443やISO/IEC 27001、さらにはフォレンジック調査手法や脆弱性対応フローなどを網羅するオンライン学習コンテンツ。 隙間時間で体系的に学習できるため、セキュリティエンジニアやPSIRT担当者の基礎力アップに有効。 コンサルティングサービス CRAやIEC62443対応の進め方を包括的にサポートし、企業の現状分析から導入計画策定、運用プロセスの定着まで伴走支援。 PSIRT体制構築や脆弱性テスト環境の整備、ISO/IEC 27001・9001との整合性確保など、個別ニーズに応じたアドバイスを行う。 自社工場・顧客工場のレジリエンス評価やリスクアセスメント手法の導入を支援する。 座学や実機を使ったフォレンジック調査技術研修 8. まとめ 本稿では、CRAへの対応戦略（その1）として、組織体制の強化やプロセスの設計・整備、人材育成の重要性を中心に解説しました。以下が主なポイントです。
実務能力を備えたPSIRT組織の構築 CISAやENISAなどの外部機関からの脆弱性連絡にも対応できるようにし、顧客工場や自社工場のセキュリティ問題を解決できる専門チームを育てる。 PSIRT業務フローをISO9001の品質管理プロセスと整合させ、監査可能で継続的改善を回す。 製品開発組織とセキュリティ品質評価組織の明確な役割分担 セキュリティ・バイ・デザイン、セキュリティ・バイ・インテグレート、多層防御の設計を製品開発段階から組み込む。 テスト組織は独立しており、フォレンジック調査や侵入テストなど高度な検証が可能。 人材育成プログラムの整備 セキュリティエンジニア育成プログラム、セキュリティテストエンジニア育成プログラム、PSIRTマネジメント育成など、多様な専門性を高める研修が必要。 これらのプログラムを通じて、製品開発環境、セキュリティテスト環境、出荷後の脆弱性対応能力をトータルで底上げする。 生産システム設計および制御システム設計における組織と人材育成 ISO/IEC 27001・27002のフレームワーク活用 情報セキュリティマネジメントシステムを製品開発・テスト・運用全般に浸透させる。 自社工場や顧客工場のサイバーレジリエンスリスクを包括的に評価し、継続的な改善サイクルを構築する。 次回（第6回）は、「CRAへの対応戦略 その2」として、実現のためのキーテクノロジーやIEC 62443との具体的関係 をさらに詳細に掘り下げます。そして、ICS研究所が提供するeICSやコンサルティングを活用した実際の導入ステップについても解説します。
この記事は役に立ちましたか？ JavaScriptを有効に設定してからご利用ください
ICS研究所は、製造業のためのセキュリティ認証と人材育成のスペシャリストです。
ICS研究所は、制御システムセキュリティ対策（IEC62443等）の
CRA（欧州サイバーレジリエンス法）の準備や対応に関する 
