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

![xmas.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/1558cd76-cd2f-0f1a-d4d6-410b342a76c5.png)
!! <font color="DeepPink"><B>Merry Christmas</B></font> !!
<font color="DarkSlateBlue">Cisco Advent Calendar 2022</font>: https://qiita.com/advent-calendar/2022/cisco

# はじめに

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

「<B><font color="Red">SecureX - ドラッグ＆ドロップだけで本格的セキュリティ調査プレイブックを作る</font></B>」

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

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

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


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


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

日々の組織のセキュリティオペレーションでどのタイミングでも必要となる、例えば、<font color="Red">被疑のある対象IPアドレス、ファイルハッシュ、宛先ドメイン、ファイルパス、等に関する、追加情報、判定情報、関連のサマリレポートを SecureX プラットフォームの基本機能として、サマリ情報、追加情報を提示できるレポート機能を Threat Response によってシンプルに実装 (<B>Threat Response クイックサーチワークフロー</B>)</font> できれば汎用的なワークフローシナリオのテーマとして考えられます。この要件はすでに SecureX Threat Response によって実装されていますが、実行時間を短縮するとともに、リレーションマップ表示でなくサマリテキストを作成、SecureX Casebook や管理者向け Email 送信を実装し、ユースケースの差別化を行います。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/7ac2a01c-b747-c5aa-5f7d-47bc45f65de0.png">



## 2. ワークフローで利用するコアAPIのテスト
<B>SecureX Threat Response enrich API (/iroh/iroh-enrich/observe/observables)</B> を利用します。シンプルな Required Value によるインプットにて多くのエンリッチできる情報を提示できる API エンドポイントを利用することにします。

`/iroh/iroh-enrich/observe/observables`

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

https://visibility.apjc.amp.cisco.com/iroh/iroh-enrich/index.html#/Observe/post_iroh_iroh_enrich_observe_observables

- "<B>Authorize</B>" クリック
  <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/a967a672-9d0e-fdb7-13f9-5d7550c02684.png">
- "<B>Log In with SecureX Sign-On</B>" クリック、SecureX にログオン
  <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/f522a722-2505-3753-bb47-871f16164acd.png" width=40%>
- "<B>Try it out</B>" クリックし、インプット Value を編集可能にする
- Required Value に Enrich Observable でエンリッチしたい調査対象 IoC を編集・入力し、"<B>Execute</B>" をクリック

```json:Example Value
[
  {
    "value": "string",
    "type": "file_path"
  }
]
```
```json:Edited Value
[
  {
    "value": "157.7.97.72",
    "type": "ip"
  }
]
```
- Swagger の実行結果から、Curl のリクエストコマンド、Request URL、Response Body、Response Header の出力結果を確認することによって、この API を実行するためのリクエストに必要なデータ、ヘッダ、APIによって出力される実行結果のデータ形式を事前に把握することに役立ちます。
  <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/06b32a04-6e60-8a9e-144a-3e872916d5a4.png">

 
