INDUSTRIES

重要な"Patch Tuesday"にSplunkを活用

2020年1月14日、Microsoft社は、今年最初の「Patch Tuesday」にMicrosoft Windowsクライアントおよびサーバーのオペレーティングシステムの重大な脆弱性に対するパッチをリリースしました。

これらの脆弱性の対応がどれだけ重大であるかを強調するために、DHSサイバーセキュリティおよびインフラストラクチャセキュリティ庁(CISA)は、2度目となる緊急指令を公開しました。また、国家安全保障局(NSA)は補足的なガイダンスを提供するサイバーセキュリティアドバイザリとプレスリリースを発表しました。どちらも、技術的なガイダンスと影響を軽減するためのアクションが明確かつ実行可能な形で記されています。皆さまの企業でも、これらの資料で重要とされているガイダンスを速やかに確認することをお勧めします。

Splunkをデータプラットフォームとして活用していただいている組織をサポートするために、私は今朝から昼すぎにかけて、この問題に対応するSplunkダッシュボードのプロトタイプといくつかのSPLを作成しました。この脆弱性の検出にあたり、この記事が自社環境の見直しをすぐに始めようとしている皆さまのお役に立てば幸いです。

以下に詳しくご説明します。

脆弱性スキャンの結果を評価する

SPLを作成するために、私はまず脆弱性スキャンデータから取りかかりました。というのも、これらのデータがすでに手元にあり、正直に言えばSplunkならデータからCVEを検索し、関連するホストを見つけるのは簡単だったからです。このブログをいつもご覧いただいている方なら、このアプローチが2019年のBlueKeepに関する記事と似ていることにお気づきになるでしょう。

この最初の行は、「脆弱性データモデルからCVE、Microsoft KB、およびホストを検知すること」を指示しています。BlueKeepのプロトタイプのときと同様、豊富な知識を持つSplunkユーザーから、効率的に検索するには最初のtstatsサーチでCVE-2020-0601を明示するべきだとすぐに指摘されるでしょう。まさにその通りなのですが、私のサンプルデータにはこのCVEが含まれていなかったため、作成したSPLのテストを簡単に行えるよう「Vulnerabilities.cve=*」を残しました。

CVE-2020-0601または関連するMicrosoft KB (4528760、4534271、4534273、4534276、4534293、4534306)の検索を元のクエリーに追加すると、SPLパイプラインが少し長くなりますが、「Vulnerable_Host、CVE、Microsoft_KB」をテーブルヘッダーまたはフィールドとして返し、結果テーブルを構築できるように再フォーマットされた正確な結果が得られます。この2番目のスクリーンショットには結果が表示されていませんが、これはサンプルデータセットに関連するCVEやMS KBが含まれておらず、テーブルが空になったためです。

以下にSPLを貼り付けておきますので、このSPLが必要な方はコピー＆ペーストしてお使いください。

| tstats count from datamodel=Vulnerabilities.Vulnerabilities where Vulnerabilities.cve=* Vulnerabilities.mskb=* by Vulnerabilities.cve Vulnerabilities.mskb Vulnerabilities.dest 
| search Vulnerabilities.cve=cve-2020-0601 OR Vulnerabilities.mskb=4528760 OR Vulnerabilities.mskb=4534271 OR Vulnerabilities.mskb=4534273 OR Vulnerabilities.mskb=4534276 OR Vulnerabilities.mskb=4534293 OR Vulnerabilities.mskb=4534306 
| rename Vulnerabilities.dest as Vulnerable_Host Vulnerabilities.cve as CVE Vulnerabilities.mskb as Microsoft_KB 
| table Vulnerable_Host, CVE, Microsoft_KB

お使いの環境でこのSPLを動作させるための注意事項：

上記の例は、データがSplunk CIM (共通情報モデル)に準拠した形式で取り込まれていることを前提としています。また、最後の2行では前述の内容を記述しています。
脆弱性スキャンデータがSplunkインスタンスに取り込まれている必要があります。
脆弱性スキャンデータには、環境内で実際に特定された、CVE-2020-0601の影響を受けやすいシステムインスタンス、または関連するMS KBやパッチ適用が必要なシステムインスタンス、あるいはその両方が含まれている必要があります。

脆弱性スキャンを実行せずに影響を受けやすいOSを特定する

