適応と調整: 検索の適応

[これは Splunk Enterprise の Recorded Future アプリの v4.0.x 用です]

検索を適応させる

相関検索

Recorded Futureは、一般的なログ形式と、それらを当社のリスクリストと関連付ける方法を、サポート Web に掲載しています: Recorded Futureリスク リストの一般的な Splunk 検索文字列

Splunk には、「ワークフロー アクション」と呼ばれる機能もあり、検索結果のコンテキスト依存のメニュー エントリを可能にします。

デフォルトのアクション セットでカバーされていないフィールドには、このようなアクションを簡単に追加できます: Splunk でRecorded Futureエンリッチメント データへのピボット

ベース検索

相関ダッシュボードの基本検索はほぼ同じです。これは、IP ログ相関ダッシュボードのデフォルトのベース検索です。

    インデックス=メイン ソースタイプ="netscreen:firewall" 最早=-24時間
| 評価名=dst
 | 結合 [|inputlookup rf_ip_risklist.csv | テーブル * ]
 | 検索リスク != ""
 | 並べ替え -リスク

ベース検索は、その名前が示すように、より具体的な検索のベースとして使用され、最適化を可能にするだけでなく、検索の最初の部分を 1 回記述するだけで済むため、クエリの記述を容易にするために使用されます。これにより、コピー アンド ペースト エラーのリスクも軽減されます。

最初の行では、検索のインデックス「main」、ソースタイプ「netscreen:firewall」、時間範囲「過去 24 時間」を選択します。

2 行目では、 evalステートメントを使用して、ログ内のフィールド「dst」の名前を「Name」に変更します。

3 行目では、前回の検索結果と、ip_risklist.csv ルックアップ ファイルで使用可能なすべてのフィールドを含むテーブルを結合します。このダッシュボードの以前のバージョンでは、代わりにlookupコマンドを使用していました。私たちの目的からすると、 Lookup if は非常に遅く、結果から一致しないイベントを削除しません。そのため、代わりに join inputlookup による サブ検索 を使用するように変更しました。

4 行目では、リスクが割り当てられていないすべての結果を削除します。したがって、フィールド「リスク」が空でない結果を検索することで、リスク リストに一致するものがない結果が削除されます。

最後の行では、リスクに関して、フィールド名の前に「-」を追加して結果を降順に並べ替え、高リスクの結果が一番上に表示されるようにします。

ここでの一般的な変更は、カスタム リスク リストなど、データを照合する別のリストを使用することです。Recorded Future リスク リストでは、一致の対象となる主な要素は「名前」と呼ばれます。たとえば、ドメイン リスク リストのドメインや脆弱性リスク リストの CVE などです。カスタム リスク リストを使用する場合は、2 行目を Splunk のデータとリスク リストの両方のフィールド名と一致するように変更してください。

サブ検索

これは、基本検索における一意の行の数を決定する検索です。最初のステートメントは統計的に個別のカウントを実行し、フィールド 'Name' 内の一意の値のみをカウントし、その結果をフィールド 'count' に保存します。この値は、 rangemapステートメントを使用して色分けされます。

    | stats dc(名前) as count
 | 範囲マップフィールド=カウント 低=0-0 レベル=1-1 デフォルト=重大

相関ダッシュボードの最後のテーブルであるこのサブ検索では、まず「名前」フィールドの各値の出現回数をカウントします。statseventstatsの違いは、eventstats では結果の各行に新しいフィールドが追加されることです。この場合は、フィールド「Count」です。次に、「名前」に関して重複する行をすべて削除します。「format_evidence」は、Recorded Future によって作成されたマクロで、「EvidenceDetails」フィールドのJSONオブジェクトを解析し、そこに含まれるデータを新しいフィールドに入力します。次に、リスクを降順で並べ替え、小数点以下をすべて削除してから、最終的な情報を表示する表を作成します。

    | eventstats 名前別カウント
| 重複除去名
| `format_evidence`
 | 並べ替え -リスク
| リスク = round(リスク,0) を評価する
| テーブル リスク、名前、カウント、リスク文字列、ルール、証拠

エンリッチメント検索

エンリッチメント ダッシュボードは、 RESTエンドポイントを使用して Recorded Future Connect API から情報を取得し、入力されたエンティティに関する詳細情報を取得します。このRESTエンドポイント、およびエンリッチメント ダッシュボードでは API クレジットが使用されることに注意してください。

ベース検索

各エンリッチメント ダッシュボードの基本検索には、入力されたエンティティに関する情報を取得するためのREST呼び出しが含まれています。ここでは、API から取得する情報の種類をカスタマイズできます。私たちのケースでは、ユーザーにできるだけ多くのデータを提供できるように、利用可能なすべてのフィールドを取得することを選択しました。利用可能なフィールドは、 Recoded Future APIページで確認できます。CDATA カプセル化 (つまり、検索前の<![CDATA[]]>の理由は、この検索における正規表現の文字を Splunk が処理するためです。spathステートメントは、 JSONオブジェクトを解析して、その情報を検索で使用できるようにするために使用されます。最後の 2 つのステートメントは、タイムスタンプを人間にとってより読みやすい形式に変換します。

    <![CDATA[
 | rest /services/TA_recordedfuture-cyber/lookup_ip/$name$ fields="counts,risk,analystNotes,location,sightings,,timestamps,metrics,relatedEntities,riskyCIDRIPs,intelCard,threatLists" output_mode=json
 | `unpack_metrics`
 | rex フィールド = risk.riskString ".*/(?<rulesMax>.+)"
    | rulesMax の名前を risk.rulesMax に変更します
| spath 入力=タイムスタンプ
| eval FirstSeen=strftime(strptime('timestamps.firstSeen', " %Y-% m- %dT% H: %M:% S.%NZ"), "%b %d, %Y")
 | eval LastSeen=strftime(strptime('timestamps.lastSeen', " %Y-% m- %dT% H: %M:% S.%NZ"), "%b %d, %Y")
 ]]>

サブ検索

エンリッチメント ダッシュボードのサブ検索の多くは、特に関連エンティティ テーブルに関しては非常に似ています。関連ドメインの例を以下に示します。

    | `unpack_relatedEntities(関連インターネットドメイン名)`
 | ソート -count, 名前
| 名前をドメインに変更
| 参照としてカウントの名前を変更
| 表 ドメイン、参照

最初に行うことは、マクロに送信されたフィールド内のJSONオブジェクトを解析するマクロ 'unpack_relatedEntities' を呼び出すことです。ここでマクロを使用すると、同じコードを何度も記述する必要がなくなり、関連するすべてのエンティティ テーブルに対して同じ方法で実行できるようになります。次に、いくつかのフィールドを並べ替え名前を変更し、必要なヘッダーと順序を取得します。最後の行では、ダッシュボードに表示される「ドメイン」および「参照」フィールドを示すテーブルを作成します。

さらに詳しい情報

さらにご質問やアドバイスがありましたら、Recorded Future Intelligence Services のコンサルタントが喜んでお手伝いいたします。相手が誰なのか分からない場合は、support@recordedfuture.com までお問い合わせください。

「Recorded Future for Splunk Enterprise」については Splunk サポートに問い合わせないでください。

This content is confidential. Do not distribute or download content in a manner that violates your Recorded Future license agreement. Sharing this content outside of licensed Recorded Future users constitutes a breach of the terms and/or agreement and shall be considered a breach by your organization.
この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています

このセクションの記事

もっと見る