🕵

【Elastic】Elastic Security でインシデント対応してみた

Hisashi Hibino

2024/05/17に公開

はじめに

Elastic 社の SIEM ソリューションを組み込んだ Elastic Security ^[1] について
何ができるのか、AWS CloudTrail ^[2] の監査ログを使ったシナリオで機能検証してみました。

SIEM とセキュリティ分析のための Elastic Security

【参考】
・Elastic SIEM 登場（Elastic ブログ 2019年6月26日）
・Elastic SIEM 検知（Elastic ブログ 2020年3月12日）

本投稿で説明する内容

AWS アカウント内の操作をイベントログとして記録するサービスである CloudTrail を使い
MFA（多要素認証）を使わずに AWS マネジメントコンソールにログインした操作を検知させます。

そのアラート検知を Slack チャネルに通知させ、それをトリガーにインシデント調査を開始し
どのユーザーによる操作なのかを Elastic Security App の機能を用いて特定します。

【検証する Elastic Security App】

App 名	説明	検証対象
Dashboards ^[4]	Elastic Security で管理しているイベントデータを使ったダッシュボードを管理します（デフォルトダッシュボードの提供、カスタムダッシュボードの作成が可能）	◯
Rules ^[5]	セキュリティ監視のための検知ルールを管理します（事前定義済みルールの提供、機械学習や各種クエリ言語によるルールの作成が可能）	◯
Alert ^[6]	検知ルールにマッチしたアラートを管理します（アラートをケースに登録可能）	◯
Findings ^[7]	CSPM/KSPM で検出された検出結果（クラウドや kubernetes の設定ミスなど）や脆弱性を管理します	-
Cases ^[8]	セキュリティインシデント対応を管理するためのチケットを管理します（検知したアラートや Timelines で調査した結果をケースに登録します）	◯
Timelines ^[9]	クエリ言語（KQL/EQL/ES\|QL）を用いて、時系列でアラートとログのイベントをまとめて深堀調査するためツールになります（調査結果をケースに登録可能）	◯
Intelligence ^[10]	脅威インテリジェンスフィードからデータを収集し、侵害の痕跡（IoC）^[11] を一元的に管理します（Enterprise サブスクリプションが必要）	-
Explore ^[12]	Hosts, Network, Users の 3 つの観点でイベントの傾向を掴むための UI を提供します	◯

前提

・AWS アカウントは事前作成済みです。
・Elastic Cloud は Gold サブスクリプションで事前構築済みです。
・Elastic Agent のインストールはスタンドアローン方式を利用しています。
・CloudTrail の監査ログはあらかじめ Elastic Cloud に取り込み済みです。
・アラート通知先の Slack チャネル（プライベート）は事前に作成済みです。

利用環境

各ソフトウェアのバージョンは以下の通りです。

Product	version
Amazon Linux	2023.4.20240429.0
Elastic Cloud	8.13.3
Elastic Agent	8.13.3
AWS CloudTrail Integration	2.15.0

【構成図】
・AWS CloudTrail Integration ^[13] を利用して CloudTrail の監査ログを取り込んでいます。
・Rule に合致し、検知した Alert は Slack connector を利用して Slack チャネルに通知されます。

全体構成図

実施手順

ここからは実施手順について解説します。

Rule の作成
Alert 通知の確認
Case の作成
Timelines による調査

【参考】
・Elastic Security overview（公式ページ）

1. Rule の作成

まず、MFA 未使用でログインした場合にアラート検知するようにルールを作成します。

【参考】
・Create a detection rule（公式ページ）

検知ルールには、あらかじめ Elastic SIEM として定義されている 事前定義ルール（Prebuilt rule）
と呼ばれるものがあります。

今回は新規でルール作成せずに事前定義ルールを複製し、複製したルールのクエリを改修します。
ちなみに新規でルールを作成する際に選択可能な方式は以下の7種類 ^[14] になります。

