Case Alerts

Overview

While sources can send alerts to Fluency, Fluency can create its own alerts based on correlation. This document covers how Fluency determines the data to analyze, how to apply analysis rules, what the purpose of case manager is, and how to create reports and dashboards.

Obviously from the features listed, this is not a simple switch to turn on. There are steps for collecting and alerting.

  1. Determine “what” an alert is.

  2. Select the records that contain the relevant data.

  3. Relate the attributes to an alert signal.

  4. (optional) Apply Behavior Rules to an alert to determine when the alert is relevant.

  5. Send a final alert to the Case Manager.

  6. Apply actions to be related to a new (unique) alert.

Step 1: Determine the Alert

The most important aspect to data analysis is to understand why you are performing it. For instance, we might care to determine when a user logs in from a location that they have not appeared from before.

Knowing the question we are trying to answer allows us to compose the process to respond. It also allows us to clarify what we are truly asking. In this case we really want to know where users are when they are provided access to the system. The data might not show login, but still provide us detail of a user that is authenticated. This occurs in audit logs where the user is signed into multiple days by a device.

We will need to define what data is to be involved in alerting. In this case, we need to create buckets that contain the location of users. We can review the type of logs that come into the system that provide a source location or source IP address and a user’s identity. This will be used for step two.

Next, we need to determine if this is a trivial case. A trivial case is when each time the event is seen, an alert is created. In this case, we are looking at the first-time something occurs. When we get into Step Four, we will ask more questions about the details.

If we know it is trivial, we will send an alert to the case manager. In this case, its not, so we send a signal to the Behavior Rules. These are more like models than rules. They each have an algorithm and logic relate to a particular behavioral question.

Case management will when help us group the alerts into levels. Here is how we control the flow of alerts to the actions and users. Case Management addresses alert fatigue while continuing to be accurate.

Lastly, we need to start creating a list of actions that we can do. This provides automation that can investigate and possibly address the issue.

Step 2: Creating an Event Bucket

Once we have an outline of what we are trying to accomplish, we can begin the process of automating the workflow.

What is a bucket?

An event bucket is a way to filter events using search filters or a query. This allows an analyst to view and perform actions on common events of interest.

With event buckets, the analyst is able to narrow down events to view only the ones pertaining to the question they are trying to answer. Using the example in step 1, we might want to know when a user logs in from a location they have not logged in from before. To do this, we want to create an event bucket that gives us user login data. From there, we can use aggregations or signals to isolate data on new locations for users.

There are three purposes for creating an event bucket:

  • Displaying data on the dashboard

  • Creating an alert signal

  • Tagging data in order to enhance searching

The easiest way to begin bucket creation is through the Events page. When an event is expanded into Parsed Table format, hovering over a row displays four buttons. The rightmost button is the histogram button. Clicking it will redirect you to an event bucket creation page that is populated with a count aggregation using the highlighted row's field as its group by field.

This is an example of an event bucket with attached signals. The signal O365_User_Country will trigger if the UserId has an associated country based on geo-IP address.

Step 3: Creating an Alert Signal

What are alert signals?

An alert signal is a way for analysts to create an alarm when certain criteria are met. These signals can be sent to the Case Manager for management and display in order to detect important events.

For example, say you want to create an alert whenever an operation is performed from a new country based on the user's geo-IP address. This requires a first occurrence rule.

This rule is triggered by the O365_User_Country signal defined in the last step. In this case, if the user has not logged in from this country in the last 3 days, this rule will emit a new signal called O365_USER_NEW_COUNTRY. The Case box is checked, so this signal will be sent to the Case Manager.

The fields @fields.UserId and @fields._ip.country are specified under Fields. This means that when the case is sent to the Alarms page, the values of these fields will be displayed as part of the summary.

There are also last occurrence rules. These can be used to create an alert based on the last instance of a specific event.

This rule is triggered by the lack of the OFFICE_USER_LOGIN_OK signal. If it has been 2 days since a user last logged in, this rule emits the LAST_LOGIN_OK_USER_CITY signal to the Case Manager.

There are also aggregation cases. Two of the common aggregation cases are summation and unique count.

The WEB_UPLOAD signal is defined to sum the txB field. When attached to this rule, the signal will sum all of the uploaded bytes over a 1 hour period. If this sum exceeds 6MB, the NETWORK_BIG_UPLOAD signal will be sent to the Case Manager.

The UNIQUE_FILE_OPEN signal is defined to detect unique values for the Source File Name field using the cardinality type. This signal is grouped by user, and if a user exceeds 5 files opened in the span of 1 hour, the OFFICE_FILE_COUNT_EXCEPTION signal will be sent to the Case Manager.

Step 4 (Optional): Applying Behaviors

Action Rules use lambda scripts to perform actions on signals.

For example, the PageDuty action rule sends a notification for CRITICAL signals to the SOC personnel on pager duty. This rule uses the notification lambda in order to do this.

Step 5: Case Manager

Alert signals can be sent directly to the Case Manager, or grouped together to form new signals using a Signal Set rule.

For example, this signal set rule looks for instances of four different signals over the period of 1 day: NEW_OFFICE_USER_WORKLOAD, OFFICE_USER_LOGIN_FAILED, NETWORK_BIG_UPLOAD, and LOGIN_MIX. If present, this rule sends a CRITICAL signal to the case manager, indicating to an analyst that there is a trend of events that could indicate a serious threat.

Start by giving the rule a name and description. In this case, the name is loginMix and the description is "see both OK and FAILED action in 10 minute." The 10 minute references the next two fields: window size and window unit. These two fields allow you to adjust the window of time that this rule searches within. The default is 10 minutes.

Next, select which signals should be included for this rule. Signals are attached to Event Buckets and can be defined during Event Bucket creation, or by clicking the "+ ADD" button in the Bucket Signals section of the Correlation page, which redirects the user to the Event Bucket creation page.

In this case, we select OFFICE_USER_LOGIN_FAILED and OFFICE_USER_LOGIN_OK in order to make sure the alert information includes data on both successful and failed logins. Signals can also be excluded from the rule.

Next, define the key field for the signal. This field will be displayed on the correlation page so it should be the most useful field in relation to the signal for analysis purposes. In this case, we are using @fields.UserId. This will allow us to see the user associated with the login.

Next, define the Emit Signal. This is the signal name that will show up on the Alarms page if the case button is checked. We want this signal to create a case when triggered, so check the case box to send it to the Case Manager.

NOTE: There is a 24 hour learning window before alarms trigger.

The alarms page displays a tree-style format of all defined signals. The Case Manager manages this data in order to prevent information overload and alert fatigue.

This tree sorts the correlation hits based on signal. Exclamation points indicate that the hit is new, while a checkmark indicates that the hit has been acknowledged, or “acked.”

Clicking on an arrow expands that signal and allows the user to view hits by date. Clicking the arrow to expand a specific date allows the user to view hits based on the key specified during bucket signal creation.

Clicking on a single hit displays a detailed view on the right side of the screen. This view displays the state, event count, create time, last update, and attributes of the hit, along with any comments that have been made. Clicking the "UPDATE" button allows the user to mark the alert as “new” or “acked” and make comments. Clicking the “SEARCH” button will redirect the user to the events page and perform a search based on the signal name and key field associated with the alert.

Step 6: Actions

Workflows use lambda scripts to perform actions on cases.