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

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

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

デバイスが ASIM スキーマに適合するイベントを提供するが、デバイスと関連するスキーマのソース固有のパーサーをMicrosoft Sentinelで使用できない場合。
デバイスで ASIM ソース固有のパーサーを使用できるが、デバイスが ASIM パーサーによって予期される形式とは異なるメソッドまたは形式でイベントを送信する場合。例:
- ソースデバイスは、標準以外の方法でイベントを送信するように構成できます。
- デバイスのバージョンは、ASIM パーサーでサポートされているバージョンとは異なる場合があります。
- イベントは、中間システムによって収集、変更、転送される可能性があります。

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

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

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

サンプルログを収集します。
ソースから送信されたイベントが表すスキーマまたはスキーマを特定します。詳細については、「スキーマの概要」を参照してください。
ソースイベントフィールドを識別されたスキーマまたはスキーマにマップします。
ソース用の 1 つ以上の ASIM パーサーを開発します。ソースに関連するスキーマごとに、フィルターパーサーとパラメーターレスパーサーを開発する必要があります。
パーサーをテストします。
パーサーをMicrosoft Sentinelワークスペースにデプロイします。
関連する ASIM 統合パーサーを更新して、新しいカスタムパーサーを参照します。詳細については、「 ASIM パーサーの管理」を参照してください。
また、パーサーをプライマリ ASIM ディストリビューションに提供することもできます。提供されたパーサーは、組み込みのパーサーとしてすべてのワークスペースで使用することもできます。

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

サンプルログを収集する

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

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

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

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

ヒント

同じスキーマの既存のパーサーを使用して、新しいカスタムパーサーを開始します。パーサーをフィルター処理して、スキーマに必要なすべてのパラメーターを確実に受け入れるようにするには、既存のパーサーを使用することが特に重要です。

計画マッピング

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

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

パーサーの開発

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

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

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

フィルター処理

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 ドキュメントの次の項目の詳細を参照してください。

フィルター処理の最適化

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

解析されたフィールドではなく、組み込みのフィールドで常にフィルター処理します。解析されたフィールドを使用してフィルター処理する方が簡単な場合もありますが、パフォーマンスに大きな影響を与えます。
最適化されたパフォーマンスを提供する演算子を使用します。特に、 ==、 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 つ目は最も最適化されたパフォーマンスを提供し、最後のパフォーマンスは最も最適化されていないパフォーマンスを提供します。

Operator/function()	説明
split() 関数	区切られた値の文字列を解析します。
parse_csv() 関数	CSV (コンマ区切り値) 行として書式設定された値の文字列を解析します。
parse-kv 演算子	文字列式から構造化情報を抽出し、キー/値形式で情報を表します。
parse 演算子	パターンを使用して任意の文字列から複数の値を解析します。これは、パフォーマンスが向上した簡略化されたパターンや正規表現である可能性があります。
extract_all() 関数	正規表現を使用して任意の文字列から単一の値を解析します。 `extract_all` 後者が正規表現を使用する場合、 `parse` と同様のパフォーマンスが得られます。
extract() 関数	正規表現を使用して任意の文字列から 1 つの値を抽出します。 `extract`を使用すると、1 つの値が必要な場合は、`parse`や`extract_all`よりもパフォーマンスが向上します。ただし、同じソース文字列に対して `extract` の複数のアクティブ化を使用することは、単一の `parse` または `extract_all` よりも効率が低く、避ける必要があります。
parse_json() 関数	JSON 形式の文字列内の値を解析します。 JSON から必要な値が少ない場合は、 `parse`、 `extract`、または `extract_all` を使用すると、パフォーマンスが向上します。
parse_xml() 関数	XML 形式の文字列内の値を解析します。 XML から必要な値が少ない場合は、 `parse`、 `extract`、または `extract_all` を使用すると、パフォーマンスが向上します。

正規化

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

正規化の最も簡単な形式は、元のフィールドの名前を正規化された名前に変更することです。そのための演算子 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')

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

[コンピューター] フィールド	出力フィールド
server1	SrcHostname: server1 SrcDomain、SrcDomainType、SrcFQDN すべて空
server1.microsoft.com	SrcHostname: server1 SrcDomain: microsoft.com SrcDomainType: FQDN SrcFQDN:server1.microsoft.com

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

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

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

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

オペレーター	説明	パーサーで使用するタイミング
project-away	フィールドを削除します。	結果セットから削除する特定のフィールドには、 `project-away` を使用します。結果セットから正規化されていない元のフィールドは、混乱が生じたり、非常に大きかったり、パフォーマンスに影響を与えたりしない限り、削除しないことをお勧めします。
プロジェクト	以前に存在していたフィールド、またはステートメントの一部として作成されたフィールドを選択し、他のすべてのフィールドを削除します。	パーサーは正規化されていない他のフィールドを削除しないでくださいので、パーサーでの使用はお勧めしません。解析中に使用される一時的な値など、特定のフィールドを削除する必要がある場合は、 `project-away` を使用して結果からフィールドを削除します。

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

    | 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 テンプレートを使用することをお勧めします。

