高度なセキュリティ情報モデル (ASIM) パーサーを開発する

高度なセキュリティ情報モデル (ASIM) ユーザーは、クエリでテーブル名ではなく 統合パーサーを 使用して、正規化された形式でデータを表示し、スキーマに関連するすべてのデータをクエリに含めます。 パーサーを統合するには、 ソース固有のパーサーを 使用して、各ソースの特定の詳細を処理します。

Microsoft Sentinelは、多くのデータ ソースに組み込みのソース固有のパーサーを提供します。 次の状況では、これらのソース固有のパーサーを変更または 開発することができます。

• デバイスが ASIM スキーマに適合するイベントを提供するが、デバイスと関連するスキーマのソース固有のパーサーをMicrosoft Sentinelで使用できない場合。

• デバイスで ASIM ソース固有のパーサーを使用できるが、デバイスが ASIM パーサーによって予期される形式とは異なるメソッドまたは形式でイベントを送信する場合。 例:

  • ソース デバイスは、標準以外の方法でイベントを送信するように構成できます。

  • デバイスのバージョンは、ASIM パーサーでサポートされているバージョンとは異なる場合があります。

  • イベントは、中間システムによって収集、変更、転送される可能性があります。

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

カスタム ASIM パーサー開発プロセス

次のワークフローでは、ソース固有のカスタム ASIM パーサーを開発する際の大まかな手順について説明します。

1. サンプル ログを収集します。

2. ソースから送信されたイベントが表すスキーマまたはスキーマを特定します。 詳細については、「スキーマの 概要」を参照してください。

3. ソース イベント フィールドを識別されたスキーマまたはスキーマにマップします。

4. ソース用の 1 つ以上の ASIM パーサーを開発します。 ソースに関連するスキーマごとに、フィルターパーサーとパラメーターレスパーサーを開発する必要があります。

5. パーサーをテストします。

6. パーサーをMicrosoft Sentinelワークスペースにデプロイします。

7. 関連する ASIM 統合パーサーを更新して、新しいカスタム パーサーを参照します。 詳細については、「 ASIM パーサーの管理」を参照してください。

8. また、パーサーをプライマリ ASIM ディストリビューションに 提供 することもできます。 提供されたパーサーは、組み込みのパーサーとしてすべてのワークスペースで使用することもできます。

この記事では、プロセスの開発、テスト、デプロイの手順について説明します。

サンプル ログを収集する

効果的な ASIM パーサーを構築するには、代表的なログ セットが必要です。ほとんどの場合、ソース システムを設定してMicrosoft Sentinelに接続する必要があります。 ソース デバイスを使用できない場合は、クラウド従量課金制サービスを使用して、開発とテストのために多数のデバイスをデプロイできます。

さらに、ログのベンダーのドキュメントとサンプルを見つけることは、広範なログ形式のカバレッジを確保することで、開発を加速し、間違いを減らすのに役立ちます。

ログの代表的なセットには、次のものが含まれている必要があります。

• イベントの結果が異なるイベント。
• 応答アクションが異なるイベント。
• ユーザー名、ホスト名、ID、および値の正規化を必要とするその他のフィールドのさまざまな形式。

計画マッピング

パーサーを開発する前に、ソース イベントまたはイベントで使用できる情報を、特定したスキーマにマップします。

• すべての必須フィールドと推奨されるフィールドをマップします。
• ソースから使用可能な情報を正規化されたフィールドにマップしてみてください。 選択したスキーマの一部として使用できない場合は、他のスキーマで使用できるフィールドへのマッピングを検討してください。
• ソースのフィールドの値を、ASIM によって許可される正規化された値にマップします。 元の値は、 EventOriginalResultDetailsなどの別のフィールドに格納されます。

パーサーの開発

関連するスキーマごとに、フィルター処理とパラメーターレス パーサーの両方を開発します。

カスタム パーサーは、Microsoft Sentinel ログ ページで開発された KQL クエリです。 パーサー クエリには、次の 3 つの部分があります。

フィルター>Parse>フィールドの準備

フィルター処理

関連レコードのフィルター処理

多くの場合、Microsoft Sentinelのテーブルには複数の種類のイベントが含まれています。 例:

• Syslog テーブルには、複数のソースからのデータがあります。
• カスタム テーブルには、複数のイベントの種類を提供し、さまざまなスキーマに適合できる 1 つのソースからの情報が含まれる場合があります。

そのため、パーサーはまず、ターゲット スキーマに関連するレコードのみをフィルター処理する必要があります。

