CrowdStrike は検出速度と開示順序をエンドポイントの説明責任の一部に据えた

要約

• CrowdStrike の公開記録は、異常な明瞭さで2つの時刻を特定している。欠陥のある Rapid Response Content のリリースは2024年7月19日04:09 UTC、ロールバックされたコンテンツは05:27 UTC に利用可能となった。未解決の説明責任のギャップは、その78分間の窓の存在だけでなく、その間に監視が何を検出し、いつ人間がコンテンツリリースが Windows システムをグローバルにクラッシュさせていることを理解したかである。
• このインシデントは、エンドポイントの説明責任に開示の順序付けが含まれるようになったことを示している。顧客は、マルウェア、Microsoft プラットフォームの問題、CrowdStrike のコンテンツ問題、復旧可能なクラウドロールバック、または手動によるブート修復問題のいずれに直面しているのかを知る必要があった。それぞれの解釈は、対応者を異なる運用経路に導いた。
• CrowdStrike はその後、より強力な検証、段階的なコンテンツ展開、コンテンツピニング、クラッシュループの自己復旧、監視、顧客スケジューリング制御について説明した。これらの対策は多くの防止策の疑問に答えるものであるが、公開記録は、自動停止のしきい値、最初のテレメトリシグナル、最初のクラッシュシグナルからロールバック承認までの時間について、外部から確認できる証拠が限られたままである。
• より広範な教訓は、特権的で中央配信されるエンドポイントコンテンツを持つセキュリティベンダーは、検出速度、公開属性の特定、顧客が読める復旧手順を、広報の後付けとしてではなく、安全制御として扱うべきであるということである。

エビデンスマップ

説明責任の時計は公開時計の前から動き始める

CrowdStrike インシデントで最も公表された時計は、04:09 UTC から05:27 UTC までの間である。問題のある Rapid Response Content のリリースからロールバックされたコンテンツが利用可能になるまでの時間であるため、この時計は重要である。しかし、それは不完全な尺度でもある。Windows マシンがクラッシュするのを目の当たりにしている顧客にとって、より重要な時計は別のものだった。いつベンダーはリリースが顧客に害を及ぼしていることを知るのに十分なテレメトリを受信したのか、いつ特定のコンテンツが共通原因であると特定したのか、いつ追加配信を停止したのか、いつ有用なガイダンスを公開したのか、そして顧客は通常の再起動では不十分であることをいつ知ることができたのか。

この区別がここでの説明責任のレンズである。この障害は、リリース、検証、ブラスト半径、復旧の失敗の連鎖として理解できるが、検出と開示はそれ自体の制御分析に値する。特権的な検出コンテンツをグローバルに配布できるプロバイダーは、グローバルな害センサーも運用している。そのセンサーが顧客が広範な障害を経験した後にのみ問題を検出するならば、リリースシステムはそれを取り巻く説明責任システムよりも高速になっている。

CrowdStrike 自身の記録は、功績と限界の両方を支持している。功績は、同社が多くの大規模インシデントに比べて問題のあるコンテンツを迅速にロールバックしたことである。限界は、公開された証拠が分単位の内部検出記録を示していないことである。公衆はリリース時間とロールバック時間を見ることができる。最初の異常なクラッシュクラスター、最初の自動アラート、最初の人間によるエスカレーション、コンテンツ移動を停止する最初の決定、またはロールバック前に到達した人口を見ることはできない。それらの詳細がなければ、78分間の間隔は有用ではあるが十分ではない。

エンドポイントセキュリティにとって、これは通常の SaaS の変更よりも重要である。Falcon センサーは深いオペレーティングシステム統合を備えて動作し、脅威を早期に検出・防止する。その特権的な立場は、コンテンツエラーが即座にデバイスレベルの結果を生み出す可能性があることを意味する。エンドポイントベンダーのリリース機構がセキュリティ速度で動く場合、監視と開示の機構は安全速度で動かなければならない。説明責任の問いは、ベンダーが事後にポストモーテムを書けるかどうかではない。システムがブラスト半径がまだ小さいうちに悪いリリースを検出し、顧客に自分たちがどのような緊急事態にいるのかを伝えられるかどうかである。

公開記録はその非対称性の結果を示している。修正されたコンテンツを受け取った一部のシステムは、再起動の試行後に復旧できた。しかし、すでにクラッシュループにある多くのシステムは、セーフモード、復旧環境、ブートメディア、管理者アクセス、または BitLocker キーを必要とした。クラウドでロールバックが発生した時点で、多くの影響を受けたデバイスは確実にクラウドに到達できなかった。これが、十分に早期に自動停止しない検出および配信システムの運用上の代償である。

