JetBrains TeamCity がビルドサーバーをソフトウェアサプライチェーンのアカウンタビリティ・サーフェスにした

概要

• JetBrains は 2023 年 9 月に CVE-2023-42793 を公開しました。CISA と Microsoft はその後、脅威アクターが TeamCity サーバーを下流の侵害のエントリポイントとして使用するなどの悪用活動を報告しました。
• 中心的なアカウンタビリティの問いは次のとおりです。TeamCity の露出、パッチ速度、ビルドサーバーのアイデンティティ、シークレットストレージ、アーティファクト署名、下流の顧客リスク、および悪用後の再構築について、誰が実質的な管理を行っていたのか？
• このケースの実質的な原因は、侵害、停止、脆弱性、ベンダー障害といった単一のラベルではありません。記録の中心は、認証バイパス脆弱性、インターネットに露出した CI/CD サーバー、パッチの採用、ビルド資格情報の保存、ソースコードとアーティファクトの信頼、脅威アクターの悪用、および侵害後のビルド完全性を証明するために必要な証拠です。
• ソフトウェアチーム、ベンダー、エンタープライズ顧客、オープンソース利用者、クラウドアカウント、セキュリティチームは、侵害されたビルドサーバーが後の攻撃の信頼できる配信経路になる可能性に直面しました。
• この記録は、管理義務と証拠のギャップに関する高信頼性のアカウンタビリティ評価を裏付けていますが、すべてのログエントリ、すべての顧客影響、すべての内部決定、すべての下流損失など、非公開の事実を前提とすることはできません。

証拠記録とその使用方法

本稿は、公開記録を単一のマスターアカウントとしてではなく、階層化された証拠として扱います。企業通知は、JetBrains, s. r. o. が発見、変更、または助言した内容を示すために使用されます。政府、規制当局、脆弱性、およびセキュリティ研究資料は、インシデントに関する管理義務を枠付けるために使用されます。二次的な報道は、安定した一次文書では入手できない公開声明、時系列、または影響を受けた当事者の文脈を保存する場合にのみ使用されます。

このインシデントの本質は管理にある

JetBrains TeamCity は、ビルドサーバーをソフトウェアサプライチェーンのアカウンタビリティ・サーフェスにした。なぜなら、この出来事は、見出しよりも実践的な管理に強い光を当てたからだ。公開記録はJetBrains TeamCity CVE-2023-42793 ブログに始まり、JetBrains 修正済みセキュリティ問題ページとNVD CVE-2023-42793 エントリによって補強されている。これらの記録が重要なのは、漠然としたセキュリティストーリーと一連の運用義務との違いを示すからだ。影響を受けたシステムを見つけ、どのデータや信頼材料が到達可能だったかを判断し、行動すべき人に通知し、古いリスク経路が閉鎖されたことを証明するという義務である。

分析上の重要な動きは、トリガーとアカウンタビリティを分離することだ。トリガーは、JetBrains TeamCity CVE-2023-42793 認証バイパスの悪用とサプライチェーンリスク（2023 年）である。アカウンタビリティはより広範で、イベント前の設計選択、異常な活動を検出すべきだった監視、それを封じ込める緊急権限、確認された侵害と可能性のある露出を区別する証拠、そして関係者が独自の判断を下せるようにするコミュニケーションが含まれる。プロバイダーは狭い技術的トリガーについて正確であっても、顧客がリスクの自陣を管理するための十分な証拠を与えずに済ませることができる。

JetBrains, s. r. o. にとって、この公的問題はしたがって管理面にある。CI/CD の露出、認証バイパス、ビルドシークレット、アーティファクトの信頼、パッチの採用、脅威アクターの悪用、そして再構築の証拠である。これらは広報の詳細ではない。それらは害が拡大または縮小するメカニズムである。短い侵入が長期にわたるアイデンティティリスクを生み出すことがある。古い脆弱性が生きた継続性障害になることがある。ベンダーアカウントが顧客アカウントの問題になることがある。プラットフォームのサポートチケットが本番サービスよりも機密性の高い材料を運ぶことがある。本稿ではこのレンズを全体にわたって使用している。

タイムラインは証拠の一部である

タイムラインが重要なのは、顧客が行動するのに十分な情報を知った後でしか行動できないからだ。このケースでは、公の時系列は上述のトリガーから始まり、封じ込め、顧客ガイダンス、フォローアップ報告、そして後の分析へと進む。初期の瞬間は検出とエスカレーションをテストする。中期の瞬間は、一時的な管理策が恒久的な修復になったかどうかをテストする。後期の瞬間は、組織が注意が薄れた後に単にインシデントを終わらせるのではなく、同様の経路を防ぐのに十分な学習をしたかどうかをテストする。

