850万台のPCがクラッシュ——あなたの側の誰もレビューしなかった、たった一つのファイルで

2024年7月19日の朝食時、中堅航空会社のセキュリティを統括している友人が、私に一枚の写真を送ってきた。それは出発案内板だったが、どのパネルも同じ色合いの青一色で、ターミナル全体にわたってパネルからパネルへと、同じ白いエラーテキストが繰り返し表示されていた。彼はそれに何も書き添えなかった。書き添える必要もなかったのだ。

私がコーヒーを飲み終える頃には、その数は850万台のWindowsマシンに達し、90分足らずでクラッシュしていた。マルウェアではない。ゼロデイでもない。CrowdStrikeからの日常的なコンテンツアップデートだった——それらの企業が、まさに自分たちを守ってもらうために対価を払っていたベンダーからのものだ。エンドポイントを保護していたものが、それらを文鎮化させたものだったのである。

それ以来、私はこれらのベンダーとこれらのマシンの間に位置すべきだったレイヤー、すなわち私たちが今こう呼ぶものの構築に時間を費やしてきた——ソフトウェアアップデート展開の整合性、すなわちベンダーのアップデートパイプラインとあなたの本番フリートの間に立つ独立したチェックポイントだ。本稿は、なぜそのレイヤーが存在しなかったのか、なぜそれを構築する明白な方法が間違っているのか、そしてあの青い画面が灯った瞬間に、カーネルレベルのエージェントを稼働させるすべての企業の足元で何が変わったのかについてである。

第21のフィールド

私はCrowdStrikeの外部根本原因分析（External Root Cause Analysis）を、それが公開された2024年8月のその夜に読んだ。そして、その原因はあまりに些細で、ほとんど侮辱的なほどだった。

CrowdStrikeのセンサーであるFalconは、Rapid Response Contentと呼ぶ仕組みを通じて検知ロジックを配信する——これは、まったく新しいバイナリを配布することなく新たな脅威に対応できるようにする、小さな設定アップデートだ。7月19日、Falconはプロセス間通信の検知用に、2つの新しいTemplate Instanceを配信した。それらのインスタンスは、21番目の入力パラメータを参照していた。CrowdStrikeのクラウドベースのContent Validatorは、そのアップデートを新しい21フィールドのスキーマに照らして検査し、有効だと判断して、承認した。

問題は、Windowsカーネル内部、すなわちオペレーティングシステムで最も特権的な層であるRing 0で動作するContent Interpreterだった。それは依然として20フィールドを期待していた。21番目に手を伸ばしたとき、そこに存在しないメモリを読み込み、マシンは瞬時にブルースクリーンになった。

クラウドのバリデーターは、新しいルールに照らしてアップデートを承認した。それを受け取ったカーネルは、依然として古いルールに従って生きていた。両者が一致しているかを確認する者は、誰もいなかった。

エンジニアとして今なお最も私を悩ませるのは、この部分だ。クラッシュは起動シーケンスのあまりに早い段階で起きたため、Falcon自身の管理エージェントが一度も立ち上がらなかった。そのため、エンドポイントはCrowdStrikeが送り出したロールバックコマンドを受け取ることができなかった。そのコマンドを受け取るはずのソフトウェアこそが、マシンをクラッシュさせている当のものだったからだ。業界にはこれを指す不吉な名前がある——デッドエージェント・ループだ。復旧はボタン一つではなかった。それは、各マシンの前で人間が、セーフモードで起動し、次の場所へ辿り着き、C:\Windows\System32\drivers\CrowdStrike\、そして不具合のあるC-00000291-*.sysファイルを手作業で削除する、というものだった。デルタはこれを4万台のサーバーにわたって行った。復旧には5日を要した。

問題は決して一つのベンダーのことではなかった

分かりやすい筋書きは、CrowdStrikeが不注意だった、というものだ。だがそれは同時に誤った教訓でもあり、それを追い求めていたら、私は間違った製品を作ることになっていただろう。

なぜなら、このパターンはCrowdStrikeに固有のものではないからだ。どんな大企業のエンドポイント台帳を開いても、カーネルレベルで、あるいは昇格された権限で動作する8つから12のエージェントが見つかるだろう——EDRエージェント、データ損失防止（DLP）エージェント、暗号化エージェント、パッチ適用エージェント、VPNクライアント、デバイス管理エージェント。スプレッドシート上の8行、そしてそれは、8つの別々のアップデートチャネルであり、それぞれが独自のスケジュールで配信し、それぞれが素通りで通過させられている。