Rule type	説明
Custom query	KQL または Lucene のクエリを用いて、フィールドに対するフィルター条件を定義し、合致したときにアラートを作成します
Machine Learning	機械学習ジョブによって定義されたしきい値を超える異常（外れ値）を検出したときにアラートを作成します（Platinum サブスクリプション以上が必要）
Threshold	Aggregate 機能で集計したフィールド値に対して、その数値が閾値を超えたときにアラートを作成します
Event Correlation	EQL（Event Query Language）のクエリを用いて、異なる `event.category` の時系列イベントを相関した条件を定義し、合致したときにアラートを作成します
Indicator Match	脅威インテリジェンスフィードから収集した侵害の痕跡（IoC）とのマッチングに関する条件を定義し、合致したときにアラートを作成します（IoC の利用は Enterprise サブスクリプションが必要）
New Terms	KQL または Lucene のクエリを用いて、フィールドに対するフィルター条件を定義し、指定した期間内に指定したフィールドにおいて、はじめての用語が出現したときにアラートを作成します
ES\|QL	Elasticsearch Query Language のクエリを用いて、フィールドに対するフィルター条件を定義し、合致したときにアラートを作成します（バージョン 8.11 でリリースされたばかりの機能で、まだテクニカルレビューの状態で本番環境での利用は推奨されていません）

Rule type

【参考】
・Elastic Stack 8.11: 新しい強力なクエリ言語 ES|QL の導入（Elastic ブログ 2023年11月7日）
・ES|QL (Elasticsearch クエリ言語) の入門（Elastic ブログ 2023年11月7日）

1-1. 事前定義ルールからの複製

ここでは、AWS Root Login Without MFA という事前定義ルールを複製します。

Kibana にログイン後、左上のハンバーガーメニューから Security を開きます。
[Rules] の右側のボタンから Detection rules (SIEM) をクリックします。

Detection rules(SIEM) を開く

今回は事前定義ルールを利用するため、画面上部の +Add Elastic rules をクリックします。

Add Elastic rules をクリック

検索バーで aws root と入力し、AWS Root Login Without MFA の Install rule をクリックします。

Install rules をクリック

追加されたルールで Duplicate rule をクリックします。

Duplicate rule をクリック

Only the rule を選択し、Duplicate をクリックします。

Only the rule を選択して複製

1-2. 検知ロジックの定義

前手順の続きで、複製したルールの編集画面が開きます。
Custom query に書かれているクエリ文の中でルートユーザーを指定している部分を削除します。
（aws.cloudtrail.user_identity.type:Root and を削除）

削除後のクエリ文

event.dataset:aws.cloudtrail
 and event.provider:signin.amazonaws.com
 and event.action:ConsoleLogin
 and aws.cloudtrail.console_login.additional_eventdata.mfa_used:false
 and event.outcome:success

About タブを開き、Name と Description の記載内容を修正します。

Name と Description

Name の修正案

AWS Login Without MFA

Description の修正案

Identifies attempts to login to AWS as all user without using multi-factor authentication (MFA).

1-3. 通知

Actions タブを開き、Select a connector type で Slack を選択します。

Slack connector が存在しない場合は、Create a connector ボタンをクリックします。

Slack connector の作成

❶ Connector name にコネクタ名を入力します。（ここでは Slack のチャネル名としています）
❷ Connector settings の Webhook URL に通知先チャネルの Webhook URL をコピペします。
❸ Save ボタンを押して保存します。

Slack connector の作成

【参考】
・SlackのWebhook URL取得手順（Qiita）
・Slack connector and action（公式ページ）

Message は欲しい情報にカスタマイズします。
（ここでは Slack の通知からすぐにルールを開けるよう Rule URL {{rule.url}} を追記）

Slack Actions の設定

画面下部の Save changes ボタンを押して、Rule の編集内容を保存します。

Rules の保存

1-4. ルールの有効化

ルールの保存後、画面上部の Enable の脇のスイッチをオンにして、ルールを有効化します。

ルールの有効化

2. Alert 検知

次はアラートの検知になります。
今回作成したルールの実行間隔は複製元のルールのまま（10 分間隔）としています。

ルールの実行間隔

