· 

CrowdStrike Falconのブルースクリーン問題から今後の更新管理を再考する

松田 幸裕 記


2024年7月19日、CrowdStrikeの製品が原因で、世界中のWindows環境でブルースクリーンが発生しました。まだ記憶に新しい出来事ですが、「喉元過ぎれば熱さを忘れる」にならないよう、この出来事から学びを得て次につなげたいですよね。本投稿では私の観点で、この出来事からの学びを整理してみたいと思います。

ブルースクリーン発生の原因

多くの記事で取り上げられているため、ここでは軽い説明に留めます。ブルースクリーンを引き起こしたのは、CrowdStrike社のEDR(Endpoint Detection and Response)製品である「CrowdStrike Falcon」です。この製品のアップデートによってこの製品自体の不具合が発生し、Windowsの動作にも影響を与えてしまい、Windowsも動作できなくなって停止してしまった、という流れになります。

1つのアプリによってWindowsの動作に影響を与える理由

Windowsには「カーネルモード」と「ユーザーモード」という領域があります。簡単に説明すると、カーネルモードはWindowsのコア機能やドライバーなどが動作する領域で、ユーザーモードは一般的なアプリケーションが動作する領域です。

ユーザーモードではアプリケーションごとにメモリの領域が分離されているため、お互いの領域を干渉することはできないようになっています。例えばExcelが不具合で誤動作をしても、それが「メモ帳」アプリに何か影響を与えるということは基本的にありません。

しかし、カーネルモードでは各モジュールが同じ領域内で動作しています。カーネルモード内でお行儀の悪いモジュールがあると、それが別のモジュールのメモリ領域を破壊する可能性もあり、場合によってはWindowsの動作にも支障をきたします。ウイルス対策ソフトなどセキュリティ製品はディスクの読み書きやネットワークの送受信を監視する都合上、一部のモジュールはカーネルモードで動作する必要があります。Falconにもカーネルモードで動作するモジュールが存在し、そのモジュールが今回の障害を引き起こしたということになります。

超余談になりますが、20年以上前にある洋服屋さんで店員さんと雑談していた時、私がIT屋だと知ったその店員さんから「うちのWindows PCがよく落ちるんだけど、なんでかな?」と相談されたことがあったのを思い出しました。私からは「Windows 95や98は、各アプリが同じ領域を共有していて、1個のアプリがお行儀の悪い行動をとると、それが全体に影響してしまうんです。新しく出たWindows XPはそこが大きく改善されていますよ。」と説明したのを覚えています。昔と比べればずいぶんと改善されていますが、このカーネルモード内での問題はなかなか改善が難しいですね…。

Microsoft社からのベストプラクティスの提示

今回の問題を受けて、Microsoft社から以下のブログが公開されました。

Windows resiliency: Best practices and the path forward

この中で、「組織のレジリエンスをサポートするためのベスト プラクティス」としていくつかの対策が提示されています。本投稿ではこれらすべてには触れないため、興味がある方はぜひ本文の方をお読みいただきたいですが、ここでは1つだけ、「展開リングの利用」について触れたいと思います。

展開リングとは?

展開リング(更新リングともいう)とは、「情報システム部のPC」、「基幹系業務以外のPC」、「基幹系業務用のPC」などにグループ化し、影響の少ないグループから段階的に更新プログラムを展開していくことで、何か不具合があった際の業務影響を最小化するというやり方です。例えばWindowsやOfficeにおける最近の更新プログラム展開機能では、グループさえ定義すればあとは自動的にこの展開リング通りに段階的な展開をしてくれるようになっています。

セキュリティ製品の更新は盲点だった?

中堅企業や大企業ではやり方はいろいろあれど、この展開リングに似たようなやり方でWindowsやOfficeの更新を展開していると思います。例えばWSUS(Windows Server Update Services)を用いて、更新プログラムが公開されて1~2週間後にまずは情シス部門のPCへ展開し、続いてこの部門のPCへ…など、毎月のように順序立てて丁寧かつ段階的に更新プログラムを展開しているのではないでしょうか。

しかし、ウイルス対策ソフトなどについてはどうでしょうか。基幹系業務システムの端末でもこの展開リングの考え方は用いられておらず、製品における既定の設定に従って自動的かつ即時に適用されている場合が多いと思います。

今回のFalconの問題では、厳密にはカーネルモードのモジュールのアップデートではなく、カーネルモードで動作するモジュールが参照するコンテンツのアップデートによって、モジュールが誤動作してしまったようです。そのため今回の問題がこの展開リングの考え方によって確実に回避できるかは微妙なところですが、この考え方自体、多くの場合効果はあると思っています。

ちなみに、CrowdStrike社からは今回のようなコンテンツの更新においても段階的な展開をしていくという発表がなされているようです。

インシデント事後のプレレビュー(PIR)

WSUSの非推奨化をきっかけに再考を

先月、WSUSが非推奨になることがMicrosoft社より発表されました。

Windows Server Update Services (WSUS) deprecation

非推奨になったと言っても機能が無くなるわけでもなく、サポートが終了するわけでもないため、まだ当分は利用を継続することができますが、WSUSを利用してきた企業は今後について少しずつでも考えていく必要があると思います。これを機に、WindowsやOfficeのみでなく、各アプリケーションの更新管理について全体的に見直しを行うのもありかもしれませんね。