優れたインシデントタイムラインは、いくつかの質問に答えるべきだ。異常な活動はいつ始まったのか？防御側が最初にそれを認識したのはいつか？防御側がその重要性を理解したのはいつか？組織が経路を封じ込めたのはいつか？どの顧客、記録、サービス、資格情報、システムが影響を受ける可能性があるかをいつ把握したか？組織外の人々が自らを守るのに十分な情報を受け取ったのはいつか？公開通知がこれらの質問すべてに答えることはめったにないが、それでも質問は正しいアカウンタビリティの枠組みである。

内部イベントと公表の間のギャップが自動的に不正行為を意味するわけではない。インシデント対応者は事実を確認する時間が必要だ。時期尚早の通知は誤ったアドバイスを広める可能性がある。しかし、そのギャップは説明可能でなければならない。顧客がパスワード、トークン、エンドポイント、サポートファイル、銀行口座、管理者、下流のユーザーを管理している場合、遅延はリスクを顧客に移転する。責任ある基準は、即時の完璧さではない。確認された事実、もっともらしいリスク、推奨される行動、未解決の不確実性を区別する、迅速で段階的なコミュニケーションである。

データまたは信頼オブジェクトは付随的ではなかった

このケースで露出または危険にさらされたオブジェクトは、ビジネスにとって付随的ではなかった。記録の中心は、認証バイパス脆弱性、インターネットに露出した CI/CD サーバー、パッチの採用、ビルド資格情報の保存、ソースコードとアーティファクトの信頼、脅威アクターの悪用、侵害後のビルド完全性を証明するために必要な証拠である。つまり、このインシデントは、組織が管理するために存在する、または顧客が依存するように招いた信頼オブジェクトに触れたのである。そのオブジェクトが資格情報、署名証明書、サポート添付ファイル、顧客メタデータセット、ビルドサーバー、ファイアウォール、ハイパーバイザー、または公共サービス ID 記録である場合、組織はそれを通常のオフィスシステムの詳細として扱うことはできない。

信頼オブジェクトには特別なアカウンタビリティプロファイルがある。それらは他のシステムに判断をさせる。コード署名証明書は、エンドポイントにソフトウェアが正当かどうかを伝える。サポート資格情報は、プラットフォームに人が顧客記録を見てよいかどうかを伝える。ビルドサーバーは、下流のユーザーにアーティファクトが期待されたプロセスから来たことを伝える。ファイアウォールやリモートアクセスゲートウェイは、ネットワークにどのセッションが入ってよいかを伝える。顧客メタデータ記録は、詐欺師に誰を標的にすべきかを伝える。害はしばしば後で、誰かが異なる状況で信頼オブジェクトを再利用するときにやってくる。

これが、スコープ分析がテーブル名やサーバー名だけでなく機能をカバーする必要がある理由である。コピーされたフィールドが管理者を特定する場合、データベーステーブルがコピーされたかどうかを尋ねるだけでは不十分だ。コーポレートレコードが後でそのデータプレーンを攻撃する方法を明らかにする場合、本番データプレーンが侵害されたかどうかを尋ねるだけでは不十分だ。資格情報、証明書、または添付ファイルがイベント後も使用可能なままだった場合、サービスがオンラインのままだったかどうかを尋ねるだけでは不十分だ。

プロバイダーの責任は最も高いレバレッジの管理策に従う

この話のプロバイダーは、公のイベントが始まった環境を管理していたが、その声明だけでは不十分だ。より正確な質問は、プロバイダー側にどのような高いレバレッジの管理策があったかである。多くのインシデントでは、それらの管理策にはアーキテクチャ、特権アクセス、サービスセグメンテーション、証明書や鍵の取り扱い、ログのカバレッジ、顧客データの最小化、安全なデフォルト、緊急失効、リリースエンジニアリング、そして信頼できるガイダンスを公開する権限が含まれる。

プロバイダーは、リスクのある経路を容易にしたか困難にしたかによって判断されるべきだ。特権ツールには強力な認証と厳格なロールが必要だったか？機密性の高いサポート添付ファイルやメタデータが必要以上に保持されていたか？本番システムは企業システムから分離されていたか？露出したサービスは失敗時にクローズするように設計されていたか？ログはアクセスを再構築するのに十分な完全性があったか？組織は信頼材料を迅速に失効できたか？顧客は安全なバージョンをインストールしたか、適切な封じ込め手順を踏んだことを確認できたか？