上記の Runs every がルールで定義したクエリの実行間隔になります。
Additional look-back time は検知の見逃しが起きないようにするための設定になります。

【参考】
・Set the rule's schedule（公式ページ）

2-1. Slack チャネルへの通知

MFA 未使用でマネジメントコンソールへのログインが発生すると Slack に通知が飛んできます。

Slack チャネルへの不正ログイン検知の通知内容

2-2. Rule でのアラート確認

Slack メッセージに記載されている Rule URL をクリックすると Kibana の該当ルールが開きます。
Rule 画面をスクロールすると下部に検知した Alerts が記録されています。

Alertsの内容

Reason に送信元 IP アドレス（xxx.xxx.44.244）とユーザー名（test-user01）が記載されています。

Reasonの内容

authentication event with source xxx.xxx.44.244 by test-user01 created high alert AWS Login Without MFA.

2-3. Alerts でのアラート確認

Kibana メニューの [Security] > Alerts を開きます。

【Summary タブ】
以下のグラフで分析ができます。

Severity levels: ルールの重要度での件数集計
Alerts by name: ルール名での件数集計
Top alerts by (指定したフィールド名): 指定したフィールドでの集計

Summary by Alerts 画面

【Trend タブ】
積立棒グラフを表示できます。（集計に利用するフィールドは指定可）

Trend by Alerts 画面

【Counts タブ】
2 項目で上位 1,000 位までの表グラフを表示できます。（集計に利用するフィールドは指定可）

Counts by Alerts 画面

【Treemap タブ】
その名の通りツリーマップを表示できます。（集計に利用するフィールドは指定可）

Treemap by Alerts 画面

3. Case の作成

検知したアラートをトリガーにインシデント調査を開始します。
インシデント調査の実施内容をチームで共有するため、クローズまでの対応を記録します。

【管理する情報】
・インシデントの概要
・インシデントの対応者
・対応のステータス
・ケースの重要度
・該当するアラート
・調査内容とその結果

【参考】
・Open and manage cases（公式ページ）

3-1. 新規のケース作成

検知したアラートを起点に新規ケースを作成します。

Alerts 画面の下部にあるアラート一覧から該当のアラートを見つけます。
❶ Actions の[more actions]から❷ Add to new case をクリックします。

新規ケースの作成

❸〜❻について、以下の設定項目を入力し、❼ Create case ボタンで保存します。

新規ケースの入力

【設定内容】

項目名	設定値	説明	備考
Name	AWS Login Without MFA 2024-05-13_1	任意のケース名を入力します	適当にアラート名と日付の組み合わせ
Assignees	日比野恒	オプションでケースの担当者をアサインできます	Elastic Cloud にログインできるユーザーから選択
Tags	-	オプションでタグを自由入力できます（複数タグ入力可）	デフォルトのまま
Category	-	オプションでカテゴリを自由入力できます（1 つまで）	デフォルトのまま
Severity	High	重要度を Low, Medium, High, Critical から指定します	アラートの重要度と合わせるなど
Description	[新規ケースの入力]の画像参照	インシデントの概要、実施予定の内容を記述します	-
Sync alert status with case status	On	ケースと紐づいているアラートのステータスを同期するかを設定します	デフォルトのまま
External incident management system	No connector selected	JIRA などの外部のチケット管理システムと連携するかを設定します	デフォルトのまま

以下のような画面になれば、ケースの作成完了です。

ケースの作成完了

3-2. 既存のケースに登録

1 つのインシデントに対して、複数のアラートが該当する場合があります。
ここでは、先ほど新規作成したケースに追加でもう 1 つアラートを登録します。

❶ Actions の[more actions]から❷ Add to existing case をクリックします。

既存のケースに登録

紐づけたいケースを指定します。（AWS Login Without MFA 2024-05-13_1 を Select します）

ケースを選択

該当のケースを開くと Total alerts や Activity でアラートが登録されたことがわかります。

追加のアラートの登録完了

4. Timelines による調査

Elastic Security では、インシデントの深堀調査は Discover を使わずに Timelines を利用します。

