世界同時障害に発展したCrowdStrike事件とは何だったのか？企業ができる予防措置とは
Windowsは世界で10億台を超えるPCで運用されている、IT時代における社会インフラとも言えるOSです。クラウドサービスの登場やインターネットの普及と高速化により、ユーザー間の結びつきは強固なものとなっていきました。
しかし、このようなOSにおいて障害が発生し、全世界でシステムが停止した際にはどのような事態が起きるのでしょうか。
2024年7月、CrowdStrikeに起因する障害の発生は、まさに懸念していた問題が現実となったものでした。世界同時多発的な障害が発生した原因、そしてその被害の全容はどのようなものだったのかを知ることは、今後ますます増加するインシデントリスクへの対処方法を把握する上で、非常に重要です。
また、CrowdStrike障害のような大規模なインシデントの発生は、今後も度々発生する可能性があると考えておかなければなりません。改めて今回の事件の全容について確認し、有効な防止策についての知見を深めておきましょう。
世界的なWindows障害「CrowdStrike事件」のあらまし
新型コロナウイルスの感染拡大から終結に至るまでのここ4年ほどで、過去最悪とも言える大規模インシデントを招いたCrowdStrikeは、そもそもどのような企業なのでしょうか。
世界有数のセキュリティ企業「CrowdStrike」
CrowdStrikeは、2012年に設立されたセキュリティソフトのベンダー企業です。アメリカのテキサス州に本社を構え、その売り上げは年間30億ドルにのぼる、世界有数のIT企業として知られています。
アメリカをはじめ、世界各国の大規模なインシデント調査に関与してきたことから、セキュリティ業界では高い知名度を有していたCrowdStrike。「Falcon」という名前のエンドポイントセキュリティサービスを世界各国の企業に提供し、高いシェアを誇っていたことでも有名です。
そして、今回の事件を引き起こした黒幕とも言えるソフトもまた、このFalconであったことが後ほど判明します。2024年7月19日、欧米をはじめ、日本を含めたアジアなど全世界で原因不明のBSOD、いわゆる「死のブルースクリーン」が一斉に表示され、企業は大混乱に陥りました。
Falconのアップデートが招いた「ブルースクリーン」
世界中のWindowsでブルースクリーンエラーを招いたこの事件では、システム障害がWindowsのマシンに限定されていたことから、当初はMicrosoft側に問題があると考えられていました。
しかし調査を進めるにつれ、明らかになったのがCrowdStrike社のソフト「Falcon」の存在です。被害が確認されたのは、Falconの最新アップデートが適用された際にオンラインだった端末で、CrowdStrikeによる早急な修正パッチの適用が行われました。
Falconの最新アップデートには、脅威を確認した際の対処動作を定義するテンプレートインスタンスに関する重大エラーが見過ごされた上で含まれていたのです。これが原因でパッチを適用したマシン上で、正常な起動が阻害され、ブルースクリーンに至ったのでした。
当初はサイバー攻撃も疑われた今回の事件でしたが、蓋を開けてみれば配信前の不十分な検証に起因する、セキュリティベンダーの過失による大規模インシデントだったのが顛末です。
Windowsベースのクラウドサービスにも障害が発生
Falconのアップデートを原因とする今回の障害は、Windowsを導入しているPCのみならず、Windowsベースで動作しているクラウドサーバーにも被害をもたらしています。
Widowsベースのクラウドには「Microsoft Azure」や「AWS（Amazon Web Services）」と、有名なサービスが揃っています。Falconのアップデートにより、これらサービスのサーバーもPCと同様に被害を被り、手動での復旧作業が強いられました。
クラウドサービスの利用は、自社でセキュリティ対策に取り組む負担を減らし、GAFAM基準の高度なセキュリティ環境を採用できるという点が評価されている施策です。
しかし、今回のようにOSそのものでインシデントが発生した場合、強固なインシデント対策環境が整えられていても、一定の損失を被るのは免れないことがわかりました。
復旧に向けたCrowdStrikeの対応
Falconに起因する今回の大規模障害は、具体的には事件の発覚後から1時間半弱続きました。アップデートの取り下げと復旧ツールの公開、そして復旧に向けた最大限のサポートをMicroasoftとCrowdStrikeが共同で提供し、事態の収拾に向けて迅速に動いていたということです。
ここで問題となったのが、復旧を自動で行うのには限界があった点です。被害を受けた、アップグレード完了後のマシンは同社からの修正パッチの配布で対処することができず、被害を受けた企業が手動で修復を行うことを求められました。
CrowdStrikeは自己修復の手順をYouTube上で公開しました。しかし、被害者が一台一台マシンを復旧しなければならない負担は看過できるものではなく、企業に多くの損失をもたらす結果となっています。
50億ドル以上の損失をもたらしたCrowdStrike事件
障害の発生からその復旧に至るまで、企業に甚大な被害を与えたCrowdStrike事件は、予想される損失額も無視できないものとなっている可能性があります。
今回のインシデントによって、被害を受けたとみられるWindowsマシンは850万台にのぼると試算されています。この数は全体の1%に満たないと言われていますが、問題なのは各社で発生した損失金額です。
インシデントの発生によりシステムが停止したのは1時間程度のものですが、完全な復旧には手動操作が必要であり、その間失われた損失は途方もない金額になっていると言われます。
この事件の経済的損失はおよそ50億ドル、日本円にして7,500億円以上とされ、各社のサービスを享受しているエンドユーザーの損失も踏まえると、さらに大きなものとなることも考えられるでしょう。
公共サービス関連で深刻な被害。二次被害の報告も
CrowdStrikeの障害発生により、特に深刻な被害を受けたのが公共サービス関連企業です。航空業界ではフライトシステムの機能停止に伴い、各地で運休が発生し、多大な損失をもたらしました。
また、金融機関や医療機関、小売サービスを提供する企業など、多くの組織のシステムはWIndowsをベースに構成されているため、いずれも少なからず損失を被ったと見られます。
もう一つ恐ろしい問題として挙げられるのが、障害発生を被った企業に対してのマルウェア感染による二次被害の発生です。
CrowdStrikeの障害に乗じて、修正パッチを標榜するマルウェアを各社に配信し、サイバー攻撃を行う試みが世界で確認されています。
マルウェアが含まれていると見られるファイルには「bsod」や「microsoft」といった、今回の事件に関連するキーワードが盛り込まれており、パニックになっており正常な判断ができなくなっている現場を見越した攻撃であることは明白です。
世界的なインシデントが発生した場合、この騒ぎに乗じたサイバー攻撃の試みが拡大することも、今回の事件から企業のセキュリティ担当者は改めて認識すべきでしょう。
「もう起きない」とは限らない。14年前に発生していた類似のインシデント
企業のミスに起因する重大インシデントとしては、ここ10年で最悪レベルのケースとなったCrowdStrike事件。このような世界的な障害の発生は、DX時代ならではのものと考える人は少なくありませんが、実は今から14年前にも似たような事件が、CrowdStrikeの関係者の管轄のもと発生していることも知っておかなければなりません。
2010年、大手セキュリティソフトのMcAfeeはアップデート内容の不備が原因で、同ソフトを導入している企業のシステム上で再起動ループを引き起こし、システムダウンを招きました。
この事件においてもCrowdStrike同様、修正パッチの適用では完全な復旧が見込めず、エンドユーザーは手動での復旧作業を強いられ、事業に多大な損失をもたらすことになったのです。システム運用経験の長い担当者の方には、当時のことをよく覚えている方も多いかもしれません。
世界中の公的機関や大手企業で多大な損失をもたらした、McAfee障害発生時に同社の最高技術責任者であった人物は、CrowdStrikeの創設者であるGeorge Kurtz氏でした。大規模な障害がほぼ同じ原因で、そして同じ責任者のもとで発生したことは、偶然とは言い難いでしょう。
どれだけ知名度や実績があるサービスであっても、それを運営しているのが人間である以上、人に起因するリスクをゼロにすることはできないことを示す事件です。
今後一層大規模なインシデントが発生する可能性も視野に
2024年に発生したCrowdStrike事件は、社会のデジタル化・クラウド化が進んだことにより、2010年当時よりもさらに被害は大きなものとなったことは、合わせて覚えておくべきです。
DXに伴い、企業の業務デジタル化は今後もさらに進んでいくことが予想されます。生産性向上や新しいビジネスの創出は喜ばしいことですが、今回のようなインシデントが発生した場合、業務の大半が被害を受けてしまう可能性もあることを知っておかなければなりません。
デジタル化による利便性には、相応のリスク管理負担が付きまといますが、かといってアナログ業務への回帰は、著しい競争力の低下を招くでしょう。このジレンマにどう応えるべきかが、今後企業が考えていくべきシステム運用の課題です。
同様のリスクを被らないためのBCP対策を
CrowdStrike事件は、サービスを利用しているユーザーにとって一切の非がない、ベンダーの過失によって起こった重大インシデントです。
しかし責任の所在が明らかであるからといって、それで問題が解決するわけではありません。誰の責任で発生しても、インシデントによって自社システムの機能が損なわれ、重大な損失が発生したという事実は変わらないからです。
CrowdStrike事件によって発生した損失を、CrowdStrike社に求める集団訴訟はすでにアメリカで始まりつつあります。ただ、14年前に似たような事件が発生し、今回もなす術なく被害を被ってしまったことを踏まえると、想定内のリスクとして企業は同様の問題にこれから備えていくことが大切です。
インシデント対応において重要なのは、いかなる原因の問題に対しても有効な施策を実行できる環境です。サイバー攻撃はもちろん、ベンダー側の障害にも臨機応変に対応して、業務の継続性を確保できるBCP対策が求められています。
BCP対策の基本となるのは、予備端末の配備です。メインで使用しているシステムが障害発生などにより機能しなくなった際、すぐにバックアップシステムに切り替え、損失の発生を抑えられるよう、日頃から備えておくべきでしょう。
これまでBCP対策は、災害の発生に伴う本社サーバーの停止などを見越したバックアップ体制の構築が注目されてきました。しかし近年のサイバー攻撃の増加や、急速に進展するデジタル化の実情を踏まえると、本体システムとは隔離された状態でスタンバイ状態にあるバックアップ体制の構築が重要視されています。
バックアップ体制を構築していたとしても、本体システムと同じネットワークに接続した状態で管理していると、BCP対策を遂行できない可能性があります。サイバー攻撃や障害発生時、バックアップもまとめて被害を受けるリスクがあるからです。
また資産管理システムの導入によって、現在システムを構成している製品のアップデート状況などについて、リアルタイムで把握できることも重要です。社内の脆弱性へ迅速に対処したり、インシデント要因となりうるデバイスやソフトの利用を制限できます。
冗長性の確保も、インシデント発生時の被害抑制において役に立ちます。隔離によって障害発生の範囲を制限しやすくなるからです。
まとめ：「もしも」の事態は明日起きるかもしれない。リスクありきのシステム運用体制の構築は必須
今回のCrowdStrikeの障害発生を予見できていた人はゼロに等しく、正しく「想定外」の事件であったことは間違いありません。ただ、セキュリティベンダーの不手際に起因するインシデントの発生リスクはゼロではないことは、これまでも強く言われてきたことであり、損失を最小限に抑えられる努力は前々からできるものであったのも事実です。
今回の事件ほど大規模なインシデントの発生は、そうそうおこることではありません。現に14年前に同様の事件が発生し、今回のインシデントに繋がっていることから、近い将来、同様の事件が起きると考えておくべきでしょう。
また、ベンダーに起因する事件だからといって、自社で何も対応しなくて良いというわけではありません。責任の所在はベンダーにあるかもしれませんが、実際に損失を被るのは私たちであり、その損失を避けるための努力は必ず行うことが大切です。
今回の事件では、日本円にして数千億円規模の損失をもたらしたとされています。デジタル化が今後も普及していくことを考えると、次に起こる事件はさらに規模の大きいものとなることが懸念され、やはり早急な予防策の検討が重要です。
インシデントはいつどこで、どのように発生するかを予見するのは困難です。あらゆるリスクにも柔軟に対応できるよう、例え安全性に優れる仕組みを整備できている場合でも、改めてリスクシナリオを見直しておくことをおすすめします。
この記事をシェア
