← すべての記事

約14分で読めます

公開せずに検証可能なセキュリティインシデントのタイムラインを構築する

セキュリティチームが証拠を収集しながらインシデントの証拠にタイムスタンプを付与して封印する方法。機密の詳細を公開することなく、何がいつ存在したのかを証明する、耐久性があり独立して検証可能なタイムラインを構築します。

セキュリティチームは、準備が整う前にインシデントを公開することなく、証明可能なインシデントのタイムラインを構築できます。証拠を収集しながら、重要なアーティファクトを 1 つずつハッシュ化し、そのダイジェストを Label 309 に基づいて Cardano 上に公開します。後から、ご自分が選んだ相手であれば誰でも、それらの正確なバイト列が公開ブロック時刻までに存在していたことを確認できます。しかも、ご自分のサーバーもドメインも、言葉さえも信頼する必要はありません。機密性の高い素材は封印でき、平文は暗号化されたままコミットメントだけが公開されます。

実際の運用では、インシデントの進行に合わせて、レポート、ログ、フォレンジックのエクスポート、スクリーンショット、顧客向け通知、規制当局向けドラフト、証拠マニフェストをハッシュ化します。各公開は、公開された時刻に対するコミットメントを記録します。平文は指定した受信者に向けて封印できるため、チェーンは「何を」を開示せずに「いつ」を証明します。

これは証拠レイヤーであり、インシデント対応、法律顧問、開示判断、規制当局への報告を置き換えるものではありません。これらの判断の背後にあるタイムラインに、外部の改ざん検出可能なアンカーを与えるものです。

インシデント中にタイムラインが証拠になるのはなぜか

インシデントの最中は、時刻そのものが証拠になります。

その後、チームは次のような問いに答えなければならないことがよくあります。

  • 不審な活動が最初に観測されたのはいつか
  • インシデントがエスカレーションされたのはいつか
  • 法律顧問に通知されたのはいつか
  • 封じ込めが開始されたのはいつか
  • システムが再構築される前にどのログが存在したか
  • 各段階でどの顧客レコードが影響を受けたと考えられていたか
  • どのバージョンのレポートが取締役会に提出されたか
  • どの規制当局向け通知が作成または提出されたか
  • 最初の評価と最終レポートの間で何が変わったか

問題は、インシデントの証拠が目まぐるしく移り変わることです。ログはローテーションされます。チケットは編集されます。レポートは改訂されます。スクリーンショットはスライドに貼り付けられます。エクスポートは再実行されます。初日には明白に見えた一連の出来事も、6 か月後には証明が難しくなることがあります。

タイムスタンプ付きのコミットメントは、重要なアーティファクトそれぞれに、誰も（ご自分を含めて）後から日付を遡らせられない外部アンカーを与えます。

セキュリティチームは何にタイムスタンプを付与すべきか

タイムラインが将来疑問視されたときに重要になるアーティファクトに、タイムスタンプを付与してください。

セキュリティインシデントの場合、これには次のものがよく含まれます。

  • 初期検知メモ
  • アラートのエクスポート
  • SIEM（security information and event management）ツールからの検索結果
  • EDR（endpoint detection and response）ツールからのエクスポート
  • ファイアウォールおよびアクセスのログ
  • アイデンティティプロバイダーのログ
  • クラウド監査ログ
  • マルウェアサンプルまたはサンプルハッシュ
  • フォレンジック用のディスクまたはメモリイメージのマニフェスト
  • 影響を受けたアカウントの一覧
  • 影響を受けた顧客の推計
  • 封じ込めおよび根絶のメモ
  • インシデントチケット
  • 内部ステータスレポート
  • 取締役会向けの更新報告
  • 規制当局向けドラフト
  • 顧客通知のドラフト
  • 最終インシデントレポート

シークレットを平文で公開しないでください。ハッシュ、Merkle ルート、または封印された暗号文は、公開テキストよりもほぼ常に安全であり、しかも同じだけ証明可能です。

Label 309 はインシデント対応にどう組み込まれるのか

