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
After installation, tags can be managed through the CLI command:
./armor tags create-tags
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::host.example.com) is not found, the base Log Relay core instance id (
4f730b6e-1336-4302-b5bf-957478c4eb3d) is referenced for tags information.
add_dynamic_tagwill 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
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
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
Gather Unique Identifier for Flows
The tags endpoint is then called with
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.