Once we have polished a query, the next logical step is to make something with the output. For example, continue the analysis now that we know more, visually represent the data with activeboards, or define alerts so we get notified every time the behavior we identified in the query happens.
Let’s check this last use case.
Part 1: Creating the alert
-
Use the finder to open the proxy.bluecoat.proxysg.main table.
-
Set the time range to display results the last 24 hours.
Lets begin by isolating those connection requests that were denied by the proxy server. Then we’re going to group the connections by the user and the category that describes the target of the connection.
-
Apply a filter so that we see only those events where the action is “TCP_DENIED”.
-
For this example, we are not enriching the data, so we go from filtering to grouping.
-
Perform a time-based (say, 5m) grouping by the username and categories fields.
-
Add an aggregation that totals the number of connections denied for each user and category combination.
We want to trigger an alert every time a user attempts to connect to a web that is off-limits.
-
Apply a filter on the count column that includes only counts of 2 or more.
Now we can create the kind of alert that triggers when there’s a new entry that meets the query conditions. That is to say, every time a connection to a forbidden site is logged.
-
Use the New Alert Definition tool to create the new alert.
-
Give your alert a meaningful name. Use “DeniedNav_yourinitials”.
-
Set the subcategory of the alert to “Proxy”.
-
Alert’s summary and description are meant for two different things: enter the gist of the idea in the summary field and use the description field for the detailed purpose and use case of the alert.
The description field can be enhanced by using references to values from the data feed. If an alert triggers and its query used, for example, the “username” field, I can reference the value it had when the alert triggered and load it into the description.
For this example, you may use the following:
The user $username was denied a connection within the $categories category $count times in this period of time. - Set the prority to Low if it is not already.
- You are done!
This query reproduces the previous steps:
from proxy.bluecoat.proxysg.main
where action = "TCP_DENIED"
group every 5m by username, categories
every 5m
select count() as count
where count>=2
Part 2: Deliver the alert via email
For this Arcadia use case we want to deliver this alert to the IT security manager via email. How do we set this alert to be sent via email? We need three things for this:
- What would be sent? The results of a query as defined by the alert we created
- How would it be sent? As per a delivery method tied to an email.
- When will it be sent? As per a sending policy defined by us.
We already did the what. Let’s go with the how:
- Go to Administration > Alerts Configuration. Open the Delivery Methods tab.
- Select Email, and create a new delivery method using your own email address.
IMPORTANT NOTE: Do NOT select the option "Attach the events that triggered the alerts to the email" for this example.
- You might need to confirm the email with a message sent to that address, so use a valid account.
If you did everything right, you should have received a message like this:
Good! Now with the when:
- Move to the Alert policies tab.
- Click on the New sending policy button.
- Name the sending policy MyInitialsYear.
- It should be active from Monday to Friday, from 00:00-23:59h. No emails on the weekend, please.
- Select your email delivery method and any anti-flooding policy you like.
- Click on the Create button.
Great! We have the what, the how, and the when. We only have to link them together.
- Go to the Available alerts tab.
-
Use the “Proxy” subcategory to quickly locate your alert.
- Click on the plane icon on the row for your alert. Select the sending policy you just created.
You are done! Depending on the grouping period you set, you will receive the notification in your inbox sooner or later.
😐 Not receving anything?
The data we are using for this exercise is simulated and scripted. If you check the histogram, the condition for the alert is true every 2 hours or so:
If you don’t want to wait, you might create a new alert definition discarding the rule of the count being higher or equal than 2.
Once you are finished, go to Alert management and turn your alert off.
