# Creating triage filters via API

Triage filters can be viewed, created, and modified through the public API. In this article, we will explore an example of creating a new triage filter using the v2.5 (QUX) API. Please see the following resources for details on using Vectra's APIs:

Respond UX

* [Vectra Platform API Quickstart Tutorial](https://docs.vectra.ai/configuration/access/api-rux/rux-api-postman-quick-start-guide)
* [Vectra Platform API Guide v3.4](https://docs.vectra.ai/configuration/access/api-rux/v34-api-guide-rux)
* [Vectra Platform API Public Postman Collection](https://www.postman.com/vectra-internal/workspace/vectra-ai/collection/1058623-cc38478b-7261-4e59-8768-1cf61a68ec5d)

Quadrant UX

* [REST API Quick Start Guide for Postman v2.5 using OAuth2 (QUX)](https://docs.vectra.ai/configuration/access/api-qux/v25-postman-quick-start-guide-using-oauth2)
* [REST API Guide v2.5](https://docs.vectra.ai/configuration/access/api-qux/v25-api-guide-qux)
* [Vectra v2.5 Public Postman Collection](https://www.postman.com/vectra-internal/workspace/vectra-ai/collection/7429442-509c593b-8de4-4aa3-ac05-e07934eb9f17)

In the following example, we will create a triage filter that applies to a specific host, which we will reference by it’s ID. In this case the ID is 3345. The ID can be obtained from the API (https\://\<vectra\_brain\_IP>/api/v2.5/hosts) or by looking at the full URL for a host and noting the ID ad the end of the URL (https\://\<vectra\_brain\_IP>/hosts/3345.)

Triage filters can be applied to hosts, IPs/subnets, or all hosts. Only one of these options should be provided. Hence, if the intent is to triage on hosts, then it will not be possible to triage based on IP/subnet in the same triage filter.

Examples of each:\
"host": \[3345, 3350] #applying to hosts with IDs 3345 and 3350\
"ip": \["192.168.1.1"]\
"all\_hosts": true

In this example, we are going to create a triage filter that reclassifies a "Brute-Force Attack" in the "LATERAL MOVEMENT" category, of type "ssh", that is targeting the 10.1.1.0/24 and 10.1.2.0/24 subnets. When creating a triage filter, the detection\_category and detection name must be provided exactly as documented in the [Understanding Vectra AI Detections](https://docs.vectra.ai/operations/analyst-guidance/understanding-vectra-ai-detections) article.

Following is an example of using the curl utility to create a triage filter. The string supplied for triage\_category is the new category type that the detection will be reclassified as.

Specifying the filter is a whitelist ("is\_whitelist": true) will preclude the need to set the triage\_category, as this tells Vectra to create a whitelist filter vs a more common triage filter.

```
curl -X POST \
 https://<vectra_brain_ip_or_hostname>/api/v2.5/rules/ \
 -H 'Authorization: Token <api token>' \
 -H 'Content-Type: application/json' \
 -d '{
    "detection_category": "LATERAL MOVEMENT",
    "triage_category": "SSH.Brute.Force-SystemAuth",
    "detection": "Brute-Force",
    "remote1_ip": ["10.1.1.0/24", "10.1.2.0/24"],
    "remote1_proto": ["ssh"],
    "is_whitelist": 0,
    "description": "Normal Authentication Activity",
    "host": [3345]
 }'
```

Using curl to view the new entry after it was created:

```
curl -H "Authorization: Token <api token>" -k https://<vectra_brain_ip_or_hostname>/api/v2.5/rules/
{
  "id": 167,
  "url": "https://<ip_removed>/api/v2.5/rules/167",
  "description": "Normal Authentication Activity",
  "created_timestamp": "2018-01-05T19:37:48Z",
  "last_timestamp": null,
  "host": [
    "https://<ip_removed>/api/v2.5/hosts/3345"
  ],
    "all_hosts": false,
    "is_whitelist": false,
    "sensor_luid": null,
    "ip": null,
    "priority": 2,
    "remote1_ip": [
    "10.1.1.0/24",
    "10.1.2.0/24"
  ],
    "remote1_proto": [
    "ssh"
  ],
  "detection_category": "LATERAL MOVEMENT",
  "triage_category": "SSH.Brute.Force-SystemAuth",
  "detection": "Brute-Force"
}
```