AWS関連

【AWS】SIEM on Amazon ES ちょっとだけ触ってみた

はじめに

インシデント発生時、みなさんはどのように調査していますか?(するつもりですか?)

『インシデント調査って何から手を付ければいいんだろう?』

『・・・・まっったく想像できん。やべえ。』

私は当初、そんな状態でした。

本当にやばいですよね。

今回、前から気になっていてなかなか手をつけれてなかった「SIEM on Amazon ES」のハンズオンイベントが開催されていたので、ここぞとばかりに参加してきました。

結果、インシデント発生時の調査のイメージが少し湧いてきました。

というか、SIEM 使ったら調査めちゃめちゃ捗りそうやん!!と感じるようになったので、どんどん活用していきたいと思いました。(インシデントには遭遇したくないですが。)

今回のイベントでは、
SIEM 環境の構築やログの取り込みが完了している状態で、すぐにKibana の画面を操作することができました。

以下に、実際に触ってみた「Discover」機能と「Dashboard」機能に関して操作感をレポートしていきたいと思います。

SIEM ツール自体はGitHub (aws-samples/siem-on-amazon-elasticsearch-service) で公開されているため、Cloud Formation を利用して簡単に構築することが可能です。

Kibana – Discover 画面の使い方

Discover 画面の全体像

まずは Discover 画面の全体像。大きく分けて3つのブロックで構成されています。

  • 画面上部: 検索用の入力欄(クエリーバー) と時間範囲の指定欄。クエリーバー。適用中のフィルター情報を表示する欄がある。
  • 画面左: インデックス(ログの種類) 切り替え欄とフィールド表示欄。
  • 画面右: 検索結果の時系列表示と、個々のログ。フィールドを指定してテーブル形式で表示することも可能

これ以降は、各項目の操作方法について順に触れていきます。

キーワードで検索する

クエリーバーでは、任意のキーワード検索や、Key-Valueによる検索、AND/OR/NOT等の条件で検索が可能です。

上記画面では、S3 に関するイベントを「Key-Value」形式で検索していますが、”S3” のようなキーワードでも検索が可能です。

  • 任意のキーワード等でログに対して検索が可能

クエリバーにおける条件式等の詳しい使い方は、Elastic 社のKibana 説明ページ を参照。

参照期間を指定する

画面右上の項目で、(ログの参照範囲となる) 期間の指定が可能です。

デフォルトでは「直近の30分 (Last 30 minutes)」が指定されており、カレンダーアイコンを選択するとプリセットされた範囲候補から選択して指定することが可能です。

ちなみに、プリセットされた範囲だけではなく、日時指定による期間指定も可能です。

表示された時系列表示に対してドリルダウンしたい場合は、対象期間(の棒グラフ) をドラッグして選択するだけでOKです。
選択すると、対象期間のみのログ情報に絞り込まれた情報が表示されます。

  • 直近◯◯時間や、任意の期間を指定することが可能
  • ドラッグするだけでドリルダウンが可能

ログの種類を指定する

ログは種類毎にインデックスが分かれているため、インデックスパターンの選択により参照するログの切り替えが可能です。

デフォルトでは「全種類([log-*])」のログが表示されており、リストの中から「CloudTrail( [log-aws-cloudtrail-*])」等を選択することで確認対象のログを指定することが可能です。

  • 参照するログは、インデックスを利用して切り替えが可能

ログフィールドで絞り込む

フィールド一覧では、検索できるフィールドやフォーマット等の確認が可能です。

“event.action” の中身を見てみると、どのような処理が含まれているか知ることができます。(最新500のログを集計した情報が表示される)
そして、「+」ボタン/「ー」ボタン でフィルタリング(絞り込み/除外)追加が可能です。

  • フィールド一覧やフォーマットの確認が可能
  • フィルタリング追加が可能

個々のログ詳細を確認する

画面右側、時系列表示の下には個々のログ一覧が表示されています。
ログの詳細情報を確認するためには、時間(Time) 左にあるボタンをクリックすることで詳細情報の表示が可能です。

ここでも、ログ詳細に含まれる「ユーザー」や「IP」の情報に対して 「+」ボタン/「ー」ボタン でフィルタリング追加が可能です。(ここではIP 情報をフィルタリングに追加しています)

なお、フィルタリングした内容は画面左上に表示されます。フィルタ解除は「×」ボタンを利用します。

  • ログ詳細で実際のログ内容が確認可能
  • フィルタリング追加が可能

Kibana – Dashboard 画面で調査してみる

ついに来ました。Dashboard。

Discover 画面だけでも十分捗りそうな感じはありますが、なんと言ってもDashboard 画面は見栄えがいいですよね。笑

”映え” ばかりを気にしていてもしゃーないのですが、

ログ情報 という とっつきにくい大量のデータを可視化するという観点で ”映え” てることは正義なのであります。

ということで早速進めていきます。

Dashboard 画面を開くと、参照するログの一覧が表示されるので、今回はGuardDuty を選択しましょう。

ちなみに、
このDashboard 画面では少しだけ実践を意識して「調査をやってみる」感じで使用感をレポートしていきます。

