IEC 62443-4-1、4-2、6-2にみるOT環境の製品（コンポーネント）向けセキュリティ要件

2025年1月、IEC TS 62443-6-2「IEC 62443-4-2のためのセキュリティ評価方法論（Security evaluation methodology for IEC 62443-4-2）」がIEC（International Electrotechnical Commission：国際電気標準会議） より発行されました。これは、OTシステムのコンポーネント（デバイスやソフトウェア等の構成要素）のセキュリティ要件を定めたIEC 62443-4-2「IACSコンポーネントの技術的セキュリティ要求事項（Technical security requirements for IACS components）」（2019年2月発行）と、OTシステム及びコンポーネントの開発プロセスのセキュリティ要件を定めたIEC 62443-4-1「安全な製品開発ライフサイクル要求事項（Secure product development lifecycle requirements）」（2018年1月発行）に基づき、コンポーネントのセキュリティ対策を評価するための規格です。本稿では、近年のデジタル製品へのセキュリティ要求の高まりと、IEC 62443-4-1、IEC 62443-4-2、IEC TS 62443-6-2の解説、さらに製品サプライヤに推奨される対応について解説します。

デジタル製品へのセキュリティ要求の高まり

前回は、OTシステムに関するサプライチェーンのうち、サービス（構築、保守）のセキュリティについて解説しました。今回は製品（OTシステムと、システムを構成するアプリケーション、デバイス）のセキュリティを取り上げます。

サイバー攻撃が行われるとき、多くのケースでソフトウェア、ハードウェアの脆弱性を突いた攻撃が行われます。例えば、OSやオフィスソフトの脆弱性を悪用してマルウェアに感染させる、ネットワーク機器の脆弱性を悪用して侵入するなどです。こういった脆弱性を減らすためには、製品の設計・開発時点からセキュリティを組み込んでいくことが必要です。しかしながら、脆弱性をゼロにすることはなかなか難しいため、セキュリティパッチで修正するという対応も併せて必要となります。

近年では、EUサイバーレジリエンス法（CRA）、オーストラリアサイバーセキュリティ法など、製品のセキュリティ確保を要求する法規制が登場しています。日本でも、IoT製品を対象としたセキュリティ要件適合評価及びラベリング制度（JC-STAR）が開始されました。これらの法規制や制度によって、販売される製品のセキュリティが向上し、サイバー攻撃の被害が抑制されることが期待されています。

OT環境で用いられるシステムやアプリケーション、デバイスについても、上記の法規制や制度の対象に含まれるものが多数あります。これらの法規制や制度の要求事項に対応できない場合、製品が顧客から選ばれにくくなると考えられます。特に、EU CRAについては、対応しなければ製品を欧州市場で販売できなくなってしまうため、製品ベンダーにとってその対応は急務となっています。

IEC 62443シリーズは、OTセキュリティに関する代表的な国際標準規格として、これらの法規制や制度の検討において参考にされています。対応にあたっては、IEC 62443シリーズの文書を活用することが大いに有効です。

IEC 62443-4-1の概要

IEC 62443-4-1（以下4-1と記載）は、OTシステムで用いられる製品のセキュアな開発ライフサイクルを規定した文書です。「ライフサイクル」ですので、製品の設計・開発だけでなく、リリース後の不具合やパッチの管理などもスコープに含まれます。要求事項は、以下図表3に示した、8つの実践（Practice）に分類されています。

図表3：IEC 62443-4-1の要求事項の構成

このうち、SMは開発プロセス全体のマネジメントに関する要求事項、SR／SD／SI／SVVはそれぞれ開発工程の各段階（要件定義、設計、実装、テスト）における要求事項となります。SGはユーザー向けの文書の作成・提供に関する要求事項です。

要求事項は、「○○するプロセスを採用しなければならない（A process shall be employed…）」という書き方になっており、製品サプライヤの製品開発ライフサイクルのプロセスの一部として含まれることが想定されています。

要求事項の評価には、IEC 62443-2-1第2版及び2-4と同じく成熟度モデルが用いられます。定義については前々回のインサイト（成熟度モデルの定義）をご参照ください。

IEC 62443-4-2の概要

IEC 62443-4-2（以下4-2と記載）は、OTシステムのコンポーネントのセキュリティ要求事項を定めた文書です。要求事項は基本的に「コンポーネントは○○する機能を提供しなければならない（Components shall provide the capability to…）」という書き方になっており、セキュリティ対策の技術面を規定しています。

4-2が対象としている「コンポーネント」はOTシステムの構成要素であり、4種類に分類されています。これに対して、要求事項もコンポーネントに共通のものとコンポーネントの各種類に固有のものに分けて規定されています。図表4にこれらの関係を示します。

図表4：コンポーネントの種類、例と対応する要求事項

また、要求事項は内容によって図表5に示す7つの基本的要求事項（FR）に分類されています。この分類は、システムに対する技術的な対策を要求しているIEC 62443-3-3と共通です。

図表5：基本的要求事項（FR）

このうち、FR2は装置や情報が権限のないユーザーに使用されることから保護するための対策、FR5はネットワーク分離や通信制御に関する対策、FR6はログによるセキュリティ侵害の監視について主に定めています。

各要求事項は、対象とするコンポーネントの種類と基本的要求事項の分類による番号が付与されています。例えば、コンポーネントに共通の要求事項のうち、識別・認証に関する要求事項は、CR1.1、CR1.2…のようになります。

