イベントを適切に正規化する方法は？何かを忘れたり混乱させたりすることなく、異なるソースからの同様のイベントを正規化する方法は？しかし、2人の専門家が独立してこれを行うとしたらどうでしょうかこの記事では、この問題の解決に役立つ一般的な正規化手法を共有します。

画像： Martinoflynn.com

ほとんどの場合、相関ルールは正規化されたイベントに基づいて構築されます。したがって、イベントの正規化とその正確な実行方法は、相関ルールの精度に直接影響します。

イベントの正規化から生じる問題は最初の記事（ここ）で定式化され、解決策は後続の記事（こことここ）で提案されました。ここで、前述の内容を要約し、イベントを正規化する一般的なアプローチを作成します。

まず、正規化レベルのどのツールを開発したかを思い出してください。

イベントから取得したデータを保存するために必要なユニバーサルフィールドスキーマ。その特徴：
- イベントのサブジェクト、オブジェクト、ソース、およびトランスミッター、およびリソースのイベントの存在を考慮します。
- イベントにネットワークレベルとアプリケーションのエンティティが含まれ、複数のサブジェクトやオブジェクトがある場合に、正しい正規化を提供します。
- サブジェクトとオブジェクトの間の相互作用のプロセスの構造を明示的に識別および維持できます
ITまたはIBイベントのセマンティクスを反映できるイベント分類システム。

イベントの正規化方法

イベントを正規化するための方法論全体は、3つのステップで構成されています。

イベントの専門家による評価。
相互作用スキームの定義。
イベントカテゴリの定義。

ツールの仕組みを理解しやすくするために、イベントを選択し、方法論に従ってすべての正規化手順を詳細に検討します。

次のネットワークアドレッシングを備えたDBMS-Oracle Databaseのソースがあるとします。

IP ：10.0.0.1;
ホスト名 ：myoracle;
FQDN ：myoracle.local。

このソースから、SIEMエージェントは次のイベントをアンロードします。

ステップ1.イベントの専門家による評価

イベントを正規化するプロセスの最初に、このイベントが何であるかを理解することが重要です。その本質を自分自身に言うだけで十分です。まだ正規化されていない初期のイベントから、エキスパートがソースでどのプロセスが発生しているのかを理解していない場合は、誤って正規化する可能性が高くなります。次に、相関ルールのどのような正しい操作について話せますか？

エキスパートがイベントをいかに正確に解釈するかという問題は非常に現実的です。たとえば、専門家は次のイベントの意味を理解できますか？

元の例で、イベント自体のテキストからエッセンスを取得できる場合、この場合、どのソースで作業していて、どの場合に同様のイベントが生成されるかをよく理解する必要があります。複雑で解釈が難しいイベントをSIEMに送信する状況を完全に再現するために、ソースを備えた独立したスタンドを展開する必要がある場合もあります。

Oracle Databaseからのイベントを使用して元の例に戻りましょう。この段階で、専門家は次のように考える必要があります。

「 専門家として、最初のイベントはOracle Databaseのあるユーザーが別のユーザーからロールを取り消すプロセスを説明していると思います 。」

ステップ2.相互作用スキームの定義

前の手順により、少なくともイベントの一般的な意味を理解できるようになります。次に、エンティティを区別し、それらの相互作用のスキームを決定する方法を詳細に分析します。

この方法論によれば、各相互作用スキームについて、正規化されたイベントのフィールドでのキーエンティティ識別子の配布に関するルールを記述する必要があります。同時に、次のルールが定義されます。

ネットワークレベルのエンティティ
アプリケーションレベルのエンティティ。

サブジェクトがオブジェクトに等しく、ソースに等しいスキームがあることを覚えておくことが重要です。このようなスキームでは、3つのエンティティすべてのフィールドを埋めるためのルールを明確に定義する必要があります。これを行わないと、相関ルールまたはイベントの検索のレベルで問題が始まり、空のフィールドを正しく解釈するための追加のロジックが表示されます。これについて- 相互作用スキームに関する記事。

方法論のこのステップが最初の例でどのように機能するかを見てみましょう。