KQL でのフィルター処理は、 where 演算子を使用して行われます。 たとえば、 Sysmon イベント 1 はプロセスの作成を報告するため、 ProcessEvent スキーマに正規化されます。 Sysmon イベント 1 イベントは、Event テーブルの一部であるため、次のフィルターを使用します。

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Watchlist を使用したソースの種類によるフィルター処理

場合によっては、イベント自体に、特定のソースの種類のフィルター処理を可能にする情報が含まれていません。

たとえば、Infoblox DNS イベントは Syslog メッセージとして送信され、他のソースから送信される Syslog メッセージとは区別が難しくなります。 このような場合、パーサーは関連するイベントを定義するソースの一覧に依存します。 このリストは、 Sources_by_SourceType ウォッチリストに保持されます。

パーサーで ASimSourceType ウォッチリストを使用するには、パーサー フィルターセクションの _ASIM_GetSourceBySourceType 関数を使用します。 たとえば、Infoblox DNS パーサーには、フィルター処理セクションに次のものが含まれます。

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

パーサーでこのサンプルを使用するには:

• Computerを、ソースのソース情報を含むフィールドの名前に置き換えます。 これは、Syslog に基づくすべてのパーサーの Computer として保持できます。

• InfobloxNIOS トークンを、パーサーの任意の値に置き換えます。 選択した値と、この種類のイベントを送信するソースの一覧を使用して、 ASimSourceType ウォッチリストを更新する必要があることをパーサー ユーザーに通知します。

パーサー パラメーターに基づくフィルター処理

フィルター パーサーを開発するときは、そのスキーマのリファレンス記事に記載されているように、パーサーが関連するスキーマのフィルター処理パラメーターを受け入れることを確認します。 既存のパーサーを開始点として使用すると、パーサーに正しい関数シグネチャが確実に含まれます。 ほとんどの場合、実際のフィルター コードは、同じスキーマのパーサーをフィルター処理する場合にも似ています。

フィルター処理を行うときは、次の点を確認してください。

• 物理フィールドを使用して解析する前にフィルター処理します。 フィルター処理された結果が十分に正確でない場合は、解析後にテストを繰り返して結果を微調整します。 詳細については、「 フィルターの最適化」を参照してください。
• パラメーターが定義されておらず、既定値が残っている場合はフィルター処理しないでください。

次の例では、文字列パラメーターのフィルター処理を実装する方法を示します。既定値は通常は '*' で、list パラメーターの場合は既定値は通常は空のリストです。

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Kusto ドキュメントの次の項目の詳細を参照してください。

• array_length 関数
• has_any 演算子

フィルター処理の最適化

パーサーのパフォーマンスを確保するには、次のフィルター処理に関する推奨事項に注意してください。

• 解析されたフィールドではなく、組み込みのフィールドで常にフィルター処理します。 解析されたフィールドを使用してフィルター処理する方が簡単な場合もありますが、パフォーマンスに大きな影響を与えます。
• 最適化されたパフォーマンスを提供する演算子を使用します。 特に、 ==、 has、および startswith。 containsやmatches regexなどの演算子を使用すると、パフォーマンスにも大きな影響を与えます。

パフォーマンスに関するフィルター処理の推奨事項は、必ずしも簡単に従えない場合があります。 たとえば、 has の使用は、 containsよりも正確ではありません。 他の場合、 SyslogMessageなどの組み込みフィールドの照合は、 DvcActionなどの抽出されたフィールドを比較するよりも正確ではありません。 このような場合でも、組み込みのフィールドに対してパフォーマンス最適化演算子を使用して事前にフィルター処理し、解析後により正確な条件を使用してフィルターを繰り返することをお勧めします。

例については、次の Infoblox DNS パーサー スニペットを参照してください。 パーサーはまず、SyslogMessage フィールドが client という単語hasすることを確認します。 ただし、この用語はメッセージ内の別の場所で使用される可能性があるため、 Log_Type フィールドを解析した後、パーサーは、 client という単語が実際にフィールドの値であることを再度確認します。

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

解析

クエリで関連するレコードを選択したら、それらを解析する必要がある場合があります。 通常、1 つのテキスト フィールドに複数のイベント フィールドが伝達される場合は、解析が必要です。

解析を実行する KQL 演算子を次に示します。パフォーマンスの最適化によって順序付けられます。 1 つ目は最も最適化されたパフォーマンスを提供し、最後のパフォーマンスは最も最適化されていないパフォーマンスを提供します。

