カスタムパーサーの概要

ヒント

より高いレベルのサポートをご希望の場合、SecureworksプロフェッショナルサービスチームがTaegis XDRへの投資から最大限の価値を引き出すお手伝いをいたします。高度なスキルを持つコンサルタントが、迅速な展開、最適化、価値実現までの時間短縮をサポートします。詳細については、以下をご覧ください。 プロフェッショナルサービスの概要。

XDR におけるログメッセージの取り込みと正規化

ログメッセージの取り込み

イベントスキーマ

ログメッセージが サポートされているXDR転送方法 を通じて XDR に送信されると、パースエンジンを通過し、20種類以上のイベントスキーマのいずれかに正規化されます。イベントスキーマとは、さまざまな種類のセキュリティイベントデータを標準化して見るための方法です。たとえば、ユーザー認証ログは通常、Authenticationスキーマに正規化され、username、action、logon_type、mfa_used などの共通フィールドを持ちます。Stolen User Credentials や Password Spray などの検知機は、Authenticationスキーマに取り込まれたデータに対して実行されるため、データを正しく正規化することは、データソースからセキュリティ価値を得るために非常に重要です。

XDR ルート（マスター）パーサーは、event_time および sensor_id などの共通フィールドを抽出し、これらは追加のスクリプトなしで全てのパーサーで利用可能です。

Genericスキーマ

XDR で受信したすべてのログメッセージは、デフォルトで Genericイベントスキーマに正規化されます。XDR は、これらのメッセージをケースでのコンテキストや相関、および カスタムルール で利用できるようにします。これらは詳細検索パラメータを使用した検索クエリでのみ表示されます。ユニバーサルなログメッセージフィールドは、XDR の特定のフィールド（sensor、sensor_type、sensor_id、host_id、event_time_usec など）に正規化されます（このリストは網羅的ではありません）。残りのメッセージはパースされません。メッセージの残り全体を含む生ログは、original_data という単一のフィールドに格納されます。このスキーマは、カスタムルール、詳細検索、ログ保持のユースケースで利用可能です。

追加スキーマへのパースと正規化

カスタムパーサーでサポートされている XDR スキーマの完全なリストは スキーマ をご覧ください。

XDR で受信したログメッセージは、宛先スキーマの要件に合うようにパースおよび正規化される必要があります。これは XDR のパースおよび正規化エンジンで行われます。ログメッセージが入力され、正規化されたイベントデータが出力され、XDR の他の機能（検出、検索、カスタムルールなど）で利用可能になります。

XDR でネイティブにサポートされていないセキュリティテレメトリーソースは、ログメッセージを XDR の追加スキーマに正規化するためにカスタムパーサーの設定が必要です。

検知機とカスタムパーサー

カスタムパーサーで正規化されたログメッセージは、必要なフィールドが入力されていれば、XDR の Domain Generation Algorithms、IP Watchlist、Domain Watchlist 検知機をトリガーできます。以下は各検知機の必須フィールドです。

Domain Generation Algorithms

スキーマ	正規化されたフィールド	パーサーのフィールド
scwx.dnsquery	query_name	queryName$

IP Watchlist

IP Watchlist検知機は、NIDS（scwx.nids）スキーマまたはNetflow（scwx.netflow）スキーマに正規化されたメッセージと互換性があります。

スキーマ	正規化されたフィールド	パーサーのフィールド
scwx.nids	source_address または destination_address	sourceAddress$ または destinationAddress$
scwx.netflow	source_address または destination_address	sourceAddress$ または destinationAddress$

Domain Watchlist

スキーマ	正規化されたフィールド	パーサーのフィールド
scwx.dnsquery	query_name	queryName$

重要

その他のネイティブ検知機は、データソースのメッセージが特定の検知機に関連付けられたスキーマに正規化されていても、必ずしもトリガーされるとは限りません。ただし、カスタム検出ルール を作成して、カスタムイベントデータソースから正規化されたデータに基づいて検出を生成することができます。

サポートされているログメッセージフォーマット

