metadataとtstatsを使って状況をすばやく把握する
ハンティングに出かけたい？ではさっそく、私の若きパダワンを…いえ、ちょっと待ってください。あるSplunkジェダイがかつて私に教えてくれたように、急がば回れが大切です。つまり、急いで脅威ハンティングを始めてSPLをむやみやたらに実行しても、調査で壁に突き当たる可能性があります。では、壁を避けて通るにはどうすればよいでしょうか？かつて賢者は言いました、「汝のネットワークを知れ」と。要は、まずはネットワークと、この場合はホストについても、よく知っておくということです。
ハンティングを効果的に行うには、ホストについてわかるデータとわからないデータを理解することが大切です。ここを理解していないと、脅威ハンティングで見当違いの仮説を立てて、誤った判断をしてしまう可能性があります。
このブログ記事では、脅威ハンティングを始める際の情報収集で私が使用している方法と、収集したデータを理解するためのmetadataコマンドとtstatsコマンドの使い方をご紹介します。
(この記事は「Splunkで脅威ハンティング」シリーズの一部であり、初稿はDomenico “Mickey” Perreが執筆しましたが、お客様に最大限の価値を提供できるよう、その内容を最近更新しました。)
脅威ハンティングでのmetadataコマンドの使い方
まずはmetadataから見ていきましょう。metadataコマンドは生成系のコマンドであり、サーチの先頭で使用します。
Splunkの内部動作に詳しい方はご存じかと思いますが、データのインデックス時に自動的に書き込まれるフィールドがいくつかあります。以下のフィールドです。
- _time、source (イベントの発生元。ファイルパスまたはプロトコル/ポート値)
- sourcetype (マシンデータのタイプ)
- host (イベントを生成したホスト名またはIPアドレス)
これらのメタデータフィールド(まさに望んでいた情報源)をサーチして、各値について最初の記録日時、最後の記録日時、件数などの情報を調べることができます。例をいくつかご紹介します。
汝のデータを知れ：期間とソースタイプ
最近収集されたデータから問題の兆候を見つけてハンティングを行うように上司に指示されたとしましょう。まず思いつくのは、ハンティングの対象期間内で入手できるデータセットを確認することです。次の簡単なサーチを使って、過去7日間にSplunkで収集されたソースタイプを列挙できます。
図を見ると、過去7日間でFireEyeイベントが5,162件発生していることがわかります。UNIX時間を変換すると、インデクサーがこのデータを最初に受信したのが2017年5月12日2:31:00 GMTで、最後に受信したのが2017年5月20日22:01:12 GMTです。
サーチの対象期間が5月13日22:00 GMTから5月20日22:38:15 GMTであることを考えると、これらのFireEyeデータはまさに現在起こっていることを示しているとほぼ断定できますが、5月12日より前にさかのぼって調査する場合、調査すべきFireEyeデータがないことになるため、このアクティビティをどのようなアプローチで調査すべきかは難しいところです。そもそも、ネットワークで問題が最初に発生したと考える日時を変えるべきなのかもしれません。
汝のデータを知れ：ホスト
Splunkで収集されたデータのタイプがわかったので、次に、そのデータの送信元ホストを調べましょう。すべてのホストから最新データが送られているでしょうか？
ここでは、特定のインデックスにデータを書き込んでいるホストを対象にします。今回のハンティングでは「os」インデックス内のデータが重要だとわかっているため、このインデックスにデータを書き込むすべてのホストを調べます。
metadataコマンドのオプションはあまり多くありませんが、以下の条件でサーチを絞り込むことができます。
- 特定のインデックス
- サーチピアまたはサーバーグループ
- ソースタイプ(前述)
一連の結果が出力されたら、SPLの力を借りて、ここからさらに情報を引き出しましょう。ハンティングを始める前に状況をもう少し詳しく把握したいので、過去24時間でSplunkにデータをまったく送信していないホストを調べます。
このサーチでは、metadataコマンドを使ってホストのリストを取得しています。その後、eval、search、fieldformatの各コマンドを使って、以下の操作を行っています。
- 過去24時間にログをまったく記録していないホストを見つけます。
- 前述の例では日時がわかりづらかったので、今回は値を読みやすい形式に変換します。
- 見やすいようにデータをソートして表に出力します。
metadataコマンドについて最後に補足しておきます。このコマンドを使用するには、あらかじめ、ユーザーのロールにget_metadata機能を関連付けておく必要があります。(おまけ情報：実は、サーチのホームページで[データサマリー]ボタンをクリックしたときに、内部でmetadataコマンドが実行されていることをご存じでしたか？)
では別の話題に移りましょう… (まったく関係ないわけではありませんが)。
脅威ハンティングでのtstatsコマンドの使い方
強力でありながら意外と知られていないもう1つのSplunkコマンドが、tstatsです。tstatsコマンドは、高いビルもひとっ飛び、弾よりも速くサーチ結果を生成してくれます(あくまでイメージですが)。
metadataと同じように、tstatsも生成系のコマンドで、以下のフィールドを扱えます。
- インデックスされたフィールド(host、source、sourcetype、_time)
- データモデル
(私は誰にも負けないくらいデータモデルが好きなのですが、この記事で語るにはスペースが足りないので、ぜひとも別の機会にお話したいと思います。)
話を元に戻しましょう。これまでに確認した情報ではまだ物足りないので、ハンティングを始めるうえで基本的な疑問を解決したいと思います。それは、どのような情報を利用できるのか、盲点はないか、ということです。ここでは、DNSイベントを確認してみます。
ソースタイプをstream:dnsとし、調査対象のインデックスにmainを指定して、過去7日間で発生したイベントの合計数を調べます。このサーチでは、_timeとhostごとに1時間単位でデータをまとめています。metadataコマンドを使って実行した先ほどのサーチと同様に、SPLを使ってデータを見やすい形式で表示します。ここでは、xyseriesコマンドを使用して面グラフを適用し、DNSデータの収集元ホストで発生したイベント数をグラフ化しています。
ここで注意点があります。ホストが多数ある場合、このようなtstatsの使い方は最善ではありません。表形式で出力して件数を調べるのであれば、この方法は効果的です。しかし、多数のホストのデータをグラフにすると、アナリストが状況を判断するときにかえってわかりづらくなります。
では次に、ログに記録するデータが通常よりも多すぎるまたは少なすぎるホストをすばやく見つけ出すサーチを作っていきましょう。データに基準を設けることは、ホスト数が多い場合でも簡単にできます。
このサーチでは、osインデックスにログを記録するホストを調べ、各ホストについて、過去7日間に発生したイベントを3時間ごとにカウントして、それらの中央値を求めます。ここで利用できる統計関数には以下のものがあります。
続いて、各ホストについて、過去3時間のイベント数を調べます。この値と中央値を使ってパーセント差を計算し、差が+/-5%を超えるものを抽出します。外れ値を見つけやすいようにフィールドをソートし、わかりやすい名前に変更します。この結果から、中央値、過去3時間のイベント数、パーセント差を示すグラフを生成します。
metadataとtstatsを持ってハンティングに出かけよう
metadataコマンドとtstatsコマンドを活用して、これからハンティングするホストやソースタイプについて状況をすばやく把握する方法をおわかりいただけたでしょうか。
Splunkはセキュリティチームをいつでもサポートします。
最新の脅威ハンティング手法については、E-book『PEAK脅威ハンティングフレームワーク』もぜひご覧ください。