BlueKeepのプロトタイプと同様に、私は脆弱性スキャンの結果だけに頼りたくはありませんでした。というのも、脆弱なシステムの中には定期的にスキャンされないものがあったり、CVE-2020-0601を探す脆弱性スキャンの実行時にそのシステムがネットワークにつながっていない場合もあるためです。次の基本的なクエリーを使用すると、前述のアドバイザリで特定された影響を受けるOSの名前とサービスパックに該当するシステムを検知できます。

この基本的なサーチでは、「Compute_Inventoryデータモデルを検索し、「Caption」フィールドを持ち、名前の文字列が「Microsoft*」で始まるオペレーティングシステム(OS)を表示する」よう指示しています。これを実行すると、テストするべきシステムが特定されます。

次のステップは、CVE-2020-0601、CISA ED 20-02、およびNSAのアドバイザリで「影響を受ける」と特定されたOSおよびバージョンを明示的に呼び出すための検索文字列を追加することです。下の図では、前の図の基本的なサーチと区別しやすいように、追加したSPLを青色で強調表示しています。

これらのサーチを、いくつかの複数選択ボックスとサーチボックスを備えたダッシュボードに移動することがわかっていたため、evalコマンドを使用して「Caption」フィールドと「Version」フィールドを「os_string」という新しいフィールド(以下の図では青色で強調表示)に統合したあと、_timeを使用してその結果をテーブルに出力しました。

ここで注意していただきたいことがあります。上記のテーブルでWindows 10という結果が繰り返し表示されているのは、使用したWindowsのサンプルデータが非常に限られていたためです。

以下にSPLを貼り付けておきますので、このSPLが必要な方はコピー＆ペーストしてお使いください。若干の変更は必要になるかもしれませんが、このSPLを使えば、脆弱性スキャンデータに依存することなく、すぐに開始できるはずです。

| tstats prestats=1 count from datamodel=Compute_Inventory where All_Inventory.OS.os=Microsoft* AND Caption=* 
| search (Caption="Microsoft Windows Server 2016 *" Version=*) OR (Caption="Microsoft Windows Server 2019 *" Version=*) OR (Caption="Microsoft Windows 10 *" Version=*) OR (Caption="Microsoft Windows 10 *" Version="*1607") OR (Caption="Microsoft Windows 10 *" Version="*1709") OR (Caption="Microsoft Windows 10 *" Version="*1803") OR (Caption="Microsoft Windows 10 *" Version="*1809") OR (Caption="Microsoft Windows 10 *" Version="*1903") OR (Caption="Microsoft Windows 10 *" Version="*1909") OR (Caption="Microsoft Windows Server *" Version=*1803) OR (Caption="Microsoft Windows Server *" Version=*1903) OR (Caption="Microsoft Windows Server *" Version=*1909) OR (Caption="Microsoft Windows Server 2012 *" Version=*)
| eval os_string = Caption+" - "+Version
| search (os_string="*") (host="*")
| stats count by os_string host _time
| table _time, os_string, host

ダッシュボードでさらに簡単に

実際に上記の例のSPLプロトタイプを使用する際に、どうすればより便利になるかを考え、これら2つのクエリーを基本的なダッシュボードに展開し、いくつかの複数選択ボックスと1つのサーチボックスを追加して、継続的な監視を簡単に行えるようにしました。ちなみに、これらはすべて、以前作成したBlueKeepのプロトタイプのものを利用しました。

左側のパネルでは、CVE-2020-0601の影響を受けやすいOSバージョンを検出しています(脆弱性スキャンデータは除く)。右側のパネルには、脆弱性スキャンの結果に基づき、CVE-2020-0601に対して「脆弱である」とフラグ付けされたシステム、またはこのCVEに適用されるMicrosoft KBまたはパッチが必要なシステムが表示されます。

ここで注意していただきたい点は、上の図の右側のパネルを、無関係なKB 3065823を含むよう変更しいることです。これは使用した脆弱性データのサンプルが実際にはCVE-2020-0601に対応していなかったため、結果がダッシュボード上でどのように見えるかを示すためだけに変更しています。下の図は、このCVEと関連するMicrosoft KBだけに限定した、変更していないダッシュボードを示しています。

「No results found」と表示されていますが、これは単にサンプルのデータセットが限られていたためです。残念ながら、最初の脆弱性スキャンの結果がこのように空になる可能性は低いと思われます。

