Advanced Security Information Model (ASIM) パーサー (パブリックプレビュー) を開発する

[アーティクル]
03/29/2023

Advanced Security Information Model (ASIM) ユーザーは、クエリでテーブル名の代わりに "統一パーサー" を使用して、正規化された形式でデータを表示し、スキーマに関連するすべてのデータをクエリに含めます。その結果、統一パーサーでは、"ソース固有パーサー" を使用して各ソースの具体的な詳細が処理されます。

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

デバイスから ASIM スキーマに適合するイベントが提供されるが、デバイスと関連するスキーマに対応するソース固有パーサーが Microsoft Sentinel で使用できない場合。
デバイスで ASIM ソース固有パーサーを使用できるが、デバイスから ASIM パーサーで想定されているものとは異なる方法または形式でイベントが送信される場合。次に例を示します。
- ソースデバイスが標準以外の方法でイベントを送信するように構成されている。
- デバイスのバージョンが ASIM パーサーでサポートされているものと異なる。
- イベントが中間システムによって収集、変更、転送される場合がある。

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

重要

現在、ASIM はプレビュー段階です。 Azure プレビューの追加使用条件には、ベータ版、プレビュー版、またはまだ一般提供されていない Azure 機能に適用される追加の法律条項が含まれています。

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

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

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

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

ヒント

さらに、Microsoft Sentinel の正規化パーサーと正規化されたコンテンツに関する詳しいウェビナーをこちらでご視聴いただけます。関連するスライドデッキはこちらでご確認いただけます。詳細については、「次のステップ」を参照してください。

サンプルログの収集

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

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

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

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

ヒント

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

マッピングを計画する

パーサーを開発する前に、ソースイベントまたはイベントで使用可能な情報を、識別したスキーマにマップします。

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

パーサーの開発

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

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

Filter>Parse>Prepare fields

フィルター処理

ウォッチリストを使用したソースの種類によるフィルター処理

特定のソースの種類をフィルター処理するための情報が、イベント自体には含まれていない場合もあります。

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

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

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

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

Computer を、ソースのソース情報を含むフィールドの名前に置き換えます。 Syslog ベースのパーサーの場合、これは Computer のままで構いません。
InfobloxNIOS トークンを、使用するパーサーに適した任意の値に置き換えます。上記で選択した値を使用して ASimSourceType ウォッチリストを更新する必要があること、および、この種類のイベントを送信するソースの一覧をパーサーのユーザーに通知します。

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

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

フィルター処理を行う場合は、次の条件を確認します。

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

次の例は、文字列パラメーター (既定値は通常 '*') およびリストパラメーター (既定値は通常空のリスト) のフィルター処理を実装する方法を示しています。

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_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 演算子を、以下にパフォーマンスが最適化されている順に示します。最初の方法では最適なパフォーマンスが得られますが、最後のパフォーマンスは最も最適化されていません。

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

正規化

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

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

 | 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 パーサーは、次のように、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	以前に存在した、またはステートメントの一部として作成されたフィールドを選択し、その他のフィールドをすべて削除します。	パーサーでは、正規化されていない他のフィールドを削除してはいけないため、パーサーでの使用は推奨されません。解析時に使用される一時的な値など、特定のフィールドを削除する必要がある場合は、`project-away` を使用して結果から削除します。

たとえば、カスタムログテーブルを解析するときに、次のコマンドを使用して、型記述子が残っている残りの元のフィールドを削除します。

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

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

重要

異なるバリアントは、異なるスキーマに一般的にマップされ、別々のパーサーを開発する異なるイベントタイプを表します

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

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

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

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

ヒント

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

パーサーをテストする

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

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

ASIM をテストするには、次の要件を満たす Microsoft Sentinel ワークスペースに ASIM テストツールをデプロイします。

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

出力スキーマを検証する

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

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

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

Error	アクション
Missing mandatory field [<フィールド>]	フィールドをパーサーに追加します。多くの場合、これは派生値または定数値であり、ソースから既に入手可能なフィールドではありません。
必須の列 [<フィールド>] が存在する場合は、欠損フィールド [<フィールド>] が必須です	フィールドをパーサーに追加します。多くの場合、このフィールドは、参照先の既存の列の型を示します。
列フィールド [<フィールド>] が存在する場合は、欠損フィールド [<フィールド>] は必須です	フィールドをパーサーに追加します。多くの場合、このフィールドは、参照先の既存の列の型を示します。
Missing mandatory alias [<フィールド>] aliasing existing column [<フィールド>]	この別名をパーサーに追加します
Missing recommended alias [<フィールド>] aliasing existing column [<フィールド>]	この別名をパーサーに追加します
Missing optional alias [<Field>] aliasing existing colum [<Field>]	この別名をパーサーに追加します
Missing mandatory alias [<フィールド>] aliasing missing column [<フィールド>]	このエラーは、別名が設定されたフィールドに関する同様のエラーと共に発生します。別名が設定されたフィールドのエラーを修正し、この別名をパーサーに追加します。
type mismatch for field [<フィールド>] It is currently [<型>] and should be [<型>]	通常は `tostring` などの変換関数を使用して、正規化されたフィールドの型が正しいことを確認します。