ネットワークレベルの相互作用スキーム ：送信機のない完全な直接収集スキーム。
アプリケーションレベルでの相互作用のスキーム ：リソースを介した相互作用。

これらのスキームでは、次の正規化ルールを定義できます。

ネットワーク層エンティティ：
- 件名：
  - フィールド：src.ip = <empty>
  - フィールド：src.hostname = alex_host
  - フィールド：src.fqdn = <empty>
- 対象
  - フィールド：dst.ip = 10.0.0.1
  - フィールド：dst.hostname = myoracle
  - フィールド：dst.fqdn = myoracle.local
- ソース（オブジェクトに一致） ：
  - フィールド：event_source.ip = 10.0.0.1
  - フィールド：event_source.hostname = myoracle
  - フィールド：event_source.fqdn = myoracle.local
- 送信機 ：
  - フィールド：forwarder.ip = <empty>
  - フィールド：forwarder.hostname = <empty>
  - フィールド：forwarder.fqdn = <empty>
- 相互作用のチャネル ：
  - フィールド：interact.id = 2342594
アプリケーションレベルのエンティティ（要素のコレクション）：
- 件名：
  - フィールド：subject [1] .name =“ Alex”
  - フィールド：subject [1] .type =“ account”
- 対象
  - フィールド：object [1] .name =“ Bob”
  - フィールド：object [1] .type =“ account”
- リソース ：
  - フィールド：resource [1] .name =“ MYROLE”
  - フィールド：resource [1] .type =“ role”

ステップ3.イベントカテゴリを定義する

イベントのすべての重要なエンティティが特定された後、イベントに反映されたプロセスの本質を記述し、正規化言語に移行する必要があります。これらの目的のために、イベントを分類するシステムが使用されます。イベント分類システムについては別の記事で詳しく説明しましたが、実際にどのように機能するかを見てみましょう。

正規化を統一するために、分類システムは次のルールを定義します。

ITおよび情報セキュリティイベントの各レベルの各カテゴリについて、専門家は、最初のイベントで見つけて正規化する必要がある情報のリストを含むディレクトリを作成します。
イベントにカテゴリが割り当てられている場合、専門家はディレクトリに従って、必要な情報を見つけて正規化する必要があります。
各カテゴリは、入力する必要がある正規化されたイベントスキーマフィールドのセットを定義します。

したがって、イベントに選択されたカテゴリは、以下の間の直接的な対応を確立します。

イベントのセマンティクス。
添付されたカテゴリに応じて、イベントから抽出される重要な情報。
この情報が「put」である必要がある正規化されたイベントのスキームのフィールドのセット。

このアプローチにより、正規化されたイベントのどのフィールドにどのデータが含まれているかを、イベントのカテゴリから明確に理解できます。

新しいソースのサポートにより、特定のカテゴリのイベントからいくつかの重要な情報を追加で抽出する必要があることが判明した場合、ディレクトリに入力されます。この場合、次のものが必要です。

イベントスキーマのフィールドに入力するためのルールを定義します。
以前にサポートされたすべてのソースのこのカテゴリのイベントの正規化を監査します。
以前に正規化されたイベントに新しい情報を追加します。

このようにして、行われた変更の一貫性が維持されます。元の例を考えてみましょう。

分類システムによると、このイベントには次のカテゴリがあります。

分類システム ：ITイベント
第1レベルのカテゴリー（レベル1） ：ユーザーと権利
第2レベルのカテゴリー（レベル2） ：ユーザー
第3レベルのカテゴリー（レベル3） ：操作

このカテゴリのディレクトリは次のようになります。

ユーザーと権利のカテゴリのイベントを正規化する場合、次のことを理解することが重要です。
- 特権エスカレーションが使用された場合、プロセスが実装されるのはそのためです。
  - フィールド：件名[i] .assign
- アクションが成功したか。
  - フィールド：result.status
- 戻りコードは何ですか。
  - フィールド：result.status.code
