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

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

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

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

• デバイスで ASIM ソース固有パーサーを使用できるが、デバイスから ASIM パーサーで想定されているものとは異なる方法または形式でイベントが送信される場合。 例えば次が挙げられます。

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

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

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

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

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

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

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

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

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

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

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

6. DeployパーサーをMicrosoft Sentinelワークスペースに配置します。

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

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

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

サンプル ログを収集する

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

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

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

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

計画マッピング

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

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

パーサーの開発

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

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

フィルター>解析>フィールドを準備

フィルター処理

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

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

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

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

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

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

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

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

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

パーサーで ASimSourceType ウォッチリストを使用するには、パーサー フィルターセクションの _ASIM_GetSourceBySourceType 関数を使用します。 例えば、InfobloxのDNSパーサーは以下のフィルターを含め、関連するSyslogレコードのみを処理することで、Infoblox NIOSソースのみにレコードを制限します。

  | 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)

array_length関数およびhas_any演算子の詳細については、Kustoのドキュメントをご覧ください。

• array_length 関数
• has_any 演算子

フィルター処理の最適化

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

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

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

例については、次の Infoblox DNS パーサー スニペットを参照してください。 パーサーはまず、SyslogMessage フィールドに has という単語 client が含まれていることを確認します。 ただし、この用語はメッセージ内の別の場所で使用される可能性があるため、 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 を使用します。 プロジェクト名の変更を使用すると、フィールドが物理フィールドとして引き続き管理され、フィールドの処理がよりパフォーマンスが高くなります。 例えば、以下のクエリはソースアカウントフィールドを正規化されたASIMアクターフィールド名にマッピングしています:

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

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

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

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

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

  | extend EventOriginalUid = tostring(ReportId),

派生フィールドと値

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

例えば、MicrosoftのDNSパーサーは、ソース固有のイベントコードやレスポンスコードから正規化された成功または失敗の結果を導き出します。 パーサはイベントIDと応答コードに基づいて EventResult フィールドを iff 文を用いて割り当てます。

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

複数の値をマップするには、 datatable 演算子を使用してマッピングを定義し、 lookup を使用してマッピングを実行します。 たとえば、一部のソースでは数値の DNS 応答コードとネットワーク プロトコルが報告されますが、スキーマでは両方に対してより一般的なテキスト ラベルの表現が義務付けられています。 以下の例は、数値プロトコル識別子や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は共通のルックアップ値のための組み込みヘルパー機能を提供しています。 よく知られたマッピングの datatable や lookup を手動で構築する代わりに、これらの関数を使って正規化されたフィールドを直接埋めることができます。 例えば、上記の 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 フィールドに格納されている値の種類を指定します。 型フィールドの詳細については、 エンティティの説明を参照してください。

ほとんどの場合、型には定数値も割り当てられます。 しかし、場合によっては実際の価値に基づいてタイプを決定しなければならないこともあります。 例えば、解析されたホスト名が複数のセグメントを含むかどうかを確認することで、解析されたホスト名が完全修辞ドメイン名(FQDN)かどうかを判断します。

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

Microsoft Sentinel は、エンリッチメントを処理するための便利な関数を提供します。 例えば、 _ASIM_ResolveSrcFQDN ヘルパー関数を使って、 Computer 列から正規化されたソースホスト名、ドメイン、ドメインタイプ、FQDNフィールドを導出します。 以下のスニペットは、Computerフィールドの値に基づいて自動的に、SrcHostname、SrcDomain、SrcDomainType、SrcFQDNフィールドを埋め込みます。

  | invoke _ASIM_ResolveSrcFQDN('Computer')

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

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

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

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

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

例えば、カスタムログテーブルを解析する際は、 _d、 _s、 _b、 _g の接尾辞付きフィールドなど、ソース固有のタイプ付き列を残して、パーサ出力に保持したい正規化されたフィールドのみを含ませるようにします。

    | 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…

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

パーサーをデプロイする

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

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

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

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

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

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

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

パーサーをテストする

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

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

ASIMテストツールを導入する前に、以下のMicrosoft Sentinel Workspaceを用意していることを確認してください。

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

ワークスペースがこれらの要件を満たしたら、 ASIMテストツール をそのワークスペースに展開します。

出力スキーマを検証する

パーサーが有効なスキーマを生成することを確認するために、Microsoft Sentinel Logsページで以下のスキーマテストクエリを実行してください。 このコマンドは、パーサーの出力フィールド、型、エイリアスが期待されるASIMスキーマと一致しているかを確認します:

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

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

出力値を検証する

パーサーが有効な値を生成するかを確認するために、ASIMデータテスターを使ってパーサー出力のサンプルのフィールド値を検証し、エラーや警告を特定しましょう。 Microsoft Sentinelログページで以下のクエリを実行してください:

<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ファイルに承認された警告を記録してください。 以下のYAML例は、パーサー定義の Exceptions セクションで承認されたパーサーテスト警告を記録する方法を示しています。

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ファイルで指定された警告は、対応するASIMテスター警告メッセージの短縮形であり、その特定の警告を識別できるほど一意であるべきです。 この値は、自動テスト中にASIMテスターの警告メッセージを照合し、一致した警告を無視するために使われます。

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

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

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

• Logs画面で、パーサーによって選択されたイベントのみをソース テーブルから抽出するクエリを実行します。 例えば、 Infoblox DNSパーサーの場合、以下のクエリを使ってパーサーが扱うInfoblox NIOS Syslogレコードのみを取得します。

    Syslog
    | where ProcessName == "named"

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

• Logs画面でソーステーブルにgetschemaを実行し、利用可能な列とその型を確認してください。 このスキーマ情報をサンプルデータと一緒にエクスポートしてください。 例えば、InfobloxのDNSパーサーの場合、クエリは次のようになります:

    Syslog
    | getschema

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

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

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

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

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

• Testパーサーで説明されている通りにパーサーテストを実行してください。

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

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

関連するコンテンツ

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

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

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

• 高度なセキュリティ情報モデル (ASIM) の概要
• 高度なセキュリティ情報モデル (ASIM) スキーマ
• Advanced Security Information Model (ASIM) コンテンツ
• Microsoft Sentinel の正規化パーサーと正規化コンテンツに関する詳細解説ウェビナー