検出速度は安全特性であり、虚栄心の指標ではない

ベンダーのステータスページやインシデントレポートは、しばしば検出をタイムスタンプとして提示する。特権的なエンドポイントインシデントでは、検出は安全特性である。リリースシステムは、コンテンツインスタンスが統計的に異常なクラッシュパターンを生成しているかどうか、クラッシュがオペレーティングシステム、センサーバージョン、コンテンツチャネル、地域、顧客コホート、またはハードウェアプロファイルごとに集中しているかどうか、影響を受けたホストが修正されたコンテンツを収集するのに十分迅速に再起動しているかどうか、そして是正措置がリリースが到達した同じ人口に到達しているかどうかを知るべきである。

CrowdStrike が後に強調した証拠は、このニーズに対応している。その根本原因分析は、ランタイム境界チェックの欠如、入力カウントの不十分な検証、決定的な条件を実行しなかったテストケース、および関与する特定の種類の Rapid Response Content に対する段階的展開の欠如を説明した。その後の改善声明は、コンテンツ品質の可視性、リングベースのコンテンツ配信、ホストグループのスケジュール、コンテンツピニングを説明した。これらは単なるエンジニアリング衛生項目ではない。それらは検出機器である。リングは比較人口を生み出す。ベイク時間はテレメトリが蓄積する余地を与える。ピニングにより、顧客は証拠が弱い間に新しい露出を回避できる。ホストグループスケジュールにより、重要度の低いシステムを初期のリングに配置し、重要な運用を最初の接触から遠ざけることが可能になる。

しかし、公開記録は運用しきい値に関しては依然として薄い。顧客、規制当局、または取締役会は合理的に次のことを尋ねるだろう。リング内のカーネルクラッシュの数がいくつで自動昇格が停止されるのか、クラッシュテレメトリはどのくらい迅速にリリース制御システムに到達するのか、コンテンツシステムは手動トリアージを待たずに特定のファイルバージョンとクラッシュを相関させることができるのか、そして影響を受けたホストがブートできないためにテレメトリをアップロードできない場合はどうなるのか。答えは CrowdStrike 内部に存在するかもしれない。それは会社の外部では完全には見えていない。

この可視性のギャップが重要なのは、自信が最も必要なところで自己証明が最も弱いからである。顧客はグローバルな CrowdStrike コンテンツ障害をシミュレートして、ベンダーの自動停止しきい値を検証することはできない。保証、契約条件、リリース制御の説明、テスト証拠を求めることはできるが、ライブのコントロールプレーンをローカルの変更管理プロセスであるかのように検査することはできない。したがって、プロバイダーは通常の謝罪以上の開示責任を負う。検出速度が測定可能で、実行され、統治されていることを顧客が理解できるように、十分な制御証拠を公開すべきである。

検出速度はまた、診断速度から分離されるべきである。初期のシグナルは、リリース後に Windows ホストがクラッシュしていることを示すかもしれない。診断は後で21番目の入力フィールドと欠落した境界チェックを特定するかもしれない。顧客は最初の1時間で完全な因果メカニズムを必要としていなかった。彼らは、インシデントが CrowdStrike のコンテンツアップデートによって引き起こされたこと、アクティブな悪意のあるキャンペーンではないこと、Mac と Linux が同じパスにいないこと、悪いコンテンツがロールバックされたこと、そしていくつかのホストは手動修復を必要とすることを知る必要があった。良い開示の順序付けは、実行可能性から説明へと移行する。完全な根本原因を待ってから有用な運用上の真実を発行するのではない。

最初の公開フレームが復旧経路を決定する

初期のフレーミングは表面的なものではない。対応者が悪意のある攻撃者がエンドポイントを悪用していると信じる場合、ネットワークを隔離し、イメージを保存し、自動修復を遅らせ、外部接続をブロックするかもしれない。Microsoft Windows 自体が障害を起こしていると信じる場合、プラットフォームのガイダンスを待つかもしれない。CrowdStrike のコンテンツファイルがトリガーであると信じる場合、関連するドライバディレクトリ、センサーバージョン、コンテンツタイムスタンプ、再起動動作に集中できる。最初の信頼できるフレームは、限られた対応リソースが封じ込め、パッチ適用、インフラフェールオーバー、または手動デバイス修復のどれに向かうかを決定する。