スキーマごとに関連するテンプレートに基づいて YAML ファイルを作成し、クエリを含めます。まず、スキーマとパーサーの種類、フィルター処理、またはパラメーターレスに関連する YAML テンプレートから始めます。
ASIM YAML から ARM へのテンプレートコンバーターを使用して、YAML ファイルを ARM テンプレートに変換します。
更新プログラムをデプロイする場合は、ポータルまたは関数削除 PowerShell ツールを使用して、以前のバージョンの関数を削除します。
Azure portalまたは PowerShell を使用してテンプレートをデプロイします。

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

ヒント

ARM テンプレートはさまざまなリソースを組み合わせて使用できるため、パーサーをコネクタ、分析ルール、ウォッチリストと一緒にデプロイして、いくつかの便利なオプションに名前を付けることができます。たとえば、パーサーは、一緒にデプロイされたウォッチリストを参照できます。

パーサーのテスト

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

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

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

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

出力スキーマを検証する

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

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

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

Error	アクション
必須フィールドが見つからない [<Field>]	パーサーにフィールドを追加します。多くの場合、これは派生値または定数値であり、ソースから既に使用できるフィールドではありません。
必須列 [<Field>] が存在する場合、フィールド [<Field>] が見つからない場合は必須です	パーサーにフィールドを追加します。多くの場合、このフィールドは参照する既存の列の型を表します。
列 [<Field>] が存在する場合、フィールド [<Field>] が見つからない場合は必須です	パーサーにフィールドを追加します。多くの場合、このフィールドは参照する既存の列の型を表します。
既存の列 [<Field>] にエイリアスを設定する必須のエイリアス [<Field>] がありません	エイリアスをパーサーに追加する
既存の列 [<Field>] のエイリアスの推奨されるエイリアス [<Field>] がありません	エイリアスをパーサーに追加する
既存の列 [<Field>] にエイリアスを設定する省略可能なエイリアス [<Field>] がありません	エイリアスをパーサーに追加する
必須のエイリアスが見つからない [<Field>] のエイリアスが見つからない列 [<Field>]	このエラーは、エイリアス化されたフィールドの同様のエラーに伴います。エイリアス化されたフィールドエラーを修正し、このエイリアスをパーサーに追加します。
フィールド [<Field>] の型の不一致。現在は [<Type>] であり、[<Type>] にする必要があります。	通常、`tostring`などの変換関数を使用して、正規化されたフィールドの種類が正しいことを確認します。

情報	アクション
推奨フィールドが見つからない [<Field>]	このフィールドをパーサーに追加することを検討してください。

情報	アクション
存在しない列 [<Field>] のエイリアスが見つからない [<Field>]	エイリアス化されたフィールドをパーサーに追加する場合は、このエイリアスも必ず追加してください。
省略可能な別名 [<Field>] が存在しない列のエイリアスが見つからない [<Field>]	エイリアス化されたフィールドをパーサーに追加する場合は、このエイリアスも必ず追加してください。
省略可能なフィールドが見つからない [<Field>]	省略可能なフィールドは見つからないことがよくありますが、一覧を確認して、任意のフィールドをソースからマップできるかどうかを判断する価値があります。
追加の正規化されていないフィールド [<Field>]	正規化されていないフィールドは有効ですが、リストを確認して、正規化されていない値のいずれかを省略可能なフィールドにマップできるかどうかを判断する価値があります。

注:

エラーにより、パーサーを使用したコンテンツが正しく動作できなくなります。警告はコンテンツの動作を妨げませんが、結果の品質を低下させる可能性があります。

出力値を検証する

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

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

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

注:

スキーマを指定しない場合でも、関数名の後に空のかっこが必要です。

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

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

メッセージ	操作
(0) エラー: 列 [<Field>] の型の不一致。現在は [<Type>] であり、[<Type>] にする必要があります。	通常、`tostring`などの変換関数を使用して、正規化されたフィールドの種類が正しいことを確認します。
(0) エラー: [<Logical Type>] 型のフィールド [<Field>] の値が無効です (最大 10 個まで表示されます)。	パーサーが正しいソースフィールドを出力フィールドにマップしていることを確認します。正しくマップされている場合は、パーサーを更新して、ソース値を正しい型、値、または形式に変換します。各論理型の正しい値と形式の詳細については、論理型の一覧を参照してください。テストツールでは、10 個の無効な値のサンプルのみが一覧表示されることに注意してください。
(1) 警告: 必須フィールドの空の値 [<Field>]	必須フィールドは、定義だけでなく、設定する必要があります。現在のソースが空のレコードに対して、フィールドを他のソースから入力できるかどうかを確認します。
(2) 情報: 推奨フィールドの空の値 [<Field>]	通常、推奨されるフィールドには値を入力する必要があります。現在のソースが空のレコードに対して、フィールドを他のソースから入力できるかどうかを確認します。
(2) 情報: 省略可能なフィールドの空の値 [<Field>]	エイリアス化されたフィールドが必須か推奨されるか、その場合は他のソースから入力できるかどうかを確認します。

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

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 の詳細については、次を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-23