公開記録はその管理態勢の一部しか示さないかもしれない。通知が発行されたこと、パッチがリリースされたこと、パスワードリセットが必要とされたこと、ベンダーアカウントが無効化されたこと、証明書が交換されたこと、または公共機関がサービスを稼働させ続けたことを示せる。しかし、内部アクセスレビュー、取締役会の議論、フォレンジックの確信度、またはすべての顧客メッセージを示せないことが多い。完全な可視性の欠如は推測で埋めるべきではない。それは証拠の限界として名付けられ、将来のより明確な保証への要求に変換されるべきである。

顧客とオペレーターの責任は消えなかった

顧客とオペレーターにも義務があった。これは責任転嫁ではない。多くのテクノロジーインシデントが組織の境界を越えるという認識である。顧客はエンドポイントの更新、パスワードの再利用、特権アカウント、ファイアウォールの露出、サポートアップロード、管理者の行動、バックアップの分離、アラートのレビュー、ユーザー教育を管理するかもしれない。公共機関は本人確認と市民への通知を管理するかもしれない。マネージドサービスプロバイダーは顧客が決して見ることのないコンソールを管理するかもしれない。

適切な配分は能力に依存する。どのサポート記録がアクセスされたかを特定できるのがプロバイダーだけなら、プロバイダーがその証拠を所有する。下流のシークレットをローテーションするか、自らのログをレビューできるのが顧客だけなら、顧客が信頼できる通知を受けた後、そのアクションを所有する。マネージドプロバイダーが影響を受けたツールを実行している場合、マネージドプロバイダーはアクションと証拠の両方を顧客に負う。アカウンタビリティはブランドの可視性ではなく、実践的な管理に従う。

これが重要なのは、過小反応がしばしば他者の過失の陰に隠れるからだ。顧客はベンダーが問題を引き起こしたと言い、そのため自らの露出をレビューしないかもしれない。ベンダーは顧客がシステムを誤設定したと言い、そのため安全なデフォルトを改善しないかもしれない。マネージドプロバイダーはパッチを当てたと言い、侵害をレビューしたかどうかの説明を避けるかもしれない。公共の利益は、各当事者が何を管理し、その管理で何をしたかを述べたときにのみ果たされる。

セグメンテーションはインシデントと連鎖の境界である

セグメンテーションは、インシデントが限定されたままかどうかを決定する。このケースでは、関連するセグメンテーションは、企業 IT と製品インフラストラクチャの間、サポートツールと本番データの間、メタデータと顧客コンテンツの間、管理プレーンとトラフィックプレーンの間、ビルドサービスと署名鍵の間、またはハイパーバイザーホストとバックアップ資産の間かもしれない。正確な境界は主題によって変わるが、アカウンタビリティの原則は安定している。

セグメンテーションの主張はテスト可能であるべきだ。ある環境が別の環境から分離されていると言うだけでは不十分だ。記録は、どのアイデンティティが境界を越えることができたか、どのネットワーク経路が存在したか、どのログが失敗または不在の移動を確認するか、どのサービスアカウントがレビューされたか、そしてどの緊急管理策が適用されたかを示すべきである。顧客はすべての機密詳細を必要としないが、プロバイダー側のインシデントが自らのリスクを変えたかどうかを知るのに十分な保証を必要とする。

最も強力な公的声明は、二つの極端を避ける。依存するすべてのシステムが侵害されたと示唆して害を誇張しない。また、接続されたリスクを無視しながら狭い技術的境界の陰に隠れない。本番データプレーンが影響を受けなかったと言うことは有用だ。どのメタデータ、資格情報、証明書、添付ファイル、または管理記録が影響を受けたかを言うことも同様に必要である。なぜなら、それらの材料は後でデータプレーンを攻撃するために使用され得るからだ。

通知は受信者に何ができるかを伝えなければならない

通知は儀式ではない。それは実行可能な証拠の移転である。有用な通知は、何が起こったか、どのデータや信頼材料が関与している可能性があるか、組織がすでに何をしたか、受信者が今何をすべきか、何がまだ不明か、そして後の更新がどこに現れるかを受信者に伝える。通知が単にインシデントが発生したとだけ言うなら、形式的なコミュニケーションの必要性を満たすかもしれないが、運用上の必要性には失敗する。