CISA の同日アドバイザリは、フレームを修正するのに役立った。それは、イベントが CrowdStrike Falcon コンテンツアップデートによる Windows 10以降のシステムに影響を与えたこと、Mac と Linux はそのパスの影響を受けなかったこと、そしてイベントは悪意のあるサイバー活動ではないことを特定した。その公開された表現は、誤ったサイバー攻撃対応のリスクを低減した。オーストラリア信号局は同様に実用的なガイダンスを提供し、悪意のある復旧サイトや非公式のコードについて警告した。その警告は偶発的なものではなかった。対応者が修正を切望しているとき、復旧チャネル自体が攻撃対象領域になる。

Microsoft の初期のフレームでの役割も重要だった。Windows はクラッシュを表示し、Microsoft は顧客を大規模に復旧し、Microsoft は修復ツールを公開した。しかし、Microsoft の公開メモとその後の技術分析は、このイベントが Microsoft 発ではないことを明確にした。その区別は、ユーザーに見える症状だけが Windows を指していたため必要だった。ブルースクリーンイベントは、トリガー入力がサードパーティのセキュリティ製品から来たとしても、プラットフォームの属性を直感的に感じさせることがある。公開説明責任は、症状の表面と制御の表面を分離することに依存する。

CrowdStrike は、最も正確なインシデント固有の事実を管理していた。問題のある Channel File、影響を受けたセンサーバージョン、リリースとロールバックのタイムスタンプ、および意図された顧客修復手順である。Microsoft は復旧環境の多くを管理していた。政府は調整と公開警告を管理していた。顧客はローカルトリアージを管理していた。これらの開示のいずれかが遅れたり、不明確だったり、矛盾したりした場合、復旧労力はさらに高くついただろう。したがって、このインシデントは開示の順序付けを製品の安全ケースの一部にしている。

これは特に中小企業に当てはまる。大銀行や航空会社は技術的なブリッジを設置し、テレメトリを比較し、ベンダーに直接連絡できる。小規模な診療所、小売業者、地域サービスプロバイダーは、マネージドサービス、メディアレポート、政府アドバイザリ、または決済システムの障害を通じてインシデントを知るかもしれない。それらの組織にとって、公開メッセージは行動に移せるほど簡潔で、有害な推測を避けるために正確でなければならない。「再起動して待つ」は「セーフモードに入り、特定のファイルを削除する」とは異なる。「悪意なし」は「調査しない」とは異なる。良い初期通知は、安全な行動に必要な最小限の事実を提供する。

ロールバックは一部のシステムにとっては予防であり、他のシステムにとっては過去のものだった

クラウドロールバックは決定的に聞こえる。このケースでは、2つの意味があった。問題のあるファイルをまだ受信していなかったエンドポイントにとって、ロールバックは予防だった。ファイルを受信したが、ブートしてロールバックされたコンテンツを収集するのに十分な時間接続を維持できたエンドポイントにとって、ロールバックは自己修復になり得た。通常の管理がロードされる前に繰り返しクラッシュに陥ったエンドポイントにとって、ロールバックはすでに過去のものだった。それらのホストは物理的または帯域外の復旧を必要とした。

Microsoft のサポートガイダンスは、運用上の現実を可視化している。管理者は、セーフモード、復旧環境、影響を受ける Channel File 291パターンの削除、および BitLocker 回復キーを必要とするかもしれない。Microsoft は後に、WinPE、セーフモード、USB、ISO、ネットワークブートを使用した復旧ツールパスを公開した。これらは困難な問題に対する合理的なツールである。また、「ベンダーがコンテンツをロールバックした」と「企業がサービスを復旧した」の間の大きな隔たりも示している。ローカル技術スタッフのいないリモートオフィス、ブート設定がロックされたキオスク、厳格な変更プロセスの背後にあるサーバー、または暗号化キーがすぐに利用できなかったラップトップは、クラウドコントロールプレーンが修正された後も機能し続ける可能性があった。

それが、検出速度がベンダーのダッシュボードを超えて結果を持つ理由である。配信が継続する毎分ごとに、手動カテゴリに落ちるデバイスの数が増加する。リリースシステムは可用性イベントを作り出しただけではない。中央で引き起こされた障害を、分散された復旧労力に変換した。被害を受けた組織は、インベントリ、アクセス、資格情報、暗号化キーの管理、ブートメディア、ローカル調整、および重要なデバイスを優先する方法を必要とした。それらの一部は顧客の責任だった。ベンダー管理のリリースが最初にデバイスに到達したため、それらは緊急になった。

