2026年に報告されたCVEは、1日あたり前年比131%増加しています。

PSIRT

IEC 62443-4-1:産業用製品のセキュア開発ライフサイクル

IEC 62443-4-1は、産業用オートメーション・制御システム向けのセキュアな製品を開発・保守するために、サプライヤーが従うべきプロセス要件を定めています。8つのプラクティスのうち、セキュリティ課題の管理とセキュリティアップデートの提供の2つは、PSIRTが担う業務です。

更新日

IEC 62443-4-1とは

IEC 62443-4-1:2018(Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements)は、2018年1月に発行されました。規格自身の適用範囲によれば、本規格は「産業用オートメーション・制御システムで使用される製品のセキュアな開発のためのプロセス要件を規定する」ものです。定義されるライフサイクルは、セキュリティ要件の定義、セキュアな設計、セキュアな実装、検証と妥当性確認、欠陥管理、パッチ管理、製品のサポート終了までをカバーします。

適用対象は製品の開発者と保守者、つまりコントローラー、組み込み機器、ネットワーク機器、ホストソフトウェア、アプリケーションを製造する製品サプライヤーです。製品のインテグレーターやユーザーは対象外で、それぞれに対応するパートがシリーズ内にあります。ISAはこのシリーズをISA/IEC 62443として発行しています。

本規格が記述するのは技術的なセキュリティ機能ではなく、プロセス要件、ポリシー、手順です。コンポーネントに対する技術要件はIEC 62443-4-2にあります。

IEC 62443-4-1の8つのプラクティス

要件は8つのプラクティスに分類され、それぞれに要件IDの接頭辞となる短い略称があります。ISA Global Cybersecurity Allianceによれば、要件は合計47項目です。

プラクティス 要件 対象範囲
1. セキュリティマネジメント(SM) SM-1〜SM-13 セキュリティプロセスの計画と運用:責任、専門性、開発環境のセキュリティ、秘密鍵、外部提供コンポーネントとサードパーティコンポーネント、プロセスの検証、継続的改善
2. セキュリティ要件の仕様化(SR) SR-1〜SR-5 製品のセキュリティコンテキスト、脅威モデル、製品のセキュリティ要件とそのレビュー
3. セキュアバイデザイン(SD) SD-1〜SD-4 セキュアな設計原則、多層防御の設計、設計レビュー、設計のベストプラクティス
4. セキュアな実装(SI) SI-1〜SI-2 セキュリティ実装レビューとセキュアコーディング標準
5. セキュリティ検証・妥当性確認テスト(SVV) SVV-1〜SVV-5 要件テスト、脅威緩和テスト、脆弱性テスト、ペネトレーションテスト、テスターの独立性
6. セキュリティ関連課題の管理(DM) DM-1〜DM-6 製品のセキュリティ課題の受付、レビュー、評価、対処、開示
7. セキュリティアップデート管理(SUM) SUM-1〜SUM-5 セキュリティアップデートの適格性確認、文書化、適時の提供
8. セキュリティガイドライン(SG) SG-1〜SG-7 多層防御、ハードニング、セキュアな運用、アカウント管理、廃棄に関するユーザー向けドキュメント

プラクティス6:セキュリティ関連課題の管理(DM)

DMは、PSIRTが自らの業務と認識するプラクティスです。ISAGCAによれば、そのプロセスは、多層防御戦略に従って構成された製品のセキュリティ関連課題を扱うために用いられます。6つの要件は、課題を報告から解決まで追跡します。

  • DM-1:セキュリティ関連課題の通知の受付
  • DM-2:セキュリティ関連課題のレビュー
  • DM-3:セキュリティ関連課題の評価
  • DM-4:セキュリティ関連課題への対処
  • DM-5:セキュリティ関連課題の開示
  • DM-6:セキュリティ欠陥管理プラクティスの定期的なレビュー

平たく言えば、報告を受け付け、確認し、評価し、修正し、ユーザーに伝え、プロセス自体を見直すということです。

この流れは、名前を変えた脆弱性管理ライフサイクルそのものであり、DM-1とDM-5は協調的な脆弱性開示が関わる部分です。開示はCSAFアドバイザリーとして公開でき、影響を受けないバージョンについてはVEXステートメントを添えられます。

プラクティス7:セキュリティアップデート管理(SUM)