すでに運用しているツールの傍らに置く証明レイヤーとして使ってください。

インシデント対応チームは、SIEM、ケース管理ツール、チケットシステム、フォレンジックプラットフォーム、ドキュメントリポジトリを置き換える必要はありません。重要なアーティファクトをエクスポートまたはスナップショットし、ハッシュを計算して、対応の定められた時点でレコードを公開します。

典型的なフローは次のとおりです。

  1. 検知チームが最初のアラートバンドルをエクスポートします。
  2. インシデントリードがファイルのマニフェストを作成します。
  3. マニフェストをハッシュ化します。
  4. Label 309 レコードがそのハッシュ、またはバンドル全体の Merkle ルートを記録します。
  5. 機密ファイルが法律顧問とセキュリティ責任者に向けて封印されます。
  6. トランザクション参照がインシデントのケースに添付されます。

後から、そのトランザクション参照を持つ人であれば誰でも、ある特定のファイルやマニフェストが、公開タイムスタンプの時点でコミットされたバイト列と一致することを確認できます。検証ツール、オープンソースのコマンドラインツール、あるいは標準を実装した任意のサードパーティ製ツールを使えば、それが可能です。公開と検証のコードは github.com/cardanowall でオープンソースとして公開されています。

バイト列を公開する代わりにインシデントレコードを封印するのはなぜか

インシデントの詳細は、公開するのが危険な場合が少なくありません。

そこには、未修正の脆弱性、認証情報、IP アドレス、顧客データ、従業員データ、脅威アクターの詳細、法執行機関にとって機微な事実、商業的に機微な是正計画などが含まれる場合があります。

封印付きレコードを使えば、ファイルを暗号化したまま、コミットメントだけを公開できます。オンチェーンのレコードは平文のハッシュ（タイミングの証明）に加えて、選ばれた受信者だけが開けるラップされた鍵を保持します。暗号文はオンチェーンではなくコンテンツアドレス指定ストレージの URI に置かれ、受信者の公開鍵もチェーン上には一切現れません。観測者が知り得るのは、封印付きレコードが存在すること、そのブロック時刻、そして何人の受信者に対して封印されたかだけです。受信者が誰であるか、何が封印されたかは決して分かりません。

こうして、証明レコード自体を通じてインシデントを開示することなく、元の証拠を保全できます。内容を露出させずに特定の相手にファイルを封印する方法の詳細は、公開ファイルなしで機密を開示するをご覧ください。

これは規制当局のタイムラインにどう役立つのか

多くのインシデント規制はタイミングを軸としており、何をいつ把握したかについての改ざん検出可能な記録は、そうした判断を支える場合があります。

  • 米国では、SEC 規則により、国内の登録企業は重大なサイバーセキュリティインシデントについて、インシデントが重大であると判断してから 4 営業日以内に Item 1.05 に基づく Form 8-K を提出することが義務づけられています。期限は、発見からではなく、重大性の判断から起算されます。SEC はまた、重大性の判断を不合理に遅延させることなく行わなければならないと強調しています。
  • 欧州連合では、NIS2 指令が重大なインシデントについて 3 段階の期限を設けています。インシデントを認識してから 24 時間以内の早期警告、72 時間以内のインシデント通知、そして 1 か月以内の最終報告 です。
  • EU の金融事業体については、デジタル・オペレーショナル・レジリエンス法（DORA）が ICT インシデント管理と重大インシデント報告の義務を調和させて導入し、2025 年 1 月 17 日 から適用が始まりました。

具体的な義務は、企業、業種、法域、インシデントによって異なり、時とともに変化します。これは一般的な背景情報であって、法的助言ではありません。証明は、報告が必要かどうかを判断するものではなく、期限を守ったことを証明するものでもありません。証明にできるのは、それらの判断の背後にあるアーティファクトと評価について、改ざん検出可能な記録を保全することです。それによって、依拠したタイムラインを後から示せるようになります。証明は主張を支え得る証拠として扱ってください。法律顧問を置き換えるものではありません。