異なる受信者は異なる内容を必要とする。セキュリティ管理者は、インジケーター、影響を受けたアカウント、リセット要件、ログレビューウィンドウ、設定ガイダンスを必要とする。消費者は、平易な言葉でのアイデンティティリスクアドバイス、支払いとパスワードのガイダンス、サポート連絡先を必要とする。公共サービスユーザーは、重要なサービスが継続するか、代替手段が存在するという保証を必要とする。開発者は、ビルド完全性ガイダンスとシークレットローテーション手順を必要とする。経営幹部は、露出、侵害、修復、残留リスクのマトリックスを必要とする。

したがって、本稿はコミュニケーションを儀礼ではなく管理策として扱う。遅れたり曖昧な通知は、最初の侵害が迅速に封じ込められたとしても害を増大させる可能性がある。段階的な通知は、すべての事実が確定する前でも害を減らすことができる。スコープが拡大した場合、修正された通知は責任あるものとなり得る。鍵は、最初の公開バージョンが最終であるふりをするのではなく、不確実性を正直にラベル付けすることである。

悪用の表面は確認された侵入を超えて広がる

確認された侵入は最初のリスク表面に過ぎない。攻撃者、犯罪者、日和見主義者は、インシデント情報をフィッシング、詐欺、資格情報の盗難、脅迫、偽のサポート電話、ソフトウェア更新の誘い、請求書詐欺、雇用標的化、社会的圧力に再利用することができる。ソフトウェアチーム、ベンダー、エンタープライズ顧客、オープンソース利用者、クラウドアカウント、セキュリティチームは、侵害されたビルドサーバーが後の攻撃の信頼できる配信経路になる可能性に直面した。したがって、組織は侵入者が何をしたかだけでなく、露出した情報が他者にその後何をさせるかを測定しなければならない。

これは、露出した資料が管理者、サポート連絡先、支払い関係、特定ブランドの顧客、身分証明書を提出したユーザー、または特定の技術を実行している組織を特定する場合に特に当てはまる。それらの記録は攻撃者の検索コストを削減する。それらはソーシャルエンジニアリングをより安価で信頼性の高いものにする。また、犯罪者がタイミングをパーソナライズすることを可能にする。実際のインシデント後の偽のリセット通知は、通常のフィッシングメッセージよりも信じやすく見える。

イベント後の悪用防止には、なりすましの監視、可能性のある誘惑について顧客に警告すること、サポート検証の強化、古いトークンの失効、露出したシークレットのローテーション、新しいアカウント活動の監視、そしてより多くの情報を漏らさない最前線のサポートスタッフへのスクリプト提供が含まれるべきである。組織はまた、サポートやサービス機能が本当に必要とする以上のデータを収集または保持していなかったかどうかをレビューすべきである。

フォレンジックは信頼の決定をサポートしなければならない

フォレンジックレビューには特定の目的がある。それは信頼の決定をサポートすることだ。顧客はソフトウェアを使い続けられるか？組織はファイアウォールを信頼できるか？ビルドアーティファクトを信頼できるか？サポート記録を信頼できるか？アイデンティティプロバイダー、メタデータストア、ハイパーバイザー、証明書、バックアップ、またはリモートアクセスセッションを信頼できるか？パッチ適用、リセット、または何かを無効化することは答えの一部に過ぎない。

信頼の決定には、何がアクセスされたか、何がアクセスされた可能性があるか、何が変更されたか、どの資格情報やキーが存在していたか、どのログが完全か、ログが改ざんされた可能性があるかどうか、そしてどの独立したシグナルが結論を確認するかについての証拠が必要である。証拠が不完全な場合、組織はその旨を述べ、高価値資産については保守的な決定を下すべきである。侵害された境界システムやビルドサーバーは、元のバグが修正された後でも再構築とシークレットローテーションが必要になるかもしれない。

弱いフォレンジック記録は二次的なアカウンタビリティ問題を生み出す。組織が信頼オブジェクトが安全なままだったと証明できない場合、より広範な修復のコストを負担する必要があるかもしれない。それは高価である。しかし、代替案は不確実性をプロバイダーの証拠を持たない顧客、市民、または下流のユーザーに移転することである。成熟したインシデント管理は、プライベートログを部外者が合理的に行動するのに十分な公的保証に変える。

経済的インセンティブが過小投資を説明する