これまで Discover を利用していた身としては、何が違うんだろうかと疑問に持ちましたが
Timelines を使ってみた感想として、以下の点を特徴と感じました。

【主な特徴】
・調査結果を Case に登録ができる。
・Custom queury（KQL/Lucene）と ES|QL 以外に EQL での検索ができる。
・アラートのイベントを起点に関連するログもまとめて時系列で分析できる。

以下、Query タブを指定した時の簡単な画面説明になります。

Timelines の画面説明

【参考】
・Investigate events in Timeline（公式ページ）

4-1. 表示するフィールドの設定

ここではケースに登録したアラートを起点に Timelines で深堀調査を行います。

まず、手順 3-1 で作成したケースに登録した ❷ Alerts を開きます。
深堀調査したいアラートの Actions の ❸ Investigate in timeline をクリックします。

Timeline の開始

未保存の Timeline が開きます。Fields ボタンを押して表示するフィールドを確認します。

Fields の設定

デフォルトで表示されているフィールドは以下の通りです。

・@timestamp
・message
・event.category
・event.action
・host.name
・source.ip
・destination.ip
・user.name

表示したいフィールドにはチェックを入れ、Close で閉じます。

表示するフィールドの指定

4-2. 対象データの設定

次に Timeline で検索・フィルターする対象データを確認します。
Data view を押すと対象とするインデックスを確認できます。

Data view の設定

デフォルトでは、Security Default Data View という Data view が設定されています。
この Data view にはアラートに関するイベントとログに関するイベントが含まれます。

特徴に記載しましたが、アラートとログのイベントを合わせて調査できるのが大きなメリットです。
Show only detection alerts にチェックを入れるとアラートのイベントのみに対象を絞ります。

今回は設定変更せず、そのまま閉じます。

もう 1 つ、対象とするイベントについても確認します。
Customize Event Renderers のボタンを押します。

Customize Event Renderers の設定

デフォルトでは、すべてのイベント種別が有効になっています。

Customize Event Renderers

今回は設定変更せず、そのまま閉じます。

4-3. フィルター条件の設定

いよいよ、Timelines での深堀調査を開始します。
アラートから Timelines を起動すると該当アラートの _id のみ検索条件に追加されています。

query builder に該当アラートのみ表示するような検索条件が記載されている

すでに MFA を使用せずにログインしたユーザーは test-user01 と判明しています。
ここでは、このユーザーがどのような API 操作したのかを調査してみましょう。

query builder で ❶ + Add field をクリックし、❷ フィールド名で ❸ user.name を選択します。

user.name フィールドの指定

user.name が ❹ test-user01 であることを追加し、❺ Save します。

test-user01 の値の指定

条件追加により、該当アラートを含む test-user01 の操作イベント（計 67 件）が表示されます。

条件追加による検索結果

event.action に AWS API 名が記載されます。
AWS API 名にカーソルを合わせて Show top event.action をクリックします。

Show top event.action の選択

対象イベント 67 件の event.action の 積立棒グラフ（Top 10） が表示されます。

event.action の Top10

上記グラフをケースに登録することもできます。

【補足】
query builder の ❶ 左側で AND Filter と OR Search の切替ができます。

AND Filter と OR Search の切替

この切替が反映されるのは、検索バーに入力した KQL / Lucene のクエリ文になります。

❶ AND Filter で ❷ NOT event.action : (Describe* OR Get* OR List*) を追加してみます。

参照系イベントの除外

すると ❸ ConsoleLogin のイベントのみでした。AWS は設定変更されていないことがわかります。

【参考】
・Kibana Query Language（公式ページ）

4-4. ケースに追加

Timelines で調査した結果をケースに追加するためには名前をつけて保存する必要があります。

Save ボタンで名前をつけて保存

Save ボタンを押し、Title と任意で Descripton を記載し、保存します。

名前と説明の入力

[Attach to case] から Attach to existing case を選択します。

Attach to existing case

追加したいケースを Select します。

ケースの選択

保存した Timeline のリンクは自動的に記載されます。
調査した際の内容をコメントに追記し、 Add comment ボタンを押します。