モバイル機器(ラップトップなど)を利用する現在のエンタープライズ環境においてもう1つ残念なのは、脆弱性スキャンが実行されるとき、あるいはパッチが初めて適用されるときに、影響を受けるすべてのシステムがネットワーク上にあるとは限らないため、これらすべてのシステムにパッチを適用するには、ほぼ確実に複数のパッチサイクルが必要になるという点です。

CDMプログラム参加機関

SplunkプラットフォームはCDMのデータ統合レイヤーとして機能します。このブログ記事のサンプルSPLを利用することで、各機関はCDMのデータ統合レイヤーに含まれるハードウェア資産管理(HWAM)、ソフトウェア資産管理(SWAM)、脆弱性管理のデータを調査、監視、分析し、それに基づいて行動を起こすことができます。さらには、自らの機関が、これらの重大な脆弱性による影響をどの程度受けるのかも把握できます。

自動化とオーケストレーションを活用する

オーケストレーション、自動化、およびレスポンス技術を搭載したSplunk Phantomを使用すれば、既存のネットワークアクセスコントロール(NAC)技術を強化して、パッチが適用されたWindowsデバイスだけにネットワークへのアクセスを許可することができます。

NACとCDMの高度な使用例の1つとして、デバイスにネットワークへのアクセスを許可する前に、Splunk Phantomを使用してCDMのデータ統合レイヤーからコンテキスト情報(最後に脆弱性スキャンを実行した日付、オープンな脆弱性、最新のパッチなど)をプロアクティブに取得し、そのデバイスにパッチ適用やスキャンが必要かどうかを判断できます。そのデバイスがスキャンされていない場合、あるいはパッチ適用が必要である場合、Phantomではネットワークへのアクセスを許可する前に、デバイスのスキャンまたはパッチ適用を自動で実行できます。

これで、お使いの環境内でCVE-2020-0601の影響を受けるシステムを検知するという、同じ課題を解決するために別々のアプローチを使用した基本的なSPLが完成しました。CDM、高度なNAC (ネットワークアクセスコントロール)、そしてPhantomについての親切なアドバイスを与えてくれた、友人であり同僚でもあるPatrick Chuに深く感謝します。

繰り返しますが、これはあくまで出発点であり、環境や特定のデータに合わせて若干の変更が必要になる可能性があるということを覚えておいてください。いずれにしても、会社全体で影響を受けるシステムを探しているのであれば、それらを確認するための足がかりとなるはずです。

この記事が皆さまのお役に立てば幸いです。サポートが必要な場合や、上に示したダッシュボードのプロトタイプを希望される場合には、gov_answers@splunk.comまでお気軽にお問い合わせください。

Splunkのメリットをどうぞお試しください。

ライターあとがき：CVE-2020-0601とCISA緊急指令20-02は、当然ながら大きな関心と懸念を生みました。この脆弱性検出の重大さと、CISA緊急指令20-02によって10日以内に報告する義務が課せられている点から、私はすぐにガイダンスを発表しなければならないという緊急性を切実に感じました。そのガイダンスをすぐに発表できるよう、私はこの記事の内容を、(1)OSとバージョンに基づく影響を受けるシステムの検出と、(2)脆弱性スキャンの結果に基づく脆弱なシステムの検出に絞ることにしました。また、これらはすべて、PoCエクスプロイトコードが公開される前に発表しなければなりませんでした。幸いなことに、Splunkの優秀な同僚であるDrew Churchがフォローアップ記事を執筆してくれました。この記事では、Zeek (別名Bro)とエンドポイントログを利用してCVE-2020-0601を悪用しようとする試みを検出するための2つの例が詳しく紹介されています。現在、この脆弱性に対するPoCエクスプロイトコードは複数のバージョンが出回っており、これにはDrewが例として使用したエクスプロイトコードも含まれています。読者の皆さまには、Drewのブログ記事をよくお読みいただき、推奨されている検出方法のいずれか、あるいは両方を運用していただくことをお勧めいたします。

January 15, 2020

Posted by

Anthony Perez

Anthony is Director of Field Technology for Splunk’s public sector headquarters in Mclean, Virginia. Prior to joining Splunk, Anthony spent several years at a global consulting firm where he led the development and execution of novel approaches for aggregating, analyzing, and assessing cyber threats to US interests.

Mr. Perez is a graduate of the Whiting School of Engineering at Johns Hopkins University and holds an M.S. in Information Systems specializing in Security.