Overview

To understand Actionable Alerts and how they are created, it helps to understand the workflow that takes place when an Inspector runs.

After your Inspector successfully runs, it will collect information about the target system, and it will send that data to Liongard in what we refer to as a "Data Print."

A Metric is a query into the Data Print that returns a value or data point. All Actionable Alert rules are built on Metrics.

Once that Data Print lands in Liongard, Liongard runs the query for the Metric used in the Actionable Alert rule. It then compares the output value of the Metric to the thresholds set for the specific Actionable Alert rule.

Only Actionable Alert rules that are enabled in active Templates, applied to Environments will trigger alerts.

How are Actionable Alerts triggered?

Actionable Alerts are triggered by querying into the Inspectors Data Print, retrieving a specific Metric, and comparing that value to the thresholds set for the specific Actionable Alert rule.

Example: Active Directory | User Accounts With Brute Force Attempts

To demonstrate how this works, we will use our Actionable Alert rule, "Active Directory | User Accounts With Brute Force Attempts."

Active Directory stores a value called “badPwdCount” that increases by one every time an incorrect password is entered. When your Active Directory Inspector runs, we read this value and place it in the Data Print as the key, “AnomalousActivity.”

If the value of the "badPwdCount" is less than or equal to three, the value for "AnomalousActivity" will read “Incorrect Password Attempts" in the Data Print.

If the value of the "badPwdCount" is greater than three, the value for "AnomalousActivity" will read “Brute Force Attempts” in the Data Print.

The Metric that will output this data is titled, "Active Directory: User Accounts With Brute Force Attempts Count".

The Actionable Alert rule "Active Directory | User Accounts With Brute Force Attempts" is set to trigger when the query output for the "Active Directory: User Accounts With Brute Force Attempts Count" Metric is greater than zero.

Once your inspection is complete and a Data Print lands in Liongard if you have the Actionable Alert rule "Active Directory | User Accounts With Brute Force Attempts" enabled in an active Template that is applied to Environments, we run a query into the Data Print to retrieve this stored value.

Finally, once the value is retrieved, we evaluate it against the threshold set for the Actionable Alert. In this case, if the value is greater than zero.

How to Address Actionable Alerts

Actionable Alerts are addressed by evaluating and/or clearing the issue in question on the system being inspected. This means that the only way to close an Actionable Alert in Liongard automatically is to rectify the issue in the target system.

Rules using change detections will not automatically close. They will only automatically close unless the correct PSA board and associated statuses are set up in the integration.

Liongard will leave any alerts that are still triggered when the next inspection runs open.

Example: Active Directory | User Accounts With Brute Force Attempts

Using our example above, you would need to clear the “badPwdCount” value in Active Directory so that the next time the Inspector runs it returns a value of “0.” The “badPwdCount” value is cleared by successfully logging into the account listed in the alert.

When the inspection runs at its next scheduled time, the workflow process repeats. Provided that a successful login was completed, the inspection will return a value of “0” for “badPwdCount” and a zero will be returned in our Data Print under the key, “AnomalousActivity.” Then, when the Metric query runs again for the alert, it too will return a 0, and the alert will automatically clear.

In alerts written by Liongard, an Action recommendation is included in the body of the alert to help users determine how to clear the alert. Again, remediations need to take place on the target system. You will not be able to clear the condition from Liongard.

What causes an Actionable Alert to Reopen?

Liongard reopens an Actionable Alert if the alert is closed but the condition resurfaces within seven calendar days.

Example: Active Directory | User Accounts With Brute Force Attempts

In our example above, if the alert was triggered on Monday, and the account was successfully logged into on Monday (clearing the counter), and then, the inspection ran on Tuesday, the alert would clear.

Then, suppose on Wednesday, when the inspection ran, it was detected that the Active Directory counter for that same account returned a value of five bad attempts. Instead of opening a new alert, Liongard would reopen the same alert from Monday because the condition returned within seven days.

How are Change Detection Actionable Alerts triggered?

Liongard's Change Detections notify you of critical changes to the systems you are managing.

Change Detection Alerts are considered to be any alert rule that uses the "changed" operator. Additionally, when the "changed" operator is selected, a Change Detection will automatically be enabled for that alert.

Change Detection alerts are triggered when there is a change in the output value of the Metric used in an Actionable Alert rule that uses the "changed" operator. Change Detection alerts will always include a comment by the RoarBot that depicts the Data Print changes for the Metric used in the alert.

Example: Active Directory | Change to Privileged Users

For this example, we will use the alert, "Active Directory | Change to Privileged Users"

Assume "User A” is added as a Privileged User on Monday. The next time the Active Directory inspection runs, it would trigger an alert for, "Active Directory | Change to Privileged Users" because a new user has been added to the Privileged Users list.

Then, suppose "User B" is added as a Privileged User on Wednesday. The next time the inspection runs, it will trigger the same alert because both items are considered to be a change to the Privileged Users list.

How to Address Change Detection Actionable Alerts

If you are sending Change Detection Alerts to ConnectWise, once you have reviewed the alert, close the ticket in ConnectWise. This will then close the ticket in Liongard.

If you are using Liongard's alerts in Liongard and/or our other PSA integrations/email, you will need to close the Change Detection Alert inside Liongard once you have reviewed it. To close an Alert, please review our Closing Liongard's Actionable Alerts documentation.

Closing the alert will ensure that future changes will be triggered as a new alert as opposed to just a RoarBot comment on the original alert.

Silencing an Individual Alert

If you need to silent an individual alert for a system, please review our Silence Actionable Alert Rules and Alerts documentation.