実務的な証明ワークフローはどのようなものか

必要になるよりも前に、少数の証明ポイントを定義しておいてください。

企業は、たとえば次のようなインシデントの証明チェックポイントを定義できます。

  • T0: 最初に検知されたシグナルまたはアラートバンドル
  • T1: インシデント宣言
  • T2: 初期スコープ評価
  • T3: 封じ込めアクション開始
  • T4: 重大性または報告義務の評価ドラフト
  • T5: 取締役会または経営層への更新報告
  • T6: 規制当局または顧客への通知ドラフト
  • T7: 最終インシデントレポート
  • T8: インシデント後のレビューと是正計画

各チェックポイントはマニフェストを生成します。マニフェストは直接ハッシュ化することも、より広いインシデントのルートに Merkle リーフとして含めることもできます。

その結果として得られるのは、後から説明しやすいタイムラインです。これがチェックポイント、これがアーティファクト、これが公開タイムスタンプ、そしてこれがファイルの一致を検証する方法です。

ファイルごとに 1 レコードではなく Merkle ルートをコミットすべきなのはいつか

証拠セットが大きいときは Merkle ルートを使ってください。

深刻なインシデントでは、数千から数百万行に及ぶログ、アラート、パケット、ファイルハッシュ、エンドポイントイベント、チケット更新が関わることがあります。アーティファクトごとに 1 レコードを公開するのは高コストで、管理も困難です。

代わりに、決定論的なマニフェストを構築し、各エントリをリーフへとハッシュ化し、Merkle ツリーを構築して、チェックポイントごとに単一の 32 バイトのルートを公開します。後から、特定のログエクスポート、イベント、またはファイルハッシュがそのチェックポイントに含まれていたことを、証拠セットの残りを明かすことなく、短い包含証明で証明できます。

これは次のような場面に自然に適合します。

  • 日次のインシデント証拠バッチ
  • 大量のクラウドログ
  • 顧客影響リスト
  • エンドポイントのアーティファクトインベントリ
  • フォレンジック収集マニフェスト
  • 脆弱性スキャンのスナップショット
  • パッチおよび是正の証拠

ただし 1 つ注意点があります。ルートが役立つのは、マニフェスト、順序づけられたリーフリスト、そして包含証明を保全している場合だけです。チェーンはルートを保存します。リーフがそのルートの下にあることを証明するのに必要なものは、すべてご自分で保存します。同じパターン（1 つのレコードが膨大なセットを代表する）については、数千のファイルを 1 レコードにで扱っています。

事実が変わったとき、訂正はどう機能するのか

インシデントレポートは事実がより正確になるにつれて変わるものであり、標準はその変化を可視化できるようにします。

初期の推計はしばしば誤っています。チームは最初に 200 件のアカウントが影響を受けたと考え、その後 2,000 件を発見し、さらに 150 件の誤検知を除外する、といったことがあります。こうした変化は隠されるべきではなく、説明可能であるべきです。

レコードは置換ポインタ（supersedes）を保持できます。これは、置き換える対象である過去のレコードの 32 バイトのトランザクションハッシュです。過去のレコードはチェーン上に残り、独立して検証可能なままです。チェーンは追記専用なので、置換によって何かが削除されたり無効化されたりすることはありません。ポインタは実質的に「これがより新しいバージョンです」と述べるだけです。理由フィールドは持ちません。人間にとっての意味づけは、ポインタではなく新しいコンテンツの中に置かれます。

この区別が重要です。それによって、誠実な改訂と密かな書き換えとの違いが保たれます。履歴は可視で、順序立っており、証明可能です。

封印付きインシデントレコードは誰が受け取るべきか

受信者リストは小さく、意図的に保ってください。受信者が 1 人増えるごとに、平文を復号できる関係者が（そして復号後に漏洩させ得る関係者が）1 人増えます。