正規化

フィールド名のマッピング

正規化の最も簡単な形式は、元のフィールドの名前を正規化された名前に変更することです。 そのための演算子 project-rename を使用します。 プロジェクト名の変更を使用すると、フィールドが物理フィールドとして引き続き管理され、フィールドの処理がよりパフォーマンスが高くなります。 例:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

フィールドの書式と型の正規化

多くの場合、抽出された元の値を正規化する必要があります。 たとえば、ASIM では MAC アドレスがコロンを区切り記号として使用し、ソースはハイフン区切り MAC アドレスを送信する場合があります。 値を変換するための主要な演算子は、KQL 文字列、数値、日付関数の広範なセットと共に extendされます。

また、パーサー出力フィールドがスキーマで定義されている型と一致することを確認することは、パーサーが機能するために重要です。 たとえば、日付と時刻を表す文字列を datetime フィールドに変換する必要がある場合があります。 このような場合、 todatetime や tohex などの関数が役立ちます。

たとえば、元の一意のイベント ID は整数として送信される場合がありますが、ASIM では、データ ソース間の広範な互換性を確保するために、値を文字列にする必要があります。 したがって、ソース フィールドを割り当てる場合は、project-renameではなくextendとtostringを使用します。

  | extend EventOriginalUid = tostring(ReportId),

派生フィールドと値

抽出されたソース フィールドの値は、ターゲット スキーマ フィールドに指定された値のセットにマップする必要がある場合があります。 関数 iff、 case、および lookup は、使用可能なデータをターゲット値にマップするのに役立ちます。

たとえば、Microsoft DNS パーサーは、次のように、iff ステートメントを使用して、イベント ID と応答コードに基づいてEventResult フィールドを割り当てます。

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

複数の値をマップするには、 datatable 演算子を使用してマッピングを定義し、 lookup を使用してマッピングを実行します。 たとえば、一部のソースでは数値の DNS 応答コードとネットワーク プロトコルが報告されますが、スキーマでは両方に対してより一般的なテキスト ラベルの表現が義務付けられています。 次の例では、 datatable と lookupを使用して必要な値を派生させる方法を示します。

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

マッピングに使用可能な値が 2 つしかない場合でも、参照が便利で効率的であることに注意してください。

マッピング条件が複雑な場合は、 iff、 case、および lookupを結合します。 次の例は、 lookup と caseを組み合わせる方法を示しています。 上記の lookup 例では、ルックアップ値が見つからない場合、 DnsResponseCodeName フィールドに空の値が返されます。 次の case 例では、使用可能な場合は lookup 操作の結果を使用し、それ以外の場合は追加の条件を指定して、それを強化します。

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinelは、一般的な参照値に便利な関数を提供します。 たとえば、上記の DnsResponseCodeName 参照は、次のいずれかの関数を使用して実装できます。

| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

最初のオプションは、検索する値をパラメーターとして受け取り、出力フィールドを選択できるため、一般的なルックアップ関数として役立ちます。 2 番目のオプションは、パーサーに合ったものであり、ソース フィールドの名前を入力として受け取り、必要な ASIM フィールドを更新します (この場合は DnsResponseCodeName)。

ASIM ヘルプ関数の完全な一覧については、ASIM 関数に関するページを参照してください。

エンリッチメント フィールド

ソースから使用できるフィールドに加えて、結果の ASIM イベントには、パーサーが生成する必要があるエンリッチメント フィールドが含まれます。 多くの場合、パーサーは次のようにフィールドに定数値を割り当てることができます。

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

パーサーが設定する必要があるエンリッチメント フィールドのもう 1 つの種類は、関連フィールドに格納されている値の型を指定する型フィールドです。 たとえば、 SrcUsernameType フィールドは、 SrcUsername フィールドに格納されている値の種類を指定します。 型フィールドの詳細については、 エンティティの説明を参照してください。

ほとんどの場合、型には定数値も割り当てられます。 ただし、場合によっては、次のような実際の値に基づいて型を決定する必要があります。

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinelは、エンリッチメントを処理するための便利な機能を提供します。 たとえば、次の関数を使用して、フィールド Computerの値に基づいてフィールドSrcHostname、SrcDomain、SrcDomainType、SrcFQDNを自動的に割り当てます。

  | invoke _ASIM_ResolveSrcFQDN('Computer')

この関数は、フィールドを次のように設定します。