XDR のカスタムパーサー機能は、CEF（Common Event Format）、LEEF（Log Event Extended Format）、JSON（JavaScript Object Notation）、XML（Extensible Markup Language）、および非構造化（タブ、スペース、カンマ、その他の一般的な区切り文字で区切られた）フォーマットのログメッセージをサポートします。

メッセージを正しいパーサースクリプトにマッチさせる：Confirm String

（該当する場合）syslogヘッダーをメッセージ本体から分離した後、パースエンジンは受信したログメッセージを既知のパターンの一連と照合しようとします。これらは、メッセージが既知のソースから来ており、そのデータを管理できるパーサーファイルが存在することを示す識別子です。たとえば、Palo Altoファイアウォールからのログメッセージには panwlogs という文字列が含まれており、他のベンダーのメッセージにはこの文字列は含まれません（このドキュメントでは簡略化していますが、実際にはPaloAltoデバイスからのメッセージであることを確認するために他にも多くの条件があります）。Confirm Stringは、正規表現パターンや true または false を評価する式であることができ、柔軟性があります。

Confirm Stringは、広すぎず狭すぎない適切な特異性を持つべきです。たとえば、Hotbeam Networked Smart Toaster 用のパーサーを作成し、Confirm Stringとして [Nn]etwork を使用した場合、Palo Alto Network からのメッセージにもマッチしてしまい、正しいパーサーへのルーティングが妨げられます。これは、Confirm Stringが広すぎる例です。

例

CEFメッセージ

Jul 21 14:28:03 10.10.20.20 Jul 21 14:28:04 1122334455 CEF:0|Netskope|CHS|NULL|uba|Suspicious Data Movement|High|accessMethod=Client act=Upload action=anomaly_detection appcategory=CHS White List TP browser=Chrome cci=0 ccl=unknown device=Windows Device deviceClassification=not configured deviceExternalId=001122334455-6677-8899-0011-0123456789 dst=10.20.30.40 event_type=sequence hostname=server.local managementId=null object=123456-7890.pdf os=Windows 10 policy_actions=['Upload'] policy_name=Suspicious Data Movement requestClientApplication=[Consolo-Wellsky-S3] sourceServiceName=Amazon S3 src=10.10.10.10 suser=JohnD@example.com timestamp=1658413646 uba_ap1=Microsoft Office 365 Outlook.com uba_ap2=[Consolo-Wellsky-S3] uba_inst1=demotest uba_inst2=null url=consolo-production.s3.us-west-2.amazonaws.com/

!CONFIRMWITH=PATTERN
!CONFIRMSTRING=.*\|Netskope\|

JSONメッセージ

{"Act":"Rej","Cphr":"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","Dir":"Outbound","Error":"Malware detected by AV Scan policy: Exploit.DDE-CmdCalc.Gen","IP":"10.2.3.4","MsgId":"<BCDEF36a7a5f13f3-31829@nodered-mimecast-5ff78ffb7b-x2zlm.XYZ.net>","Rcpt":"PERSON@lab1.net","RejCode":"554","RejInfo":"[bitd.Exploit.DDE-CmdCalc.Gen, bitd.Exploit.DDE-CmdCalc.Gen]","RejType":"Virus Signature Detection","Sender":"outbound-auth@labs.com","Subject":"It's a party invitation!","TlsVer":"TLSv1.2","Virus":"Exploit.DDE-CmdCalc.Gen","aCode":"DLHmsukFP8K2X2DIH-0nQA","acc":"CUSA12A394","datetime":"2021-10-05T08:09:33-0400","headerFrom":"outbound-auth@labs.com"} 

!CONFIRMWITH=PATTERN
!CONFIRMSTRING=\{.*?"(aCode|MimecastIP)"\s*:\s*".*?"acc"\s*:\s*".*"datetime"\s*:\s*".*\}

非構造化メッセージ

Nov  4 01:49:29 10.1.2.3 Nov 04 2019 01:49:29: %ASA-2-106016: Deny IP spoof from (10.1.2.3) to 10.1.2.3 on interface DMZ

!CONFIRMWITH=PATTERN
!CONFIRMSTRING=(ASA|FTD|FWSM|PIX)-(\w*-)?\d-\d\d\d\d\d\d:

優先順位付けとデフォルトパースの上書き

重要

カスタムパーサーはSecureworksのスタッフによって保守・更新されないため、グローバル（ネイティブ）パーサーと同期しなくなるリスクがあります。

どのパーサーを使用するかを決定する際、パースおよび正規化エンジンは、最近使用されたパーサーを未使用のパーサーよりも優先してメッセージにマッチさせようとします。これにより、パースエンジンは最も可能性の高いマッチに集中できます。

最近使用されたパーサーでマッチが見つからない場合、パースエンジンは残りのパーサーライブラリ全体を順不同で検索します。そのため、Confirm Stringが競合を引き起こさないようにすることが重要です。意図したパーサーが最初に見つかる保証はありません。

前述のPalo Alto Networksの例で、カスタムパーサーに [Nn]etwork] を使用した場合、すべての一致するメッセージがカスタムパーサーにルーティングされる可能性があります。競合するカスタムパーサーは、優先順位付けの観点で一貫性のない結果を生み出します。

サポートされているデータソースのグローバルパースを上書きすることも可能です。ベストプラクティスは、データソースをXDRのデフォルトパーサーの要件に合わせて設定することですが、それが不可能な場合は、このシナリオに対応するために新しいカスタムパーサーセットを作成できます。

詳細は グローバルパーサーの上書きと拡張 をご覧ください。

パース

正規化の最初のステップは、受信したログメッセージを構成要素に分割することです。この方法は、メッセージのデータフォーマットによって異なります。たとえば、CEFやJSON形式のメッセージは key:value ペアが組み込まれており、インデックス付き配列が生成されます。一方、非構造化メッセージはキーなし配列に変換されます。

受信メッセージのデータフォーマットを選択すると、カスタムパーサーUIは、メッセージを分割するための対応するヘルパー関数をパーサースクリプトに含めます。

JSONパース関数の例：

data    = "{ \"store\": { \"book\": [ { \"category\": \"reference\", \"author\": \"Nigel Rees\", \"title\": \"Sayings of the Century\", \"price\": 8.95 }, { \"category\": \"fiction\", \"author\": \"Evelyn Waugh\", \"title\": \"Sword of Honour\", \"price\": 12.99 }, { \"category\": \"fiction\", \"author\": \"Herman Melville\", \"title\" : \"Moby Dick\", \"isbn\": \"0-553-21311-3\", \"price\": 8.99 }, { \"category\": \"fiction\", \"author\": \"J. R. R. Tolkien\", \"title\": \"The Lord of the Rings\", \"isbn\": \"0-395-19395-8\", \"price\": 22.99 } ], \"bicycle\": { \"color\": \"red\", \"price\": 19.95 } } }"
json    = JSON(data)
OUTPUT$ = json["$.store.book[*].author"]

# OUTPUT$: "Nigel Rees","Evelyn Waugh","Herman Melville","J. R. R. Tolkien"    (String)

正規化

受信メッセージが分割された後、その構成フィールドは、宛先イベントスキーマのフィールド要件に合わせて必要に応じて結合または変換されます。一般的な変換を管理するためのヘルパー関数が多数用意されています。

例

syslogメッセージが日付時刻データ Sep 21 2018 17:35:54 を送信した場合、受信メッセージからパースされたこの日付時刻は、ISO 8601形式に正規化する必要があります（DATETIME() 関数の第2引数でGolang独自の日付フォーマットが使われている点に注意してください）。

data     = "Sep 21 2018 17:35:54"
OUTPUT1$ = DATETIME(data, "Jan 02 2006 15:04:05")
OUTPUT2$ = data

# OUTPUT1$: 2018-09-21 17:35:54 +0000 UTC    (time)

# OUTPUT2$: Sep 21 2018 17:35:54    (String)

変換されたメッセージフィールドは、宛先スキーマフィールドに割り当てられます。

親パーサーと子パーサー

ほとんどのデータソースは、さまざまな種類のメッセージタイプを送信できます。たとえば、認証イベントのログはNetflowイベントのログとは異なり、セキュリティ検出の機会も異なります。受信データを最大限に活用するために、異なるメッセージタイプを最も適切なイベントスキーマに正規化します。

異なるイベントタイプごとのコードの複雑さを最小限に抑えるため、正規化プロセスを親と子のステップに分割します。一般的に、親パーサーは特定のデバイスやソースからのメッセージを識別し、各子パーサーは1つまたは複数のメッセージタイプを単一のスキーマに正規化します。

XDR ルートパーサーは、他のすべてのパーサーの最上位の親です。該当する場合、syslogヘッダーをメッセージデータから分離・正規化します。

たとえば、ファイアウォールデバイスは、Taegis Netflowイベント、Authenticationイベント、HTTPイベントにマッピングされるログを持っています。親パーサーはファイアウォールからのすべてのメッセージを識別し、各子パーサーは3つの異なるメッセージタイプのいずれかを認識します。

• VendorFW_parent（親パーサー）
  • VendorFW_netflow（子パーサー）
  • VendorFW_auth（子パーサー）
  • VendorFW_http（子パーサー）

XDR に送信されたメッセージは、まずXDRルートパーサーでパースされ、（該当する場合）syslogヘッダーが分離・パースされます。次に、パースエンジンはメッセージをルートパーサーの子（システム内のすべての最上位パーサー）と照合します。パーサーのConfirm Stringと一致するものが見つかると、そのパーサーを使ってさらにメッセージをパースします。そのパーサーに子パーサーがある場合は、このプロセスが繰り返されます。

重要

パーサーは親から子への1世代のみの関係しか持てません。子パーサーがさらに子を持つことはできません。

親パーサーと子パーサー

XDR でのカスタムパーサーの作成・編集・有効化

既知の問題

• ある親パーサーのすべての子パーサーは、親を無効化する前に無効化または削除する必要があります。
• 親パーサーのベストプラクティスは、宛先スキーマをGenericに設定することです。現在、親パーサーの宛先スキーマはGenericに設定する必要があります。
• サポートされていないデータソースからのメッセージが既存のパーサーにマッチする可能性があります。この場合、メッセージが意図しない方法でパース・正規化されることがあります。パーサー選択の不確定性のため、サンプルメッセージを複数回テストすることを推奨します。各テストで意図しないマッチが検出される可能性が高まります。12～15回の繰り返しテストで、未検出のミスマッチの確率を許容レベル（>99.9%の確実性）まで下げることができます。この種の競合が発生した場合は、製品サポートに連絡し、既存パーサーの分析と特異性の調整を依頼してください。

新しいカスタムパーサーの作成

1. Taegis Menu から インテグレーション を選択し、カスタムパーサー を選択します。
2. 右上の カスタムパーサーの追加 を選択します。

3. カスタムパーサーに名前を付けます。推奨フォーマットは以下の通りです：

   [PRODUCT_NAME]_[FORMAT_NAME]_[PARENT|CHILD_TARGET_SCHEMA]

   例

   FUNBEAM_SMART_TOASTER_CEF_PARENT

   PAN_FW123456_JSON_CHILD_AUTHENTICATION

4. 親、子、またはスタンドアロンパーサーかを選択します：

• 親パーサーはデフォルトでGenericイベントスキーマになります。複数のスキーマに正規化するために子パーサーを作成することを前提とします。
• 子パーサーは親パーサーの選択が必要で、最終的な宛先スキーマを選択する必要があります。
• スタンドアロンパーサーは、1種類のメッセージタイプのみを持ち、1つのスキーマに正規化するテレメトリーデータソース用です。

5. ソースデータフォーマットを選択します。これにより、受信メッセージを分割するための正しいヘルパー関数が生成されるパーサーボイラープレートスクリプトに含まれます。

6. 宛先スキーマを選択します。

   注意

   親パーサーのベストプラクティスは、宛先スキーマを Generic に設定することです。

7. 作成 を選択します。スクリプトエディタ画面が表示され、パーサー作成のための事前フォーマット済みボイラープレートが用意されます。

カスタムパーサーの記述

ベストプラクティス

• カスタムパーサーの最上部には、必要なバン（!）宣言を記載してください。

• 選択したログメッセージフォーマットに適したスプリッタ関数を追加してください。

• 宛先スキーマ用にデータを整形したり、子パーサーに渡すために必要な変数宣言や内容操作を追加してください。

• protobuf 宣言は、イベントスキーマに渡されるデータを決定します。

これらのベストプラクティスは、可読性、保守性、トラブルシューティングに役立ちます。

!CONFIRMWITH および !CONFIRMSTRING の設定

親パーサーは通常、!CONFIRMWITH=PATTERN で正規表現パターンを宣言して適合させます。カスタムパーサーで正規化したいすべてのメッセージの主要部分にマッチする正規表現パターンを記述してください。通常、これはデータソースのログメッセージに記載されているベンダー名や製品名にマッチします。

重要

Taegis XDRカスタムパーサーでサポートされている正規表現の構文は、Golangバリアントです。

例：

!CONFIRMWITH=PATTERN
!CONFIRMSTRING=\|Imperva Inc.\|SecureSphere-MX

は、以下のサンプルログ内の |Imperva Inc.|SecureSphere-MX にマッチします。

Nov 11 15:55:25 172.16.11.99 CEF:0|Imperva Inc.|SecureSphere-MX|13.0.1|Correlation|sql-failed-login|Medium|act=None dst=172.16.3.45 dpt=1433 duser=Multiple src=172.16.3.51 spt=47635 proto=TCP rt=Nov 11 2022 06:05:08 cat=Alert cs1=SQL Correlation Policy  cs1Label=Policy cs2=Group1 cs2Label=ServerGroup cs3=sql-service cs3Label=ServiceName cs4=Default SQL Application cs4Label=ApplicationName cs5=SQL Failed Login  cs5Label=Description

子パーサーは通常、親パーサーで設定された変数から導出され、TRUE を評価する式で適合させます。これは通常の比較演算子を使って行います。

例：

!CONFIRMWITH=EXPRESSION
!CONFIRMSTRING=eventType$=="AUTH"

親パーサーで eventType$ という変数が宣言され、その値が AUTH であれば、これは TRUE となり、子パーサーでメッセージを正規化できます。

この時点でConfirm Stringが機能するかどうか、パーサーをテストすることを推奨します。テスト方法は下記のカスタムパーサーのテスト を参照してください。

変数とProtobufフィールドの設定

変数はファイル内の任意の場所で宣言できます。比較や連結、ヘルパー関数への渡しなど、変数が有効なあらゆる操作に使用できます。変数はパーサースクリプト内でのみ使用され、宛先スキーマには渡されません。

Protobufフィールドは末尾にドル記号（$）が付きます。Protobufフィールドは宛先スキーマに渡されるデータ用に予約されています。宛先スキーマに一致しない宣言は無視されます。たとえば、Authenticationスキーマに正規化する場合、encryption_type$ はスキーマ内のフィールドに一致するため有効なProtobufフィールドですが、my_snazzy_field$ は無効であり、正規化エンジンで無視されます。

Protobufフィールドはスキーマフィールドと1:1でマッピングされますが、構文が少し異なります。スキーマのフィールド名はスネークケース、対応するProtobufフィールドはキャメルケースで末尾にドル記号が付きます。したがって、スキーマフィールド event_time_usec は Protobufフィールド eventTimeUsec$ にマッピングされます。

変数とProtobufフィールドは親から子へ渡されるため、親パーサーで設定された変数やProtobufフィールドは、そのすべての子孫で利用可能です。

一般的な操作と関数

カスタムパーサー構文 を参照してください。

カスタムパーサーの保存

テストツールは、スクリプトエディタインターフェースに現在読み込まれている内容をテストします。テストはスクリプトを保存しません。 これにより、本番環境の動作を変更せずにアクティブなパーサーへの変更をテストできます。

パーサーを保存するには、保存して続行 を選択してください。パーサーが無効化されている場合、無効な状態でも保存できます。パーサーが有効化されている場合、システムはエラーを返し、無効な状態での保存を防ぎます。

編集画面からの退出

終了 ボタンを選択すると、カスタムパーサー画面に戻ります。保存されていない変更は失われます。

サンプルメッセージ

編集中は頻繁にパーサースクリプトをテストしてください。テストには少なくとも1つのサンプルメッセージが必要です。

オリジナルデータ方式

すでに XDR にデータを送信している場合は、イベントからオリジナルデータをコピーしてサンプルメッセージ欄に貼り付けるのが最適です。イベントを見つけるには、詳細検索で FROM Generic WHERE sensor_id='[my data source]' というクエリを使用し、[my data source] をログを送信している製品名に置き換えてください。 例は XDR を参照してください。

イベントの1つを開き、Original Dataタブに移動し、Copy Original Dataボタンを使用します。このデータをカスタムパーサーの編集画面のSample Message欄に貼り付けてください。パースしたいすべてのデータが含まれているイベントを使用してください。

ログコピー方式

データソースからのデータ送信をまだ開始していない場合でも、データをテストできますが、トラブルシューティング時の接続問題を除外するためにも、まずデータ送信を開始することを推奨します。1行のログメッセージ（ログファイル全体ではありません）をサンプルメッセージ欄にコピーしてください。サンプルメッセージは1行のログ用であり、ログファイル全体用ではありません。

ダミーサンプルメッセージデータ

まだサンプルデータがない場合でも、以下のログメッセージを使ってカスタムパーサーを試すことができます：

CEF:

Nov 11 15:55:25 172.16.11.99 CEF:0|Imperva Inc.|SecureSphere-MX|13.0.1|Correlation|sql-failed-login|Medium|act=None dst=172.16.3.45 dpt=1433 duser=Multiple src=172.16.3.51 spt=47635 proto=TCP rt=Nov 11 2022 06:05:08 cat=Alert cs1=SQL Correlation Policy  cs1Label=Policy cs2=Group1 cs2Label=ServerGroup cs3=sql-service cs3Label=ServiceName cs4=Default SQL Application cs4Label=ApplicationName cs5=SQL Failed Login  cs5Label=Description

JSON:

{"GUID":"8mr-Qf2IaEGl8ZrAgApMtUpJ1WE6MNw3","QID":"3m082vh0wa-1","ccAddresses":[],"cluster":"embdtech_production-vm","completelyRewritten":false,"fromAddress":["onedrive-storage-centers@post.com"],"headerFrom":"Portal Service \u003cOneDrive-storage-centers@post.com\u003e","headerReplyTo":"OneDrive-storage-centers@post.com","id":"17c704dd-32d7-7a7e-aabd-60bc25d6d7b8","impostorScore":0,"malwareScore":0,"messageID":"\u003cz2syHcM5R-KNfBRt164SIg@geopod-ismtpd-3-0\u003e","messageParts":[{"contentType":"text/plain","disposition":"inline","filename":"text.txt","md5":"02fb21a1047b2156d299dbbd5128eeeb","oContentType":"text/plain","sandboxStatus":null,"sha256":"46e52ba50776ff8b95baee20c8f7d2880653c02e60aeb5b7d2b9adce97d8eca2"},{"contentType":"text/html","disposition":"inline","filename":"text.html","md5":"cf84f8757abdbd98c0557b4fb595fc31","oContentType":"text/html","sandboxStatus":null,"sha256":"fbce44eb0a20aa14f8c4270a387ef8f7b86fa6df8227824555eac77286d6efbd"}],"messageSize":7320,"messageTime":"2022-11-22T16:08:29.000Z","modulesRun":["av","zerohour","dkimv","spf","spam","dmarc","pdr","urldefense"],"phishScore":100,"policyRoutes":["default_inbound"],"quarantineFolder":"Phish","quarantineRule":"inbound_passive_phish","recipient":["asmith@embdtech.com"],"replyToAddress":["onedrive-storage-centers@post.com"],"sender":"bounces+30215492-d119-asmith=embdtech.com@sendgrid.net","senderIP":"167.22.22.22","spamScore":0,"subject":"A notice sent to your mail-box asmith@embdtech.com just\r\n arrived","threatsInfoMap":[{"campaignID":null,"classification":"phish","threat":"bafybeidonkf2nkpftvrxzpjziloxhgjzdr4behzpikhktcsntarflqhkby.ipfs.w3s.link/","threatID":"3e453ec875e5d875d9a97bd2607e2b98e9915d3fbb01dd8c8e1b9314564c5c7b","threatStatus":"active","threatTime":"2022-11-22T15:38:23.000Z","threatType":"url","threatUrl":"https://threatinsight.proofpoint.com/44b3419d-b1e9-7db6-d77e-7a5cf27f7cf2/threat/email/3e453ec875e5d875d9a97bd2607e2b98e9915d3fbb01dd8c8e1b9314564c5c7b"}],"toAddresses":["asmith@embdtech.com"],"xmailer":null}

テスト

サンプルメッセージを読み込んだら、Parse ボタンを選択します。メッセージが正しく構成されていれば、Parsed Messageテーブルにフィールド間の key:value 関係（CEF、LEEF、JSONなどの構造化メッセージフォーマットの場合）が表示されるか、（非構造化フォーマットの場合は）フィールドのインデックス付き分解が表示されます。

送信されるデータの範囲が正しくパースされることを確認するため、さまざまなサンプルメッセージを追加してください。通常、2～5件のサンプルメッセージが適切です。子パーサーを使用している場合は、親・子パーサーの両方で行ってください。代表的なサンプルメッセージが揃ったら、Run Test ボタンを使ってすべてのサンプルメッセージのイベント出力を確認します。

テスト結果

Parse Message ボタンを押すと、テスト結果がメッセージ下部の省略テーブルに表示されます。ここで、パーサーが結果を生成しているかどうかを確認できます。テーブルが表示されるようになったら、展開して詳細を確認できます。Parsed Source Message テーブルは、スプリッタ関数によってメッセージがどのように分割されたかを示します。Source Destination Mapping テーブルは、変換されたソースデータがイベントスキーマフィールドにどのように割り当てられたかを示します。

Extractor Pathは、どのパーサーがメッセージのパースに使われたかを正確に示します。1つのメッセージが複数の利用可能なパーサーでパースされる状況を作ることも可能であり、この場合、意図しないパーサーがサンプルメッセージを拾っているかどうかをここで確認できます。サンプルメッセージが作成中のカスタムパーサー以外でパースされた場合、カスタムパーサーUIに以下のメッセージが表示されます。

グローバルパーサー競合

Run Test ボタンを押すと、このカスタムパーサーのすべてのサンプルメッセージがテストされ、イベント検索と同様に結果が出力されます。また、メッセージが正規化されたイベントスキーマやExtractor Pathも表示されます。

編集画面からの退出

Exit ボタンをクリックすると、パーサー編集画面を離れ、カスタムパーサー画面に戻って追加操作を行えます。保存されていない変更は失われます。

カスタムパーサーの有効化

デフォルトでは、カスタムパーサーは無効化されています。これにより、XDR のGUIツールを使って編集・テストする時間が確保できます。カスタムパーサーの準備ができたら、カスタムパーサー画面に戻って有効化してください。

パーサーの有効化は破壊的ではありません。XDR に取り込まれるデータは、現在作成されているGenericイベントを引き続き生成するため、有効化によるリスクは、パーサー名の競合に関する既述のリスク以外はありません。

パーサーを有効化すると、イベントが即座に作成されます。数分待ってデータが到着した後、WHERE sensor_type=[your_sensor_type] で検索することで確認できます。XDR でデータが受信されていれば、正しいイベントタイプに正規化された検索結果が返されます。

有効化されたカスタムパーサーの編集内容は即座に反映されます。編集時は注意してください。アクティブなパーサーに無効なパーサーを保存しようとすると、システムはエラーを返します。ただし、正しい情報でない内容を宛先スキーマフィールドに入れる有効なパーサーを作成することは可能です。

親・子パーサーを有効化する場合は、親を先に有効化する必要があります。

カスタムパーサーの無効化

カスタムパーサーは同じインターフェースから無効化できます。無効化すると、パーサーは即座にイベントの生成を停止します。Genericイベントは通常通り作成されますが、無効化したパーサーで指定した追加スキーマへのイベント送信は行われません。

カスタムパーサーの削除・アーカイブ

カスタムパーサー画面のActions列にある ゴミ箱 アイコンを選択すると、カスタムパーサーを削除できます。これは復元できない削除です。