したがって、インシデント後の制御の答えには、手動復旧が支配的な経路になる前に自動封じ込めを含めるべきである。ランタイム境界チェックは、悪い入力がクラッシュになるのを防ぐ。クラッシュループの自己復旧は、最新のコンテンツを隔離できる。最後に正常だったコンテンツをローカルで再選択できる。リングとベイク時間は配信を遅くする。顧客コンテンツホールドは、重要な人口が最初の露出を避けることを可能にする。監視は昇格を停止できる。ポイントは単一の特効薬ではない。エンドポイントベンダーは悪いコンテンツを予想される障害モードとして設計し、デバイスが復旧可能に障害を起こすようにすべきである。

CrowdStrike のその後のレジリエンスアップデートは、その方向への進歩を主張している。同社は、リングベースのコンテンツ配信、コンテンツピニング、顧客スケジューリング、帯域外修復、クラッシュループのセンサー自己復旧を説明した。これらは正しいカテゴリである。説明責任の問いは証拠に関するものになる。これらの制御は、不正なコンテンツ、カーネル障害、ネットワークの利用不可、および大規模な顧客多様性の条件下でテストされたか。そして、顧客は新しい安全マージンが本物かどうかを判断するために、テストについて十分に知ることができるか。

開示遅延は単一の数字ではない

「開示遅延」という言葉は、完璧な発表が即座に行われるべきだったと示唆するならば、不公平である可能性がある。大規模インシデントは層状に発見される。初期の事実は不完全である。一部の主張は誤っている場合に害を引き起こす可能性がある。しかし、すべての遅延を無害な注意として扱うことも同様に不公平である。開示遅延には次元がある。問題を認識する遅延、原因を特定する遅延、顧客に何をすべきかを伝える遅延、何をすべきでないかを説明する遅延、影響を受ける製品とバージョンを特定する遅延、そして長期的な説明責任に必要な証拠を公開する遅延。

CrowdStrike イベントでは、いくつかの初期開示は実用的に有用だった。テクニカルアラートは、Windows クラッシュ状態、ファイルパス、影響を受けるコンテンツタイムスタンプ、およびロールバックされたタイムスタンプを特定した。政府アドバイザリは、問題を非悪意で CrowdStrike 関連と位置付けた。Microsoft は復旧ガイダンスを公開した。これらの開示は混乱を減らした。しかし、すべての説明責任の問いに答えたわけではない。根本原因分析はその後になり、合理的なことである。議会公聴会はさらに後になった。長期的なレジリエンスアップデートは約1年後に到着した。

この順序はほとんど理解可能である。初期の運用指示があいまいである場合、または後の説明開示が顧客が将来のリスクを評価するために必要な部分を省略している場合、それは制御の問題になる。公開 RCA は欠陥経路について詳細である。最初の検出、自動停止信号、内部決定のタイムラインについてはあまり詳細ではない。これにより、顧客はコンテンツがなぜマシンをクラッシュさせたのかを理解できるが、次の異常なリリースがより早期に発見されるかどうかを評価する能力は低くなる。

より良い開示モデルは、事実を階層に分けるだろう。第1層は運用上のもの：影響を受けるシステム、即時の回避策、ロールバックされたもの、影響を受けないもの、イベントが悪意があるかどうか。第2層はスコープ設定：人口推定、コンテンツバージョン、システムバージョン、既知の復旧制限、サポートチャネル。第3層は制御の証明：因果連鎖、欠落した安全策、テレメトリタイムライン、決定タイムライン、是正責任者、独立したレビューステータス、測定可能な受入基準。各層には異なる時計がある。プロバイダーは第3層を待ってから第1層を公開すべきではない。また、緊急事態が過ぎた後で第1層で十分であると扱うべきでもない。

これは調達において重要である。エンドポイントセキュリティを購入する顧客は、マルウェア検出だけを購入しているのではない。彼らはベンダーのエンドポイント動作を安全に変更する能力を購入している。開示パフォーマンスはその能力の一部である。自社のリリース障害をいつ検出したかを説明できないベンダーは、最も重要な安全フィードバックループが非公開のままである制御システムを信頼するよう顧客に求めている。

政府とセクターの記録は真の開示オーディエンスを明らかにする

CrowdStrike の開示のオーディエンスは、直接の顧客だけではなかった。それには病院、交通システム、銀行、中小企業、規制当局、政府緊急チーム、決済処理業者、クラウドプロバイダー、そしてサービスを待つ人々が含まれていた。それらの当事者の多くは CrowdStrike と契約していなかった。それでも、エンドポイントの障害が彼らの世界に干渉したため、正確な情報を必要としていた。