その夏、私はCISOたちに同じ質問を繰り返した——これらのベンダーのアップデートを、本番環境に到達する前にレビューするのは誰なのか、と。その答えは、毎回、こんな類のものだった——「我々には変更諮問委員会（CAB）がある」。そして一拍おいて、正直な部分が続く——変更諮問委員会は社内のデプロイメントを一行ずつレビューするが、ベンダーのアップデートはチケットキューを飛ばし、ステージングを飛ばし、すべてのエンドポイントへ直行する——「ベンダーを信頼しているから」だ。その一言は業界全体を支える大黒柱でありながら、その裏には何の仕組みもなかったのである。

ほとんど誰も語らない第二の障害モードがあり、そちらは診断がさらに厄介だ。2つのベンダーが同じ日にカーネルインターフェースを更新すると、それらのドライバーが競合し、単一ベンダーのバグとまったく同じブルースクリーンを引き起こしうる。ただし今度は、根本原因分析に数時間ではなく数週間かかる。なぜなら、それぞれが当然のように相手を非難する2つのベンダーサポートチームの間で、三角測量をすることになるからだ。

私たちが最初に作ったバージョンと、それがなぜ失敗したか

始めたとき、私は答えは検知だと確信していた。エンドポイントを監視し、正常な状態がどのようなものかを学習し、アップデートが異常な挙動を始めた瞬間に警報を鳴らす。それは、オブザーバビリティ市場全体が私たちに植え付けてきた本能だ——Datadog、Dynatrace、Splunk、いずれも、たった今何が起きたかを教えることにかけては見事だ。

私たちはそのバージョンを構築した。そして、アップデートに起因する障害の再現に対してそれを走らせた。すると、それは可能な限り最も役に立たない形で機能した——問題を見事に捉えたのだ、後になって、最初のマシンがすでに落ちてしまってから。

この事実が腑に落ちた電話を、私は覚えている。あるパイロット導入先のCISOは、シミュレートした不良ロールアウトの数秒後にダッシュボードが点灯するのを見て、おおよそこう言った——すでに火事になっていることを、より速く知る手段など要らない、と。彼が必要としていたのは、そもそもアップデートがすべてのエンドポイントに一斉に到達しないことだった。90分で850万台のマシンを襲う障害に対して、デプロイ後の検知とは、家が焼け落ちてから鳴る火災報知器なのだ。

オブザーバビリティは、建物が燃えていることを教えてくれる。だがその頃には、残された唯一の問いは、再建に何日かかるかということだけだ。

その月、私は密かにこの取り組みを間違ったレイヤーに賭けてしまっていた。そして、そのダッシュボードがそれを証明するのを見たことは、私たちに起きた最も有益な出来事だった。問題は決して検知の速度ではなかった。問題は、チェックポイントが存在しなかったことだ——事前に、アップデートが到着する、その前の段階に。

では、なぜ既存のツールはこれを捉えられないのか？

人々は、ソフトウェアサプライチェーンのセキュリティがすでにこれをカバーしていると思い込んでいる。だが、そうではない。そして、その理由は明確だ。

SBOMやソフトウェア構成分析（SCA）ツール——SnykやSonatype——は、あなたのオープンソースの依存関係ツリーを監査する。それらは、3階層深いところにあるあるnpmパッケージに既知の脆弱性がある、と教えるために作られている。しかし、ベンダーのRapid Response Content、チャネルファイル、CrowdStrikeやその同業他社によって署名され配布された独自の設定ブロブ——それらは、これらのツールには見えない。それはあなたの依存関係ツリーには存在しない。それは配布される——迂回してそれを、カーネルへと直接。あなたのソフトウェアサプライチェーンを守るはずのツールは、まったく見当違いの層を監査しているのだ。

ITILやあなたの変更諮問委員会は？手続き的なものだ。それらは、あなたが自ら起こす変更のために設計されたチェックリストと承認であり、ベンダーのリリース周期と連動するようには決して作られていなかった。

