<第7回>Splunkでセキュリティダッシュボードを作成しよう！SPLの書き方(その3)

本記事では、「Splunkでセキュリティダッシュボードを作成しよう！」シリーズにおける第7回として、SPLを使用して作成したセキュリティダッシュボードを例にとり、どのような利用シーンでコマンドが使われているのか、どのような使い方が出来るのかを説明していきます。Splunkを利用したSearchに少し慣れてくると、少し欲が出てくるかと思います。「もっとSearchの実行結果が早く得られないか」「しきい値(静的／動的)をワン・コマンドで設定して動向をつかめないか」など更なる効率化・可視性の拡張に向けて、シリーズ第5回(SPLの書き方 (その1))でご紹介したstatsコマンドを例にとり、xstats(stats兄弟)についてそれぞれの機能、特徴についてご紹介したいと思います。

第1回：全体概要（ゴールと内容の説明）　
第2回：データの取り込み(その1)
第3回：データの取り込み(その2)
第4回：フィールド抽出と正規化
第5回：SPLの書き方(その1)
第6回：SPLの書き方(その2)
第7回：SPLの書き方(その3)　←今ここ
第8回：Dashboard Studioでダッシュボードを作成(その1)
第9回：Dashboard Studioでダッシュボードを作成(その2)
第10回：Dashboard Studioでダッシュボードを作成(その3)

statsコマンドの兄弟たち

1. 統計処理の王道：stats
2. 統計処理結果を爆速へと導く：tstats
3. メトリクスインデックスに格納されたデータを集計：mstats
4. ある期間における統計全体のデータからふるまいの外れ値をあぶり出す：eventstats
5. ある期間における統計に動的しきい値を設定して外れ値をあぶり出す：streamstats

1. statsとは

Splunkで取り込んだデータの統計処理(合計、平均、中央値、偏差..etc..)が行えるコマンドです。第5回 SPLの書き方(その1)にもstatsコマンドの解説がありますのでそちらもご参照ください。

今回はセキュリティダッシュボードの赤枠内のパネルで使用されているデータを使ってstatsコマンドを使用してみます。

セキュリティ重要度(Info, Medium, High, Critical)毎のイベント発生数をstatsコマンドを使って統計を取ってみます。statsコマンドの構文は以下の様な形式をとります。

stats (stats-function(field) [AS field])... [BY field-list]

コマンドや構文の詳細はこちらをご参照ください。

SPL :

index=* sourcetype="juniper:junos:idp"
| stats count  by threat_severity

次にセキュリティ重要度(Info, Medium, High, Critical)毎に外部→内部へ発生した通信バイト数の最大値をstatsコマンドを使って統計を取ってみます。

SPL :

index=* sourcetype="juniper:junos:idp" 
| stats max(inbytes) as max_inbytes by threat_severity

今度はセキュリティ重要度(Info, Medium, High, Critical)毎に外部→内部へ発生した通信バイト数の平均値をstatsコマンドを使って統計を取ってみます。

SPL :

index=* sourcetype="juniper:junos:idp" 
| stats avg(inbytes) as max_inbytes by threat_severity

なお、本blogではコマンドの概要、特徴について触れるため、詳細なオプションなどについてはコマンドリファレンスをご確認ください。

2. tstatsとは

Splunkは、取り込んだデータをIndexer内に保管する際、圧縮されたRawデータ(journal.gz)と索引データ(tsidx)のペアで保管します。

通常の統計処理を行うサーチ(statsやtimechartコマンド等)では、サーチ処理の中でRawデータ及び索引データの双方を扱いますが、tstatsコマンドは索引データのみを扱うため、通常の統計処理を行うサーチに比べ、サーチの所要時間短縮を見込むことが出来ます。

tstatsを使用して統計処理が可能となる対象(フィールド)は以下のとおりです。

• Splunk取り込み時にデフォルトで付与されるフィールド
  • host, source, sourcetype等のデフォルトフィールド
  • About default fields (host, source, sourcetype, and more) - Splunk Documentation
• CSVやJSON形式のデータに含まれるフィールド
  • INDEXED_EXTRACTIONS設定を行いフィールド抽出することが前提
  • Extract fields from files with structured data - Splunk Documentation
• PREFIX()が利用可能なフィールド
  • Use PREFIX() to aggregate or group by raw tokens in indexed data
• index-time field extraction設定済のフィールド
  • インデックス時にフィールド抽出する設定がされている事が前提
  • Create custom fields at index time - Splunk Documentation
• 高速化設定が有効となっているデータモデルで、定義されたフィールド
  • データモデル定義及び高速化設定を行うことが前提
  • Query_data_model_acceleration_summaries - Splunk Documentation