NHS England の対応はその点を明確にしている。一般診療所は、影響を受けた臨床システムが利用できない場合、紙の記録、手書きの処方箋、電話連絡、手動管理を使用した。その種の代替措置はケアを維持できるが、通常の容量を維持できない。代替措置を運用していた人々は、テンプレートタイプの深い説明を必要としていなかった。彼らは、障害が続く可能性があるかどうか、システムを安全に再起動できるかどうか、デジタル回避策が新たなリスクを生み出す可能性があるかどうかを知る必要があった。

FCA のレビューは異なる開示オーディエンスを示している。重要なビジネスサービスとサポートリソースをマッピングしていた規制対象企業は、復旧をより効果的に優先順位付けできた。これは顧客側のレジリエンスの教訓であるが、外部のインシデント情報に依存している。企業は、問題がローカルなのか、セクター全体なのか、ベンダー固有なのか、プラットフォーム固有なのか、悪意のあるものなのか、すでに上流で修復されたのかを知らなければ、復旧を適切に優先順位付けできない。公開開示は運用レジリエンスへのインプットになる。

英国下院の声明は中小企業の角度を追加した。一部の中小企業は、カード決済や ATM の中断を通じて影響を受けた。彼らは必ずしも Falcon 管理者ではなかった。彼らは、自分たちのサービス継続性が、それらの組織に依存する下流の経済参加者だった。彼らのために、ベンダー開示は公的調整の問題になる。同じことは、バックオフィスのエンドポイントがダウンしたために失敗したサービスを利用しようとする乗客、患者、市民にも当てはまる。

この広いオーディエンスは明確性の義務を課す。セキュリティエンジニアだけを対象に書かれたベンダー声明は、グローバルな可用性イベントの際に公共のニーズを満たさない可能性がある。同時に、過度に簡略化された声明は物質的な区別を消去する可能性がある。適切なトーンは、運用可能であるほど技術的であり、政府、セクター団体、マネージドサービスプロバイダー、カスタマーサービスチームを通じて意味を失わずにルーティングできるほど平易であることである。それは難しい仕事である。また、エンドポイント製品が重要なサービスに組み込まれた後は、エンドポイント説明責任の一部である。

顧客の責任はベンダーの制御限界から始まり、プレスリリースから始まるのではない

ここでの新しいレンズは、ベンダーのみを非難するものに変わるべきではない。顧客には実際の継続性の義務があった。彼らは、エンドポイントグループ化、重要なサービスマッピング、復旧キーのエスクロー、ローカル管理者アクセス、ブートメディア、スペアデバイス、帯域外通信、サードパーティサポート、手動代替措置を管理していた。より迅速に復旧した組織は、しばしばサービスマップとテストされた復旧プラクティスを持っていた。苦労した組織はすべて怠慢だったわけではない。困難な資産、限られたスタッフ、または継承された依存関係を持っていた組織もある。しかし、顧客側の準備は重要だった。

境界は実用的な制御である。顧客は CrowdStrike のコンテンツバリデータが間違った定義を信頼するのを防ぐことはできなかった。Falcon センサーにランタイム境界チェックを追加することはできなかった。Rapid Response Content がグローバルに段階的に展開されるかどうかを決定することはできなかった。ベンダーの最初のクラッシュ信号を見ることはできなかった。しかし、彼らは、支払い端末に手動代替措置があるかどうか、BitLocker 回復キーにアクセス可能かどうか、重要なデバイスが異なるグループ化されているかどうか、マネージドプロバイダーに緊急の実地計画があるかどうかを決定することはできた。

この割り振りは、開示が含まれるとより明確になる。顧客は、ベンダーがどのようなタイプの障害が発生したかを伝えるまで、正しい復旧ワークフローを開始できない。その後、顧客自身の準備が、それをどれだけうまく実行できるかを決定する。弱い開示シーケンスは顧客の能力を浪費する。弱い顧客準備は有用な開示を浪費する。同じインシデントで両方が真実であり得る。

同じ原則が中小企業にも適用される。小規模組織は Falcon を直接管理していないかもしれない。マネージドサービスプロバイダーや、エンドポイントで Falcon を実行している上流サービスに依存しているかもしれない。その現実的な制御は少ない。代替支払い受付、連絡先のエクスポート、手動予約帳、スペアデバイス、プロバイダーサポート契約、またはサプライヤー混乱中に顧客と通信する能力。これらの控えめな制御は、ベンダーのリリース障害を許すものではない。それらは、下流の害が契約よりも遠くに及ぶことを認識している。

