In this document:
Overview of Security Incidents Connectors
Security incidents, detections, and events are supported by the Armor webhook platform. Two configuration APIs are needed to set subscriptions of events, detections, and incidents: Transform Detections API and Notifications API. Subscription types which are defined can be enriched with default values, values from the Armor tags implementation, partner level overrides, and related to an Armor search direct link URL (if applicable). The platform also supports limited self service debugging through the use of an “email on failure” address whenever a target destination fails. Armor maintains a history of all webhook actions and can be contacted through a support ticket if further troubleshooting is required.
How to use the Detections Transform Config API
The Detections Transform Config API is used for each customer account which is subscribing to security detections, incidents, and/or events. For partners: All of the child accounts are automatically subscribed when creating a transform API request. The purpose of this API to two fold: to create the subscription in the Armor platform so that Armor will begin to process detections, incidents, and/or events for subscribed account (or child accounts) and to allow the customer to define additional property transforms to the outgoing webhook payload which may be relevant to the customer or partner environment (e.g. customer unique IDs or foreign keys). After the webhook payload processed it is sent to the delivery handler which will process the request through up to 25 defined destinations. Note: Only one transform can be defined per account.
The API reference is available at https://developer.armor.com/webhooks.
The API POST request body is broken into 6 parts:
name- A short name describing the transform configuration
format- Can be default, splunk, or ecs
events- Contains a string array of types of data which will be added to the payload and sent to the webhook endpoints. For event ingestion platforms use “security event” to receive all correlated events which belong to a given offense, this could trigger multiple subsequent webhooks as more events could be correlated to a detection over time. For ticketing platforms it is common to only leverage incidents and detections to trigger ticket creation. All events are stored and searchable at https://amp.armor.com.
security incident- Armor incidents are security detections which have been processed by Armor to be escalated as a full incident.
security detection- Security detections are any correlated detection in the Armor platform which hasn’t been escalated to an incident.
security event- The raw events which belong to the correlated detection or incident.
default_label- Use this section to define properties which are added to event, detection, or incident that is processed by the webhook platform. NOTE: This would apply to partner child account events, detections, or incidents which are processed by the partner parent account.
"key": "[nested].key"- Defines the name of the property that’s added to the payload object
"value": "Alpha"- The value that is placed in the property or nested property.
transform- Use this section to define transforms which require the lookup of additional data to complete.
add_dynamic_tag- Supports the Armor Tags API to enrich events.
remove_dynamic_tag- Supports the ability to exclude properties or tags which may be defined by the customer or Armor and should not be populated during the transform process. (i.e. prevent customers from accidentally overwriting important partner defined values, exclude a built in property by Armor)
add_log_search_url- Supports events which have the “eventId” property and can add linkable Kibana queries directly to the correlated event.
How to use the Notifications API
The Notifications API is used to define where events, detection, and incidents should be sent. There are several properties available to be configured for custom URL targets, headers, and email preferences in the event of an error. The notifications API also allows up to 25 notification configs to be installed. Each config can subscribe to one or more types defined in the API to allow for customization of target destinations based on the requirements of the customer.
The configuration is broken into 4 parts:
event_type and properties. At release, email_for_error supports ‘email’ type only and properties only supports a single uri and up to 25 defined header properties . All headers are added to the webhook request automatically.
nameA short name describing the webhook configuration
on_errorUse this section to define how errors can be received if the destination is unavailable or inaccessible for delivery.
event_typeAn array of security_incident, security_detecetion, and/or security_event. These event types are also defined in the Detection Transform config and are processed with each Notification config individually.
propertiesThis section contains the uri and header(s) for the target destination webhook.
"type": "uri"The full URI (with port and scheme) of the target destination webhook. NOTE Only one URI can be defined per Notification Config
"type": "header"Allows the control of headers to be placed in the request to the target destination. Headers are loaded “as is” with no attempt sanitize what gets placed in the request to allow for full customizability of any header formats.
Example Security Incidents Connector Payloads
Splunk Payload - Incident/Detection Only
Splunk Payload - Incident/Detection w/Events
Splunk Payload - Event(s) Only
Default Payload - Incident/Detection Only
Default Format - Incident/Detection w/Events
Default Payload - Event(s) Only
ECS Payload - Detection
ECS Payload – Incident
ECS Payload – Event(s)
Was this helpful?