グローバル市場の共通言語: IEC 62443で日米欧の規制を統合する

1. 米国の共通言語「NIST CSF」と、実装の「IEC 62443」

米国市場において、サイバーセキュリティの話題は常にNIST Cybersecurity Framework (CSF)を中心に回っています。CISA（サイバーセキュリティ・インフラセキュリティ庁）も、重要インフラ事業者に対してNIST CSFの採用を推奨しています。

「What」のNIST、「How」のIEC 62443

しかし、製造業のエンジニアにとってNIST CSFは時に扱いにくいものです。なぜなら、NIST CSFは「何を管理すべきか（What）」という上位概念（Identify, Protect, Detect, Respond, Recover）を示してはくれますが、製品設計レベルで「どう実装すべきか（How）」までは教えてくれないからです。

例えば、NIST CSFが「PR.AC-1: アクセス権は許可されたユーザーのみに制限されている」と要求したとします。設計者は悩みます。「パスワードの長さは何文字？ 二要素認証は必須？ 失敗時のロックアウトは？」

この「How」の答えを持っているのが、OT分野のデファクトスタンダードであるIEC 62443です。
米国では近年、政府の政策（大統領令 EO 14028等）により、CISA（規制・管理側）とISA（技術標準側）の連携が急速に進んでいます。つまり、「NIST CSFの管理目標を達成するための、最も確実な技術的実装手段がIEC 62443である」というコンセンサスが形成されつつあるのです。

米国の重要インフラは、16分野に及んでおり、EUや日本での重要インフラ分野とはその範囲が異なります。よって、米国の重要インフラの範囲については、自社がそのサプライチェーン範囲に入っているかどうかを確認してください。特に、重要機械分野には半導体製造や航空機製造や船舶業界などが入っております。防衛分野においては、航空機製造、船舶造船、車両製造など広範囲になります。

2. NIST CSF × IEC 62443 マッピングCIRCIA攻略の羅針盤

では、具体的にどう紐づくのかを見てみましょう。このマッピングを理解することは、CIRCIA対応だけでなく、顧客からの「NIST準拠」という要求に的確に答えるための最強の武器になります。

以下の表は、NIST CSFのコア機能に対し、IEC 62443のどの要件が「実装解」となるかを整理したものです。

• ※ SR: System Requirement (システム要件), CR: Component Requirement (コンポーネント要件)

CIRCIAは「Detect（検知）」と「Respond（対応）」を求めている

CIRCIAの核心である「72時間以内のインシデント報告」をこの表に当てはめると、「DETECT（検知）」と「RESPOND（対応）」の能力が極めて重要であることがわかります。

顧客（重要インフラ事業者）がCIRCIAを守るためには、NIST CSFでも示しているように、特定・防御・検知・対応・復旧の中の検知ができなければなりません。つまり、貴社製品のどこに防御機能を配置して、防御機能を破ることで異常検知（NISTの「Detect」）し、それをトリガにIEC 62443-4-2のCR 6.1（監査ログ）でログが記録される。異常検知は、CR7.x（システム整合性）のどれに該当するかが明確でなければならないのです。

「NIST対応」と聞くと膨大なドキュメントワークを想像しがちですが、エンジニアが注力すべきは「IEC 62443のCR（コンポーネント要件）を実装すること」。これが、結果としてNIST対応になり、CIRCIA対応になるという構造を理解してください。

3. CIRCIAの「報告義務」を果たすための具体要件

マッピングを踏まえ、CIRCIA対応に特化したIEC 62443の活用法を深掘りします。報告義務を果たすためには、以下の「技術」と「プロセス」が不可欠です。

1. 「いつ起きたか」を知るための防御（Protect）、検知・ログ設計 (Detect)

CIRCIAは「発生したと合理的に信じた時点」から72時間のカウントを始めます。

• IEC62443-4-2（CR1～CR5 Protect）:
  アクセス制御から利用制御からセキュリティ機能の構造設計で深層多層防御を構築し、防御機能を装備する。その防御を一つでも破ることで検知（インシデント検知）をきっかけに緊急動作やログ記録が作動することが必須です。
• IEC 62443-4-2 (CR 6.1 Audit Log):
  ログイン成功/失敗、特権操作、設定変更など、セキュリティに関わるイベントを漏らさず記録します。
• IEC 62443-4-2 (CR 6.3 Time Synchronization):
  ログの時刻がずれていては、インシデントの前後関係が証明できません。NTP等による正確な時刻同期が必須です。

2. 「何が起きたか」を知るための解析支援 (Respond)

報告には「検知時刻・使用された防御戦術・防御技術・攻撃手法と経緯（TTPs）・その影響」の記述が求められます。

• IEC62443-4-2（CR1～CR5 Protect）:
  インシデント検知の情報は、時間軸で配列させて分析するためタイムスタンプの同時性を確保する必要があります。
• IEC 62443-4-2 (CR 6.2 Audit Log Characteristics):
  単なるエラーコードではなく、「タイムスタンプ、ユーザーID、送信元IP、変更されたパラメータ」など、解析に耐えうる詳細情報をログに含めます。
• IEC 62443-4-1 (Defect Management):
  製品に脆弱性が見つかった場合、それが悪用されたものなのかどうかを判断するための、メーカー側の調査プロセスが必要です。

3. 「誰が報告するか」を決める組織体制 (Respond)

製品機能だけでは不十分です。