簡単な流れは以下の通り。

  • GuardDuty が検知した脅威を確認する(インシデントか否かの判断)
  • GuardDuty のログから攻撃者の痕跡を探す(IPアドレスや悪用されたユーザー情報)
  • CloudTrail のログから攻撃者が何をしたか確認する(影響度の調査)

※偉そうなことを言ったものの、作業中に提供いただいていた環境の利用期限が来てしまったので、薄っぺらい内容になっちゃいました。

GuardDuty|任意の期間で確認する

Dashboard 画面の全体像としては、メイン画面にダッシュボードがデザインされており、何のデータなのか「見ればわかる」状態になっております。

ここでは対象期間の絞り込みを行っており、期間内に検出されたログが存在することがわかります。

余談)このダッシュボードのデザインは、こちら(前述のGitHub 内) で提供されている設定ファイル「dashboard.ndjson」によりレイアウトされています。

この設定ファイルを Kibana の「Management」からインポートするだけでダッシュボードが完成します。一瞬にして。(神)

GuardDuty|IAMUser に関するものだけを抽出する

次に、(どのユーザーが悪用されたのか確認するために)IAMUser に関連する脅威に絞り込みます。

方法はDiscover 画面でやった時と同じで、クエリバーにキーワードを入力するだけです。

緊急度「中 (Medium)」のログが存在することがわかります。

GuardDuty|疑わしい”user.id” でフィルタリングする

先ほどの絞り込みの結果、表示されているログ詳細(画面下部)の中から、”user.id” の項目を探して、項目の左側にある「+」ボタンでフィルタへの追加を行います。

画面上部のフィルタ表示に”user.id” の指定内容が表示され、ログ情報にもフィルタリングがかかった状態になります。

GuardDuty|抽出・フィルタ条件をピン留めする

ここまでの操作によって指定した、抽出条件やフィルタ条件をピン留め(保存・固定)します。

フィルタ欄の左にあるアイコンをクリックして、「Pin all」を選択することで完了です。(簡単)

ここまでのポイント

  • 期間で絞り込み
  • ”IAMUser” 関連で絞り込み
  • “user.id” で絞り込み
  • 抽出条件をピン留めして固定

画面最上部に表示されているパンくずリスト「Dashboard / GuardDuty Summary」のうち『Dashboard』をクリックし、

CloudTrail のログを選択していきます。

CloudTrail|対象ユーザーがどんな操作を行ったのか調査する

CloudTrail のログ情報が表示されたら、ピン留めしていた抽出条件が固定されていることがわかります。

これはつまり、

先ほどの操作で調査した結果”あやしい” と判断した条件に一致するユーザーの証跡が確認できる状態になっている、ということです。

しかも、

ダッシュボードなので多くの情報がわかりやすく入ってくるのでわかりやすい。特に地図とか。(神)

こーれはめちゃめちゃ興奮しますよね。しません? え? あ、そうですか。

気を取り直して、ここまで来たらあとはログ詳細から、対象ユーザーがどんな操作を行ったのか確認することが可能です。

どのタイミングでどんなアクションを実行しているのか、

そしてそれがどれだけのインパクトがあるのか、

確認していくことで今回のインシデントのヤバさがわかる、といった感じでございます。

  • GuardDuty でピン留めした条件を流用
  • 影響度はCloudTrail のログ詳細を確認
  • IP とかでフィルタするのもあり
  • 地図情報は明らかに”あやしい” がわかって便利

調査の流れとしては、かなり乱暴でペラペラな感じになってしまいましたが、今回のレポートは以上です。

「SIEM on Amazon ES」の何となくな使い方はご理解いただけたでしょうか?

(インシデントが発生しないことに越したことはないですが、)有事に備えて一度 SIEM に触れてみるのもいいのではないでしょうか。

まとめ

今回のイベント参加で、SIEM の操作感はだいたい理解できたのでよかったです。(もっと使いこなす方法があるはずだが、今わかってるものだけでも十分捗りそうと理解した)

特に個人的には、「ピン留め」して各種ログを行ったり来たりできるのが便利だなと思いました。

ただ若干心残りな点としては、
Dashboard 画面での調査シュミレーションをもっとやりたかった、というのが正直なところ。(提供された環境が当日中しか使えなかった…)

こればっかりは自分のアカウントでSIEM 構築して触ってみるしか無いですね。
インシデントログが無いのであまり面白くないかもしれませんが。笑

最後に、
SIEM 利用によってインシデント調査が捗ることは理解できたと思います、がしかし、もっと大事なことが一つあります。

それは、ちゃんとログを取ること。

GuardDuty やCloudTrail など、「有効化する」だけでログが取得できる仕組みがいくつかあるので、

『男は黙ってログ有効化』しておくのが吉ですね。

ログがないとそもそもSIEM 使えませんしね・・・

インシデント発生時に「やり方がわからん」より、「ログ無いから何もできん」が最悪ですよね。

(もっと勉強いたします。)

では、
最後まで読んでいただきありがとうございました。