Security Incidents Connector Tagging

Overview

The purpose of Security Incidents Connector tagging is allow partners and customers to enrich outgoing webhooks with additional values which are retrieved from the Armor tagging endpoint. Armor Log Relay syslog sources, Armor Agents, and Cloud Sources can all be tagged to allow customers and partners to input unique values from their systems to be added to events, incidents, and detections which are generated by the Armor Security Platform. In addition, to allow customer child accounts to leverage the tagging implementation without interference to the parent account, Armor supports parent account level overrides to ensure consistency with expected tagging values.

Tags usage with Armor Agent 3.0

The latest Armor Agent supports many new CLI functions and customizability including being able to select which security services your business would like to install and leverage. In addition, tags can now be created directly using the agent CLI as well as creating them directly with POST requests to the Armor Tags API.

Below are the steps required to install and add tags through the Armor Core Agent.

Install the Armor Agent

Linux

CODE

$ sudo mkdir /opt/armor && sudo curl -o /tmp/armor-linux.tar.gz https://agent.armor.com/latest/armor-linux.tar.gz && sudo tar zxvf /tmp/armor-linux.tar.gz -C /opt/armor && sudo /opt/armor/armor register --license XXXXX-XXXXX-XXXXX-XXXXX-XXXXX --region us-east-1

Windows

CODE

[System.Reflection.Assembly]::LoadWithPartialName("System.IO.Compression.FileSystem");[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;mkdir c:\.armor\opt; Invoke-WebRequest https://agent.armor.com/latest/armor-windows.zip -outfile c:\.armor\opt\armor-windows.zip;[System.IO.Compression.ZipFile]::ExtractToDirectory('c:\.armor\opt\armor-windows.zip','c:\.armor\opt'); c:\.armor\opt\armor.exe register --license XXXXX-XXXXX-XXXXX-XXXXX-XXXXX --region us-east-1

After installation, tags can be managed through the CLI command: ./armor tags create-tags
CODE
```
# ./armor tags create-tags key=value,key2=value2
```

Tags usage for other data sources

Tags for log relay, cloud based logging, and flows are handled manually in the Armor platform and require end users to gather unique IDs which Armor is expecting and then to use that ID to create the resources in the tags endpoint. Once the correct tagging resource IDs are loaded the Armor webhook platform will automatically load them into enrichment on future security detections and incidents.

Armor Agent - Log Relay

Log relay tags are identified using the Armor core instance ID of the Log relay appliance and the corresponding unique identifier of the device sending the logs (found here).

The tags endpoint is then called with the Log Relay core instance ID and the device specific unique identifier e.g. (4f730b6e-1336-4302-b5bf-957478c4eb3d and host.example.com):

CODE

POST /tags/4f730b6e-1336-4302-b5bf-957478c4eb3d::host.example.com
//Request Body:
{
    "tags":
        [
            {"Key":"id","Value":"companyX"},
            {"Key":"index","Value":"production"}
        ]
}

If the full resourceId (4f730b6e-1336-4302-b5bf-957478c4eb3d::host.example.com) is not found, the base Log Relay core instance id (4f730b6e-1336-4302-b5bf-957478c4eb3d) is referenced for tags information.

If no tag resourceId is found, then add_dynamic_tag will not add any fields to the webhook payload.

Cloud Based Logs

Cloud based logs (e.g. Guard Duty and AWS Cloud Trail) are assigned unique identifiers from the Armor platform and require a log into AMP to gain access to them. The identifiers can be accessed from "HOSTNAME" column at https://portal.armor.com/security/log-management?activeTab=tab-External-Sources.

The tags endpoint is then called with

CODE

POST /tags/guardduty--#######8823--multi-azs
//Request Body:
{
    "tags":
        [
            {"Key":"id","Value":"companyX"},
            {"Key":"index","Value":"production"}
        ]
}

Flows

Flow log collection is new to Armor and is subject to change as we expand the capabilities of the current ingestion methodology and add support for different devices in which process flows.

Currently, supported flow types are

AWS VPC Flow Logs
Microsoft Azure NSG Flow logs

In the Armor platform as flows are enabled for a customer account, we assign a flow collector endpoint in the SIEM which binds all flow traffic to a specific customer account. Tagging is also implemented at the customer account level when leveraging add_dynamic_tag to enrich flow logs in the webhook platform.

Enable Flows for Current Account

To gather the flow unique identifier for the customer account you will need an account on the Armor plataform with IMC access. The flow configuration is available at: https://portal.armor.com/security/log-management?activeTab=tab-Flow-Sources. Flows can be activated for the customer account at https://portal.armor.com/security/log-management/new-source.

E.g. Unique identifier: siem_flow_10

The tags endpoint is then called with the unique identifier siem_flow_10

CODE

POST /tags/siem_flow_107
//Request Body:
{
    "tags":
        [
            {"Key":"id","Value":"companyX"},
            {"Key":"index","Value":"production"}
        ]
}

If the full resourceId (siem_flow_10) is not found, the Organization Id (1024) is referenced for tags information.

If no tag resourceId is found, then add_dynamic_tag will not add any fields to the webhook payload.

Enable Flows for customer account

https://portal.armor.com/security/log-management/new-source

Gather Unique Identifier for Flows

https://portal.armor.com/security/log-management?activeTab=tab-Flow-Sources

The tags endpoint is then called with

CODE

POST /tags/siem_flow_107
//Request Body:
{
    "tags":
        [
            {"Key":"id","Value":"companyX"},
            {"Key":"index","Value":"production"}
        ]
}

Tagging Override - Parent Account

The detections transform API also supports the ability to override tagged values, per each account, at both the partner account or customer account level. Tags are applied in an order of specificity from highest to lowest priority (Account Override-> Device(e.g. core instance) -> Detection Transform Defaults)

Using this convention to POST to the tagging API with /tags/XXXX_event_enrich_account_override, where XXXX is the account ID, will cause any customer defined tags to be overridden with properties defined in the account override. NOTE: This tag is created at the customer account and not at the partner account.

/tags/1000_event_enrich_account_override

CODE

{
  "AccountId": 1000,
  "Resource": "1000_event_enrich_account_override",
  "tags": [
    {
      "Key": "rcn_idx",
      "Value": "MY_ACCOUNT_TAG"
    }
  ]
}