インシデントにわたって繰り返されるパターンは謎ではない。予防的管理策は、多くの場合、インシデントが発生する前に目に見えるコストを課す。セグメンテーションは利便性を遅くする。最小権限はサポートを苛立たせる。証明書ローテーションは互換性リスクを生む。ビルドサーバーの強化はデリバリーを遅くする。ハイパーバイザーのパッチ適用はメンテナンスウィンドウを必要とする。顧客データの最小化はマーケティングやサポートの詳細を減らすかもしれない。バックアップテストは時間を消費する。これらのコストは即時的であり、回避される害はそれが到来するまで不確実である。

そのインセンティブギャップが、アカウンタビリティが裁判所の記録や確認された損失額を待てない理由である。すべての組織が害が証明されるまで待つなら、最も安価な道は常に管理を延期し、別の当事者が損失を吸収することを期待することである。最高の予防的管理策を持つ当事者がコストを外部として扱う一方で、顧客はアイデンティティリスク、ダウンタイム、詐欺監視、緊急人員配置、契約中断、公共サービスの不便を被るかもしれない。

より良いインセンティブモデルは、管理義務をイベント前に最も低コストでリスクを低減できる当事者に結びつける。ベンダーは安全なデフォルトと完全なログを普通にすべきである。顧客はインベントリ、パッチウィンドウ、リカバリテスト、資格情報の衛生を維持すべきである。マネージドプロバイダーは証拠パッケージを提供すべきである。規制当局や保険会社は、インシデント後に物語だけを求めるのではなく、インシデント前にこれらの管理策の証拠を求めるべきである。

ガバナンス記録はニュースサイクルを生き残るべきである

ガバナンス記録は、ニュースサイクルが薄れた後も有用であり続けるべきである。その記録は、トリガー、影響を受けた資産、影響を受けた人々、封じ込め措置、顧客アドバイス、証拠の質、残留リスク、ビジネス影響、修復責任者、フォローアップテストを記述すべきである。また、イベント後に何が変わったかを示すべきである。アクセスルール、保持期間、ベンダー監督、ログカバレッジ、パッチサービスレベル、シークレットローテーション、バックアップ分離、顧客通知プレイブックなど。

その記録がなければ、組織は一時的にしか学習しない。スタッフは入れ替わる。緊急例外は残る。一時的な緩和策が恒久的になる。同じクラスのインシデントが異なる製品やベンダー関係で再発する。長期のアカウンタビリティ記録があれば、取締役会、規制当局、顧客、または将来のオペレーターが、約束された修復が 6 か月後もまだ存在するかどうかを尋ねることができる。

JetBrains, s. r. o. にとって、永続的な教訓は、起こり得るすべての害が起こったということではない。公のイベントが再発する管理クラスを暴露したということである。次のケースは、異なる製品、地域、攻撃者、データセットを含むかもしれない。テストは同じである。組織は、誰がリスク経路を管理していたか、彼らが何をしたか、そしてなぜ部外者が結果を信頼すべきかを示せるか？

評価を変えるもの

評価は、より強力な証拠またはより弱い証拠によって変わるだろう。より強力な証拠には、独立したフォレンジックサマリー、完全な顧客影響カテゴリ、初回検出から封じ込めまでの明確なタイムライン、関連する信頼材料がローテーションされたか決して露出しなかったことの証明、そして同じ経路がもはや機能しないことを示す後のテストが含まれる。より弱い証拠には、説明なしのスコープ拡大の遅延、不明確なデータカテゴリ、欠落したログ、繰り返される類似インシデント、または顧客の行動が必要な場合に顧客の行動を任意として扱うパターンが含まれる。

また、影響を受けた当事者の証拠によっても変わるだろう。露出がなく、迅速な更新、完全なログ、到達可能な信頼材料がないことを示せる顧客は、古いバージョン、露出した管理面、不完全なログ、再利用された資格情報、機密性の高いサポートファイルを持っていた顧客とは異なって評価されるべきである。安全なデフォルトと狭い保持期間を持つプロバイダーは、広範な内部ツールに機密記録への永続的なアクセスを与えたプロバイダーとは異なって評価されるべきである。

これが、優れたアカウンタビリティ記事がパニックと免罪の両方に抵抗する理由である。公開記録は、すべての損失を証明することなく管理の所見を裏付けることができる。事実を捏造することなく証拠のギャップを特定できる。プロバイダーがインシデントの一部を責任を持って処理したことを認識しつつ、インシデント前の設計が回避可能なリスクを生み出したかどうかを問うことができる。正確さは弱さではない。それはアカウンタビリティを信頼できるものにするものである。

記憶が薄れる前に顧客が保存すべき証拠

