Dynamic Variables

Created by David Esposito, Modified on Fri, 25 Oct at 11:53 AM by David Esposito

Syntax

We use a similar syntax to Postman which should make adoption easier. When using any of the properties defined below, ensure to include the entity and property inside double curly braces, e.g. {{entity.property}}. Note that our naming scheme is influenced by the platforms heavy use of Javascript and Typescript so all properties will be written in camel case, e.g. {{user.firstName}}.

Properties

The following variables are available when configuring custom actions.

Property	Description
{{finding.displayValue}}	A short human friendly description of the finding. Can be used as a title.
{{finding.description}}	Long technical description of the finding. Often includes values like CVE's and other low level technical details. Meant for security and IT team.
{{finding.discoveredAt}}	First time the finding was discovered. Sometimes reported by vulnerability scanners but is often the date of ingestion into our system, e.g. overdue training.
{{finding.category}}	High level finding category. Amplifier defines the following values: [ENDPOINT_MANAGEMENT, ENDPOINT_SECURITY, VULNERABIITY, IDENTITY, TRAINING, CUSTOM]
{{finding.severity}}	Maps closely to CVSS with values being [INFO, LOW, MEDIUM, HIGH, CRITICAL]
{{finding.kind}}	More specific category label of the finding. Amplifier defines some based on our native integrations, but this can also be populated by custom findings $.eventType property.
{{user.firstName}}	User's first name when available. We favor identity providers, e.g. Okta, but fall back to other providers when necessary, e.g. messaging or device management user profiles.
{{user.lastName}}	User's last name when available. We favor identity providers, e.g. Okta, but fall back to other providers when necessary, e.g. messaging or device management user profiles.
{{user.organization}}	User's organization when available. We favor identity providers, e.g. Okta, but fall back to other providers when necessary, e.g. messaging user profiles.
{{user.department}}	User's department when available. We favor identity providers, e.g. Okta, but fall back to other providers when necessary, e.g. messaging user profiles.
{{user.title}}	User's job title when available. We favor identity providers, e.g. Okta, but fall back to other providers when necessary, e.g. messaging user profiles.
{{user.email}}	User's primary email address.
{{asset.displayValue}}	This is usually the hostname or assigned name of the device associated with the finding inside your Device Management service. If an assigned name is not provided, we fallback to using hostname.
{{asset.serialNumber}}	The serial number of the device associated with the finding when available.
{{asset.macAddress}}	The mac address(es) of the device associated with the finding when available.

Examples

Automox Automation

curl -XPOST https://actions.amplifiersecurity.io/automox/actions/explode \
  -h 'content-type: application/json' \
  -d '{
    "token": "my-token",
    "actionUrl": "https://console.automox.com/api/policies/######/action?o=######",
    "filter": {
        "device_filters": [
            {
                "field": "serial_number",
                "op": "like_any",
                "value": [
                    "{{asset.serialNumber}}"
                ]
            }
        ],
        "server_groups": [
            ######
        ]
    },
    "dryRun": true
}