したがって、エンドポイント説明責任には、両面の準備モデルが必要である。ベンダーは、悪いコンテンツを安全に停止、通信、復旧できることを証明すべきである。顧客は、ベンダー管理のエンドポイント障害を、影響を受けるすべてのデバイスを孤立した緊急事態に変えずに吸収できることを証明すべきである。ベンダーの第一の義務は予防と迅速な開示である。顧客の第一の義務は、正確な情報が存在した後の結果管理である。

より良い公開記録が示すもの

公開記録は技術的欠陥とセクターの結果に関しては強力である。検出経路に関しては弱い。より良い公開記録には、機密の顧客データを公開せずに制御ループを示すリリース可観測性のタイムラインが含まれるだろう。異常なクラッシュテレメトリがいつ予想ベースラインを超えたか、コンテンツリリースが可能性の高い共通要因として特定されたのはいつか、配信が停止またはロールバックされたのはいつか、顧客向け指示が最初に公開されたのはいつか、そして主要なマイルストーンまでに問題のあるファイルがターゲット人口の何パーセントに届いていたかが記載されるだろう。

また、自動停止条件も説明されるだろう。厳密な独自のスコアリングではなく、ガバナンスを確立するのに十分な情報：どのシグナルがリングを停止するか、どのシグナルがグローバルロールアウトを停止するか、停止を無効にするために必要な人間の承認、ブートしていないホストからのテレメトリがどのように考慮されるか、顧客定義の重要なグループが最初の露出からどのように保護されるか。これらは精神においてトレードシークレットではない。それらは安全の主張である。

独立したレビューは、これらの質問を中心に公開的に要約されれば、より有用だろう。CrowdStrike は外部レビューを依頼したと述べた。顧客は、レビュー担当者が不正なコンテンツ、リング停止、ロールバック到達可能性、クラッシュループ復旧、テレメトリ損失、コンテンツピニングをテストしたかどうかを学ぶために、完全な非公開レポートを必要としない。短い保証サマリーは、エクスプロイトに敏感な詳細を開示せずに信頼を向上させる可能性がある。

同じことが開示リハーサルにも当てはまる。プロバイダーはコードパスだけでなく、通信パスもテストすべきである。会社は数分以内に正確な影響を受けるバージョン境界を含む運用アドバイザリを公開できるか。Microsoft、CISA、国際機関、主要クラウドプロバイダーと調整できるか。直接顧客にコンソール通知をプッシュすると同時に、パブリックチャネルが下流組織に警告を発することができるか。リンクを壊したり、矛盾したバージョンを作成したりせずに指示を更新できるか。これらは運用制御である。

このインシデントは、CrowdStrike がエンドポイントベンダーの中で特に不注意であったことを証明したわけではない。それは、業界が安全テレメトリと開示に関するより高い基準を必要とすることを証明した。なぜなら、多くのベンダーが現在、顧客エンドポイント上でクラウド制御のセキュリティ自動化を運用しているからである。次の障害は異なる製品、プラットフォーム、または制御を含むかもしれない。説明責任のテストは同じだろう。プロバイダーは害を早期に検出し、配信を停止し、顧客に何が変わったかを伝え、手動修復がデフォルトになる前に復旧を可能にしたか。

テレメトリ問題は顧客制御の問題でもあった

CrowdStrike のその後の是正措置は繰り返し顧客制御を指している。コンテンツピニング、展開スケジュール、ホストグループ化、コンテンツ可視性、段階的コンテンツ配信。これらの制御は、不確実性の中で誰が行動できるかを変えるため、開示に関する記事に属する。顧客が最も重要なシステムに対して新しいコンテンツクラスを保持し、リスクの低いグループが最初にそれを受け取る場合、開示はもはやメッセージだけではない。それは強制可能な運用状態になる。

障害の前は、多くの顧客はセンサーバージョンのロールアウトよりも Rapid Response Content の配信に対して強力な制御を持っていたようである。CrowdStrike の初動レビューは、インシデント後に Rapid Response Content に対する追加の顧客制御の必要性を認めた。その詳細は重要である。顧客は非常に成熟していても、製品アーキテクチャがベンダーに同等の顧客ステージング権限なしでスピードを与える場合、サプライヤー管理のリリース経路にさらされ続ける可能性がある。セキュリティ自動化は、脅威条件が迅速に変化するため、しばしばそのスピードを主張する。2024年7月のイベントは可用性トレードオフを示した。

顧客制御は単純な「全員がオプトアウトできるようにする」という答えではない。すべての顧客がすべての検出コンテンツを無期限に遅らせる場合、エンドポイント保護は価値を失う。有用な設計にはより多くのテクスチャが必要である。ベンダー管理のデフォルトリング、顧客定義の重要度グループ、明確に定義された脅威条件のための緊急オーバーライド、透明なコンテンツメタデータ、およびどのホストグループがいつどのコンテンツバージョンを受信したかを顧客が知らせるレポーティング。この構造により、顧客は高速検出のセキュリティ利益を共有しながら、重要度の高いシステムの初回露出リスクを制限できる。