```Bash: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\" }]"
```
```json: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 のみを利用し、最低限なステップで構成しています。

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

- <B>ステップ1</B> : <font color="DarkSlateBlue"><B>Threat Response - Generate Access Token</B></font>
  Threat Response API 利用のために JWT Access Token を生成（ローカルVariableに保存）
- <B>ステップ2</B> : <font color="DarkSlateBlue"><B>Threat Response - Enrich Observable</B></font>
  ステップ1の Access Token を設定しAPIにアクセス、ワークフロー実行に必要な調査に必要なObservable情報を入力
- <B>ステップ3</B> : <font color="DarkSlateBlue"><B>JSONPath Query</B></font>
  Enrich Observable 出力より、主に Judgement、Indicator、Sighting に関する関連情報を抽出
- <B>ステップ4</B> : <font color="DarkSlateBlue"><B>Set Variables</B></font>
  サマリレポートを編集しローカルVariableに保存
- <B>ステップ5</B> : <font color="DarkSlateBlue"><B>Threat Response - Create Casebook</B></font>
  サマリレポートを SecureX Casebook に新規作成
- <B>ステップ6</B> : <font color="DarkSlateBlue"><B>Send Email</B></font>
  サマリレポートを指定 Email に送信
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/a0553878-e4d2-2086-279c-4ebcecbacff7.png">



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

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

- Cisco SecureX ダッシュボードログイン- "<B>Orchestration</B>" タブ選択
- "<B>New Workflow</B>" クリック、新規ワークフローを作成開始
- ワークフローの "Properties" を設定
    - "General" -> "<B>Display Name</B>" 任意のワークフロー名を指定 
    - "Variables" -> "<B>ADD VARIABLES</B>" 追加
        - "<B>value</B>"
        - "<B>type</B>"
        - "<B>Threat Response Access Token</B>"
        - "<B>Summary Text</B>"
        　追加する Variables は以下の属性（TYPE, SCOPE）を指定します。
        <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/925b8e81-394a-12ea-de3a-f3b4567b9967.png" width=70%>
    - "<B>Target</B>" -> "<B>Execute on this target group</B>" 
        - <B>Default Target Group</B>
        - "* Select target types" : <B>HTTP Endpoint</B>
        - "Conditions" -> "<B>ADD</B>"
            - "L. OPERAND" : "<B>[$HTTP Endpoint.Display Name$]</B>"
            - "OPERATOR" : "<B>eqi</B>"
            - "R. OPERAND" : "<B><font color="Red">CTR_API</font></B>" 
        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" : "<B>Choose first with matching criteria</B>"
        <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/c7bddf58-fef0-fdfc-aa74-cfd7260351cb.png" width=50%>


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

- "<B>Activities</B>" から "<B>Threat Response - Generate Access Token</B>" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/3efee313-a23e-41e5-09a7-0da6d4e55e51.png" width= 90%>

- ワークフローの "<B>Properties</B>" を設定
    - "<B>Target</B>" -> "<B>Override workflow target group criteria</B>"
        - "Conditions" -> "<B>ADD</B>"
            - L. OPERAND : "<B>[$HTTP Endpoint.Display Name$]</B>"
            - OPERATOR : "<B>eqi</B>"
            - R. OPERAND : "<B><font color="Red">CTR_For_Access_Token</font></B>"
        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シークレットを含む認証情報が必要になります。
        - "<B>* Select target group criteria</B>" : Choose first with matching criteria


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

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

- "<B>Activities</B>" から "<B>Threat Response - Enrich Observable</B>" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
- ワークフローの "<B>Properties</B>" を設定
    - "<B>Access Token</B>"
      "Browse Variables" から "Access Token" を選択
      "<B>Activities</B>" -> "<B>Query to Threat Response</B>" -> "<B>Threat Response - Generate Access Token</B>" -> "<B>Access Token</B>"
    - "<B>* Observable Type</B>
      "Browse Variables" から "Access Token" を選択
      "<B>Workflow</B>" -> "<B>Input</B>" -> "<B>Type</B>" 
    - "<B>* Observable Value</B>"
      "Browse Variables" から "Access Token" を選択
      "<B>Workflow</B>" -> "<B>Input</B>" -> "<B>Value</B>" 
      <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/ffd96245-c428-10c9-3104-8cac5ddd1a35.png">

   - "<B>Target</B>" -> "<B>Override workflow target group criteria</B>"
       - "Conditions" -> "<B>ADD</B>"
            - L. OPERAND : "<B>[$HTTP Endpoint.Display Name$]</B>"
            - OPERATOR : "<B>eqi</B>"
            - R. OPERAND : "<B>CTR_API</B>"

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

- "<B>Activities</B>" から "<B>JSONPath Query</B>" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
- ワークフローの "<B>Properties</B>" を設定
    - "JSON Query" -> "* Source JSON to Query"
      "<B>Activities</B>" -> "<B>Qury To Threat Response</B>" -> "<B>Threat Response - Enrich Observable</B>" -> "<B>Enrichment Result</B>"
    - "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 送信を行うレポートのソースとして利用します。

- "<B>Activities</B>" から "<B>Set Variables</B>" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
- ワークフローの "<B>Variables</B>" を設定
    -"*VARIABLES TO UPDATE" -> "* Variable to update"
     "<B>Workflow</B>" -> "<B>Local</B>" -> "<B>Summary Text</B>"
    -"New value"
     以下はその後のワークフローで展開するサマリーレポートの成形例です。
    ```php: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 を利用します。

