Understanding Automation Triggers
Howdy folks, triggers are crucial for automating actions with the Enforcement Center. When using triggers, there are quite a few conditionals that can be enabled to change when and what data the action runs against. Let’s review the different configuration options and how they can impact the results of our EC action.
- Understanding how triggers work.
- Specifically our conditional triggers and running on added entities only.
- Understanding their outputs.
- Understanding when to use them.
We’ll be testing the different trigger configurations with the Send to Webhook Enforcement Center action. https://webhook.site/ can be used to generate webhooks on command.
With Webhooks, we can push data from Axonius to different data sources. Webhooks can store cached device information from Axonius to allow for quick asset retrieval, Or as input for more advanced automation requiring device information from Axonius.
We’ll be using the default settings for the Send to Webhook action.
More details about the settings we are reviewing can be found in our official documentation: https://docs.axonius.com/docs/configuring-triggers
- Saved Query
- Automation Settings
- Additional Conditionals
- Run on added entities only
A saved query is the one required component when creating a trigger. The saved query contains the records we want to run the action against. We currently allow for a few different saved query types:
- Activity Logs
- Adapter Fetch History
Note: Some actions that require user/device data will fail when an activity log or adapter fetch history saved query is used.
When running notification actions, the columns in the saved query are utilized within the action. If there are any specific fields we want to be included in the output, our saved query should be updated to include those fields as columns. Let’s consider a saved query with the following columns.
We can see below that we only send these fields to our webhook.
If we update the fields in the saved query to include ServiceNow Class Name and Title, we can see they appear the next time the action runs.
Custom Schedule Settings
This is where we define how often we want our enforcement center action to automatically run.
- Every discovery cycle
- Every X hours
- Every X days
- Days of the week
- Days of the month
When possible, every discovery cycle is the preferred scheduled setting as it ensures that all phases of correlation are complete. Selecting any of the other options might cause the action to run during the discovery phase, where asset information might not be aggregated and deconflicted correctly.
Conditionals detect changes in the query results and determine the behavior of the enforcement center run accordingly.
These would be valuable if you would like an updated list of all assets only if the results in the saved query change
- Only when assets have been added since the last execution (in comparison to the last time the enforcement set had been executed).
- Only when assets have been removed since the last execution (in comparison to the last time the enforcement set had been executed).
These can be valuable guardrails in case a saved query includes/excludes too many assets.
- Only when the number of assets is above N - specify numeric value. Default value is 1.
- Only when the number of assets is below N - specify numeric value. Default value is 1.
The enforcement set runs and generates a new enforcement task only if at least one of the conditions is met.
If we use the Enforcement Center to manage our vulnerability scanning infrastructure with Qualys tags, we might want to enable “Only when the number of assets is below N” so we do not accidentally remove tags from too many assets in Qualys. This may happen in scenarios where the underlying saved query is accidentally updated to include too many devices.
Run on Added Entities Only
Automation settings need to be enabled for this setting to work.
There are scenarios where an enforcement center action should only run on an asset once — not multiple times even if the device remains in the saved query. In these cases, we would enable “Run on added entities only”
Consider the scenario where we want to create a Jira ticket when a security agent is not installed on a machine. If we have a scheduled enforcement action to create a Jira ticket for each device without a security agent. We don’t want a new ticket being generated for this device every time this enforcement runs. When this is the case, we want to enable the setting “Run on added entities only”
Let's see how this works. Here the saved query has two devices and we’ll enable “Run on added entities only”
These two devices will not be sent to Webhook unless we run the action manually. A manual run (Run 0) is required to send our initial two devices to the webhook.
Now, let’s add another device to our saved query.
On the next scheduled run, we’ll see that only that new device gets sent to our webhook.
If you have any other questions about these automation settings, please let us know!