• IEC 62443-2-1 (SPE 7 - Event and incident management):
  インシデント発生時の連絡フローや役割分担を規定します。「顧客から問い合わせがあった際、メーカーとして誰が一次受けし、誰が技術解析を行うか、誰が顧客に結果を報告、誰が顧客が公的機関への報告をする事を確認するか、誰が記録するか」が決まっていなければ、サプライヤーとしての責任を果たすことができません。それに72時間という短時間での対応は不可能です。

4. 欧州CRAも射程に「説明責任（Rationale）」の共通化

ここまで米国（CIRCIA/NIST）の話をしてきましたが、このアプローチはそのまま欧州（CRA）攻略にもつながります。

欧州CRAが求めるのは「セキュリティ」と、その適合性を証明する「技術文書」です。CRA対応の整合規格（IEC 62443ベースのEN規格）においては、「なぜそのセキュリティ機能を実装したのか」という正当性（Rationale）の記述が重視されます。

先ほどのマッピング表を思い出してください。「NISTの『Detect』要件を満たすために、IEC 62443のCR 6.1（ログ機能）を実装しました」というロジックは、そのまま欧州当局に対する「リスクアセスメントの結果に基づき、適切なリスク低減策（ログ機能）を講じました」という技術的根拠になります。

• 米国向け:
  NIST/CIRCIA対応のための「機能実装（How）」としてIEC 62443を使う。
• 欧州向け:
  CRA適合証明のための「技術文書（Rationale）」としてIEC 62443を使う。

入り口は異なりますが、中心にある「IEC 62443」というマスターキーは共通です。IEC 62443での認証証明書はCRAでもCIRCIAでも技術文書として扱われます。これを別々のプロジェクトとして管理するのではなく、統合的に進めることこそが、グローバルメーカーの勝利の方程式です。

5. 実践戦略IEC 62443による「3層防御」の実装

最後に、開発に関わる皆さまが明日から着手すべきアクションを3つの層で整理します。

1. 製品機能（IEC 62443-4-2）：実装と検証の技術

CIRCIA報告に耐えうる「セキュリティ防御戦略に基づいたセキュリティ防御機能」を装備して、「ログ機能（CR 6.x）」と「システム整合性監視（CR 7.x）」を最優先で実装してください。これがなければ、顧客を守ることも、CRAの市場投入要件を満たすこともできません。「セキュリティ防御戦略に基づいたセキュリティ防御機能」を実施するということは、システムのゾーニングと脅威リスクモデル設計をしてリスクアセスメントを行うことが基本です。そのリスクアセスメントでの対策基準は、IEC 62443でのセキュリティレベルSL-Tの特定です。システムのゾーニングは顧客が設定するので、製品供給メーカーは、提供する製品がセキュリティレベルのどのレベルまで適応できるかを明示して情報提供する必要があります。

2. 開発プロセス（IEC 62443-4-1）

開発プロセスは、Vモデルが基本です。セキュアコーディングは徹底して実施し管理してください。開発環境はISO/IEC27001認証レベルが求められます。脆弱性が見つかった際の対応フロー（Defect Management）と、SBOMを用いた構成管理を確立してください。これはCRAの「脆弱性対応義務」にも直結します。

3. 組織・運用（IEC 62443-2-1）

工場を運営する側にとって、許容リスクの範囲とセキュリティレベルを予め評価しておく必要があります。その上で、システムや製品のリスクアセスメント実施時のセキュリティレベルと残留リスクを確認して、工場のシステムのセキュリティレベルに適合しているかどうかを判断することになります。メーカー側は、PSIRT（製品セキュリティインシデント対応チーム）を組織し、インシデント発生時の顧客支援フロー（SPE 7）を整備してください。72時間報告を支援するサービスは、今後大きな付加価値となります。

まとめと次回予告

今回は、NIST CSFという「米国の共通言語」とIEC 62443をマッピングすることで、CIRCIA対応とCRA対応を統合する戦略について解説しました。

1. NIST × IEC:
   NISTの「Detect/Respond」要求は、IEC 62443の「ログ/運用」機能で具体化できる。
2. CIRCIAの核心:
   72時間報告をクリアするには、IEC 62443-4-2（ログ）と2-1（インシデント管理）の両輪が必要である。
3. グローバル統合:
   このアプローチで作成した機能とドキュメントは、そのまま欧州CRAの適合証明になる。

「規格に対応する」ことはゴールではありません。それはあくまで、インシデントという有事に備えるための「準備」です。
しかし、実際にサイバー攻撃を受け、「残り72時間」のカウントダウンが始まったとき、現場は極度の混乱に陥ります。その時、PSIRTはどう動くべきか？ どのログを抽出すればいいのか？ CISAのフォームには何を書けばいいのか？

次回、第4回は「72時間との戦い：CIRCIAインシデント報告の実践プロセス」です。IEC 62443で実装したログ機能を使い、具体的にどのように情報を集め、検知からトリアージ、証跡保全、そして報告パッケージ作成までを行うのか。その「実戦」のシミュレーションを、具体的なテンプレートやログ項目の例と共に解説します。現場マネージャー必見の内容です。

ICS研究所からのご提案

「自社製品の機能をNIST CSFやIEC 62443とどうマッピングすればいいかわからない」「CIRCIA対応のためのログ設計レビューを受けたい」

そのような課題をお持ちの方は、ICS研究所にご相談ください。IEC 62443認証取得支援から、各国の規制動向に精通したコンサルタントによるロードマップ策定まで、貴社のグローバル展開を強力にバックアップします。また、eラーニングサービス「eICS」では、NIST CSFとIEC 62443の関係性をより深く学べるコンテンツも提供しています。まずは「知る」ことから始めてみませんか。