最も有用な顧客証拠は、通知後の最初の数時間で収集されることが多い。管理者は、認証ログ、サポートコミュニケーション、露出したアカウントリスト、ファイアウォールやエンドポイントのイベント、設定エクスポート、パスワードリセット記録、証明書やキーのインベントリ、およびその時点で存在していたベンダー通知のスクリーンショットを保存すべきである。その資料は後で、なぜ組織が狭いリセット、広範なリセット、再構築、開示、または監視対応を選択したかを説明する。それがなければ、後のレビューは管理の記録ではなく、記憶に関する議論になる。

ベンダー通知が進化する可能性があるため、保存も重要である。最初の通知は調査が継続中であると言うかもしれない。後の通知は影響を受ける集団を狭めたり拡大したりするかもしれない。セキュリティアドバイザリは野生で悪用されたステータスを追加するかもしれない。各バージョンを保存する顧客は、その時点で利用可能な事実に自らの決定をマッピングできる。それは、信頼できる通知後の遅い行動を暴露しつつ、不公平な後知恵から保護する。

証拠はセキュリティチームだけの内部に留まるべきではない。法務、調達、プライバシー、サポート、事業継続、エンジニアリング、および経営幹部チームは、それぞれの役割に適したバージョンを必要とする。プライバシーチームは影響を受けたデータフィールドを必要とする。エンジニアリングは技術的指標とシステム所有者を必要とする。調達は契約義務を必要とする。サポートは顧客向けの言語を必要とする。経営幹部は残留リスクと所有者名を必要とする。証拠が正しくても誤った機能に閉じ込められている場合、単一のインシデントが失敗する可能性がある。

顧客の行動ウィンドウは測定可能な義務である

プロバイダー側のイベントはしばしば顧客側の時計を開始する。通知が顧客にソフトウェアの更新、資格情報のローテーション、ログのレビュー、露出したインターフェースの無効化、またはユーザーへの警告を指示する場合、顧客の応答時間はアカウンタビリティ記録の一部となる。プロバイダーは通知と影響を受けたサービスを管理した。顧客はローカルの行動を管理した。どちらの側も単独で仕事を終えることはできない。

その行動ウィンドウは、リスクに一致する条件で測定されるべきである。重大な露出したエッジの欠陥は数時間を要するかもしれない。広範なメタデータの露出は、即日のフィッシング警告と管理者レビューを要するかもしれない。証明書の交換は、更新の展開、許可リストのクリーンアップ、古い署名付きパッケージがもはや信頼されていないことの証明を要するかもしれない。サポートチケットの露出は、添付ファイルのレビューとユーザー通知を要するかもしれない。ハイパーバイザーランサムウェアの波は、通常のメンテナンスウィンドウが適用される前に、緊急隔離とバックアップ検証を要するかもしれない。

ポイントはすべての遅延を罰することではない。一部の環境は複雑であり、公共サービスは気軽に停止できず、緊急の変更は重要な運用を破壊する可能性がある。ポイントは遅延を明示的にすることである。組織が遅延する場合、補償的管理策、ビジネス上の理由、所有者、有効期限、およびリスクが無期限に開いたままではなかったという証拠を記録すべきである。記録されない遅延は、一時的な例外が次のインシデントになる方法である。

修復の主張には永続的な証拠が必要である

修復の主張は、変更された管理策とその変更が依然として有効であるという証拠を挙げるときにより強力になる。アイデンティティインシデントの場合、証拠には無効化されたサービスアカウント、短いセッション、より強力な管理者認証、アクセスレビュー、フィッシング耐性のあるリセットワークフローが含まれるかもしれない。サポートインシデントの場合、証拠にはより狭いベンダーロール、添付ファイル保持制限、特権アクションのログ記録、顧客ファイルのサニタイズが含まれるかもしれない。エッジデバイスインシデントの場合、証拠には外部で検証された管理の隔離、修正されたバージョン、ログレビュー、シークレットローテーション、再構築の決定が含まれるかもしれない。

公衆はすべての機密詳細を必要としないが、修復の形を必要とする。セキュリティが強化されたと言うことは、どのクラスのアクセスが削除されたか、どのクラスの記録が最小化されたか、どのクラスの資格情報がローテーションされたか、どのクラスのデバイスが再構築されたか、どのテストが結果を検証するかを言うよりも弱い。具体的な修復言語は、顧客が救済策を失敗経路と比較することを可能にする。