SUMは、DMが修正を決めたところから引き継ぎます。ISAGCAの要約によれば、そのプロセスは、製品のハードウェア、ソフトウェア、ファームウェアのセキュリティアップデートがリグレッションについてテストされ、適時にユーザーに提供されることを確実にするものです。5つの要件は次のとおりです。

  • SUM-1:セキュリティアップデートの適格性確認
  • SUM-2:セキュリティアップデートの文書化
  • SUM-3:依存コンポーネントまたはOSのセキュリティアップデートの文書化
  • SUM-4:セキュリティアップデートの提供
  • SUM-5:セキュリティパッチの適時の提供

SUM-3は、サプライチェーンにまで及ぶ要件です。製品が依存するコンポーネントやOSのアップデートが対象になります。Linuxディストリビューションをベースにした組み込み製品では、出荷するパッチの大半がこれに該当することもあります。

成熟度レベル

IEC 62443-4-1が問うのは、プロセスが存在するかどうかではなく、どれだけ成熟しているかです。CMMI for Developmentに基づく4つの成熟度レベルを用います。

レベル 意味
ML1 Initial プロセスが場当たり的に、または文書化されずに実施されている
ML2 Managed プロセスが文書化され、活動がどのように実施・管理されるかが記述されている
ML3 Defined (Practiced) プロセスが文書化され、実行され、反復可能である
ML4 Improving パフォーマンスと有効性の指標を用いて、プロセスが継続的に改善されている

ML2とML3の違いは実践にあります。文書化されたDMプロセスはML2になり得ます。ML3は、プロセスが実行され、繰り返されていることを意味します。課題を受け付け、評価し、解決し、アップデートを提供し、それを示す記録が残っている状態です。

認証

  • ISASecure SDLA。Security Development Lifecycle Assuranceプログラムは、開発組織のライフサイクルプロセスをIEC 62443-4-1に基づいて認証します。評価は、適合性評価機関として認定されたSDLA認定試験所が行います。
  • 認証機関とIECEE CBスキーム。Applus+やTÜV Rheinlandなどの試験・認証機関は、62443-4-1に照らしてサプライヤーを評価し、達成した成熟度レベルを明記します。これには50か国以上で通用するIECEE CBスキームの下での評価も含まれます。

62443-4-1の認証が対象とするのはサプライヤーの開発プロセスであり、個々の製品ではありません。製品は62443-4-2に照らして別途評価されます。

62443-4-1とシリーズの他のパートとの関係

  • IEC 62443-4-2:IACSコンポーネントの技術的セキュリティ要件。製品に何ができなければならないかを定めます。4-1は、それをどのように構築・保守するかです。
  • IEC 62443-3-3:システムのセキュリティ要件とセキュリティレベル。システムレベルにおける同等の技術要件です。
  • IEC 62443-2-4:IACSサービスプロバイダーのセキュリティプログラム要件。アセットオーナーのサイトで製品を設置・保守し、サプライヤーのセキュリティアップデートとガイドラインに依存するインテグレーターや保守事業者が対象です。

IEC 62443-4-1とPSIRT業務の対応関係

PSIRTの活動 62443-4-1での該当箇所
脆弱性報告の受付 DM-1
トリアージと分析 DM-2、DM-3
修正 DM-4、SUM-1
アドバイザリーと開示 DM-5、SUM-2
サードパーティコンポーネントのパッチ SUM-3、および外部提供コンポーネントとサードパーティコンポーネントに関するSM-9とSM-10
修正のリリース SUM-4、SUM-5
指標とプロセスのレビュー DM-6、SM-13

この対応関係は、要件のタイトルに基づいて当社が作成したものです。規格はPSIRTに名指しで言及していません。同じ業務は、FIRSTのPSIRT Services FrameworkやISO/IEC 30111に記述されています。

DMとSUMのエビデンスとしてのSBOM

2018年版の要件タイトルにはSBOMへの言及はありません。しかし、産業用製品のセキュリティ課題の多くは、サプライヤー自身が書いていないコンポーネントにあります。Linuxカーネル、OpenSSL、BusyBox、プロトコルスタックなどです。新たなアドバイザリーに対してDM-2とDM-3に応えるには、影響を受けるコンポーネントがどの製品とバージョンに含まれているかを把握している必要があります。SUM-3のアップデートを文書化するには、各リリースがどのバージョンのコンポーネントとともに出荷されたかを把握している必要があります。ML3では、それらの答えの裏付けとなる記録が必要です。

手作業で作成したコンポーネントリストやソースツリーのスキャンは、すぐに古くなります。リリースを生成したビルドから得たSBOMは、ビルド自体が記録されている限り古くなりません。