よくある受信者には次のものがあります。

  • 社外法律顧問
  • 社内法務
  • インシデントコマンダー
  • CISO またはセキュリティ責任者
  • フォレンジックパートナー
  • 適切な場合には規制当局の窓口
  • サイバー保険の顧問またはパネルベンダー
  • 取締役会のセキュリティ委員会
  • 企業が管理する信頼できるアーカイブ用アイデンティティ

各受信者は、帯域外で実際に検証した受信アドレスを提供すべきです。つまり、その鍵が本当にその人物のものであって、なりすました誰かのものではないことを確認します。誤った鍵に封印すれば、誤った読み手に封印することになり、その間違いをチェーンが代わりに捕まえてくれることはありません。その手順はファイルを封印する前に受信者を検証するで順を追って説明しています。長期にわたって保持する機密性の高い証拠には、ワークフローが対応している場合、オプションのハイブリッドなポスト量子受信アドレスを優先してください。これは「今のうちに収集し、後で復号する（harvest now, decrypt later）」攻撃に耐えるよう設計されています。これは、敵対者が今日のうちに暗号文を保存しておき、将来の量子コンピューターがそれを破るのを待つ攻撃です。

公開メタデータに決して入れてはいけないものは何か

インシデントのシークレットは、公開記録から完全に締め出してください。

次のものは公開しないでください。

  • 平文のエクスプロイトの詳細
  • 認証情報
  • 秘密鍵
  • 顧客の個人データ
  • 機微な内部ホスト名または IP アドレス
  • 秘匿すべき攻撃者インフラの詳細
  • 秘匿特権のある法的分析
  • 裏づけのない非難
  • 公開すべきでない規制当局限りの情報

公開チェーンが保持すべきはコミットメント（ハッシュ、ルート、封印エンベロープ）であって、インシデントの物語ではありません。物語はご自分のシステム内に、そして必要な場合には封印された暗号文の中に留めてください。

証明は会社がインシデントを適切に対応したことを示すのか

いいえ。あえて、それよりも狭い範囲のものです。

証明は、特定のファイルやマニフェストが公開された時刻までに存在していたことを示せます。オプションの著作者署名がある場合には、特定の署名鍵がレコードの裏づけとなったことを示せます。後のアーティファクトが先のコミットメントと一致することも示せます。

証明は、調査が完全であったこと、会社が正しい判断を下したこと、法的期限が守られたこと、統制が有効であったこと、顧客が正しく通知されたことを証明するものではありません。それはタイミングと完全性についての証拠であって、真実、判断、コンプライアンスについての証拠ではありません。この境界の一般的な説明については、証明が証明しないものをご覧ください。

何がうまくいかなくなり得るか

最もよくある失敗は、暗号上のものではなく運用上のものです。

誤ったファイルにタイムスタンプを付与してしまうことがあります。元の証拠を失うことがあります。ルートが依存する Merkle リーフを保全し損ねることがあります。機微な事実を公開フィールドに入れてしまうことがあります。誰も検証していない受信アドレスに封印してしまうことがあります。あまりに多くの人に復号を許してしまうことがあります。証明レイヤーを、その背後にある証拠レイヤーとしてではなく、報告システムそのものとして扱い始めてしまうこともあります。

最善の防御は手続き的なものです。インシデントの前に証明チェックポイントを定義し、退屈な部分を自動化し、法的リスクがあり得る場面ではどこでも法律顧問を関与させ続けてください。

要点

セキュリティインシデントには、プレッシャーに耐えるタイムラインが必要です。

Label 309 はインシデントのアーティファクト、レポート、マニフェストを公開された時刻に記録します。封印付きレコードは機密性の高い証拠を、選ばれた受信者に向けて暗号化されたまま保ちます。Merkle ルートは大きな証拠セットを単一のレコードでコミットします。置換ポインタは訂正を、密かにではなく可視に保ちます。しかも、いずれか単一のサーバーやベンダーを信頼することなく実現します。

何がいつ存在したかを証明するために使ってください。インシデント対応や法的報告を置き換えるために使ってはいけません。そして、タイミングと完全性を超える何かを証明することを期待してはいけません。

さらに読む

securityincident-responseproof-of-existence