関数 _ASIM_ResolveDstFQDN と _ASIM_ResolveDvcFQDN 、関連する Dst フィールドと Dvc フィールドを設定する同様のタスクを実行します。 ASIM ヘルプ関数の完全な一覧については、ASIM 関数に関するページを参照してください。

結果セット内のフィールドを選択する

パーサーは、必要に応じて結果セット内のフィールドを選択できます。 不要なフィールドを削除すると、正規化されたフィールドと残りのソース フィールドの間で混乱を避けることで、パフォーマンスが向上し、明確になります。

結果セット内のフィールドを選択するには、次の KQL 演算子を使用します。

たとえば、カスタム ログ テーブルを解析する場合は、次を使用して、型記述子を持つ残りの元のフィールドを削除します。

    | project-away
        *_d, *_s, *_b, *_g

バリアントの解析を処理する

多くの場合、イベント ストリーム内のイベントには、異なる解析ロジックを必要とするバリアントが含まれます。 1 つのパーサーでさまざまなバリアントを解析するには、 iff や caseなどの条件付きステートメントを使用するか、共用体構造を使用します。

unionを使用して複数のバリアントを処理するには、バリアントごとに個別の関数を作成し、union ステートメントを使用して結果を結合します。

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

重複するイベントや過剰な処理を回避するには、各関数が、解析対象のイベントのみをネイティブ フィールドを使用してフィルター処理することによって開始されるようにします。 また、必要に応じて、共用体の前の各ブランチでプロジェクトを離れて使用します。

パーサーをデプロイする

パーサーを手動でデプロイするには、[ログの監視] ページAzureにコピーし、クエリを関数として保存します。 このメソッドは、テストに役立ちます。 詳細については、「 関数の作成」を参照してください。

多数のパーサーをデプロイするには、次のようにパーサー ARM テンプレートを使用することをお勧めします。

1. スキーマごとに関連するテンプレートに基づいて YAML ファイルを作成し、クエリを含めます。 まず、スキーマとパーサーの種類、フィルター処理、またはパラメーターレスに関連する YAML テンプレート から始めます。

2. ASIM YAML から ARM へのテンプレート コンバーターを使用して、YAML ファイルを ARM テンプレートに変換します。

3. 更新プログラムをデプロイする場合は、ポータルまたは関数削除 PowerShell ツールを使用して、以前のバージョンの関数を削除します。

4. Azure portalまたは PowerShell を使用してテンプレートをデプロイします。

リンクされたテンプレートを使用して、複数のテンプレートを 1 つのデプロイ プロセスに結合することもできます

パーサーのテスト

このセクションでは、パーサーをテストできる ASIM が提供するテスト ツールについて説明します。 ただし、パーサーはコードであり、場合によっては複雑な場合があり、自動テストに加えて、コード レビューなどの標準的な品質保証プラクティスが推奨されます。

ASIM テスト ツールをインストールする

ASIM をテストするには、ASIM テスト ツールを次の場所にあるMicrosoft Sentinel ワークスペースにデプロイします。

• パーサーがデプロイされます。
• パーサーで使用されるソース テーブルを使用できます。
• パーサーによって使用されるソース テーブルには、関連するイベントのさまざまなコレクションが設定されます。

出力スキーマを検証する

パーサーが有効なスキーマを生成することを確認するには、[Microsoft Sentinel ログ] ページで次のクエリを実行して、ASIM スキーマ テスターを使用します。

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

結果を次のように処理します。

出力値を検証する

パーサーが有効な値を生成することを確認するには、[Microsoft Sentinel ログ] ページで次のクエリを実行して、ASIM データ テスターを使用します。

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

スキーマの指定は省略可能です。 スキーマが指定されていない場合は、 EventSchema フィールドを使用して、イベントが準拠するスキーマを識別します。 イベントに EventSchema フィールドが含まれていない場合、一般的なフィールドのみが検証されます。 スキーマがパラメーターとして指定されている場合、このスキーマを使用してすべてのレコードがテストされます。 これは、 EventSchema フィールドを設定しない古いパーサーに役立ちます。

このテストはリソースを集中的に使用するため、データ セット全体では機能しない場合があります。 [X] を、クエリがタイムアウトしない最大の数値に設定するか、時間範囲ピッカーを使用してクエリの時間範囲を設定します。

結果を次のように処理します。

メッセージの多くは、メッセージを生成したレコードの数と、サンプル全体の割合も報告します。 この割合は、問題の重要性を示す適切な指標です。 たとえば、推奨されるフィールドの場合:

• 90% の空の値は、一般的な解析の問題を示している可能性があります。
• 25% の空の値は、正しく解析されなかったイベントバリアントを示している可能性があります。
• 一部の空の値はごくわずかの問題である可能性があります。

パーサーを投稿する

パーサーをプライマリ ASIM ディストリビューションに提供することもできます。 受け入れられた場合、パーサーはすべての顧客が ASIM 組み込みパーサーとして使用できるようになります。

パーサーを提供するには:

• フィルター処理パーサーとパラメーターレス パーサーの両方を開発します。
• 上記の「パーサーのデプロイ」の説明に従って 、パーサー の YAML ファイルを作成します。
• パーサーがエラーなしですべての テストに 合格することを確認します。 警告が残っている場合は、パーサー YAML ファイルに 文書化します 。
• Microsoft Sentinel GitHub リポジトリに対して、次のような pull request を作成します。
  • ASIM パーサー フォルダー内のパーサーの YAML ファイル (/Parsers/ASim<schema>/Parsers)
  • サンプル提出ガイドラインに従った代表的なサンプル データ。
  • テスト結果 の提出ガイドラインに従ったテスト結果。

受け入れられた警告の文書化

ASIM テスト ツールによって一覧表示されている警告がパーサーに対して有効と見なされる場合は、次の例に示すように、パーサー YAML ファイルで受け入れられた警告を[例外] セクションを使用して文書化します。

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

YAML ファイルで指定する警告は、一意に識別する警告メッセージの短い形式である必要があります。 この値は、自動テストを実行するときに警告メッセージと一致し、無視するために使用されます。

サンプル提出ガイドライン

サンプル データは、パーサーの問題のトラブルシューティングを行う場合や、パーサーの今後の更新が古いサンプルに準拠していることを確認するために必要です。 送信するサンプルには、パーサーがサポートするイベントバリアントが含まれている必要があります。 サンプル イベントに、成功したアクティビティと失敗したアクティビティを表すイベントなど、可能なすべてのイベントの種類、イベント形式、バリエーションが含まれていることを確認します。 また、値形式のバリエーションが表されていることを確認します。 たとえば、ホスト名を FQDN または単純なホスト名として表すことができる場合、サンプル イベントには両方の形式を含める必要があります。

イベント サンプルを送信するには、次の手順に従います。

• Logs画面で、パーサーによって選択されたイベントのみをソース テーブルから抽出するクエリを実行します。 たとえば、 Infoblox DNS パーサーの場合は、次のクエリを使用します。

    Syslog
    | where ProcessName == "named"

• [ CSV にエクスポート ] オプションを使用して結果を <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv という名前のファイルにエクスポートします。ここで、 EventProduct、 EventProduct、 EventSchema はパーサーによってこれらのフィールドに割り当てられた値です。

• Logs画面で、スキーマまたはパーサー入力テーブルを出力するクエリを実行します。 たとえば、同じ Infoblox DNS パーサーの場合、クエリは次のようになります。

    Syslog
    | getschema

• [ CSV にエクスポート] オプションを使用して結果を <TableName>_schema.csv という名前のファイルにエクスポートします。ここで、 TableName はパーサーが使用するソース テーブルの名前です。

• 両方のファイルを PR フォルダー /Sample Data/ASIMに含めます。 ファイルが既に存在する場合は、次のように GitHub ハンドルを名前に追加します。 <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

テスト結果の提出ガイドライン

テスト結果は、パーサーの正確性を確認し、報告された例外を理解するために重要です。

テスト結果を送信するには、次の手順に従います。

• パーサー テストを実行し、「 testings 」セクションで説明します。

• [ CSV にエクスポート ] オプションを使用して、それぞれ <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv および <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv という名前のファイルにテスト結果をエクスポートします。

• 両方のファイルを PR フォルダー /Parsers/ASim<schema>/Testsに含めます。

次の手順

この記事では、ASIM パーサーの開発について説明します。

ASIM パーサーの詳細については、以下を参照してください。

• ASIM パーサーの概要
• ASIM パーサーを使用する
• ASIM パーサーを管理する
• ASIM パーサーの一覧

一般的な ASIM の詳細については、次を参照してください。

• パーサーの正規化と正規化されたコンテンツのMicrosoft Sentinelに関する詳細なウェビナーを見る、またはスライドを確認する
• 高度なセキュリティ情報モデル (ASIM) の概要
• 高度なセキュリティ情報モデル (ASIM) スキーマ
• 高度なセキュリティ情報モデル (ASIM) コンテンツ