CRACIの役割

CRACIはIEC 62443に基づく認証を一切行わず、お客様の開発プロセスを運用するものでもありません。CRACIの記録は、その一部のエビデンスとして活用できます。各リリースに含まれるコンポーネントのインベントリと、出荷済みビルドに対する新たな脆弱性の監視です。

CRACIは、Yoctoビルドを含むGitHub Actionsのビルドを自社のランナーで実行し、推移的依存関係、キャッシュから復元されたパッケージ、どのロックファイルにも記載されない依存関係を含め、各ジョブが実際に取得したパッケージを記録します。各SBOMには完全性の状態が付与され、CycloneDXまたはSPDXでエクスポートできます。監視対象のSBOMは継続的に再評価され、ビルド履歴では過去のどのビルドに脆弱な依存関係が含まれていたかがわかり、インベントリビューではどのバージョンがどの製品にデプロイされているかがわかります。購入したコンポーネントのベンダーSBOMも、自社のビルドと並べて監視されます。脆弱性トラッキングとPSIRT向けのCRACIをご覧ください。

OEMに製品やコンポーネントを供給していますか?サプライヤー向けSBOMガイドと、顧客が適用する可能性の高いSBOM品質チェックリストをご覧ください。

IEC 62443-4-1に関するよくあるご質問

IEC 62443-4-1とは何ですか?

IEC 62443-4-1:2018(Secure product development lifecycle requirements)は、IEC 62443シリーズのうち、産業用オートメーション・制御システムで使用される製品を開発するサプライヤー向けのプロセス要件を定めたパートです。セキュリティ要件、セキュアな設計、実装、検証と妥当性確認、欠陥管理、パッチ管理、製品のサポート終了をカバーします。

IEC 62443-4-1の8つのプラクティスとは何ですか?

セキュリティマネジメント(SM)、セキュリティ要件の仕様化(SR)、セキュアバイデザイン(SD)、セキュアな実装(SI)、セキュリティ検証・妥当性確認テスト(SVV)、セキュリティ関連課題の管理(DM)、セキュリティアップデート管理(SUM)、セキュリティガイドライン(SG)です。合わせて47の要件があります。

IEC 62443-4-1と62443-4-2の違いは何ですか?

4-1は、サプライヤーが製品を開発・保守するために用いるプロセスに関するものです。4-2は、組み込み機器、ネットワーク機器、ホスト機器、ソフトウェアアプリケーションなど、コンポーネントそのものに対する技術的なセキュリティ要件を定めています。一般にサプライヤーは、開発プロセスについては4-1、特定の製品については4-2に照らして評価されます。

IEC 62443-4-1のどのプラクティスが脆弱性管理をカバーしていますか?

主にプラクティス6のセキュリティ関連課題の管理(DM-1〜DM-6)と、プラクティス7のセキュリティアップデート管理(SUM-1〜SUM-5)です。前者はセキュリティ課題の受付、レビュー、評価、対処、開示を、後者はセキュリティアップデートの適格性確認、文書化、適時の提供をカバーします。これはPSIRTが担う業務です。

IEC 62443-4-1の成熟度レベルとは何ですか?

CMMI for Developmentに基づく4つのレベルです。ML1 Initial(場当たり的または文書化されていない)、ML2 Managed(プロセスが文書化されている)、ML3 DefinedまたはPracticed(文書化され、実行され、反復可能)、ML4 Improving(パフォーマンス指標を用いてプロセスが継続的に改善されている)です。

IEC 62443-4-1の認証はどのように取得しますか?

認定を受けた認証機関を通じて取得します。ISASecureのSDLAプログラムは、認定試験所を通じて開発組織をIEC 62443-4-1に基づいて認証します。また、TÜV RheinlandやApplus+などの認証機関は、IECEE CBスキームの下でのものを含め、達成した成熟度レベルを明記した62443-4-1の認証書を発行しています。

IEC 62443-4-1はSBOMを求めていますか?

2018年版の要件タイトルにはSBOMへの言及はありません。ただし、外部提供コンポーネントや、依存コンポーネントとOSのアップデートを扱う要件がいくつかあり、各リリースに含まれるコンポーネントの信頼できるリストは、それらへの対応を示す現実的な手段です。

脆弱なコンポーネントを含む出荷済みビルドを把握する

セキュリティ課題の管理は、各リリースに何が含まれているかを知ることから始まります。デモを予約して、Yoctoビルドを含め、各ビルドが取得したものの記録からそれをご確認ください。

デモを予約