「72時間との戦い」: CIRCIAインシデント報告の実務プロセス

1. 72時間報告パッケージに含めるべき必須項目

CISAへの報告（CIRCIA第2242条）において求められる情報は、単なる被害報告にとどまりません。事後解析や他組織への注意喚起に活用できる具体的な情報が要求されます。

表1: CIRCIAにおける主要な報告項目

特に装置メーカーが顧客から求められるのは、「攻撃手法（どの脆弱性を突かれたか）」と「影響範囲の特定」です。これらを短時間で回答するためには、平時からの準備が重要になります。

2. インシデント検知を支える技術基盤EDR、SIEM、SOC

72時間という期限は、インシデントを「検知」した時点から始まります。しかし、実際には攻撃を受けてから数週間、数ヶ月間も気づかないケースが少なくありません。検知の遅れは報告期限の超過に直結します。

EDR（Endpoint Detection and Response）の役割

装置を構成する制御PCやサーバーにおいて、個々の端末（エンドポイント）の挙動を詳細に監視するのがEDRです。従来のウイルス対策ソフト（EPP）が「既知のマルウェアを止める」ことを目的とするのに対し、EDRは「不審な挙動を検知して記録する」ことに特化しています。これにより、未知の脆弱性を突いた攻撃であっても、その予兆を早期に掴むことが可能になります。

SIEM（Security Information and Event Management）による相関分析

大規模な工場やプラントでは、多数のデバイスから膨大なログが生成されます。SIEMは、これら複数のデバイスやネットワーク機器のログを統合し、相関分析を行う仕組みです。単一のログでは見逃してしまうような断片的な攻撃の兆候を、全体像として捉えるために不可欠なツールとなります。

SOC（Security Operations Center）による判断

EDRやSIEMが発するアラートに対し、それが「報告すべき重大なインシデント（Covered Cyber Incident）」か、あるいは「誤検知」かを判断するのがSOCです。自社で24時間365日の監視体制を構築するのが困難な場合は、外部のマネージドSOCサービスを利用することが現実的な選択肢となります。

3. 設計段階で考慮すべき「解析に耐えうる製品」の要件

インシデント報告の質は、製品の設計段階で決まっています。国際規格IEC 62443-4-2（製品へのセキュリティ要件）をベースに、報告義務を果たすために不可欠な技術要件を具体化します。

監査ログの記録（CR 2.8）

誰が、いつ、どの特権命令を実行したかを記録します。特に「設定変更」や「ファームウェアの書き換え」のログは、攻撃手法（TTPs）を特定する際のエビデンスとなります。

この要件（CR 2.8）では、以下の内容が規定されています:

• 記録すべきイベントの内容:
  タイムスタンプ、ソース、カテゴリ、タイプ、ID、結果などを含める必要があります。
• 対象カテゴリ:
  アクセス制御、要求エラー、制御システムイベント、バックアップ・復元イベント、設定変更、および監査ログ自体のイベントなどが含まれます。

ログの保護（CR 2.11、CR 2.12、CR 3.4）

攻撃者は、自らの足跡を消すためにログファイルを削除・改ざんしようとします。そのため、ログを「書き換え不能（WORM）」な領域に保存する、あるいはネットワーク経由で外部のセキュアなサーバーへリアルタイムに転送する機能が、証跡保全の鍵となります。

IEC 62443-4-2におけるログ保護の要件を以下の3つの側面で要約しています。

• 時刻の正確性（CR 2.11）:
  時刻同期とタイムスタンプの保護により、記録の正確性を確保する。
• 否認防止（CR 2.12）:
  非権限者によるログの閲覧・改ざん・削除を防止する。
• 完全性の維持（CR 3.4 RE 1）:
  ソフトウエア、構成情報、その他のデータの完全性をチェックすることで、ログを含むデータの改ざんを防ぐことにもなります。

時刻同期（CR 2.11）

複数の装置やシステムにまたがる攻撃の全容を解明するには、全てのログのタイムスタンプが正確に同期されている必要があります。装置単体で時刻を保持するのではなく、NTP（Network Time Protocol）等による時刻同期機能を実装しておくことは、72時間以内のタイムライン構築において必須の要件です。

IEC 62443-4-2において、「時刻同期（Time synchronization）」を具体的に要求しているのは CR 2.11 の拡張要求（Requirement Extension）である CR 2.11 RE 1 です。

詳細は以下の通りです:

• CR 2.11（Timestamps）:
  すべての監査記録にタイムスタンプを含めることを求める基本要件です。
• CR 2.11 RE 1（Time synchronization）:
  コンポーネントが、信頼できる時間源（NTPサーバーなど）と時刻を同期する機能を持つことを明示的に要求しています。