耐久性が難しい部分である。多くの修復はインシデント直後は強力に見え、その後劣化する。一時的なファイアウォールルールが戻る。古いサポート権限が再び拡大する。新しいログがレビューされない。バックアップがテストされない。トレーニングは一度実行されて消える。したがって、アカウンタビリティ記録は後の検証ポイントを含むべきである。通常の運用を生き残れない修復は、リスクの一時停止に過ぎず、閉鎖ではない。

マネージドプロバイダーは義務連鎖の中にいる

影響を受ける組織の多くは、公的通知で議論されているシステムを直接管理していない。マネージドプロバイダーは、リモートサポートツール、ビルドサーバー、メールプラットフォーム、ファイアウォール、データベースアカウント、ハイパーバイザー、ヘルプデスクワークフロー、または顧客通知を運用しているかもしれない。そのプロバイダーはリスクを迅速に低減するか、顧客を盲目に保つことができる。したがって、その証拠義務はサービスの礼儀以上のものである。

マネージドプロバイダーは、影響を受ける製品やサービスが存在したかどうか、それが露出していたかどうか、いつ更新または隔離されたか、ログが不審な活動を示したかどうか、資格情報がローテーションされたかどうか、バックアップがテストされたかどうか、そしてどのような残留リスクが残っているかを顧客に伝える準備ができているべきである。問題が処理されたというだけの声明は、自らのユーザー、規制当局、保険会社、または取締役会に答えなければならない顧客にとって十分ではない。

契約は、緊急事態の前にその期待を明確にすべきである。緊急通知トリガー、証拠配信、緊急メンテナンス権限、資格情報の所有権、バックアップ責任、および特別な復旧の支払い者を指定すべきである。契約がセキュリティ証拠を任意として扱う場合、顧客はインシデント中にアップタイムを購入したがアカウンタビリティを購入していなかったことを発見するかもしれない。

データの最小化が爆発半径を変える

保護するのが最も簡単な露出記録は、決して保持されなかった記録である。これが、技術的な侵害に関するように見えるインシデントにおいてデータ最小化が重要である理由である。古い添付ファイルを保存するサポートツール、不要なメタデータを保持するアカウントポータル、広範な身元証拠を閲覧できるカスタマーサービスプロバイダー、または管理者の連絡先を集約する企業システムはすべて、攻撃者が到着する前に侵害の価値を増大させる。

最小化は、ビジネスが記録なしで運営できるふりをすることを意味しない。サポートチームは顧客の問題を解決するのに十分な情報を必要とする。セキュリティチームはログを必要とする。金融サービスは規制された記録を必要とする。公共交通システムは、アカウント、割引、払い戻し、支払い操作を必要とする。管理上の質問は、組織がインシデント後に各機密フィールド、各保持期間、各ベンダー許可、各エクスポート経路を正当化できるかどうかである。

より小さな記録は通知も変える。プロバイダーが狭いフィールドセットのみが保持され到達されたと言えるなら、顧客は正確に行動できる。プロバイダーが広範な添付ファイルや豊富なメタデータを保持していた場合、通知はより困難になり、下流の悪用表面が拡大する。したがって、最小化はプライバシーのスローガンではない。それは、インシデントに巻き込まれる人々と決定の数を減らすため、レジリエンス管理策である。

取締役会の監督はステータスだけでなく管理の証拠を求めるべきである

経営幹部はしばしばインシデントの最新情報をステータスワードとして受け取る。封じ込め済み、修復済み、重大な影響なし、調査継続中。これらの言葉はリスクを管理するには広すぎる。取締役会レベルの監督は、どの管理策が失敗したか、またはストレスを受けたか、どの当事者がそれを所有していたか、どの証拠が封じ込めを証明するか、どの顧客やユーザーが依然として害を受ける可能性があるか、どの修復が永続的か、そして何がまだ不明かを尋ねるべきである。

取締役会はまた、インシデントがパターンを明らかにしたかどうかを尋ねるべきである。これは以前のサポートツールの露出、古いパッチギャップ、セグメンテーションの前提、ベンダー監督の弱点、または信頼材料のローテーションの繰り返される失敗の繰り返しだったのか？一つのインシデントは不運かもしれない。繰り返される管理パターンはガバナンスの証拠である。それは組織が学習しているのか、単に対応しているだけなのかを示す。

これには、取締役がインシデント対応者になる必要はない。意思決定グレードの証拠を要求する必要がある。彼らは露出数、行動ウィンドウ、顧客義務、法的トリガー、事業継続への影響、フォローアップ所有者を必要とする。取締役会が話が終わったかどうかだけを尋ねるとき、経営陣は静かな終結に対して報われる。取締役会がどの証拠が管理環境を変えたかを尋ねるとき、修復は可視化される。

