Advanced Security Information Model (ASIM) スキーマ

Advanced Security Information Model (ASIM) スキーマは、アクティビティまたはエンティティを表す一連のフィールドです。 クエリで正規化されたスキーマのフィールドを使用すると、すべての正規化されたソースでクエリが動作します。

スキーマが ASIM アーキテクチャにどのように適合するかを理解するには、ASIM アーキテクチャの図を参照してください。

アクティビティ/イベント スキーマ

スキーマ リファレンスでは、各スキーマを構成するフィールドの概要が示されています。 ASIM では現在、イベントに対して次のスキーマが定義されています。

エンティティ スキーマ

ASIM では現在、エンティティに対して次のスキーマが定義されています。

フィールドの名前付け

各スキーマの中核となるのは、そのフィールド名です。 フィールド名は、次のグループに属します。

• すべてのスキーマに共通のフィールド。
• スキーマに固有のフィールド。
• スキーマに含まれるエンティティ (ユーザーなど) を表すフィールド。 エンティティを表すフィールドは、スキーマ間で類似しています。

文書化されたスキーマに存在しないフィールドがソースにある場合、一貫性を維持するために正規化されます。 追加のフィールドがエンティティを表す場合は、エンティティ フィールドのガイドラインに基づいて正規化されます。 それ以外の場合、スキーマはすべてのスキーマ間で一貫性を保つように努めます。

たとえば、DNS サーバーのアクティビティ ログではユーザー情報が提供されない一方で、エンドポイントからの DNS アクティビティ ログにはユーザー情報が含まれる場合があります。これは、ユーザー エンティティのガイドラインに従って正規化できます。

共通フィールド

一部のフィールドは、すべての ASIM スキーマに共通です。 各スキーマによって、共通フィールドの一部を特定のスキーマのコンテキストで使うためのガイドラインが追加されることがあります。 たとえば、EventType フィールドに使用できる値はスキーマごとに異なる可能性があり、EventSchemaVersion フィールドの値も同様に異なる可能性があります。

フィールドクラス

フィールドには、パーサーによってフィールドを実装する必要があるタイミングを定義する、いくつかのクラスが含まれる場合があります。

• 必須 フィールドは、すべてのパーサーに含まれる必要があります。 ソースがこの値の情報を提供しない場合、またはデータを追加できない場合、正規化されたスキーマを参照するほとんどのコンテンツ項目はサポートされません。
• 推奨される フィールドは、使用可能な場合は正規化する必要があります。 ただし、すべてのソースで利用できるとは限りません。 正規化されたスキーマを参照するコンテンツ項目では利用可能性を考慮する必要があります。
• 省略可能な フィールド (使用可能な場合) は、正規化することも、元の形式のままにすることもできます。 通常、最小限のパーサーでは、パフォーマンス上の理由から正規化されません。
• 条件付き フィールドは、フォローするフィールドが設定されている場合は必須です。 通常、条件付きフィールドは、別のフィールドの値を記述するために使用されます。 たとえば、共通フィールド DvcIdType は共通フィールド DvcId の値 int を記述するため、後者が設定されている場合は必須です。
• エイリアス は、条件付きフィールドの特殊な型であり、エイリアス化されたフィールドが設定されている場合は必須です。

イベントエンティティ

イベントは、ユーザー、ホスト、プロセス、ファイルなどのエンティティを中心に発展します。 各エンティティは、それを記述するために複数のフィールドを必要とする場合があります。 たとえば、ホストは名前と IP アドレスを持つことができます。

1 つのレコードに、ソース ホストと宛先ホストの両方など、同じ種類の複数のエンティティが含まれる場合があります。

ASIM によって、エンティティを一貫して記述する方法が定義され、エンティティではスキーマの拡張が考慮されます。

たとえば、Network Session スキーマにはプロセス情報は含まれませんが、一部のイベント ソースによって追加できるプロセス情報が提供されます。 詳しくは、「エンティティ」をご覧ください。

エンティティの機能を有効にするために、エンティティ表現には次のガイドラインがあります。

特定のエンティティ型の詳細については、以下を参照してください。

• ユーザー エンティティ
• デバイス エンティティ
• アプリケーション エンティティ

Aliases

エイリアスでは、指定した値に対して複数の名前が許可されます。 場合によっては、あるフィールドに対して予想される名前がユーザーによって異なるケースがあります。 たとえば、DNS の用語では DnsQuery という名前のフィールドを想定する場合がありますが、より一般的には、これにはドメイン名が保持されます。 エイリアス Domain は、両方の名前の使用を許可することでユーザーの役に立ちます。

場合によっては、イベントで使用できる値に応じて、エイリアスに複数のフィールドの 1 つの値が入ります。 たとえば、Dvc エイリアスには、DvcFQDN、DvcId、DvcHostname、DvcIpAddr、Event Product のいずれかのフィールドが入ります。 1 つのエイリアスに複数の値が入る可能性がある場合、その型は、可能なすべてのエイリアス値に対応する文字列である必要があります。 そのため、そのようなエイリアスに値を割り当てるときには、KQL 関数 tostring を使用して型を文字列に確実に変換してください。

ネイティブの正規化されたテーブル には、重複するデータ ストレージを意味するエイリアスは含まれません。 代わりに、スタブ パーサーによってエイリアスを追加します。 パーサーでエイリアスを実装するには、 演算子を使用して元の値のコピーを作成します。

論理型

スキーマの各フィールドには型があります。 Log Analytics ワークスペースには、限られたデータ型のセットがあります。 このため、Microsoft Sentinelは多くのスキーマ フィールドに論理型を使用します。Log Analyticsは適用されませんが、スキーマの互換性のために必要です。 論理フィールド型を使用すると、ソース間で値とフィールド名の両方の一貫性が保たれます。

エンティティ マッピングの例

このセクションではWindowsイベント 4624 を例として使用して、Microsoft Sentinelのイベント データを正規化する方法について説明します。

このイベントには、次のエンティティがあります。

これらのエンティティに基づいて、Windows イベント 4624 は次のように正規化されます (一部のフィールドは省略可能です)。

次のステップ

この記事では、Microsoft Sentinelと ASIM での正規化の概要について説明します。

詳細については、次を参照してください。

• Microsoft Sentinelの正規化パーサーと正規化コンテンツに関するDeep Dive ウェビナーを見るか、スライドを確認してください。
• Advanced Security Information Model (ASIM) の概要
• Advanced Security Information Model (ASIM) のパーサー
• Advanced Security Information Model (ASIM) コンテンツ