!! Merry Christmas !!
Cisco Advent Calendar 2022: https://qiita.com/advent-calendar/2022/cisco

はじめに

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

「SecureX - ドラッグ＆ドロップだけで本格的セキュリティ調査プレイブックを作る」

です。Cisco SecureX は、私の昨年と一昨年のエントリーで、AWS Lambda によるインテリジェンスリレーモジュール構築と、簡易 Python スクリプトによるワークフローのテストモジュール作成を題材として取り上げました。今回はさらに踏み込み、SecureX のオーケストレーター機能をしっかり利用した、汎用的なシナリオとして利用可能なプレイブックの作成を目的としています。

以下のステップでまとめます。

ワークフローのテーマ：SecureX 脅威インテリジェンスのクイックサーチ＆レポート
ワークフローで利用するコアAPIのテスト
ワークフローの構成と、作成のステップ、ポイント
- ステップ0 : ワークフロー全体の設定
- ステップ1 : Threat Response アクセストークンの生成
- ステップ2 : Threat Response Enrich Observable API の利用
- ステップ3 : API のアウトプットから情報を成形
- ステップ4 : サマリレポートのテキスト生成
- ステップ5 : 新規ケースブック作成
- ステップ6 : Email 送信
- ワークフローに必要な Target と Account Key
ワークフローのダウンロードと導入
ワークフローの実行

今年のAdvent Calenderの最後半の記事となりますが、特に今年はSecureXに関する題材を取り上げるメンバーも増え嬉しい限りです。Cisco SecureX は主に Cisco Secure 製品をお使いのユーザ様向けに、XDR (Extended Detection & Response) の能力をプラットフォームとして追加コスト無しにXDRの要素機能を追加できる、フルクラウドネイティブのサービスであり、素性のよい汎用 API プラットフォームとして利用できるポテンシャルがあります。具体的にCisco SecureX でできることは何？なのか、SecureX のワークフローやオーケストレーションで何ができるの？か、については、是非これまでの関連エントの説明やリンク等も参照ください。（最後に参照リンクをまとめています）

1. ワークフローのテーマ：SecureX 脅威インテリジェンスのクイックサーチ＆レポート

作成するワークフローのテーマと実現機能を検討します。最低限の統合による少ないステップで完結できる有用なシナリオを検討する必要があります。XDRとしての脅威検出をキーとして個別製品による自動隔離を行うようなシナリオは非常に強力なユースケースと言えます。ただし Cisco SecureX と連携することを前提とする機能を持つ個別有償サブスクリプションが必要になる Cisco Secure 製品が必要であるということを前提とせず、あくまでも汎用的に利用できるシナリオを目指したいと思います。

日々の組織のセキュリティオペレーションでどのタイミングでも必要となる、例えば、被疑のある対象IPアドレス、ファイルハッシュ、宛先ドメイン、ファイルパス、等に関する、追加情報、判定情報、関連のサマリレポートを SecureX プラットフォームの基本機能として、サマリ情報、追加情報を提示できるレポート機能を Threat Response によってシンプルに実装 (Threat Response クイックサーチワークフロー) できれば汎用的なワークフローシナリオのテーマとして考えられます。この要件はすでに SecureX Threat Response によって実装されていますが、実行時間を短縮するとともに、リレーションマップ表示でなくサマリテキストを作成、SecureX Casebook や管理者向け Email 送信を実装し、ユースケースの差別化を行います。

2. ワークフローで利用するコアAPIのテスト

SecureX Threat Response enrich API (/iroh/iroh-enrich/observe/observables) を利用します。シンプルな Required Value によるインプットにて多くのエンリッチできる情報を提示できる API エンドポイントを利用することにします。

/iroh/iroh-enrich/observe/observables

APIドキュメントから Swagger を利用し API の実行をテストします。

"Authorize" クリック
"Log In with SecureX Sign-On" クリック、SecureX にログオン
"Try it out" クリックし、インプット Value を編集可能にする
Required Value に Enrich Observable でエンリッチしたい調査対象 IoC を編集・入力し、"Execute" をクリック

Example Value

[
  {
    "value": "string",
    "type": "file_path"
  }
]

Edited Value

[
  {
    "value": "157.7.97.72",
    "type": "ip"
  }
]