なお、データモデルについては以下のブログもご参照ください。

高速化したデータモデルとサマリーインデックスによるサーチ時間の短縮

では試しにどれくらいのサーチ時間の短縮が見込めるか確認してみましょう。まずは、statsでソースタイプごとのイベント数をカウントします。

上記の結果が出力されるまでの時間は、ジョブ > ジョブの調査から確認が出来ます。この例ですと、1.228秒かかっているようです。

では次にtstatsを使ってみましょう。出力させたい結果はstatsと同じですが、実行するコマンドの形式がstats実行時と異なります。

SPL:

| tstats count where index=* by sourcetype

statsはサーチの条件を指定(indexやsourcetype等)した後、statsで統計を取るフィールドを指定する形式を取りますが、tstatsはwhere区の後にサーチ条件を指定(どのindexやsourcetypeなのか)を指定するイメージです。

※|(パイプ)が最初に入ることに注意してください。

構文の形式の詳細やオプションはこちらよりご確認ください。

tstatsでも同じ結果が得られたことが確認できます。そして実行時間はというと、0.352秒で終了しています。statsを使用した実行時間が1.228秒であった事を考えるとかなりの時間短縮が確認できたかと思います。今回はサーチの対象のデータがそこまで多くなく、期間も短いのですが、データ量が多く、検索期間も長い範囲を対象にする場合、違いが顕著に体感できるのではと考えております。

3. mstatsとは

Splunkではインデックス作成の際、Index Data Typeとして[Event]か[Metrics]のいずれかを選択します。mstatsはこの[Metrics]インデックスを使った統計処理を実施する際に使用します。

セキュリティの観点ですと、NWのトラフィック量などのメトリクスを観測し、アノマリをあぶり出すような用途での利用が可能です。その他CPU使用率、ディスク使用量などサーバのパフォーマンスデータを取得するメトリクスを取得する事にも利用頂けます。

Metrics Indexに関する詳細な説明はこちらをご参照ください。

では試しにmstatsを実行するための準備をしましょう。既に[Metrics]で作成されたIndexか新たに[Metrics]インデックスを作成する必要があります。今回は[Metrics]インデックスを作成してみます。

下図の新規インデックスをクリックします。

• インデックス名：任意の名前(ここではlinux_metricとします)
• インデックスデータタイプ：メトリックス
• その他の項目：デフォルトのままで[保存]ボタンを押して[Metrics]インデックスを作成します。

linux_metricインデックスが作成されました。

Splunk Add-on for Unix and Linux※をSplunkにインストールします。

今回はSplunk Add-on for Unix and Linuxを使用します。※ここではインストール方法などは割愛致します。

Splunk Add-on for Unix and Linuxがインストールできたら設定画面に移ります。

[App] > [Splunk Add-on for Unix and Linux]を選択します。

[Scripted Metric Inputs]にある任意項目をEnableにします(下図では全てEnableにしています)。

[Index]は先程作成した[linux_metric]を指定します。最後にこの設定画面の最下部にある、Saveボタンを押して設定終了です。

これでlinux_metricに一定間隔でメトリックが入る準備が整いました。

ではどのようなデータがIndexに入ってきているか見てみることにしましょう。メトリクスインデックスにおいて、どのようなデータがあるのか参照するときにはmpreviewコマンドを使用します。

| mpreview index=linux_metric

では、いくつかフィールドが確認出来たのでmetric_name:ps_metric.CPUを例にとって一定時間毎(5分毎)のCPU使用率(この例ではsplunkを稼働させているinstanceのCPU使用率)の最大値の統計を取ってみましょう。

mstatsを実行する際の構文(例)は以下のようになります。tstatsと似ていますね。

| mstats span=5min max(ps_metric.CPU) where index=linux_metric by host

mstats を使うメリットは、主に以下の点です。

• 高速かつ効率的な時系列データの検索と集計
• メトリクスデータ専用のストレージを利用してストレージコストを削減

例えば、システムリソースのパフォーマンス分析などで利用する場合に上記メリットを感じられると思います。

mstatsの構文やその他オプションなど詳細はこちらのドキュメントをご参照ください。

4. eventstatsとは

元のRawデータを保持したまま、統計処理を行い、後にRaw情報も出力したい場合などにつかいます。※例えば、statsを使用して一度テーブルを作成するとstatsを使用する前の情報が認識出来なくなる(これはサーチの構造上の制約です)ので、どうにか出来ないかと悩んだ経験はありませんか？Splunkではコマンド(ここではstats)を実行すると、実行した条件に従ってテーブルを自動で作成し結果が表示されます。以下の例では、セキュリティ深刻度事に発生したイベント数をeventcountという名前で統計を取っています。