このインシデントは将来の調達質問を変えるべきである

顧客はこのインシデントクラスをより良い調達質問に変えるべきである。ベンダーに、サポートアクセスがどのように制限されているか、顧客添付ファイルがどのようにサニタイズされるか、企業 IT が本番サービスからどのように分離されているか、署名証明書がどのように保護されているか、ビルドシステムがシークレットをどのように保存するか、エッジ製品が管理活動をどのようにログ記録するか、古いバージョンがどのように廃止されるか、そしてセキュリティイベント中に顧客がどのように緊急証拠を受け取るかを尋ねるべきである。

それらの質問は、危機の後だけでなく、更新前に尋ねられるべきである。商業チームは単純な機能比較を好むかもしれないが、インシデントは運用保証が製品能力と同じくらい重要であり得ることを示している。広範なサポート権限、弱いログ、遅い通知、不明確な復旧義務を持つ安価なプラットフォームは、何かがうまくいかなくなったときに高くつく可能性がある。より規律あるプロバイダーは、何も失敗しなくても隠れたリスクを減らす。

調達はまた、書類だけの保証を避けなければならない。アンケートの回答は、テスト可能な証拠に接続されるべきである。監査サマリー、保持設定、ロールモデル、パッチサービスレベル、顧客通知の例、復旧演習、利用可能な場合は独立した評価。目標は不可能な透明性を要求することではない。それは、プロバイダーが自らのリスク表面の一部になったときに顧客が無力にならないように、十分な証拠権を購入することである。

アカウンタビリティの教訓は再利用可能である

再利用可能な教訓は、現代のインフラインシデントは始まったシステムで止まることがめったにないということである。侵害されたサポートプロバイダーはアイデンティティ問題になり得る。企業システムのインシデントは顧客メタデータ問題になり得る。脆弱なビルドサーバーはソフトウェアサプライチェーン問題になり得る。リモートアクセス製品は証明書信頼問題になり得る。ファイアウォールやハイパーバイザーは継続性問題になり得る。顧客が分離されたボックスではなく、組み合わされたサービスに依存しているため、カテゴリは重複する。

その重複が、対応計画が管理面を中心に書かれるべき理由である。アイデンティティ信頼を所有するのは誰か？署名付きソフトウェア信頼を所有するのは誰か？サポートデータを所有するのは誰か？エッジ管理を所有するのは誰か？バックアップを所有するのは誰か？顧客コミュニケーションを所有するのは誰か？ベンダー証拠を所有するのは誰か？イベント前にこれらの所有者がわかっていれば、組織はより少ない混乱で対応できる。イベント中に発見されると、人々が権限を交渉する間にインシデントは拡大する。

成熟した組織は、このクラスの将来の通知を読み、即座に所有者、アクション、証拠にマッピングできるべきである。それがインシデント認識とインシデント準備の違いである。認識は何かが起こったと言う。準備は誰が何を、いつまでに、どのような証拠で行わなければならないか、そして依存する人々がどのように知るかを言う。

公共の利益に基づく結論

公共の利益に基づく結論は、JetBrains TeamCity CVE-2023-42793 認証バイパスの悪用とサプライチェーンリスク（2023 年）は、管理テストとして記憶されるべきだということである。この出来事は、組織とその顧客が技術的封じ込めと信頼回復を区別できるかどうかをテストした。通知が実行可能かどうかをテストした。機密記録や信頼オブジェクトが最小化されたかどうかをテストした。依存する当事者が自らを守るのに十分な証拠を受け取ったかどうかをテストした。

このクラスのインシデントに対する最も強力な対応は、より大きな安心感ではない。それは、より狭いリスク経路、より速い封じ込め経路、より完全な証拠経路、そしてより明確な顧客行動経路である。それは、不必要なデータを減らし、広範なサポート権限を減らし、管理境界を強化し、ビジネス環境とサービス環境の分離を強化し、ログを改善し、テストされた復旧、そして信頼が不確かな場合の資格情報や証明書の迅速な失効を意味する。

JetBrains TeamCity は、ビルドサーバーをソフトウェアサプライチェーンのアカウンタビリティ・サーフェスにした。なぜなら、組織は多くの他者がその証拠に依存しなければならない地点に位置していたからだ。それが真実である場合、アカウンタビリティは実践的な管理面に従う。最も明確な可視性と害を減らす最善の能力を持つ当事者は、イベントが終わったと言う以上のことをしなければならない。信頼関係が安全に継続できる理由を示さなければならない。