そして、CrowdStrike自身の是正策——自己回復モード、コンテンツのピン留め、段階的な「顧客デプロイメント制御」、CISAから借用した「Resilient-by-Design」フレームワーク——は本物の取り組みであり、私はそれを軽視しない。しかし、それが実際に何であるかを読んでほしい——それらの制御の一つひとつは、ベンダーによる自己取り締まりなのだ。第21のフィールドを出荷したのと同じ会社が、今はそれが安全だと証明している当事者なのである。ベンダーのプッシュとあなたのエンドポイントの間に立つ独立した第三者は、依然として存在しない。CrowdStrikeの総維持率は障害の翌四半期に97%を超えており、それは市場が彼らを罰しなかったことを物語る——そして、根底にあるギャップが埋まったかどうかについては、何も物語らない。埋まっていないのだ。

そのギャップこそが、製品のすべてだ。立つべき正しい場所は、火事を見張るエンドポイント上ではないし、彼らの言葉を信じるベンダーの内側でもない。それは両者の間にある——ベンダーに中立なチェックポイントであり、それはアップデートを受け取る、先んじてそれが本番環境に到達するよりも前に。そして、あなたの実際のフリートを再現したサンドボックスでそれを実行し、その内容をあなたのカーネルが実際に期待しているものと照合し、もし誤っていた場合の影響範囲をモデル化する。それこそが、私たちが最終的に構築したレイヤーであり、その形は次で見ることができる——私たちのソリューションページで。21対20フィールドのバグのようなスキーマの不一致は、まさに、デプロイ前のサンドボックスが、850万台のマシンで一斉にではなく、カナリアリング内で浮かび上がらせる類のものだ。

法的な地盤は動いた。そして、ほとんどの契約はそれに追いついていない

しばらくの間、私は規制の側面を背景雑音のように扱っていた。それは間違いで、その理由を買い手たちが教えてくれた——彼らの引き出しにある契約は、もはや彼らが思っているようには彼らを守ってくれない、ということだ。

デルタ対CrowdStrike訴訟から始めよう。2025年5月、フルトン郡上級裁判所で、エラービー判事は、重過失、コンピュータ不法侵入、そして不作為による詐欺の請求について、審理の続行を認めた——超えて、CrowdStrikeの契約上の責任上限を。コンピュータ不法侵入の部分は、すべてのCISOが姿勢を正すべきものだ——デルタは自動アップデートをオプトアウトしていたのに、チャネルファイルはそれでもカーネルに到達した。あなたの設定が支配しないチャネルを通じて、ベンダーがRing 0のコンテンツをプッシュできるのなら、あなたの契約におけるアップデートの設定は、法的強制力を持たないかもしれない。ほとんどの企業向けMSA（基本サービス契約）は、完全なセンサーアップデートとRapid Response Contentすら区別していない。区別すべきなのだ。

次に、EUが動いた。そしてこれは、私が今、同席するあらゆる契約再交渉で持ち出す部分だ。改正された製造物責任指令は、厳格責任の下でソフトウェアを明確に「製品」として分類し、企業はできない——ソフトウェアおよびサイバーセキュリティの欠陥に対する責任を、契約によって除外することは、と定めている。あなたのベンダーが契約書で丸をつけた数百万ドル台（1桁）の責任上限は、EUの法域では単純に通用しないかもしれない。それと並んで、EUサイバーレジリエンス法（CRA）は、2026年9月11日から脆弱性報告を義務化する——それは24時間の時計であり、決定的に重要なことに、その起算が始まるのは、あなたが認識した時点であって、ベンダーがあなたに通知した時ではない。ベンダーの障害が、瞬く間にあなたの報告義務へと転じ得るのだ。

そして米国では、SECが現在、上場企業に対し、重大なサイバーセキュリティインシデントを4営業日以内に開示し、10-K報告書の中でソフトウェアサプライチェーンのリスクを記述することを義務付けている。コストデータで計算してみよう——2025年9月のNew Relicの調査は、重大なITダウンタイムのコストの中央値を、1時間あたり200万ドルと算出した。そして、中堅から大企業の41%は、自社の数字を1時間あたり100万ドルから500万ドルの間としている。あなたの変更委員会が一度も目にしなかったベンダーのアップデートに起因する4時間の障害は、それだけで重要性の基準値を超える。あなたのIR（投資家向け広報）チームには、単なる情報漏洩対応の手順書ではなく、ベンダー障害対応の手順書が必要なのだ。

あなたの側の誰もレビューしなかったアップデートに起因する4時間の障害は、中央値でおよそ800万ドルに達する——それは、CISOではなくCFOの机の上に届く類の数字だ。