ユーザーカテゴリのイベントを正規化する場合、以下を理解することが重要です。
- ユーザーのマシンのIPアドレス、ホスト名、またはfqdnに関する情報はありますか。
  - フィールド：src.ip、src.hostname、src.fqdn
  - フィールド：dst.ip、dst.hostname、dst.fqdn
- ユーザーが接続したアカウント。
  - フィールド：サブジェクト[i] .name、オブジェクト[i] .name
- OSに彼のアカウントに関する情報はありますか。
  - フィールド：サブジェクト[i] .osname、オブジェクト[i] .osname
- ドメインアカウント情報はありますか？
  - フィールド：サブジェクト[i] .domain、オブジェクト[i] .domain
- ユーザーのアプリケーションに関する情報はありますか。
  - フィールド：件名[i] .application、オブジェクト[i] .application
操作カテゴリのイベントを正規化する場合、次のことを理解することが重要です。
- 操作のタイプ。
  - フィールド：interact.type
- 何が変わった。
  - フィールド：オブジェクト[i] .name、オブジェクト[i] .type-アカウントを変更する場合
  - フィールド：リソース[i] .name、リソース[i] .type-リソースを変更する場合
- 何が変わった。
  - フィールド：オブジェクト[i] .modify
  - フィールド：リソース[i] .modify
- 操作がリソースに対するものである場合、その所有者は誰ですか。
  - フィールド：リソース[i] .owner

このガイドは、その形成の原理を示すために提供したものであり、したがって、正確で完全なふりをするものではありません。

その結果、この方法で正規化されたイベントは次のようになります。

方法論の3番目のステップでの正規化されたイベントの例。

結論

経験によれば、多くの場合、相関ルールの誤検知につながるのは正規化エラーであり、均一な正規化ルールが存在しないことです。これで、取り除けなければ、少なくとも問題の影響を最小限に抑えるアプローチができました。

要約すると、アプローチには3つのステップが含まれます。

ステップ1 専門家は、最初のイベントで説明された現象の一般的な本質を理解しようとします。
ステップ2 エキスパートは、イベントのネットワークとアプリケーションレベルの主要なエンティティ、サブジェクト、オブジェクト、ソース、トランスミッタ、リソース、インタラクションチャネルを識別します。イベントでそれらを分離し、これらのエンティティの相互作用パターンを決定します。各スキームは、これらのエンティティを正規化されたイベントのフィールドに配置するためのルール、つまりスキームを生成します。これについては、エンティティインタラクションスキームに関する記事で詳しく説明されています。
ステップ3 エキスパートは、第1レベル、第2レベル、および第3レベルのカテゴリを決定します。カテゴリごとに、正規化されたときにイベントで見つけることが重要なデータの説明、正規化されたイベントのどのフィールドが見つかったデータを「置く」必要があるかについての情報を含むディレクトリを作成します。

さて、「箱から出して作業する」ための相関ルールの構築から、エンティティ自体-資産の絶え間ない変化の問題によってのみ分離されます。アドレスが変更され、新しい資産が導入され、古い資産が廃止され、クラスターノードが切り替えられ、仮想マシンが1つのデータセンターから別のデータセンターに移動します。これらの問題を克服する方法については、サイクルの次の記事で説明します。

一連の記事：

SIEMの深さ：すぐに使える相関。パート1：純粋なマーケティングか解決できない問題か？

SIEMの深さ：すぐに使える相関。パート2.「世界」モデルを反映したデータスキーマ

SIEMの深さ：すぐに使える相関。パート3.1。イベントの分類

SIEMの深さ：すぐに使える相関。パート3.2。イベントの正規化方法（ この記事 ）

SIEMの深さ：すぐに使える相関。パート4.相関ルールのコンテキストとしてのシステムモデル

SIEMの深さ：すぐに使える相関。パート5.相関ルールの開発方法

SIEMの深さ：すぐに使える相関。 パート3.2。 イベントの正規化方法

イベントの正規化方法

ステップ1.イベントの専門家による評価

ステップ2.相互作用スキームの定義

ステップ3.イベントカテゴリを定義する

結論

More articles:

SIEMの深さ：すぐに使える相関。パート3.2。イベントの正規化方法