この要件は、システム全体でログの前後関係を正確に把握し、インシデント発生時の調査を可能にするために不可欠なものとして定義されています。

4. グローバル規制の統合管理米国CIRCIAと欧州CRAの比較

工作機械や船舶装置をグローバルに展開するメーカーにとって、米国と欧州で別々の報告フローを構築することは極めて非効率です。欧州のサイバーレジリエンス法（CRA）においても、脆弱性の悪用やインシデントについて「24時間以内の早期警告」と「72時間以内の詳細報告」が求められます。

両規制の主な共通点と相違点を整理します。

• 共通点:
  24時間／72時間という厳しいタイムラインが設定されていること、および「悪用された脆弱性」の特定が求められること。
• 相違点:
  
  • CIRCIA:
    「重要インフラの運用」への影響を重視し、CISAへ報告する。
  • CRA:
    「製品の安全性」に焦点を当て、各国の市場監視当局やENISA（欧州サイバーセキュリティ機関）へ報告する。

実務上の解決策は、第3回で解説したように、IEC 62443に基づいた「共通エビデンス管理」を構築することです。単一の解析基盤から、米国用（CIRCIA形式）と欧州用（CRA形式）の報告書を効率的に出力できる体制を整えることが、開発コストの抑制につながります。

CIRCIA（米国）とCRA（欧州）には、報告先や目的以外にも、実務上の戦略を大きく左右する決定的な違いがいくつか存在します。
特にグローバルメーカーが留意すべき「語られていない重要相違点」は以下の3点です。

4.1. 報告対象となる「事象」の定義範囲

• CRA（製品軸）:
  主に「悪用された脆弱性（Exploited vulnerability）」に焦点を当てています。つまり、実害が出る前であっても「穴」が悪用された時点で報告義務が生じる「製品セキュリティ」の側面が強い規制です。
• CIRCIA（事業軸）:
  脆弱性そのものより、その結果引き起こされた「重大なサイバーインシデント（重大な運用の停止、機密情報の窃取など）」が対象です。製品の欠陥というより「事業継続への影響」がトリガーとなります。

4.2. 罰則規定の強制力と執行力

• CRA:
  非常に強力な罰則が特徴です。違反時には「最大1,500万ユーロまたは全世界年間売上高の2.5%」という、GDPRに近い高額な制裁金が科される可能性があります。
• CIRCIA:
  現時点ではCISAに直接的な「制裁金」を科す権限はありませんが、報告を怠った企業には召喚状（Subpoena）の発行や、連邦政府調達からの排除といった、実質的なビジネス制限がリスクとなります。

4.3. 「デジタル製品」の範囲と自己宣言

• CRA:
  欧州市場に投入される「すべてのデジタル要素を備えた製品」が対象であり、おもちゃから産業用機器まで網羅されます。また、製品の重要度（Criticality）に応じて、自己宣言で済むのか、第三者認証が必要かが厳格に分かれています。
• CIRCIA:
  「重要インフラセクター」に従事する企業が主な対象であり、製品そのものの認可制度というよりは、「組織としての報告体制」を問うものです。

4.4. 報告データの「再利用」の制限（秘密保持）

• CIRCIA:
  前述の第2245条により、報告内容を他の規制当局が制裁に転用することを禁じる強力な法的保護があります。
• CRA:
  報告された脆弱性情報は、ENISAを通じて各国の市場監視当局へ共有されますが、これに基づき「製品の適合性違反」としてリコールや販売停止を命じられるリスクがCIRCIAよりも直接的です。

5. 報告企業を保護する仕組み第2245条（Section 2245）の重要性

CIRCIAは企業に重い報告義務を課す一方で、報告を躊躇させないための強力な保護規定を設けています。それが第2245条（SEC. 2245）です。

この条項には、報告内容に関する以下の保護策が明記されています。

1. 民事訴訟からの免責（Liability Protection）:
   CIRCIAの規定に従って適切に報告を行った場合、その報告行為自体を理由として民事訴訟の対象となることはありません。
2. 情報公開法（FOIA）の適用除外:
   提供された情報は営業機密として扱われ、公的な開示請求の対象からも外されます。
3. 規制目的での利用禁止:
   報告された情報を直接の根拠として、政府機関がその企業に対して制裁を加えたり、新たな規制アクションを起こしたりすることは禁じられています。

これらの保護を確実に受けるためには、規定された時間内に、誠実に情報を共有することが大前提となります。

• ※ CIRCIAの報告義務を定める最終規則（Final Rule）の施行予定が2026年5月とされているためです。現状では、この条文第2245条（Section 2245）は「今後運用が開始される際の制度的な約束事」という段階にあります。