- "<B>Activities</B>" から "<B>Threat Response - Create Casebook</B>" を選択しドラッグ＆ドロップで作成ワークフロー内へ配置
- ワークフローの "<B>Properties</B>" を設定
    - "* Casebook Title" :　任意の文字列 + ワークフロー変数にて指定
    - "Access Token" :
      "Browse Variables" から "Access Token" を選択
      "<B>Activities</B>" -> "<B>Query to Threat Response</B>" -> "<B>Threat Response - Generate Access Token</B>" -> "<B>Access Token</B>"
    - "Casebook Notes" :
      "Browse Variables" から "Access Token" を選択
      "<B>Workflow</B>" -> "<B>Local</B>" -> "<B>Summary Text</B>"
    - "Target" -> "<B>Override workflow target group criteria</B>"
        - "Conditions" -> "<B>ADD</B>"
            - L. OPERAND : "<B>[$HTTP Endpoint.Display Name$]</B>"
            - OPERATOR : "<B>eqi</B>"
            - R. OPERAND : "<B><font color="Red">Private_CTIA_Target</font></B>"
        HTTP API Target の中に、Threat Response 用の "Private_CTIA_Target" が存在し、"Default Target Group" にアサインされていることを確認します。
        - "<B>* Select target group criteria</B>" : Choose first with matching criteria
        
### ステップ6 : Email 送信
SecureX Casebook への新規ケースの作成と同様に、クイックサーチの結果をアウトプットとしてレポートする手段として、指定したメールアドレスに対して Email を送信するプロセスを追加します。

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


### ワークフローに必要な Target と Account Key
このワークフローの中心は、Threat Response Enrich API となりますが、これまで説明したとおり、実際の検索対象のクエリーだけではなく、初期の Threat Response Access Token を生成するための API アクセス、Threat Response Casebook を作成するための API アクセス、外部メールサーバに接続しメッセージを送信するための機能に関わる <B>Target</B> を各ワークフローで指定しています。これらの Target、さらにその Target の中で使用される認証情報である <B>Account Key</B> が事前に設定されている必要があります。これらのコンポーネントは SecureX でデフォルトで設定されているものもありますが、ワークフロー設定時に作成が必要になるものもあります。以下の <B>Target</B> 、<B>Account Key</B> が存在していることを確認し、必要に応じて作成します。このワークフローはワークフロー 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に公開しています。以下リンクからサンプルをダウンロードし導入・テスト・実行することが可能です。
- <B>[Github @sig666] SecureX-Workflow-ThreatResponse-QuickSearchToCasebook
  https://github.com/sig666/SecureX-Workflow-ThreatResponse-QuickSearchToCasebook</B>
  <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/3d3e7e60-ad81-9a72-df6d-09b055569bca.png">
ワークフローの各構成ブロックの説明のために導入ステップを説明してきましたが、新規作成およびその設定ステップを必ずしも行う必要はありません。こちらのリンクから<B>ThreatResponse-QuickSearchToCasebook.json</B>を展開し、お使いの環境のSecureXオーケストレーターから Import を行うことによってワークフローをインストールし利用することができます。

- Cisco SecureX ダッシュボードログイン
- "<B>Orchestration</B>" タブ選択
- "<B>Import Workflow</B>" クリック、"<B>Browser</B>" 選択
- Gitの公開サイトより、<B>ThreatResponse-QuickSearchToCasebook.json</B> を展開
  https://github.com/sig666/SecureX-Workflow-ThreatResponse-QuickSearchToCasebook/blob/main/ThreatResponse-QuickSearchToCasebook.json
- コンテンツ内容をすべて選択し、コピー
- "Import Workflow" へペースト、"<B>Import</B>"
  <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/ffee2d9a-2b4c-1a74-c812-9cbe353828b1.png" width=60%>

## 5. ワークフローの実行
ワークフローのDeployと、ワークフローパラメータの確認が完了しました。ワークフローの基本ステータスにて "Validated" されており、実行 "Run" が可能であることを確認します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/e4069edd-480b-238a-4d58-34bda8102ad4.png">

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

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

ワークフローが実行され、構成されたワークフロー Activities の各ブロックの色が実行ステータスによって変化していきます。<font color="Green"><B>緑</B></font>はワークフローの実行が成功、<font color="Red"><B>赤</B></font>はワークフローの実行が失敗、ワークフローのロジック、インプット、リクエスト、サーバ等のエラーが発生している、<font color="Red"><B>青</B></font>は実行中であり時間が経つとステータスが変更、となります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/63eb827a-8cce-ddee-3cf8-5179649d7bc6.png" width=70%>

ワークフローの実行が成功すると、SecureX Casebook に新規ケースが作成され、指定されたメールアドレスに同様な内容のサマリレポートが送信されます。
![Result1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/fbe0354b-d418-e955-426b-bc04adfc30bc.png)
![Result2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311200/eaadf928-eb02-b861-8d99-d5cfc82f8231.png)


# 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