「これは我々にも起こり得るのか？」

2024年7月以降、世界中のあらゆる取締役会が、自社のCISOに同じ問いを投げかけた。そして、私が話を聞いたCISOたちの多くは、体系立った答えを持っていなかった——これは彼らへの非難ではない。2026年初頭のIANS Researchのデータによれば、自社のCISOのセキュリティ報告を「非常に効果的」だと考える取締役はわずか29%であり、アップデート展開のリスクは、まさに、現実的で、コストがかかり、そしてほとんどのチームが持つツールでは数値化することがほぼ不可能な類のものなのだ。

それが、私たちが構築したものの、より地味なもう半分だ。単なる技術的なチェックポイントではなく、「これは我々にも起こり得るのか」という問いを、取締役会に提示できる答えへと変えるものである——すべての特権エージェントとそのアップデートチャネルの台帳、ベンダーごとに定量化された影響範囲モデル、どのアップデートがサンドボックスにかけられ、そこで何をしたかの記録。それは、かつて「我々はベンダーを信頼している」と書かれていたスライドを、その裏付けを示すスライドへと変えるのだ。

Microsoftがセキュリティベンダーをカーネルの外へ追い出そうとしている今、これが本当に必要なのかと私は尋ねられる——Quick Machine Recoveryを備えたWindows Resiliency Initiativeと、エンドポイントセキュリティをカーネルモードからユーザーモードへ段階的に移行する動きだ。それは真に優れた構造的転換であり、時間をかけて最悪の影響範囲を縮小していくだろう。しかし、その工程表は2026年と2027年にまたがっており、あなたはその全期間を、移行途中の混在フリートを運用しながら過ごすことになる。そして「壊滅的でない」は「検証済み」ではない。不良な設定を配布するユーザーモードのエージェントは、それでも自らが担当するものをダウンさせ得る。独立した検査の必要性は、カーネルが消えても消えはしない——それはただ、一つ上の層へと移るだけだ。

人々が言うもう一つのことは、チェックポイントを追加するとすべてが遅くなる——Rapid Response Contentの本来の眼目は、現に活動している脅威に対する速度なのだ、というものだ。もっともな指摘だ。しかし、選択肢は決して速度か安全かではなかった。CrowdStrikeのクラウドバリデーターは高速に動作したにもかかわらず、それでも壊れたアップデートを承認した。なぜなら、それはファイルを新しいスキーマに照らして検査したものの、カーネルが同意しているかは一度も確認しなかったからだ。失敗は速度ではなかった。独立した検査が存在しなかったことこそが失敗だったのだ。スキーマの不一致を30台のマシンで捉えるカナリアリングにかかるのは、数分だ。その代替となった選択肢は、デルタに5日間と5億5,000万ドルを費やさせた。

あの青い案内板は、実際のところ何を意味していたのか？

私は、友人が送ってきたあの出発案内板の写真に、繰り返し立ち返ってしまう。ある朝の間、すべての企業がその内側で生きている抽象概念——信頼するベンダーたちが我々を守ってくれる——が、文字通りの青一色で、パネルまたパネルへと、足止めされた人々であふれる建物の中で、描き出されたのだ。

ベンダーたちが失敗したのは、無謀だったからではない。彼らが失敗したのは、私たちが集団として、単一の供給元からの単一の設定ファイルが、誰一人としてその計算を確認する独立した当事者もないまま、すべてのエンドポイントへ一斉に到達し得る業界を築いてしまったからだ。CrowdStrikeは、たまたまその番が回ってきた者にすぎない。それを起こり得るものにした構造は、まさに今、あなたが名前を挙げられるほぼすべての企業のエンドポイント台帳の中に、そのまま横たわっている——8つから12の特権エージェント、8つから12のチャネル、そしてその間には誰もいない、という構造が。

私たちが構築したチェックポイントの完全なアーキテクチャは、こちらでお読みいただける。しかし、私がCISOに持ち帰ってほしい部分は、どんな製品よりもシンプルだ。次に起こるこの種の障害は、セキュリティインシデントとして名乗りを上げたりはしない。それは、署名され、信頼され、承認された状態で到来する——ちょうど前回がそうだったのと、まったく同じように。結末を変える唯一のものは、プッシュと本番フリートの間に立ち、850万台すべてが一斉にそれを知る前に、アップデートとマシンが依然として一致しているかを確認する、誰かの存在なのだ。