要求事項の対応の要否は、図表6のセキュリティレベルのうち、どのレベルを目指すかによって変わります。4-2本文及び附属書Bにおいて、各セキュリティレベルを満たすためにどの要求事項を満たす必要があるかが示されています。

図表6：セキュリティレベルと各レベルの説明

全ての要求事項に対して、以下4つの共通コンポーネントセキュリティ制約（CCSC：Common component security constraints）が規定されています。

CCSC 1：必須機能のサポート

IEC 62443-3-3では、「必須機能」を「健康、安全、環境及び制御する装置の可用性を維持するために必要な機能や能力」と定義しています。CCSC1は、セキュリティ対策がこの必須機能に悪影響を及ぼしてはならないという趣旨のものです。また、必須機能に使用するアカウントはロックアウトしてはならないといった具体例が挙げられています。

CCSC 2：補完的対抗策

コンポーネント単体で要求事項を満たすことができず、コンポーネント外の補完的な対策が必要である場合、その対策を文書化しなければなりません。

CCSC 3：最小特権

コンポーネントは、システムが最小特権の概念を実現するために、アクセス制御などを設定できる機能を提供しなければなりません。

CCSC 4：ソフトウェア開発プロセス

全てのコンポーネントは、4-1で規定される安全な製品開発プロセスに従って開発及びサポートされなければなりません。

IEC TS 62443-6-2の概要

IEC TS 62443-6-2（以下6-2と記載）は、4-2の要求事項に対する適合性評価を行うための方法論を規定した文書です。ただし、上記のCCSC4にもあるとおり、4-2の要求事項を満たすコンポーネントは、4-1に規定されるプロセスで開発されていることが前提となっています。そのため、6-2に規定される評価プロセスの相当部分が、コンポーネントの開発プロセスが4-1の要求事項を満たしているかを確認することで占められています。

6-2では、評価プロセスを2つのステップ、6つのブロックに分けて規定しています。以下、順を追って概要を説明します。

ステップ1-1 セキュリティコンテキスト評価

セキュリティコンテキストは4-1 SR-1で要求されているもので、製品が使用される環境に関する前提条件や要求事項を指します。例えば、物理的セキュリティが実装されている環境で使用されるかどうか、ファイアウォール配下のネットワークで使用されるかどうかといった条件は、その製品に対するセキュリティ脅威や必要な対策に大きく影響します。6-2における評価プロセスでは、まずこのセキュリティコンテキストと、4-1 SR-2で要求される脅威モデル（製品に対するセキュリティ上の脅威をモデル化したもの）が文書化されていることを確認します。

ステップ1-2 セキュリティ要求事項選択評価

サプライヤが、ステップ1-1で確認したセキュリティコンテキスト、脅威モデルをベースとして4-2の要求事項を選択し、文書化したことを確認します。

ステップ2-1 設計文書評価

必要な設計文書が記載され、設計が脅威モデルと整合していることを確認します。外部で開発されたサブコンポーネントを使用している場合は、それらのリスクを識別・管理していることを確認します。

ステップ2-2 セキュリティ指針評価

セキュリティ指針とは、4-1 SGで要求されているユーザー向けの文書を指します。これらの文書が4-1の要求事項を満たしているとともに、セキュリティコンテキストと合致し、一貫性があることを確認します。

ステップ2-3 コンポーネント要求事項評価

サプライヤが選択した要求事項について、コンポーネントが要求事項を満たしているか確認します。要求事項のテストが行われている場合は、そのテストの内容や結果についても確認します。

6-2では、4-2の要求事項のそれぞれについて、詳細な評価基準が記載されています。機能として必須の要素、実装の例、不十分な例などが含まれており、評価時に参考にすることが可能です。

ステップ2-4 セキュリティテスト評価

脆弱性テストやペネトレーションテストなどの報告書を確認し、開発者から独立したテスターによって行われていること、必要な脆弱性対応が行われていることなどを確認します。

製品サプライヤに推奨される対応

前述のとおり、デジタル製品へのセキュリティ要求が高まる中で、製品サプライヤはセキュアな開発プロセスを構築し実践すること、必要なセキュリティ機能を持つ製品を開発すること、製品の既知の脆弱性をなくすとともに新しい脆弱性に対処することなどが求められています。4-1、4-2、6-2を参考に、製品の開発プロセスと製品そのものの両方のセキュリティを向上させることが推奨されます。

製品へのセキュリティ要求は法規制・制度によって異なる箇所もあります。製品の開発プロセスやセキュリティ機能の全体に対する要求事項を体系的にまとめた4-1、4-2、6-2をベースにすることで、法規制・制度の要求ベースよりも効率的な対応が可能になります。

まとめ

IEC 62443-4-1、IEC 62443-4-2、IEC 62443-6-2について解説しました。OT環境のデジタル化が進む中で、OT環境で使用される製品についてもセキュリティ向上が必要となっています。社会的な要求への対応とともに、セキュアな開発プロセスの確立やセキュリティ機能を備えた製品の開発に向けて取り組むことを推奨します。

PwCコンサルティング合同会社では、セキュアな製品開発ライフサイクルの構築や、製品に関する法規制への準拠支援など、OT環境向け以外の製品も含めた製品セキュリティに関する支援を行っています。ご興味がある方はお気軽にお問い合わせください。