Swagger の実行結果から、Curl のリクエストコマンド、Request URL、Response Body、Response Header の出力結果を確認することによって、この API を実行するためのリクエストに必要なデータ、ヘッダ、APIによって出力される実行結果のデータ形式を事前に把握することに役立ちます。

Curl

curl -X POST "https://visibility.apjc.amp.cisco.com/iroh/iroh-enrich/observe/observables" -H "accept: application/json" -H "authorization: Bearer eyxxxxxxx" -H "Content-Type: application/json" -d "[ { \"value\": \"157.7.97.72\", \"type\": \"ip\" }]"

Response Body

{
  "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": "157.7.97.72",
                "type": "ip"
              },
              "judgement_id": "transient:2acd75b7-7620-465a-ac0d-562493423794",
              "disposition_name": "Unknown",
              "valid_time": {
                "start_time": "2022-12-20T15:06:25.857Z",
                "end_time": "2023-01-19T15:06:25.857Z"
:
:
:

3. ワークフローの構成と、作成のステップ、ポイント

実際にはトライ＆エラーを繰り返しながら編集、実行を行い、ワークフロー構成としての最終形態を整えることができました。Web Service Atomic Activities や Execute Python 等による API の直接指定・実行も作成中に試してきましたが、もともとの SecureX オーケストレーターで利用できる素材として用意された Atomic Action のみを利用し、最低限なステップで構成しています。

以下がワークフロー（プレイブック）の構成ブロックです。

ステップ1 : Threat Response - Generate Access Token
Threat Response API 利用のために JWT Access Token を生成（ローカルVariableに保存）
ステップ2 : Threat Response - Enrich Observable
ステップ1の Access Token を設定しAPIにアクセス、ワークフロー実行に必要な調査に必要なObservable情報を入力
ステップ3 : JSONPath Query
Enrich Observable 出力より、主に Judgement、Indicator、Sighting に関する関連情報を抽出
ステップ4 : Set Variables
サマリレポートを編集しローカルVariableに保存
ステップ5 : Threat Response - Create Casebook
サマリレポートを SecureX Casebook に新規作成
ステップ6 : Send Email
サマリレポートを指定 Email に送信

以下、今回のワークフローの各構成ステップに必要な設定項目、注意事項です。
ステップ0は、構成ステップに入る前のワークフロー全体に関わるVariable等の必要パラメータ情報を含みます。

ステップ0 : ワークフロー全体の設定

新規ワークフローの作成を開始します。SecureX ダッシュボードにログインし、オーケストレーションペインターから新規ワークフローを作成し、必要なプロパティを追加し値を設定していきます。

Cisco SecureX ダッシュボードログイン- "Orchestration" タブ選択
"New Workflow" クリック、新規ワークフローを作成開始
ワークフローの "Properties" を設定
- "General" -> "Display Name" 任意のワークフロー名を指定
- "Variables" -> "ADD VARIABLES" 追加
  - "value"
  - "type"
  - "Threat Response Access Token"
  - "Summary Text"
    　追加する Variables は以下の属性（TYPE, SCOPE）を指定します。
- "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" : "CTR_API"
      HTTP API Target の中に、Threat Response 用の "CTR_API" が存在し、"Default Target Group" にアサインされていることを確認します。"CTR_API" で利用する認証情報は、ダイナミックで生成される Access Token を使用するため、Target 内に Account Key を設定する必要はありません。CTR_API に Account Key が設定されてしまった場合、Authorization ヘッダの重複が発生します。
  - "* Select target group criteria" : "Choose first with matching criteria"

ステップ1 : Threat Response アクセストークンの生成

新規ワークフローの枠を作成後、ワークフローを構成する Atomic Activities を配置し、必要なパラメータを設定していきます。初期の Activities はコア API にリクエストするための JWT Access Token を生成する "Threat Response - Generate Access Token" を構成します。

"Activities" から "Threat Response - Generate Access Token" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
ワークフローの "Properties" を設定
- "Target" -> "Override workflow target group criteria"
  - "Conditions" -> "ADD"
    - L. OPERAND : "[$HTTP Endpoint.Display Name$]"
    - OPERATOR : "eqi"
    - R. OPERAND : "CTR_For_Access_Token"
      HTTP API Target の中に、Threat Response 用の "CTR_For_Access_Token" が存在し、"Default Target Group" にアサインされていることを確認します。"CTR_For_Access_Token" は設定内容として、"CTR_API" と似ていますが、用途が異なります。初期のAccess Tokenを生成するためのAPIエンドポイントであるため、Threat Response のAPIキー、APIシークレットを含む認証情報が必要になります。
  - "* Select target group criteria" : Choose first with matching criteria

ステップ2 : Threat Response Enrich Observable API の利用

ワークフローで利用する ”Threat Response - Enrich Observable" Atomic Action は、前述の Swagger ツールで API の動作を確認した、enrich API (/iroh/iroh-enrich/observe/observables) を組み込んだ Atomic Workflow になります。

この Workflow で設定される Properties = * Observable Type、* Observable Value を指定することによって、調査対象の IP アドレスやドメイン名に対して、エンリッチメントを実行します。

"Activities" から "Threat Response - Enrich Observable" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
ワークフローの "Properties" を設定
- "Access Token"
  "Browse Variables" から "Access Token" を選択
  "Activities" -> "Query to Threat Response" -> "Threat Response - Generate Access Token" -> "Access Token"
- "* Observable Type
  "Browse Variables" から "Access Token" を選択
  "Workflow" -> "Input" -> "Type"
- "* Observable Value"
  "Browse Variables" から "Access Token" を選択
  "Workflow" -> "Input" -> "Value"
- "Target" -> "Override workflow target group criteria"
  - "Conditions" -> "ADD"
    - L. OPERAND : "[$HTTP Endpoint.Display Name$]"
    - OPERATOR : "eqi"
    - R. OPERAND : "CTR_API"

ステップ3 : API のアウトプットから情報を成形

ステップ2の出力結果である、"Threat Response - Enrich Observable" の "Enrichment Result" をソースとして、JSONPath Query により必要な情報を抽出するルールを作成します。

"Activities" から "JSONPath Query" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置

ワークフローの "Properties" を設定

"JSON Query" -> "* Source JSON to Query"
"Activities" -> "Qury To Threat Response" -> "Threat Response - Enrich Observable" -> "Enrichment Result"

"JSONPATH QUERIES"

Property Name	JSONPath Query	Property Type
Juddgement Source	$.data..data.judgements.docs..source	String
Juddgement Reason	$.data..data.judgements.docs..reason	String
Juddgement Source URI	$.data..data.judgements.docs..source_uri	String
Juddgement Disposition	$.data..data.judgements.docs..disposition_name	String
Juddgement Confidence	$.data..data.judgements.docs..confidence	String
Indicators Source	$.data..data.indicators.docs..source	String
Indicators Source URI	$.data..data.indicators.docs..source_uri	String
Indicators Confidence	$.data..data.indicators.docs..confidence	String
Sighting Source	$.data..data.sightings.docs..source	String
Sighting Source URI	$.data..data.sightings.docs..source_uri	String
Sighting Confidence	$.data..data.sightings.docs..confidence	String

ステップ4 : サマリレポートのテキスト生成

ステップ3の JSONPath Query の出力結果を使い、ワークフローに設定したローカルVariableの空テキストフィールドに、このステップで実行するテキスト生成のワークフロープロセス (Set Variables) により、上書きを行います。この後のステップで実行する、SecureX Casebook への新規ケース作成、管理者向け Email 送信を行うレポートのソースとして利用します。

"Activities" から "Set Variables" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置

ワークフローの "Variables" を設定
-"VARIABLES TO UPDATE" -> " Variable to update"
"Workflow" -> "Local" -> "Summary Text"
-"New value"
以下はその後のワークフローで展開するサマリーレポートの成形例です。

New Value

SecureX Threat Response Observables Information Summary

- Target : [$workflowworkflow.input.value$]
- Target Type : [$workflowworkflow.input.type$]

Enriched Judgements, Indicators, and Sightings

- Judgement Source : [$activity.JSONPath Query.output.JsonpathQueries.Judgement Source$]
- Judgement Reason : [$activity.JSONPath Query.output.JsonpathQueries.Judgement Reason$]
- Judgement Source URI : [$activity.JSONPath Query.output.JsonpathQueries.Judgement Source URI$]
- Judgement Disposition : [$activity.JSONPath Query.output.JsonpathQueries.Judgement Disposition$]
- Judgement Confidence : [$activity.JSONPath Query.output.JsonpathQueries.Judgement Confidence$]
- Indicator Source : [$activity.JSONPath Query.output.JsonpathQueries.Indicator Source$]
- Indicator Source URI : [$activity.JSONPath Query.output.JsonpathQueries.Indicator Source URI$]
- Indicator Confidence : [$activity.JSONPath Query.output.JsonpathQueries.Indicator Confidence$]
- Sighting Source : [$activity.JSONPath Query.output.JsonpathQueries.Sighting Source$]
- Sighting Source URI : [$activity.JSONPath Query.output.JsonpathQueries.Sighting Source URI$]
- Sighting Confidence : [$activity.JSONPath Query.output.JsonpathQueries.Sighting Confidence$]

@sig666 https://github.com/sig666

ステップ5 : 新規ケースブック作成

ステップ4でテキストを編集し、ローカルVariableのテキストフィールドに保存したサマリレポートを SecureX Casebook に新規ケースとして作成、保存を行います。対象の Observable についてワークフローにより検索を実施、その検索結果のレポート先として SecureX Casebook を利用します。

"Activities" から "Threat Response - Create Casebook" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
ワークフローの "Properties" を設定
- "* Casebook Title" :　任意の文字列 + ワークフロー変数にて指定
- "Access Token" :
  "Browse Variables" から "Access Token" を選択
  "Activities" -> "Query to Threat Response" -> "Threat Response - Generate Access Token" -> "Access Token"
- "Casebook Notes" :
  "Browse Variables" から "Access Token" を選択
  "Workflow" -> "Local" -> "Summary Text"
- "Target" -> "Override workflow target group criteria"
  - "Conditions" -> "ADD"
    - L. OPERAND : "[$HTTP Endpoint.Display Name$]"
    - OPERATOR : "eqi"
    - R. OPERAND : "Private_CTIA_Target"
      HTTP API Target の中に、Threat Response 用の "Private_CTIA_Target" が存在し、"Default Target Group" にアサインされていることを確認します。
  - "* Select target group criteria" : Choose first with matching criteria

ステップ6 : Email 送信

SecureX Casebook への新規ケースの作成と同様に、クイックサーチの結果をアウトプットとしてレポートする手段として、指定したメールアドレスに対して Email を送信するプロセスを追加します。

"Activities" から "Send Email" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
ワークフローの "Properties" を設定
- "Target" -> "Override workflow target"
  "* Target" : "Email Endpoint"
  Send Email Atomic で利用できる Target はメール送信の Email Target となります。Target の SMTP Endpoint を機能に持つ、"Email Endpoint" が存在し、"Default Target Group" にアサインされていることを確認します。"Email Endpoint" では各種 SMTP Server の設定である、STARTTLS over SMTP (587/tcp) や SMTPS (465/tcp) 、 SMTPoverSSL 等を利用できます。認証情報に基づく Account Keys の指定により、設定時に送信メールサーバが有効であるかどうかを確認する必要があります。
- "Email"
  - "From" : "任意の送信元メールアドレス"
  - "To" : "任意の宛先メールアドレス"
  - "Subject" : "任意のメール題名"
  - ”Message" : "Workflow" -> "Local" -> "Summary Text"

ワークフローに必要な Target と Account Key

このワークフローの中心は、Threat Response Enrich API となりますが、これまで説明したとおり、実際の検索対象のクエリーだけではなく、初期の Threat Response Access Token を生成するための API アクセス、Threat Response Casebook を作成するための API アクセス、外部メールサーバに接続しメッセージを送信するための機能に関わる Target を各ワークフローで指定しています。これらの Target、さらにその Target の中で使用される認証情報である Account Key が事前に設定されている必要があります。これらのコンポーネントは SecureX でデフォルトで設定されているものもありますが、ワークフロー設定時に作成が必要になるものもあります。以下の Target 、Account Key が存在していることを確認し、必要に応じて作成します。このワークフローはワークフロー Target を Target Group で指定制御しています。すべての必要な Target が、Default TargetGroup　にアサインされる必要があります。

Target Group: Default TargetGroup

Target 名	Target タイプ	詳細	Account Keys	参考
CTR_API	HTTP Endpoint	Protocol: HTTPS,　Host: `visibility.apjc.amp.cisco.com`,　Path: `/iroh`	None	Created by default
CTR_For_Access_Token	HTTP Endpoint	Protocol: HTTPS,　Host: `visibility.apjc.amp.cisco.com`,　Path: `/iroh`	CTR_Credentials	Created by default
Email Endpoint	SMTP Endpoint	SMTP Server: `Your SMTP Server`,　SMTP Port: `Your SMTP Port`	Email Credential

Account Key

Account Key 名	Account Key タイプ	詳細	参考
CTR_Credentials	SecureX Token		https://ciscosecurity.github.io/sxo-05-security-workflows/account-keys/securex-token
Email Credentials	Email Credentials	Username: `Your Email User`, Password: `Your Email Password`

4. ワークフローのダウンロードと導入

今回作成に取り上げたワークフローはGithubに公開しています。以下リンクからサンプルをダウンロードし導入・テスト・実行することが可能です。

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

ワークフローの各構成ブロックの説明のために導入ステップを説明してきましたが、新規作成およびその設定ステップを必ずしも行う必要はありません。こちらのリンクからThreatResponse-QuickSearchToCasebook.jsonを展開し、お使いの環境のSecureXオーケストレーターから Import を行うことによってワークフローをインストールし利用することができます。
Cisco SecureX ダッシュボードログイン
"Orchestration" タブ選択
"Import Workflow" クリック、"Browser" 選択
Gitの公開サイトより、ThreatResponse-QuickSearchToCasebook.json を展開
https://github.com/sig666/SecureX-Workflow-ThreatResponse-QuickSearchToCasebook/blob/main/ThreatResponse-QuickSearchToCasebook.json
コンテンツ内容をすべて選択し、コピー
"Import Workflow" へペースト、"Import"

5. ワークフローの実行

ワークフローのDeployと、ワークフローパラメータの確認が完了しました。ワークフローの基本ステータスにて "Validated" されており、実行 "Run" が可能であることを確認します。

ワークフローを実行します。

"Run" クリック
"Input Variables" に値指定
- "value" : "1zoom.net" (例)
- "type" : "domain" (例)
"Run" クリック

ワークフローが実行され、構成されたワークフロー Activities の各ブロックの色が実行ステータスによって変化していきます。緑はワークフローの実行が成功、赤はワークフローの実行が失敗、ワークフローのロジック、インプット、リクエスト、サーバ等のエラーが発生している、青は実行中であり時間が経つとステータスが変更、となります。

ワークフローの実行が成功すると、SecureX Casebook に新規ケースが作成され、指定されたメールアドレスに同様な内容のサマリレポートが送信されます。

Reference : SecureX Documents

[0] Cisco SecureX
http://security.cisco.com
[1] SecureX orchestration
https://ciscosecurity.github.io/sxo-05-security-workflows/
[2] SecureX API Integration
https://docs.securex.security.cisco.com/SecureX-Help/Content/integration.html

Reference : Cisco Advent Calender / Git Repo

[1] Cisco Systems Japan Advent Calendar 2022 5日目 : 無料のクラウドPython環境としてのSecureX @dmatsumu
https://qiita.com/dmatsumu/items/40b07c64bb2d688a923c
[2] Cisco Systems Japan Advent Calendar 2022 13日目 : SecureXの承認ワークフローをチャットで実現する仕組みを考えてみた @tetsusat
https://qiita.com/tetsusat/items/875f548898ce92a27832
[3] Cisco Systems Japan Advent Calendar 2022 13日目 : SecureX を Meraki MX と連携してみよう！ @takyamam
https://qiita.com/takyamam/items/1a449e00b7841dd81629
[4] Cisco Systems Japan Advent Calendar 2022 14日目 : Cisco SecureX Orchestrationを使ってWebexBOTのWebhookを受けてみる @akira103
https://qiita.com/akira103/items/3e6dd28469d0c49b343c
[5] Cisco Systems Japan Advent Calendar 2020 18日目 : AWS Lambda で作る無償の脅威インテリジェンスリレーモジュール @sig666
https://qiita.com/sig666/items/05c46d75571c46a7ab34
[6] Cisco Systems Japan Advent Calendar 2021 8日目 : Cisco SecureX を使って簡易 REST API モジュールを作る @sig666
https://qiita.com/sig666/items/ebe41f3850997d8a1303
[7] @sig666
https://github.com/sig666
[8] SecureX-Workflow-ThreatResponse-QuickSearchToCasebook @sig666
https://github.com/sig666/SecureX-Workflow-ThreatResponse-QuickSearchToCasebook
[9] SecureX-Workflow-Umbrella-EventReportToCasebook @sig666
https://github.com/sig666/SecureX-Workflow-Umbrella-EventReportToCasebook