これはまた、開示とテレメトリが出会う場所である。顧客はリリース状態を見ることができなければ、良いコンテンツホールド決定を下せない。コンソールが Falcon が「正常」であると表示している間に、新しいコンテンツインスタンスが重要なグループにちょうど到達した場合、顧客は実用的な安全制御を欠いている。コンソールがコンテンツバージョン、リリースリング、既知の問題ステータス、ロールバックステータス、復旧手順を表示する場合、顧客は行動できる。開示チャネルは、別個のインシデントブログではなく、製品インターフェースの一部になる。

規制されたセクターにとって、同じアイデアが証拠に影響する。病院、銀行、航空会社は後で、なぜコンテンツクラスを重要なエンドポイントのセットに許可したか、または定義されたグループに対してコンテンツを遅らせたかを説明する必要があるかもしれない。その説明には、タイムスタンプ、リリース識別子、ベンダー通知、顧客ポリシー、ホスト受信の証拠が必要である。それらの記録がなければ、組織は危機後にメールやチケットから決定を再構築することになる。コンテンツを大規模に配布できる製品は、顧客が読める配布台帳を生成できるべきである。

設計基準は製品の特権に比例すべきである。通常の分析タグはブートに影響を与えずに中央でロールバックできる。カーネルに隣接するエンドポイントセンサーは、悪い状態が通常のテレメトリと通常の修復を妨げる可能性があると想定しなければならない。コンポーネントの特権が高いほど、顧客は露出を見て形成できるべきである。これはクラウド配信のセキュリティの拒絶ではない。それは、クラウド配信のセキュリティを重要な運用と互換性のあるものにするガバナンス層である。

開示は復旧の物理を説明しなければならない

多くの技術インシデント通知の弱点の1つは、プロバイダーが何をしたかを説明するが、影響を受けた顧客が今物理的に何ができるかを説明しないことである。CrowdStrike インシデントでは、その違いが決定的だった。「コンテンツはロールバックされた」は真実であり重要だった。しかし、それは「影響を受けるすべてのマシンがロールバックされたコンテンツを受信できる」を意味しなかった。復旧の物理は、マシンがブート、認証、接続、コンテンツ受信、および自己修復に十分な安定性を維持できるかどうかに依存していた。

Microsoft の復旧ガイダンスはそれらの物理的制約を示した。セーフモード、Windows 復旧環境、BitLocker キー、USB メディア、ネットワークブート、ローカル管理者アクセスは抽象的なステップではない。それらはどこで労力が発生しなければならないかについての事実である。クラウド発の障害は、机のそば、データセンター、支社、リモートサイトの問題になった。その移行は開示において明示的であるべきである。顧客は、修正が存在することだけでなく、どのクラスのデバイスが自己復旧できるか、どのクラスが繰り返しの再起動試行を必要とするか、どのクラスが実地介入を必要とするか、どのクラスが最初の修復試行の前に暗号化キーの準備を必要とするかを知る必要がある。

復旧の物理はまたトリアージの順序に影響する。数千の影響を受けたデバイスを持つグローバル企業は、すべてのエンドポイントを平等に扱うべきではない。臨床ケア、決済処理、交通スケジューリング、ID 管理、セキュリティ監視、カスタマーサービスをサポートするデバイスが最初に動く必要があるかもしれない。FCA の運用レジリエンスの教訓は、マッピングされた重要なビジネスサービスが企業に復旧の優先順位付けを可能にするため、ここで有用である。そのマッピングは、インシデント開示が可能性の高い修復経路を説明する場合にのみ実用的になる。クリーンなコンテンツを受け取った後に自己修正できるデバイスは、物理的に触れなければならないデバイスとは異なるキューに置かれる。

小規模組織は同じ物理のより厳しいバージョンに直面する。中小企業は予備の管理者、ブート可能な復旧ツール、または暗号化キーへの即時アクセスを持っていないかもしれない。また、過負荷のマネージドサービスプロバイダーに依存しているかもしれない。エンタープライズツールを前提とした開示は、意図せずに小規模事業者を置き去りにする可能性がある。政府アドバイザリは、広いオーディエンスに警告し、公式指示を指し示すことで役立ったが、製品所有者自身のガイダンスは、特定のファイル名、バージョン、回避策のための権威ある情報源であり続ける。