Info	アクション
Missing recommended field [<フィールド>]	このフィールドをパーサーに追加することを検討します。

Info	アクション
Missing recommended alias [<フィールド>] aliasing non-existent column [<フィールド>]	別名が設定されたフィールドをパーサーに追加する場合は、必ずこの別名も追加します。
Missing optional alias [<フィールド>] aliasing non-existent column [<フィールド>]	別名が設定されたフィールドをパーサーに追加する場合は、必ずこの別名も追加します。
省略可能なフィールドがありません [<フィールド>]	多くの場合、省略可能なフィールドは欠落していますが、ソースから省略可能なフィールドをマップできるかどうかを判断するには、一覧を確認してください。
Empty value in mandatory field [<フィールド>]	正規化されていないフィールドは有効ですが、正規化されていない値を省略可能なフィールドにマップできるかどうかを判断するには、一覧を確認してください。

注意

エラーが発生すると、パーサーを使用するコンテンツは正しく機能しなくなります。警告によってコンテンツの機能が妨げられることはありませんが、結果の品質が低下する可能性があります。

出力値を検証する

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

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

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

注意

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

このテストはリソースを集中的に使用するため、データセット全体を対象にすると機能しない可能性があります。クエリがタイムアウトしない最大値に X を設定するか、時間範囲の選択を使用してクエリの時間範囲を設定してください。

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

メッセージ	アクション
(0) Error: type mismatch for column [<フィールド>]. It is currently [<型>] and should be [<型>]	通常は `tostring` などの変換関数を使用して、正規化されたフィールドの型が正しいことを確認します。
(0) Error: Invalid value(s) (up to 10 listed) for field [<フィールド>] of type [<論理型>]	パーサーによって正しいソースフィールドが出力フィールドにマップされていることを確認します。正しくマップされている場合は、ソース値を正しい型、値、または形式に変換するようにパーサーを更新します。各論理型の正しい値と形式の詳細については、論理型の一覧をご覧ください。テストツールでは、10 個の無効な値のサンプルのみが一覧表示されることにご注意ください。
(1) 警告: Empty value in mandatory field [<フィールド>]	必須フィールドは、定義されているだけでなく、値が設定されている必要があります。現在のソースが空であるレコードの他のソースからフィールドに値を設定できるかどうかを確認します。
(2) 情報:Empty value in recommended field [<フィールド>]	通常、推奨フィールドには値を設定する必要があります。現在のソースが空であるレコードの他のソースからフィールドに値を設定できるかどうかを確認します。
(2) 情報: Empty value in optional field [<フィールド>]	別名フィールドが必須または推奨であるかどうかを調べ、そうである場合は他のソースから値を設定できるかどうかを確認します。

メッセージの多くは、メッセージを生成したレコードの数と、サンプル全体に占めるそれらの割合も報告します。この割合は、問題の重要性を示す良い指標です。たとえば、推奨されるフィールドの場合は、次のようになります。

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

注意

パーサーを提供する

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

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

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

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

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 は、パーサーが使うソーステーブルの名前です。
両方のファイルを /Sample Data/ASIM フォルダーの PR に含めます。ファイルが既に存在する場合は、GitHub ハンドルを名前に追加します (例: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv)

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

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

テスト結果を提出するには、次の手順のようにします。

「テスト」セクションで説明されているように、パーサーのテストを実行します。
[CSV へのエクスポート] オプションを使って、テスト結果をそれぞれ <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv および <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv という名前のファイルにエクスポートします。
両方のファイルを /Parsers/ASim<schema>/Tests フォルダーの PR に含めます。

次の手順

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

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

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

Microsoft Sentinel の正規化パーサーと正規化されたコンテンツに関する詳しいウェビナーをこちらでご視聴いただけます。スライドはこちらでご確認いただけます。
Advanced Security Information Model (ASIM) の概要
Advanced Security Information Model (ASIM) スキーマ
Advanced Security Information Model (ASIM) コンテンツ

次の方法で共有

Advanced Security Information Model (ASIM) パーサー (パブリックプレビュー) を開発する

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

サンプルログの収集

マッピングを計画する

パーサーの開発

フィルター処理

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

ウォッチリストを使用したソースの種類によるフィルター処理

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

フィルター処理の最適化

解析

正規化

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

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

派生されるフィールドと値

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

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

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

パーサーをデプロイする

パーサーをテストする

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

出力スキーマを検証する

出力値を検証する

パーサーを提供する

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

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

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

次の手順

フィードバック

その他のリソース

次の方法で共有

Advanced Security Information Model (ASIM) パーサー (パブリック プレビュー) を開発する

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

サンプル ログの収集

マッピングを計画する

パーサーの開発

フィルター処理

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

ウォッチリストを使用したソースの種類によるフィルター処理

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

フィルター処理の最適化

解析

正規化

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

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

派生されるフィールドと値

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

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

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

パーサーをデプロイする

パーサーをテストする

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

出力スキーマを検証する

出力値を検証する

パーサーを提供する

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

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

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

次の手順

フィードバック

その他のリソース

Advanced Security Information Model (ASIM) パーサー (パブリックプレビュー) を開発する

サンプルログの収集

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

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

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

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