6. 実務的なインシデント対応フロー検知から更新報告まで

インシデント発生後の初動から報告までの標準的なタイムラインは、以下のように設計するのがよいでしょう。

0時間〜24時間: 初動・トリアージ

• EDR/SIEMによるアラート検知。SOCによる緊急度判定。
• 顧客（重要インフラ事業者）への連絡。ランサムウェアの場合は24時間以内の支払い報告準備。

24時間〜72時間: 解析・第一報

• PSIRT（製品セキュリティインシデント対応チーム）による一次解析。
• 影響範囲の特定と、判明している事実に基づくCISAへの第一報。

その後: 更新報告（Supplemental Report）

• 解析の進展により新たな事実（真の原因、侵入経路の詳細など）が判明した場合、または事態が収束した際に「更新報告」を行います。CIRCIAでは、重要な情報の変化があった場合、速やかに報告を更新することが求められています。

CIRCIA（重要インフラのためのサイバーインシデント報告法）において、ランサムウェアの「身代金支払い」が発生した場合、報告期限は通常の72時間から24時間以内へと大幅に短縮されます。

ランサムウェア対応フロー: 検知から支払い報告・更新報告まで

0時間〜24時間: 超短期的初動・支払い報告

• 事象の特定と意思決定:
  システム暗号化やデータ窃取の検知後、即座にトリアージを実施。事業継続への影響から身代金支払いを決定・実行した場合、ここから「24時間」のカウントダウンが始まります。
• CISAへの支払い報告（Ransom Payment Report）:
  支払い完了後、24時間以内にCISAへ報告を行います。この報告には、支払った金額、通貨、受取人の情報（暗号資産アドレス等）、および支払いの理由などを含める必要があります。

24時間〜72時間: インシデント全容報告

• 被害状況の精査:
  支払いとは別に、サイバー攻撃そのものが「重大なインシデント（Covered Cyber Incident）」に該当する場合、発生から72時間以内にその詳細を報告します。
• 共同報告の活用:
  支払いのタイミングがインシデント検知と近い場合は、これらをまとめた「共同報告（Joint Report）」として提出することも可能です。

その後: 更新報告（Supplemental Report）

• 情報の追記:
  解析の進展により、新たな侵害の痕跡（IoC）や、当初不明だった侵入経路、データ流出の詳細が判明した場合、速やかに「更新報告」を行います。
• 事態の収束報告:
  インシデントが完全に鎮静化し、復旧が完了した段階で最終的な更新を行い、報告プロセスを終了します。

7. ICS研究所がコンサルする場合

ここに上げている項目を、さらにIEC 62443-4-1（プロセス）とIEC 62443-4-2（技術要件）で定義されるPCL（Product Compliance List: 製品適合性リスト）として整理していきます。

CIRCIAの「72時間報告」を完遂するには、製品設計段階のPCL（適合性リスト）が鍵となります。
インシデント発生時の「72時間報告」を的確に行うためには、製品設計段階でのPCL（適合性リスト）の策定が不可欠です。IEC 62443-4-2の技術要件に基づき、正確な監査ログを記録することで、侵害の特定と第一報が可能になります。さらに、4-1の脆弱性管理プロセスは、未知の攻撃への迅速な対応と「更新報告」を支援します。PCLの整理は、報告の正確性と法的保護の根拠となり、企業の信頼を維持するための重要な取り組みです。

まとめと次回の展望

CIRCIAが求める72時間報告は、単なる法制度の遵守にとどまらず、製造業における「品質保証」の概念をサイバーセキュリティ領域まで拡張することを意味しています。

装置が故障した際に応急処置と原因究明を行うのと同様に、サイバー攻撃を受けた際にも、技術的な事実に基づいた迅速な報告が求められる時代になりました。

ここで重要となるのは、「インシデントが発生してからログの取り方を考えるのではなく、設計段階でログを出す仕組みを入れておく」という、セキュリティ・バイ・デザインの考え方です。

次回の第5回では、本稿で触れたインシデント報告の「前提条件」となる、製品への具体的な実装技術について解説します。SBOM（ソフトウェア部品表）を用いた脆弱性管理や、セキュアアップデートの実装、そして海事（UR）や半導体（SEMI）といった業界固有の要件を、どのように製品設計に落とし込むべきかを詳述します。

ICS研究所からのご案内

本連載で解説しているCIRCIAやCRAへの対応は、組織的な体制整備と高度な技術実装の両面が求められます。ICS研究所では、IEC 62443に基づいた製品セキュリティ体制（PSIRT）の構築支援や、人材教育のためのeラーニングプログラム「eICS」を提供しています。グローバル市場でのコンプライアンス対応にお悩みの際は、ぜひご相談ください。