Elastic SIEM検知
ElasticはElasticセキュリティ7.6のリリースと同時に、最新の検知エンジンを開発したことを発表しました。Elastic SIEMで使えるこのエンジンは、一元的なSIEMルールに基づく検知エクスペリエンスをSOCチームに提供します。 この検知エンジンは目的特化型の複数のElasticsearch分析エンジンをベースに開発されており、Kibanaの新たな分散実行プラットフォームで実行できます。 本ブログ記事は、Elastic SIEMにおける検知フローの簡潔な概要、ならびに、検知のシームレスな動作を支える新しいUIとバックエンド機能についてお伝えします。
本題に入る前に、いくつかご案内です。「SIEMアプリを試用してみたい」という方には、ブログ記事シリーズ“SIEM for small businesses and at home（小規模事業・自営業のためのSIEM）”がおすすめです。こちらに、クラウドで無料のElasticsearch Serviceトライアルを立ち上げ、Beatsでお使いのシステムからデータをSIEMに収集、ストリーミングする手順などの説明があります。（皆さんが思っているよりも、おそらくかなり簡単です。） またこの他に、“getting started guide for hybrid deployments（ハイブリッドデプロイの入門ガイド）”もあります。気になる方は、ぜひご覧ください。
シグナル管理のUIワークフロー
Elastic SIEMの検知に欠かせない“シグナル”。その実体は、あるシグナル検知ルールの条件が満たされた場合に作成されるElasticsearchドキュメントです。最もシンプルなケースでは、ルールに定義されたクエリに一致する各イベントごとに、1つのシグナルドキュメントが作成されます。シグナルドキュメントには一致するドキュメントのフィールドのコピーがあり、またシグナルドキュメントは個別のシグナルインデックス内に格納されます。シグナルが作成されるとき、元のイベントは変更されません。
シグナルはSIEMアプリに表示されます。新規のシグナルが表示されるとき、シグナルのステータスは“open”です。分析や次の手順の判断が完了したら、担当者はステータスを“closed”に変更します。変更操作は、SIEMアプリの[Detections]（検知）ビューで管理できます。
シグナルカウントのヒストグラムは、“open”のシグナルを表示し、主要な複数の属性からシグナルを簡単に比較できます。属性は次の通りです。
- スコア、深刻度、タイプ、名称、またはMITRE ATT&CK™の戦術名
- 送信元、または宛先のIPアドレス
- イベントアクション、またはカテゴリー
- ホスト名、またはユーザー名
次に、[Timeline]（タイムライン）上でシグナルを調査します。
ルールの作成時にタイムラインテンプレートを指定していない場合、[Timeline]（タイムライン）はシグナルドキュメントのデータを表示します。タイムラインテンプレートを指定済みの場合、ユーザーが保存した条件に従って[Timeline]（タイムライン）にデータが表示されます。この仕様を活用すると、特定のルールタイプの調査作業をスピードアップできます。
Elastic Endpoint SecurityやSuricata、Zeekなど外部のアラートシステムから来るアラートは、専用の[External alerts]（外部アラート）タブで確認できます。質の高いシグナル調査ワークフローを活用するため、シグナルを生成する各種ルールを実装して高付加価値の外部アラートを受け取っている組織は少なくありません。
担当者は納得がいくまで1つまたは複数のシグナルを調査した後、シグナルを個別に、または一括で“close”できます。また必要に応じて、シグナルを“open”に戻すこともできます。Elasticは、シグナルを自動で“close”する機能のリリースを今後実現できるよう取り組んでいます。
ルール作成のUIワークフロー
シグナルを表示するには、検知のためのルールが必要です。SIEM検知に使うルールを作成する手順はシンプルで、簡単です。基本的な手順は3つです。
1．毎回のルール実行時に使うクエリを生成します。クエリはLucene構文、KQL、保存済みの検索のいずれでもよく、保存済みのタイムラインからクエリをインポートすることも可能です（今後のリリースに向けて、さらに多くのルールクエリオプションの開発を進めています）。
2．そのルールについて情報を追加します（タイトル、説明など）。
3．ルールを実行する時間の間隔をスケジュール設定し、サニティチェックのための遡及時間を設ける場合は、その設定も行います。ユーザーのインジェストパイプラインで生じる遅延に対応できるよう、Elasticは一般的に、ある程度の遡及時間を設定することを推奨しています。また、遡及時間の設定が推奨される理由は他にもあります。予定通りの時間間隔でルールが実行されることは保証されておらず、実行に遅れが生じる可能性があるためです。このような遅延は、タスクマネージャーのワーカーキューに過負荷が生じる、あるいは演算処理リソースが不足するといった場合に生じます。
以上が、検知ルールを作成する3つの基本手順です。また、この検知ルールをMITRE ATT&CK戦術とテクニックに基づいて分類する設定を行えるほか、付加的な参照情報へのリンクもあります。
さらに、担当者は既存のルールに対して個々に、または一括でアクションを実施することもできます。たとえば、ルールを（カスタマイズ用に）複製したり、無効化、エクスポート、削除するといったアクションです。一般的なルール管理のガイドに、詳しい情報を記載しています。
事前構築済みルール
ルールを開発する作業のハードルが高かったり、テストに非常に時間がかかることは珍しくありません。Elasticセキュリティのインテリジェンス＆分析チームが92の事前構築済みルールを開発し、それを使った検知をはじめた理由もそこにあります。92の事前構築済みルールは、Elasticの運用環境で広範に活用されています。また、最新のクリティカルな脅威に対応する新規のルールを開発する取り組みも、継続して行っています。ユーザーはボタンを1クリックするだけで、一連のルールを簡単に実装、運用できます。事前構築済みルールの使用や調整の方法について詳しくは、こちらでご覧いただくことができます。
検知の実装について
KibanaにElastic Stackのアラートが登場し、アラートが第一級エンティティとしてサポートされるようになってまもなく、アラートはElastic SIEMでも検知の土台として活用されるようになりました。UIの背後で、検知はアラートAPIの上の階層にあるAPIを使用します。このSIEM検知APIは、“便利”なだけではありません。ワークフロー（シグナルのopenやcloseなど）、セキュリティ領域の詳細コンテンツ（MITRE ATT&CKの特定など）、KQLサポートの利用もSIEM検知APIによって可能になります。
APIキーを作成し、ユーザーに代わってAPIキーを使ったリクエストを行うことにより、ルールは水面下で実行されます。このとき、ルールは検索を使って一致するイベントを見つけ、一括作成機能を使って、イベントからコピーした情報をシグナルインデックス内のシグナルドキュメントに入れてゆきます。1つのシグナルは、ルールの詳細と、ルールに一致する元のイベントドキュメントの詳細で構成されます。
1つのルールを実行し、一致するドキュメントが100以上見つかる場合、シグナルインデックスにコピーされるドキュメントは`@timestamp`で降順に並べた最後の100件のみです。このシグナルインデックスは、ユーザーがシグナル検知ルールページを最初に閲覧した際、Kibanaのspaceごとに自動で作成されます。インデックス名の形式は、`.siem-signals-
SIEMシグナルインデックスのマッピングは、Elastic Common Schema（ECS）とシグナルの存在を定義するカスタムマッピングを組み合わせたものです。ルールクエリによって一致するドキュメントが検知されると、ソースインデックスのフィールドがコピーされ、ソースドキュメントがECS互換であれば、生成されるシグナルフィールドを検索可能になります。ソースインデックスのフィールドがECS互換でない場合も、シグナルインデックスの`_source`に格納され、[Timeline]（タイムライン）をはじめとするアプリの随所で閲覧することが可能です。ただしこの場合、検索をかけることはできません。
スケーラビリティ
検知UIは、新たに開発されたKibanaアラートフレームワークと、Kibanaタスクマネージャー上に搭載されています。この2つが水平方向と垂直方向のスケール能力を提供することで、どのようなハードウェアもフレキシブルに使用できます。Kibanaタスクマネージャーのworkerは、数を増やして垂直スケールさせたり、あるいは個別のKibanaインスタンスに複製して水平にスケールさせることができます。
複数のKibanaインスタンスを実行する場合、タスクマネージャーは全体的な調整役を担い、インスタンス間のタスクのバランスをとります。kibana.ymlファイル内のmax_workersの数をデフォルトの10から変更することにより、垂直なスケールアップまたはスケールダウンを実施し、Kibanaノードごとに適切なリソースを、より効率的に割り当てることができます。
シグナルの重複を排除する
あるルールを実行するとき、そのルールのクエリに一致すると判断されたイベントに基づいて、シグナルが生成されます。別々のルールでクエリが重複することでシグナルが2つになったり、ルールを2回連続で実行したときに、遡及時間が長いために同じシグナルを捉え、2つになったりすることもあります。シグナルのテーブルにシグナルが重複して表示されることのないよう、Elastic SIEMはソースイベントを取得したインデックス、ソースイベントのドキュメントID、ソースイベントのバージョン番号、実行したルールのIDに基づいてシグナルを特定します。これらのプロパティから計算したハッシュ値をシグナルのドキュメントIDとすることで、一意のシグナルだけを確実にシグナルインデックスに追加することができます。
エラー
ルールのクエリに含まれる構文エラーや、ルール実行中に生じたその他の問題により、エラーが発生することがあります。このようなエラーは、ルールの詳細ページにある[errors]（エラー）タブに表示されます。Elasticは今後、ルールの実行に関する情報について可視性を強化し、一般的なルール監視を拡充させる予定です。
下の画像は、エラーの履歴表示画面です。ここに、ルール実行中に生じたエラーのうち、直近の5つが表示されます。
SIEM検知のこれから
Elastic SIEM検知のベータ版開発とリリースに取り組む私たちにとって、Elastic SIEMディスカッションフォーラムに届く初期からの継続的なコミュニティフィードバックと、オープンな機能トラッキングリストは何よりエキサイティングな存在です。
今後、さらにパワフルな検知を実現するための壮大なプランも策定しています。一例として、ルールクエリを拡充し、アグリゲーション、機械学習、EQLをサポートする予定です。すぐれたセキュリティユースケースを思いついた方や、開発についてご質問がおありの場合はぜひ、コミュニティにご参加ください。