セキュリティアナリストのためのElastic。パート1：文字列の検索。
目次：
目的：
Elasticはそのソリューションの速度と拡張性によりサイバーセキュリティ分野での足場を固めつつあり、より多くの新しいElasticユーザーが増加すると予想しています。これらのユーザーは、他のプラットフォームやSIEMでの経験から得た直感を持ってElasticにアプローチするでしょう。しかし、この直感はElasticで数回検索した後に直接的に挑戦されることがよくあります。このシリーズの目的は、Elasticの独自性についてセキュリティアナリストを迅速にキャッチアップさせることです。この投稿では、Elasticでの文字列データに対する適切な検索を構築するためのガイドを読者に提供します。分析済み テキスト および非分析済み キーワード データ型が文字列ベースのデータ検索に与える影響を誤解すると、誤解を招く結果をもたらします。この投稿を読むことで、分析の意図に沿った文字列検索を行うためのスキルをより適切に身に付けることができます。
概要：
- 始める前に
- 使用しているデータ型はどれですか？
- 違いの概要
- 違い1：トークナイズ＆用語
- 違い2：大文字小文字の区別
- 違い3：シンボルマッチング
始める前に：
Lucene
このブログ投稿ではLuceneを使用します。KQLは正規表現をまだサポートしておらず、必要です。
用語：データ型、マッピング、およびアナライザー：
Elasticのインデックスにデータがどのように保存されるかについて議論する際、マッピング、データ型、およびアナライザーという用語に精通しておく必要があります。
- データ型 – 値が保存/インデックス化される「型」、「データの型」、「データ型」。データ型の例としては：文字列、ブール型、整数、IPがあります。文字列は「テキスト」または「キーワード」のデータ型として保存/インデックス化されます。
- マッピング – これは、各フィールドをデータ型に割り当てる（マッピングする）設定です。 get mapping APIを介してアクセス可能です。「マッピングを取得」すると、データ型にマッピングされたフィールドが返されます。
- アナライザー – 文字列データが保存/インデックス化される前に、値は保存および検索を最適化するために前処理されます。アナライザーは文字列に対する検索を高速化するのに役立ちます。
文字列の保存方法：
文字列には2つの主要なデータ型があります： キーワード and テキスト.
- キーワード – 型の文字列は、その生の値のまま保存されます。アナライザーは適用されません。 キーワード are stored as their raw value. No analyzer is applied.
- テキスト – テキスト 型の文字列は分析されます。デフォルトで最も一般的なアナライザーは、 標準（テキスト）アナライザーです。この投稿では、｢テキスト｣データ型について説明する際には、標準アナライザーが使用されているデータ型について言及しています。他にもアナライザーがあり、カスタムアナライザーも可能です。 テキスト datatype with the standard analyzer. There are other analyzers, and custom analyzers are possible.
使用しているデータ型はどれですか？
あなたのElasticインスタンスが、文字列用の両方の テキスト and キーワード データ型を使用している可能性が非常に高いです。ただし、Elastic Common Schema (ECS) およびWinlogbeat は主に キーワード データ型を使用しています。
仮にECSを使用していても、管理者はマッピングをカスタマイズできます！特定のフィールドがどのようにマッピングされているかを知るには、Elasticインスタンスにクエリを送信することが必要です。これをするためには、get field mapping API、あるいは、get mapping APIを使用できます。定期的に検索を行ったりコンテンツを構築したりしているフィールドの最新のマッピングを把握しておくことは良い実践です。マッピングは変わることがありますが、フィールド名は同じまま残ることがあります。言い換えると、今日の キーワード フィールドが明日には テキスト フィールドになるかもしれません。
キーワード and テキスト の間の注目すべき違いは、以下のセクションで詳述されています。さらに検索結果に影響を与える各違いは、それぞれのセクションで詳しく探ります。
違いの概要
このセクションを一読して、これらのタイプがいつ一致するのかすぐに理解できるとは思っていません。各違いがそれぞれのセクションで詳述されます。表の各例も、その動作を説明するセクション内の表に配置されています。
違い
以下の表は、データ型の主要な違いを簡単に概観したものです。
| 違い | 標準（テキスト） | キーワード |
| トークナイズ | 用語に分割（トークナイズ）、元の値は失われるが、より速い | トークナイズされず、元の値は保持される |
| 大文字小文字の区別 | 大文字小文字を区別しない、大文字小文字の区別ができるクエリ不可 | 大文字小文字を区別する、正規表現を使用して大文字小文字を区別しないクエリ可能 |
| シンボル | 一般的に、非英数字は保存されません。ただし、特定のコンテキストで非英数字を保持します | 非英数字を保持 / シンボルを保持 |
動作の違い
以下の表は、タイプが検索動作に与える影響の実世界の例を示しています。
| 例の値 | クエリ | テキストマッチ | キーワードマッチ |
| Powershell.exe –encoded TvqQAAMA | process.args:encoded | Yes | No |
| Powershell.exe –encoded TvqQAAMA | process.args:/.*[Ee][Nn][Cc][Oo][Dd][Ee][Dd].*/ | Yes | Yes |
| Powershell.exe –encoded TvqQAAMA | process.args:*Powershell.exe*Tvq* | No | Yes |
| TVqQAAMA | process.args:*TVqQAAMA* | Yes | Yes |
| TVqQAAMA | process.args:*tvqqaama* | Yes | No |
| cmd.exe | process.name:cmd.exe | Yes | Yes |
| CmD.ExE | process.name:cmd.exe | Yes | No |
| CmD.ExE | process.name:/[Cc][Mm][Dd].[Ee][Xx][Ee]/ | Yes | Yes |
| \*$* | process.args:*\\*$* | No | Yes |
| \C$WindowsSystem32 | process.args:*C$\* | Yes | Yes |
_
違い1：アナライザー、トークナイズ＆用語
違い
| 違い | テキスト（標準アナライザー） | キーワード |
| トークナイズ | 用語に分割（トークナイズ済み） | 分析されず、トークナイズされず。元の値保持。 |
なぜ…？
The テキスト データ型／標準アナライザーは、文字列をチャンク（トークン）に分割するトークナイズを使用します。これらのトークンは、単語の境界（つまりスペース）、句読点などに基づいています。
例として、標準アナライザーで次の文字列をトークナイズした場合：「Elasticでの検索は簡単です」結果の用語は：「searching」 | 「for」 | 「thing」 | 「with」 | 「elastic」 | 「is」 | 「straightforward」すべてがスペース（単語の境界）でトークナイズされ、小文字化され、「s」は「thing」から削除されています。
トークナイズにより、包含やワイルドカードを使用せずに単一の用語に基づいたマッチングが可能になります。たとえば、「Elastic」で検索すると データ型の文字列に含まれる the テキスト 「Elasticでの検索は簡単です」 が一致します。他のSIEMがワイルドカードや「contains」ロジックに大きく依存するのとは異なります。
しかし、トークナイズは単語間のワイルドカードで中断されます。たとえば、 「*searching*Elastic*」 は標準分析された文字列「Elasticでの検索は簡単です」と一致しません。 注意：これは近接で対処できますが、順序は維持されません。例えば、「searching Elastic」~1 は、 「searching with Elastic」や 「Elastic with searching」と一致します。 セキュリティで正確な一致と単語間のワイルドカード使用が必要なことが多々あります。これが、
データ型がECSで事実上のデータ型となった理由の1つです。性能を犠牲にすることで、より精密な検索が可能になります。 キーワード 例
process.args: ”Powershell.exe –encoded”
| 例の値 | クエリ | テキストマッチ | キーワードマッチ |
| process.args: ”Powershell.exe –encoded” | 小文字で完全に保存されているため、大文字小文字を区別しません。ケースセンシティブなクエリは不可能です。 | Yes | Yes |
| Powershell.exe –encoded TvqQAAMA | process.args:/.*[Ee][Nn][Cc][Oo][Dd][Ee][Dd].*/ | Yes | Yes |
| Powershell.exe –encoded TvqQAAMA | process.args:encoded | Yes | No |
| Powershell.exe –encoded TvqQAAMA | 小文字で完全に保存されているため、大文字小文字を区別しません。ケースセンシティブなクエリは不可能です。 | No | Yes |
_
違い2：大文字小文字の区別
違い
| 違い | テキスト（標準アナライザー） | キーワード |
| 大文字小文字の区別 | 大文字小文字を区別します。正規表現を使用して大文字小文字を区別しないクエリが可能です。 | 大文字小文字の区別問題は、セキュリティ アナリストとしてのElasticの動作を理解する際の最も大きな原因の1つです。これは特に |
なぜ…？
データ型 (ECSクラウドの皆さん、こんにちは) に当てはまります。 キーワード ログ中のケースのずれた1文字が、 フィールドに対する不適切に構成されたクエリをバイパスさせることがあります。特定のデータを攻撃者が制御する部分が キーワード に到達する場合 (Windows 4688 & 4104イベントを考えてみてください)、正規表現を使用して大文字小文字を区別しないようにする必要があります! さらに、Elasticは、ケースの異なる1文字によってドキュメントがわずかに見落とされた場合でも警告を出さないため、意図したよりも少ない結果または多すぎる結果を得ることが、セキュリティ アナリストの混乱の主な原因です。
以下は 「PoWeRsHeLl」に対する基本的なマッチング例です。クエリが一致するのを防ぐためには、ほんの1文字のケースのずれだけで済むことがわかります。 はい（全ケースに一致）process.args:/[Pp][Oo][Ww][Ee][Rr][Ss][Hh][Ee][Ll][Ll]/
| 例の値 | クエリ | テキストマッチ | キーワードマッチ |
| はい（全ケースに一致） | Kibanaでの実際の例を示します。下の画像では、 | Yes | No |
| はい（全ケースに一致） | はい（全ケースに一致） | yes | yes |
| はい（全ケースに一致） | Kibanaでの実際の例を示します。下の画像では、 | yes | 型フィールド「process.args」に「windows」文字列がクエリされました。知らないアナリストにとって、これが十分に思えるかもしれません…42件の結果が返されました。ところが、「windows」を含むドキュメントがほしいと考えている場合、それは間違いです。この検索はケースセンシティブのため、「Windows」は一致しません。 |
ケースセンシティブ検索からの限られた結果 キーワード 以下のクエリでは、正規表現を用いて「windows」を検索することで、以前は「欠けていた」567件の結果が返されます！
最大の結果
希望として、私たちが
型を使っていて、正規表現を使用しない場合、「powershell」の正確な一致を超えたバリエーションを見逃すことになることを理解していますように。データが攻撃者によって制御される場合には、(正規表現をサポートしていないKQLを使用して)この状況を回避しないようにしてください。
注：Base64など、キーワードフィールドで大文字小文字を区別したい場合もあります。 キーワード 正規表現の文字セットを使用して、任意のクエリを大文字小文字を区別しないようにできます。例は以下の通りです。/[Cc]:\[Ww][Ii][Nn][Dd][Oo][Ww][Ss]\[Ss][Yy][Ss][Tt][Ee][Mm]32\.*/C:windowssystem32*
| すべてのシンボルは、データが入力されたフィールド全体がそのまま保持されるため、 | なぜ？ |
| cmd.exe | すべてのシンボルは、データが入力されたフィールド全体がそのまま保持されるため、 |
| なぜ？ | すべてのシンボルは、データが入力されたフィールド全体がそのまま保持されるため、 |
process.args: ”Powershell.exe –encoded”
| 例の値 | クエリ | テキストマッチ | キーワードマッチ |
| TVqQAAMA | なぜ？ | Yes | Yes |
| TVqQAAMA | すべてのシンボルは、データが入力されたフィールド全体がそのまま保持されるため、 | Yes | No |
| cmd.exe | process.name:cmd.exe | Yes | Yes |
| CmD.ExE | process.name:cmd.exe | Yes | No |
| CmD.ExE | process.name:/[Cc][Mm][Dd].[Ee][Xx][Ee]/ | Yes | Yes |
_
違い3：シンボルマッチング
違い
| 違い | テキスト（標準アナライザー） | キーワード |
| シンボル | 一般的に、非英数字は保存されません。ただし、特定のコンテキストで非英数字を保持します | 非英数字を保持 / シンボルを保持 |
タイプでは保持されます。（注を参照）ただし、標準アナライザーでは、一般的なルールとして、シンボルは保持されません。これはアナライザーが全体的な単語マッチング用に作られており、シンボルは言葉ではないためです。言い換えれば標準アナライザーでは、シンボルは（大半が）保存されません。ですので、
シンボルでマッチするつもりがある場合、 キーワード データ型を使用するのが最適です。ただし、テキストフィールドしかなく、一連のシンボルにマッチしないといけない場合はどうにもなりません。 しかし、標準アナライザーでは、シンボルが保持されるコンテキストがあります。たとえば、「cmd.exe」などの用語ではピリオドが保持されます。著者は標準アナライザーでシンボルがどのように保持されるかを理解する最も簡単な方法は、analyze APIでテストデータを実行することだとしばしば見出しました。 キーワード 結論 Elasticは強力なツールです。しかし、それは誤解を招くことがあります。我々が少しでも知識を武器にし、文字列ベースのデータに対して自信を持って検索する力を持つことを願っています。
すべてElastic用のコンテンツ作成に助言が必要だと感じる場合、SOC Primeの
process.args: ”Powershell.exe –encoded”
| 例の値 | クエリ | テキストマッチ | キーワードマッチ |
| \*$* | process.args:*\\*$* | No | Yes |
| \C$WindowsSystem32 | process.args:*C$\* | Yes | Yes |
| cmd.exe | process.name:cmd.exe | Yes | Yes |
_
将来の投稿
には、私たちのお勧めのElastic設定を使用したデテクションコンテンツが満載されています。 将来の投稿 Elasticをセキュリティ アナリストとして使用する基礎およびかなりの応用を探るさらなるブログ投稿をお見逃しなく。
検索に関する追加リソース：
このシリーズは、分析者の痛点に焦点を当てており、構文の詳細には入り込まずに進めています。Elasticの提供する
Lucene構文
に関する詳細なドキュメントが存在します。また、以下の注目すべきいくつかの質の高いコミュニティ製チートシートがあります：特に McAndreのFlorian RothとThomas Patzkeの メタ： and 公開日 – 2020年3月
最終更新 – 3月12日
著者 – Adam Swan (@acalarch) Nate Guagenti (@neu5ron) の協力により
使用Elasticバージョン：7.5.2
例に使用したログ：.
https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES
Published – March 2020
Last Updated – 12 March
Authors – Adam Swan (@acalarch) with help from Nate Guagenti (@neu5ron)
Elastic Version Used: 7.5.2
Logs Used In Examples: https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES
