Cisco Advent Calendar 2023年版: : https://qiita.com/advent-calendar/2023/cisco

はじめに

シスコの同志による今年の Advent Calender "Cisco Systems Japan Advent Calendar 2023" の 20 日目として投稿しました。このエントリで取り上げるテーマは、

「Cisco XDR - ドラッグ＆ドロップだけで本格的セキュリティ調査プレイブックを作る（改良版：Ver2.0）」

です。昨年の Cisco Advent Calender のエントリにて、SecureX 以外に連携コンポーネントの必要が無く、SecureX を基軸に連携された高機能なインテリジェンスからの自動調査を実施するワークフロー作成の手順を取り上げました。SecureX のオーケストレーション機能の構造の理解を深めるとともにPython等のスクリプティングのナレッジを必要としない簡易的なステップでThreat Response APIを利用することを目的としました。前回のワークフローでは、APIから読み込もうとする指定した Observable に情報が無い場合、Casebookを作成できず、実行したはずのワークフローが完了できないという問題がありました。基本的な機能を変更せず Observable 情報の検索を分散した並列処理で収集する方法を追加してみます。

以下が、今回改変したワークフローの変更点です。この記事ではVer1.0からの差分のポイントを取り上げます。すべての作成ステップは含まれません。

新規 SecureX Token の利用
APIによる並列検索処理を追加する

Ver1.0

ワークフローの基本機能に関する構成や詳細情報は過去の記事でまとめています。
https://qiita.com/sig666/items/0603b12a4d018c065276

GitHub - SecureX-Workflow-ThreatResponse-QuickSearchToCasebook
https://github.com/sig666/SecureX-Workflow-ThreatResponse-QuickSearchToCasebook

SecureX から Cisco XDR へ

Cisco製 Security 製品をお使いのユーザ向けにセキュリティオペレーションの自動化、インシデントレスポンスと脅威ハンティングの効果的な方法を追加するツールとして、無償提供してきた SecureX が EoS を迎えることになりました。今 SecureX にアクセスすると EoS の日付が大きくアナウンスされるようになっています。

SecuX 後継の後継となる、Cisco XDR は XDR (Extended Detection and Response) として、大幅な機能改善を行ったプレミアバージョンの製品として 2023 年 7 月 31 日にリリースされました。2017 年の Cisco Threat Response をリリース、2020 年に SecureX をリリース、市場に XDR というカテゴリが存在する前から XDR としての製品開発を続けてきたことになります。

Cisco XDRは、脅威・インシデント分析と可視化、モジュール化された製品統合を機能として提供してきた、これまでの製品を含む以下のコンポーネントの組み合わせで構成しています。

SecureX：Incident/Observable Enrichment、均質化モデリング (CTIM)、センサー/外部インテリジェンス/外部資産とのモジュール統合
Secure Cloud Analytics：センサーからのマルチテレメトリ収取、Data Warehouse、Incident Correlation、Attack Chaining
Cisco XDR UI Widget：新規UIコンポーネント（Control Center、Incident、Automate、Device等）
Kenna Security：Scoring Method

Cisco XDR はもともとの SecureX で利用している Orchestration Cloud (Action Orchestrator) をそのまま使用しており、SecureX で作成され稼働しているワークフローは、そのまま Cisco XDR でも利用できます。

新規 SecureX Token の利用

Cisco XDR Automate (SecureX Orchestration) では、HTTP, AWS, Git, IMAP, JDBC, Meraki, 等様々な "Target" (API Endpoint) を利用できます。API を利用するには当然認証が必要となり、"Target" の内に "Account Key" (認証情報) を設定し、作成・変更するワークフロー内で "Target" を指定します。今回も調査ワークフローのAPIとして、以下の Cisco XDR Rest API (HTTP Target) を利用します。

/iroh/iroh-enrich/observe/observables

これまでの API Token

Cisco XDR 上で "API Client" をジェネレートし、Account Key (HTTP Basic Authentication) を作成、この Account Key をワークフローで利用する Target の Default Account Keys に設定します。

この後に Cisco XDR Enrichment API を利用して、調査対象のドメイン、IP Address、ファイルハッシュ、URL等に対して調査を実行、またはその情報を Cisco XDR に Casebook を書き出すために利用する、API Token の生成が必要なります。

API Client の作成

[Cisco XDR] "Administration" -> "API Clients" -> "Generate API Client"

Account Key (HTTP Basic Authentication) の作成

[Cisco XDR] "Automate" -> "Account Keys" -> "New Account Keys"
- Account Key Type : "HTTP Basic Authentication"
- Username : "API Client Key"
- Password : "API Client Secret"
- Authentication Option : "Basic"

Cisco XDR (SecureX) Token

SecureX を含むその後のバージョンアップにより、Cisco XDR APIを利用するための専用 Token である Cisco XDR (SecureX) Token が利用できるようになりました。Enrichment API のような HTTP Target の中で、こちらの新しい Token を直接していすることが可能です。

この方式を利用することで API を利用するための一時 Token の生成を自動化し、ワークフロー内でステップを簡素化することができるようになりました。Cisco XDR API を利用する場合、API Client の生成、Account Key (HTTP Basic Authentication) を利用する必要が無くなりました。

