Elasticセキュリティの内幕：事前構築済み保護機能でセキュリティチームを支援

異常検知エンジニア向けの検知コンテンツ

現在、Elasticセキュリティには1,100以上の事前構築済み検知ルールが用意されており、Elasticセキュリティユーザーがすぐに検知とセキュリティ監視をセットアップして使い始められるようになっています。その1,100を超えるのルールのうち、760以上がSIEM検知ルールで、複数のログソースを考慮したものです。残りは、Elastic Security for Endpointを利用してエンドポイントで実行するものです。

Elasticは、セキュリティコミュニティと共に透明性とオープン性の実現に努めています。それが、関心のある人たちと協力して公開の場で検知ロジックを作成し、保守している大きな理由です。Elasticの研究、ルールなどの知見をセキュリティコミュニティと共有することで、コミュニティがその内容を知り、それをさらに改善できるようにすることが重要だと考えています。

このコンテンツはすべて、Elasticセキュリティに組み込まれていてすぐに使えるのに加え、パブリックGitHubレポジトリ（SIEM検知ルール、エンドポイントルール）でも公開されています。

Elasticは検知機能に重点を置く他の製品と比較されることも厭いません。Elasticセキュリティは、Tidal Cyberプラットフォームにも採用されています。

Elasticがセキュリティコンテンツを提供する理由

最新のテクノロジーや機能を駆使し、新しい脅威を調査して検知する方法を考え出せる人材は、あらゆる企業にいるわけではありません。そこでElasticセキュリティの出番です。Elasticセキュリティが、セキュリティチームの助っ人の役割を果たします。

Elastic TRADE（Threat Research and Detection Engineering）チームは、新しい脅威や一般化した脅威を研究し、ユーザーに代わって検知/防御ルールを開発、保守します。また、セキュリティユースケースのサポートに使われるさまざまなクエリ言語を改善するために、フィードバックも提供します。TRADEチームは、Elasticの内部情報セキュリティチームをはじめ、さまざまなエンジニアリングチームと緊密に連携して、フィードバックが確実に取り入れられて着実に改善が行われるようにします。

このブログ記事では、SIEM検知ルールとそれに付随するセキュリティコンテンツの活用方法と、その作成方法を紹介します。早速始めましょう。

Elasticルールの作成プロセス

1．トピックの特定

ルール作成プロセスの最初の手順は、調査計画、現在の脅威状況、インテリジェンス分析、カバレッジ分析に基づいて、焦点を当てるべきトピックを特定することです。このとき、利用可能で人気のある統合、ユーザー需要、トレンドも考慮します。

2．トピックの調査

焦点を当てるテクノロジー、脅威、または戦術を特定したら、それを調査します。Google Workspaceを題材にした分析例をご覧ください。対象のアーキテクチャーとサービスを詳しく理解し、行われうる敵対的手法を特定します。それは通常、MITRE ATT&CK framework®にマッピングされます。

3．ラボの作成

ルールを開発するにあたり、脅威をシミュレートし、検知ロジックの作成やテストに必要なデータを生成するためのラボ環境が必要な場合があります。先ほど挙げた分析例では、Google Workspaceのラボ作成の裏側をうかがい知ることができます。同じアプローチを、ルール作成の対象となるデータソースすべてのラボ環境の作成と維持に当てはめることができます。

4．ルールの作成

通常はルール作成者が、使用するルールのタイプを決め、ベストプラクティスに従ってパフォーマンスに優れた誤検知の少ない検知ロジックを作成し、テストし、必要なメタデータフィールドすべてを設定したルールファイルを作成します。適切なルール開発とテストの中核には、TRADEの哲学があります。

5．ピアレビューの実施

次は、ルールのピアレビューです。当然ながら、新しい検知ルールで対応するテクノロジーと脅威について、レビュアーも理解する必要があります。同僚が既存の検知ロジックを評価し、そのロジックが働かない可能性のあるエッジケースを指摘する作業が欠かせません。脅威がルールをすり抜けたり、ルールがユーザー環境でノイズになったりする可能性があるので、バランスの見極めが重要です。

6.カバレッジの考慮

TRADEチームでは、検知カバレッジを改善しようとするとき、既存のルールを調整して新しい検知に対応できないかどうか、セキュリティアナリストの視点から見て生成されたアラートが妥当かどうかも確認します。このようにすることで、ルール作成者は、定性的ルール作成と定量的ルール作成のどちらが適しているかに焦点を絞って検討できます。 

場合によってはこのプロセスの途中で、そのルールでは誤検知が多すぎると判断し、構築ブロックルールとしてリリースを保留にすることがあります。また、効果的な検知ロジックを作成するにはデータカバレッジが不足していることがわかり、Elastic内の他のチームと協力して不足に対処するために、ルール作成が後回しになることもあります。

デフォルトの検知ルールのカバレッジが全ユーザーの環境に完璧に適合するわけではないことは、Elasticも認識しています。そのため、ユーザーが変更できるように、ルールをKibanaでフォーク可能にしています。ルールの調整は簡単で、使用している脅威モデルと環境の仕様に応じてルールに例外を追加して更新するだけです。Elasticのルール開発アプローチについての詳細を読み、ルールに期待できることをご確認ください。

検知ルールレポジトリでElasticのルール開発の最新状況を確認できます。他のElasticユーザーと共有したいルールがある場合は、他のユーザーと同じように、ぜひElasticのレポジトリを通じてコミュニティに公開してください。

実は新規ルール以外も

TRADEチームは、新規ルール作成だけでなく、既存ルールの監視と調整にも多くの時間をかけています。時折、Elasticの標準に合わなくなったルールの廃止もしています。

