Taniumのチーフ・セキュリティ・アーキテクトであるライアン・カザンシヤン氏は、WannaCryランサムウェア攻撃の発生後、世界中の数十社の企業における内部対応プロセスを目の当たりにしてきました。 彼が得た最大の気づきは？ 単なる怠慢ではなく、組織に根付いた変化への抵抗こそが、これほど多くの企業が脆弱な状態に置かれてしまった最大の理由の一つです。 その対策としては、次のような方法があります。
(Image: Arek Socha / Pixabay)
WannaCryランサムウェア攻撃を受けて、責任のなすり合いが拡大していく様子を見ていると、被害者がなぜ、すぐに利用できる対策の導入をこれほど遅らせてしまったのか、疑問に思うのも当然のことです。 この感染拡大を防ぐことができたはずのパッチは、2か月前から利用可能でした。 このマルウェアは、4年前に非推奨となっていたWindowsの機能を悪用しました。 見過ごされがちなのは、単なる怠慢ではなく、組織的な変化への抵抗こそが、これほど多くの企業が脆弱な状態に置かれてしまった最大の理由の一つであるということです。
この1週間、WannaCryランサムウェア攻撃を受けて、世界中の数十社の企業における内部対応プロセスの一部を垣間見る機会がありました。 私は、認識と現実の間に、あまりにも頻繁に生じる乖離を目にしました。
まず、最も顕著な認識のズレから見ていきましょう。多くの組織は、自社のシステムの大半にはパッチが適用されているという前提の下で運用していました。 ところが、彼らは自社のコンピュータ群のうち、この脆弱性の影響を受けやすいコンピュータの割合が2桁に達していることを発見しました。 他の関係者には、システムが再起動されたかどうか、あるいはその他のリスク軽減のための設定変更が実施されたか、あるいはその変更が有効になったかどうかを確認する手段がありませんでした。 また、修正を「実行」することに躊躇している人もいました。それは、予期せぬ影響を迅速に検知できるかどうか、あるいは必要に応じて変更を元に戻せるかどうか、確信が持てなかったからです。
このような状況は、WannaCry攻撃に限ったことではありません。 Even as annual worldwide IT security approaches $100 billion in 2017, businesses continue to struggle with basic systems management tasks, like patching, which are critical to so-called security hygiene. なぜそうなるのかを理解するためには、まず、ほとんどのIT組織がどのように運営されているかを検討する必要があります。
この10年間、ソフトウェア開発者たちはDevOpsの動きや、いわゆるアジャイル手法を取り入れてきました。 これらのアプローチでは、企業におけるソリューションの反復的かつ迅速な開発、テスト、および提供を重視しています。 しかし、ITやセキュリティ運用の多くの分野において、エンジニアリングや変更管理のプロセスは依然として比較的旧態依然としたままであり、進化することに頑なに抵抗し続けています。 これは、哲学の対立と言えます。すなわち、迅速で段階的かつ自動化された変化と、系統的で綿密に計画・検証された大局的なアプローチとの対立です。
WannaCryは、組織にとって深刻な問題を引き起こしています
ITおよびセキュリティ運用部門が変化に抵抗を示すのには、非常に現実的で実用的な理由があります。 ITインフラの多くは、レガシー技術と最新技術がごちゃ混ぜになったもので、長年にわたり何とか機能するようにその場しのぎで組み合わされてきました。 Frost & Sullivanの調査（）によると、平均的な組織では、エンドポイント上で4～6種類のオペレーティングシステムを、サーバー上で4～7種類の異なるオペレーティングシステムを稼働させているとのことです。 これらのプラットフォーム上では、OSレベルの変更に対して、あるものは他のものよりも敏感であるものの、何百もの業務に不可欠なアプリケーションが実行されている可能性があります。 また、こうしたインフラ全体を管理する運用上の責任は、多くの場合、部門間の壁が極めて高く、エンドユーザー向けコンピューティング、サーバー管理、アプリケーションの監視といった業務が、必ずしも同じペースで動いているとは限らない多数のチームに分担されています。 請負業者や外部委託先を巻き込むと、事態はさらに複雑になります。 また、どの個人やチームも、自分たちのパッチ適用作業が原因で重要なシステムがダウンしてしまうような事態は避けたいと考えています。
ビジネス上の要件としてシステムの可用性を絶えず確保することが求められる場合、企業が特定の種類のIT変更に対して慎重な姿勢をとる理由は容易に理解できます。 そして、公平を期すならば、現代の変更管理プロセスには、いずれも緊急事態に対処するための規定が設けられています。 しかし、WannaCry事件の緊急性から変更を加える柔軟性が求められたにもかかわらず、多くの組織では、セキュリティ運用やシステム管理の技術的な制約に縛られたままでした。 これは悪循環を示しています。すなわち、大規模な変化を確実かつ迅速に実現し、その成果を監視するための技術的能力が欠如していると、人々はより多くの審議や手続き、合意形成という形で「足かせ」を加えてしまうのです。 これにより、企業の機動性がさらに損なわれ、投資してきたソリューションの有効性が制限されてしまいます。
残念ながら、WannaCryの拡散を食い止めることができたはずのパッチには、その普及を遅らせるのに「絶妙な」組み合わせの特性がありました：
- この問題はWindowsのほぼすべてのバージョンに影響を及ぼしたため、テストが必要なシステムの役割や種類が増えました。
- 再起動が必要でした（すべてのパッチがそうであるわけではありませんが）、業務への影響を最小限に抑えるため、スケジュールの調整が必要となりました。
- 当初、Windows XPおよびServer 2003 向けのリリースは、WannaCryの感染拡大が起きてから行われました。 どちらのオペレーティングシステムもサポート終了となっていますが、依然として多くの環境で使用されています。 その数は減少傾向にあります――例えば、NHSの報告によると、管理対象ホストのうちXPを実行していたのは約 5％にとどまりました――が、そうしたシステムは、重要なレガシー機器の運用を支えるためにしばしば利用されています。
こうした技術的・手続き上の障壁を背景に、WannaCryが、とりわけ医療業界などの特定分野において、これほど壊滅的な影響を与えたことは驚くことではありません。
恐ろしいことに、WannaCryによる被害は、もっと、もっと甚大なものになり得たのです。 この記事の執筆時点で、このマルウェアによる感染は「わずか」数十万台のシステムにとどまっています。 In contrast, Conficker (which exploited a similarly widespread Windows vulnerability in 2008) spread to over 10 million computers. 多くの組織は、単に運が良かっただけで、初期の攻撃キャンペーンの標的から逃れることができました。 とはいえ、 2017 ではITシステムへの依存度が高いため、今回の攻撃の影響は、これまでの他の攻撃に比べてはるかに深刻に感じられました。
ITのリーダーたちは、単に攻撃の検知や対応の改善に注力するだけでなく、この機会を捉えて、システム管理やセキュリティ運用を支えるプロセスやテクノロジーの近代化を推進する必要があります。 将来、攻撃が必然的に第一線の防御を突破したとしても、セキュリティ衛生管理に対する機敏な取り組みにより、小規模で散発的な感染が次の世界的な大流行へと発展するのを防ぐことができます。
著者について：Taniumのチーフ・セキュリティ・アーキテクトを務めるライアン・カザンシヤン氏は、インシデント対応、フォレンジック分析、およびペネトレーションテストの分野で、 14 年以上にわたる豊富な経験を有しています。 ライアン氏は、Taniumの脅威対応ソリューションの設計とロードマップを統括するとともに、Taniumのエンドポイント検出・対応（EDR）チームを率いています。 Taniumに入社する前、ライアン氏はMandiantにおいて、標的型攻撃の被害を受けたフォーチュン 500 にランクインする数十社の企業と連携し、調査および対策業務を統括していました。 ライアン氏は、Black HatやFBIのサイバー対策チームのインストラクターとして、数百人のインシデント対応担当者を育成してきました。 同氏は、『Incident Response and Computer Forensics 第3版』（McGraw-Hill、 2014）の寄稿者の一人です。 また、ライアン氏はテレビシリーズ『Mr. Robot』の技術コンサルタントも務めており、脚本家や制作チームと協力して、劇中で描かれるハッキングの手法を考案しています。