Account Key (Cisco XDR Token) の作成

Account Key Type：　"Cisco XDR Token"
- 必要な認証情報が自動生成される、ワンクリックのみで生成

ワークフロー作成：新規 Token を利用したEnrich Observable

新規ワークフローの作成を開始します。過去のバージョンで利用した HTTP Basic Authentication の Account Key を利用した Target を利用するより、API Token を生成するためのワークフローステップが省略され API の利用をシンプルに行うことができます。

作成するワークフローの Global Parameter を以下のように設定します。

ワークフローの "Properties" を設定
- "General" -> "Display Name" 任意のワークフロー名を指定
- "Target" -> "Execute on this target group"
  - Default Target Group
  - "* Select target types" : HTTP Endpoint
  - "Conditions" -> "ADD"
    - "L. OPERAND" : "[$HTTP Endpoint.Display Name$]"
    - "OPERATOR" : "eqi"
    - "R. OPERAND" : "[Cisco XDR Token を設定した新規作成 Target]"
      HTTP API Target の中の、Threat Response 用のデフォルト Target である "CTR_API" を指定する必要はありません。指定する新規作成 HTTP Target が "Default Target Group" にアサインされていることを確認します。こちらで指定した Target名を Default Target Group から検索します。
  - "* Select target group criteria" : "Choose first with matching criteria"

APIによる並列検索処理を追加する

前回バージョンのワークフローでは、単一で順番に処理されるシンプルなワークフローを構成しています。このため途中処理に探そうとする情報が、前のワークフローで実行されたJSONアウトプットに含まれていない場合、エラーとなりワークフローの実行が完了されません。細かく並列処理で検索を実行し、情報が得られなかったワークフローのグループを Continue Workflow Execution On Failure としエラー検索を許容します。

分岐処理の作成

分岐ワークフローを作成するために、"Logic" の "Parallel Block" を利用します。"Parallel Block" で分岐されたそれぞれの後続ワークフローの指定の中に "Logic" の "Group" をドラッグ＆ドロップし、それぞれの"Group"のパラメータの "Continue Workflow Execution On Failure" をチェックします。

ワークフロー分岐Logicを増やす場合、"Parallel Block"内の、"Duplicate" により増やしていくことが可能です。

分岐Logic内に検索ワークフローを作成

最初の Enrichment API からの　Response Output の例です。このアウトプット内容を確認しレポートの対象となるパラメータを決定していきます。

Response Body

{
  "data": [
    {
      "module": "Threatscore | Cyberprotect",
      "module_instance_id": "0e1568db-893b-4168-9264-04dc734b40ff",
      "module_type_id": "5482db38-56d7-4508-bdbf-003cd6d0ce0d",
      "data": {}
    },
    {
      "module": "Umbrella",
      "module_instance_id": "102318f2-ab8d-4f63-88d1-933e18d848f0",
      "module_type_id": "188d70f7-29d5-5069-9098-d83a3ec8e797",
      "data": {
        "verdicts": {
          "count": 1,
          "docs": [
            {
              "type": "verdict",
              "disposition": 5,
              "observable": {
                "value": "akubi.info",
                "type": "domain"
              },
              "judgement_id": "transient:5f3fe719-76c9-4ee8-80e3-84223406bfa7",
              "disposition_name": "Unknown",
              "valid_time": {
                "start_time": "2023-12-19T21:12:27.208Z",
                "end_time": "2024-01-18T21:12:27.208Z"
              }
            }
          ]
        },

最終的に作成したワークフローでは、"Judgement"、"Virdict"、"Sighting"、"Module"、"Sightingの詳細情報" の5つに分岐させそれぞれを "Parallel Block" の各 "Group" 内で実行するようにしてみました。各分岐 "Group" の中で実行される処理は以下のようになっています。

Read Table from JSON
Enrichment APIからのObservable情報をテーブルに変換
レポートに必要なパラメータと値を JSON Path で指定し抜き出す
Convert Table to XML
レポート用のパラメータ整形のため、JSON フォーマットを XML フォーマットに変換
Replace Strings
XML タグを文字変換し、HTML フォーマットに変換
Set Variables
各処理のレポート用テキストを作成する

Read Table from JSON で Virdict 情報を抜き出しているパラメータのセット例です。

Read Table

Property Name
$.data..data.sightings.docs.

Read Table *COLUMNS TO READ

Name	Type
source	String
source_uri	String
description	String
short_description	String
title	String
confidence	String
sensor	String
tlp	String

ワークフロー全体と実行例

主要な変更を実施したワークフローの全体像です。

ワークフローを実行した例です。情報が取得されないワークフロー Group にエラーが起きても、その情報は抜き出さず、検索できたデータだけでレポートを作成します。実行できたワークフロー Group は緑色で終了し、エラーが起きたワークフロー Group は赤色で表示されています。

成形したテキストを同じくAPIにて、Cisco XDR Casebookとして追加しています。

Git Repo

[1] @sig666
https://github.com/sig666
[2] SecureX-Workflow-ThreatResponse-QuickSearchToCasebook @sig666
https://github.com/sig666/SecureX-Workflow-ThreatResponse-QuickSearchToCasebook