SPL:

index=* sourcetype="juniper:junos:idp"
| stats count as eventcount by threat_severity

しかしセキュリティ重大度毎のイベント数だけではなく、トータルで発生したイベント数と比較してそれぞれの重大度毎のイベント数は何件かという事を調べたい場合、問題が生じます。

SPL:

index=* sourcetype="juniper:junos:idp"
| stats count as eventcount by threat_severity
| stats sum(eventcount) as sum_eventcount
| table threat_severity eventcount sum_eventcount

このSPLを実行してもイベント合計数(sum_eventcount)のみ実行結果として表示され、セキュリティ重大度(threat_severity)やセキュリティ重大度毎のイベント数(eventcount)は表示されません。これはstatsを最後に実行した結果、保存される中間テーブル情報をSplunkは保持して表示する為です(これは仕様です)。

そのため、元のフィールドを追加したい場合や、元のフィールドに追加の計算を行いたい場合は、それらをstatsコマンドの前、もしくはStatsコマンドにおいて元のフィールドを定義、もしくは追加計算を実行する必要がありますがそのような場合にeventstatsを使用します。

SPL:

index=* sourcetype="juniper:junos:idp"
|stats count as eventcount by threat_severity
|eventstats sum(eventcount) as sumcount

期待通り、セキュリティ重大度(threat_severity)やセキュリティ重大度毎のイベント数(eventcount)、イベント合計数(sum_eventcount)が実行結果として表示されました！

利用用途として、一定期間のイベント全体に対し、例えば、平均、偏差などからの割合や乖離を求めたりする場合に使う場合に有効です。

以下の例では、セキュリティイベント全体の中から重大度別のイベント件数、割合を計算しています。

SPL:

index=* sourcetype="juniper:junos:idp"
|stats count as eventcount by threat_severity
|eventstats sum(eventcount) as sumcount
|eval perc = round(eventcount/sumcount *100, 1)
|eval perc = perc."%"
|table threat_severity eventcount perc

5. streamstatsとは

最後にstreamstatsのご紹介です。statsのみでは表現が難しい元のRawデータとの比較などをイベント全体に対して実施したい場合はeventstatsを使用しますが、特定の時間帯などやストリーミング形式でイベントが検出された順に結果を見たい場合などにstreamstatsを使用します。

わかりやすい活用例でいうと、NWのスループットなど日次や曜日で変化するものに対し、静的なしきい値を設けると(正しくチューニングができれば良いのですが)一定の閾値を超えたものは全てアラート対象となってしまいます。これではアラート疲れを引き起こしてしまいかねませんのでこういう場合、streamstatsを用いる事である程度直近のデータの推移傾向を捉えながら外れ値(アラート候補の可能性となりうるもの)の絞り込みが行えます。

以下の例ではNWのスループットを元に、1時間毎にデータ観測ポイント(スループットの平均値を取得)を設け、データ観測ポイント168ポイント分(つまり24×7=168時間=1週間)毎に平均値および標準偏差を取得し、それらに基づき上限(UB)、下限(LB)を設けています。

ここで設定したUB、LBから外れた値が外れ値として表示されています。

このstreamstatsは以下のセキュリティダッシュボードの「物理的に移動不可能な地域からのアクセス」※の情報にも使用されています。
※同一ユーザが８時間以内に物理的に移動不可能であると思われる距離から異なるIPアドレスでアクセスしたリストを抽出

ちなみにセキュリティダッシュボードの「物理的に移動不可能な地域からのアクセス」パネルについてはInfosec(Splunk app)でも同等の内容で実装※されておりますので、ご興味あるかたは是非インストールの上、パネルに実装されたSPLをご確認ください。

※Infosecのダウンロード先はこちら

インストール後、[App] > [Infosec]を選択

タブ> [Advanced Threats] > [Access Anomaly]を選択

パネル：Geographically Improbable Access

まとめ

• 統計処理の王道：stats
• 統計処理結果を爆速へと導く：tstats
• メトリクスインデックスに格納されたデータを集計：mstats
• ある期間における統計全体のデータからふるまいの外れ値をあぶり出す：eventstats
• ある期間における統計に動的しきい値を設定して外れ値をあぶり出す：streamstats

終わりに

いかがでしたでしょうか。今回はstats兄弟たち(xstats)をご紹介しましたが、兄弟たちの特徴を踏まえ、今後の業務効率化や新たなひらめき(Aha Moment)の一助になれば幸いです。Happy Splunking!