より安全な開示パターンは復旧状態を説明するだろう。状態1：コンテンツを受信していないため影響なし。状態2：コンテンツを受信したが、ブートして更新可能。状態3：クラッシュループにあり、復旧環境での修復が必要。状態4：修復にローカルアクセスまたは暗号化キーの取得が必要。状態5：文書化された手順では修復できず、ベンダーサポートへのエスカレーションが必要。この種の状態モデルにより、顧客はベンダーインシデントを復旧計画に変換できる。

公開記録は速度と封じ込めを区別すべきである

CrowdStrike の78分間のロールバックは認識に値する。それはまた、速度と封じ込めが同じ指標ではない理由を示している。リリースは広範な配布後に迅速にロールバックされるか、または狭い配布後にゆっくりとロールバックされる。後者はより少ない害を生み出す可能性がある。特権的なエンドポイント製品の場合、公衆はロールバック時計の優雅さよりも、ロールバックが有効になる前に復旧不可能または手動復旧状態に入ったホストの数に関心を持つべきである。

公開記録は完全な露出曲線を提供していない。Microsoft は影響を受ける Windows デバイスを850万台と推定した。その推定値は規模を定義するのに役立つが、分単位で悪いコンテンツを受信したデバイスの数、ロールバック前にクラッシュした数、自己復旧できた数、手動修復を必要とした数、またはそれらの人口がセクター間でどのように異なるかを示していない。その曲線がなければ、外部者はリリース制御システムがイベントを封じ込めたのか、それともイベントがすでに大規模になった後にファイルをロールバックしただけなのかを完全に評価できない。

これは、顧客の身元や機密テレメトリを公開するための議論ではない。集計されたリリース曲線は、注意深く設計されれば安全に公開できる。ベンダーは、各リングに到達したホスト数またはアクティブな Windows センサーの割合、時間間隔ごとに観測されたクラッシュ信号の数、発動すべきだった自動停止条件、停止までの時間、ロールバックまでの時間、推定される自己復旧対手動復旧の人口を報告できる。範囲だけでも有用だろう。それにより、顧客と規制当局は、すでにグローバルなインシデントへの迅速な対応と真の早期封じ込めを区別できる。

同じデータは顧客の計画を改善する。ベンダーが新しいリングが定義されたベイク時間で実行され、小さなクラッシュ異常の後に昇格が停止されることを示すことができれば、顧客はどのホストグループをどのリングに配置すべきかを決定できる。ベンダーがいかなる集計安全証拠も共有できない場合、顧客は信頼に頼らなければならない。信頼は重要であるが、インフラ説明責任は測定可能な主張を必要とする。

この基準はセキュリティ自動化にとって正常であるべきである。セキュリティベンダーは、敵対者が迅速に動くため、自動化された決定を受け入れるよう顧客に定期的に求める。相互の義務は、オートメーションが監視よりも速く動いていないことを顧客が知ることができるように、十分な安全パフォーマンスの証拠を公開することである。ロールバックタイムスタンプは1つの有用なデータポイントである。封じ込め曲線は説明責任の記録である。

説明責任のテスト

CrowdStrike の2024年7月の障害は、検出速度を外部の義務に変えた。技術的な根本原因は、Windows マシンがなぜクラッシュしたかを説明している。特権的なエンドポイントコンテンツを取り巻く安全システムが十分に迅速で、観測可能で、伝達可能であったかどうかには完全には答えていない。ベンダーは78分でロールバックでき、それでもなぜこれほど多くのシステムが予防可能な露出から手動復旧に移行したのかという合理的な疑問を残す。

答えは演劇的な非難であるべきではない。それは測定可能な説明責任であるべきである。エンドポイントベンダーは、ランタイム安全チェック、段階的リリース、コンテンツホールド、クラッシュループ復旧、および監視が悪いリリースを早期に停止できることを示す公開証拠を必要とする。顧客は、サービスマップ、テストされた復旧アクセス、暗号化キーの管理、サプライヤー障害のプレイブックを必要とする。政府とセクター規制当局は、影響を受ける公衆がしばしばベンダー契約の外にいるため、ベンダー開示をレジリエンスの一部として扱う必要がある。

永続的な教訓は、セキュリティ自動化は敵対者をどれだけ迅速に検出するかだけで判断されるべきではないということである。自分自身が問題になることをどれだけ迅速に検出するかでも判断されなければならない。コンテンツファイルがクラウドコンソールからカーネルコンテキストまで数分で到達できる世界では、開示の順序付けは評判管理ではない。それは害の制御である。