With Perch you can setup event notifications for any event type logged to Perch from your IDS or from your logs. The new event notifications feature will allow you to create custom notifications based on specific criteria that you setup that will email you or create an alert for our SOC to triage.
To see your currently configured event notification rules:
From this list of notification you can take actions on your existing notifications like:
You can create a new event notification by clicking the purple plus sign at the top right of the event notifications card.
There are four configuration sections required before you can save your event notification.
If your account has access to manage more than one organization, the organization picker dropdown in the top navigation will control which organization the notification is run as and which organization can edit, delete, or disable the notification. The query that is defined later will have access to all data that this organization has access to.
You can create an event notification under your account, but limit the query results to a specific organization you manage. This means that the organization it is limited to will not be able to see, edit, delete, or disable the notification.
You will need to give the notification a name and a description. Event notification names must be unique. It is recommended that the notification description be helpful to anyone receiving the notification and which describes the scenario you are creating the notification for. Additionally, you can select a severity for this notification. The default is “info” for an information notification.
When an event notification is triggered you can control the actions it kicks off. Currently, the available actions include sending an email or creating an alert. Alerts will be triaged by the Perch SOC and escalated to you if there is a threat. Because it is possible to create an event notification on normal operational activity, it is not recommended to create an alert unless you believe this activity represents a threat to your organization.
Keep on the look out for more triggered actions in future releases, like creating a ConnectWise Manage ticket.
Event notifications are run on a regular schedule. It’s possible to schedule every few minutes, hour, or days. Choose a schedule that best fits the scenario you’re monitoring for. WARNING: It’s possible to spam yourself if you choose a frequent interval with a loose query. Don’t make an event notification that you train yourself to ignore.
Conditions and Filters is the most complex part of creating an event notification. This is where you define a query to find data in Perchybana relevant to the notification you are trying to create.
Select an index type for the type of data your event notification is focused on. For example, If you wanted to create an event notification based on Office 365 events you should select the “office365” index type.
For the timestamp field, @timestamp the most common choice. However, some events contain other timestamps you might want to choose based on your scenario.
Keyword and query filters are identical to searching within Perchybana Discover. All fields in the event from Discover are accessible. You can free hand your search query and/or filter based on fields and values. This is where you will narrow your event notification query to focus on specific activity.
TIP: Although you can test your query from the event notification page, it is recommended to have Perchybana Discover open in another tab so you can see what fields are available and make sure that your query and filters are returning the results you expected.
In some cases you may want to trigger based on aggregation. This feature allows you to access the metrics and split by terms common in data table visualizations. Perhaps you want to aggregate based on the count of user IDs so you get notified when one or more users failed login count goes above a certain threshold. Or, maybe you want a notification when the unique count of DHCP source IPs goes above a certain threshold. Triggering based on aggregation makes these scenarios possible.
Last but not least, you will need to pick a trigger condition. When you start thinking about creating an event notification for a scenario, this is when you should start your consideration. Trigger conditions are very powerful and allow for a wide variety of scenarios to be covered by event notifications.
The most basic trigger condition is Threshold. Did events from my query happen Y times in the last Z amount of time. It’s recommended that the look back window, the time window, to match the frequency at which the event notification is scheduled to run.
Flatline trigger condition is a simple but powerful trigger. Rather than looking for the presence of an event it looks for the absence of certain records. Perhaps there is a specific server that you expect to regularly see logs for. Or, a network that you expect to see netflow from. Absence of these records could indicate a change in your environment that has impacted Perch’s visibility. These are just a few example scenarios that you might use Flatline to draw your attention to.
Spike trigger condition puts Perch event notifications ahead of the pack. With this condition you can get notified based on trends in events. For example, you could compare the number of failed logins from last week to the preceding two weeks to get notified when the activity spikes by a specified percentage.
One of our personal favorite trigger conditions is New Value. This does a diff of results from a recent period and compares it to a historical period to see if new values are observed. One example of a cool way to use the New Value condition is to look for new mac addresses in DHCP records in your environment.
Finally, there is Repeated Value trigger condition. Which is configured similar to New Value, but creates a notification when a value is repeated between the two time periods.
Now that you’ve configured everything you can save the event notification. Congrats!