Elasticはデータを重視しています。そこで、検知ルールレポジトリに対する600件の最新のプルリクエストを調査し、検知ルールに対して行った作業の種類を調べてみました。以下のグラフに示すように、ルールの調整と保守が新規作成を上回っています。それは、検知の質を高く、最新の状態に保ちたいからです。

Elastic Security Labの研究者は、定期的にテレメトリーデータをレビューして、アラートやルール固有のパラメーターの出現率に基づいて調整が必要なルールは何かを確認しています。

Elasticセキュリティのテレメトリーは、Elasticユーザーが自発的に共有したもので、製品パフォーマンスや機能の有効性の改善に使用されています。なお、最近公開されたElasticグローバル脅威レポートは、ユーザーから共有されたデータに基づいています。この脅威レポートは、脅威状況に関するグローバルな知見とコンテキストをまとめたもので、カスタムルール作成の指針とすることができます。

テレメトリーをレビューしてルールの有効性を改善するのと平行して、エンジニアが調査に参加して真陽性（TP）アラートをレビューする脅威特定も優先的に実施しています。TPテレメトリーには個別のトリアージワークフローが必要ですが、それには新しいルール開発や詳しい調査が必要になることがあります。TRADEは、調査や高度な分析でElastic Security Labsに貢献しています。特にマルウェアのリバースエンジニアリング、敵対的プロファイリング、インフラストラクチャー検出、自動インジケーター収集など、高度な技術的分析を行っています。このような調査の実施にあたり、他の内部研究チームとも頻繁に協力しています。 

セキュリティアナリスト向け検知コンテンツ

検知ルールを使うのは、検知エンジニアだけではありません。アラートのトリアージや調査を行うセキュリティアナリストもそうです。

Elasticでは、セキュリティアナリスト向けに、調査ガイドなどの情報を追加してルールを充実させた、運用的脅威コンテキストを提供しています。ルール作成者により、攻撃/動作に関する情報や、調査、誤検知、分析、修復手順に関するアドバイスが追加されています。この情報は、アラートを確認して、そのアラートがトリガーされた理由をすばやく理解し、今後の手順を決める必要のあるアナリストにとって、とても有益です。この調査ガイドは、Elasticセキュリティソリューションのアラートインターフェースでも確認できます。

自分のカスタムルールに対しても調査ガイドを作成することをお勧めします。それがセキュリティチームにとって有益な資料になります。

Elasticでは、脅威検知ルールすべてに調査ガイドを用意しようと取り組んでいます。この記事の公開時点で、全事前構築済みルールのうち30%に調査ガイドが用意されています。"Investigation Guide"タグを使って、ガイド付きの事前構築済みルールを簡単にフィルターできます。

製品テレメトリーも、ガイド作成の優先順位付けに活用されています。ユーザーが最も使用しているルールを調査し、そのルールが最も役立つ状況に関する情報をユーザーに提供します。

Elasticのロードマップは、トリアージと復旧の推奨事項を中心とした調査ガイドの継続的な改善と、機能の改善の2つから構成されています。たとえば、Elastic Stackバージョン8.5以降では、カスタム使用可能なOsquery検索を調査ガイドに追加できます。この機能でエンドポイントをクエリすることで、分析やトリアージ中に役立つ可能性がある追加テレメトリーが得られます。

調査ガイドに関するご意見やご提案がある場合は、GitHubイシューを作成してお知らせください。コミュニティにご協力いただけますと幸いです。

潜在的脅威の特定支援の中核は質の高い検知ロジックですが、具体的な脅威に関する追加コンテキストを提供し、アナリストに役立ててもらうことも重要だと考えています。そのため、事前構築済み検索ルールでは、そのルール自体に関するコンテキストをできるだけ多く提供しようと努めています。

調査ガイド以外の取り組みも紹介します。まず、すべてのルールで特定のMITRE ATT&CKマトリックスへのマッピングを行い、アラートの緊急性とリスクを明らかにしています。また、取り込んでいるデータソースが多岐に渡る場合、適切なルールの選択に悩む可能性があるので、所定のルールに必要な統合を特定するサポートをしています。［Related Integrations］（関連する統合）フィールドを使うと、関連する統合に移動し、セットアップして、（必要に応じて）関連するルールを有効にし、適切なデータセットが取り込まれるようにできます。

追加コンテキストを含むルールの更新は通常は不定期にリリースされ、Elasticセキュリティソリューションで直接提供されます。スタックを最新バージョンにアップグレードして、新しいセキュリティ機能に即したルールを最大限に使えるようにすることをお勧めします。

その他

TRADEチームは、Red Team Automation（RTA）と呼ばれる検知ルールの機能にも取り組み、公開しています。この機能はPythonで作成されており、ルールのテストに役立ちます。RTAスクリプトを使うと無害なTPを生成でき、複数バージョンのElasticセキュリティソリューションを対象に検知ルールの回帰テストを自動化するのに役立ちます。公開されているRTAスクリプトを自身のテストに使うことも、自身のカスタムルール用に新しいスクリプトを作成することもできます。

チームが提供しているRTAやその他のツールについての詳細は、こちらのブログをご覧ください。

今後の展開をお楽しみに

これまで説明したように、Elasticでは、ルール作成から使用方法の説明、保守、テストまで、検知ワークフローと検知ルールのライフサイクル全体にわたって事前構築済みコンテンツを提供しようと努めています。繰り返しになりますが、それらのコンテンツはすべて、製品内で提供されているだけでなく、GitHubを通じてコミュニティにオープンに共有されています。

Elasticは常に、ユーザーのシステムがよりセキュアになり、セキュリティチームの仕事がより楽になるよう努力しています。アイデアや困りごとがあれば、ぜひお知らせください。ElasticのSlackコミュニティまたはDiscussフォーラムへの投稿を通じてご連絡いただけます。