コメントへの追記

以下のようなコメントがケースに追記されます。

追加されたコメント

以上でケースへの追加は完了です。

最後にインシデント対応が完了し、ケースをクローズする際は、Status で Close を選択します。

ケースのクローズ

まとめ

かなりのボリューム感となってしまいましたが、いかがでしたでしょうか？

Elastic Security の SIEM 機能を使ってインシデント対応を行うために必要な要素はだいぶ抑えられたのではないでしょうか。

ポイントは、最適な Rule type を選択して筋のよい検知ロジックを書けること
また、Timelines で迅速な調査をするためのクエリが書けることと思います。

そのためには KQL, EQL, ES|QL のそれぞれのクエリ言語の特徴を理解し、どの言語で書くのが最適なのか、そもそも書けるのかを理解することだと思います。

本記事がセキュリティ運用を構築する上で役に立つことを切に願っています。

Dashobards の確認（おまけ）

Elastic Security ではセキュリティ分析のためのダッシュボードを作成できます。
（基本的な考え方は Kibana の Dashboards と同じで、作成したグラフやパネルを配置します）

標準で以下のダッシュボードが搭載されています。

【Default Dashboard】

ダッシュボード名	説明
Overview ^[15]	全体の概略を掴むためのダッシュボード（アラートやイベントの傾向、ホストやネットワークのイベントの内訳、脅威インテリジェンスの情報など）
Detection & Response ^[16]	検知したアラートや対応しているケースのサマリーを表示するダッシュボード（アラートやケースの傾向や重要度の内訳や件数など）
Kubernetes ^[17]	Kubernetes クラスターから取得した Linux プロセスデータに関するイベントを表示したダッシュボード
Cloud Security Posture ^[18]	CIS Benchmarks で定義されたルールによって検出された CSPM と KSPM の Findings のサマリーを表示するダッシュボード（AWS/Google Cloud/Azureごとのセキュリティスコアなど）
Cloud Native Vulnerability ^[19]	CNVM Integrations を有効化した Elastic Agent がインストールされた仮想マシンで検出された脆弱性（CVSS v3 ベース）のサマリーを表示するダッシュボード（まだベータ版）
Entity Analytics ^[20]	ホストにおけるリスク、ユーザーにおけるリスク、ネットワーク内からの異常検出などエンティティベースの脅威のサマリーを表示するダッシュボード（機械学習機能に依存するため、Platinum サブスクリプション以上が必要）
Data Quality ^[21]	イベントデータの取り込みにおけるデータ品質のサマリーを表示するダッシュボード（インデックス数やドキュメント数など）

【参考】
・Dashboards（公式ページ）

Overview

Kibana にログイン後、左上のハンバーガーメニューから Security を開きます。
[Dashboard] の右側のボタンから Overview をクリックします。

Overview ダッシュボードでは、Alert trend と Events で積立棒グラフが表示されていました。

Overview dashboard

Alert trend は Stack by で好きなフィールドによる集計表示できます。（上記ではアラート検知したルール名になっています）
Events の Stack by は event.action, event.dataset, event.module のフィールドから選択しての表示になります。

Detection & Response

[Dashboard] の右側のボタンから Detection & Response をクリックします。

Detection & Response ダッシュボードでは、Alerts, Open alerts by rule, Users by alert severity で表示がありました。

Detection & Response dashboard

Detection & Response dashboard の続き

見たままなので、説明は割愛します。
SIEM での検知の傾向を掴む上でたまに見てみるのも良いでしょう。

Explore の確認（おまけ）

Explore では 3 つの観点（Hosts, Network, Users）のセキュリティイベントを集計した UI が用意されています。
（新規作成はできませんが、Dashboard と機能的に何が違うんだという気持ちもあります...）

Explore の画面

Users

ユーザー観点の UI では、ユーザー数のトレンドやリスト、認証の成功と失敗のトレンド、イベントのトレンドや詳細を確認することができます。

Users UI

Users UI の続き

脚注

Logspect Tech BlogPublication

ログスペクト株式会社の技術ブログ