Fluency takes an agnostic view of audit data. It is not designed to favor one analysis technique over another. The concept is to focus on capturing log data no matter where it is, or if it is seen as relevant at the time. Most data collected is support data, data that provides the ability to reconstruct what happened.
With all types of data and from so many sources, there needs to be an agnostic way to get through all this data. This section addresses that issue.
Efficient log analysis is not about hunting, but more about organizing. Fluency has four major starting points in reviewing data: Confident Events, Correlated Vectors, and Compliance Events. The fourth means is Tracking Gaps, which is covered at the end of this process.
There are alerts from devices that are almost always correct, and at the very least should always be reviewed. These are high confidence events. We want these events to be seen in the dashboard and generate a ticket (or email) when they occur.
There are two ways to implement this in the system; both ways can be active at once:
High Confidence Vector Tag: Appears on the Notification Page
Assigning an Issue Tag: Appears on the Tracking Page
Use the Risk Mapping interface to relate what signatures are related to High Confidence. https://terplab.cloud.fluencysecurity.com/config/risk/view
The description of the risk map explains why the map is being made. The Risk is a drop down, and High Confidence Alert is an Option. Select that option, then the field that needs to be mapped. Often this is the
sid field. Finally, select the value of the match.
Once added, the fusion engine will map the new risk category to the alert.
Issue Tags can be added in a number of manners.
Fluency RiskScore is a scoring process that prioritizes events based on the supporting facts and statistics. It mimics the human process of looking for supporting information to determine which events are most likely to be correct in detecting unwanted activity.
Fluency RiskScore highlights our approach to information management. Information management is about leveraging the information derived from devices. Fluency focuses on what a SIEM is supposed to be, an information and event manager. RiskScore performs set theory on each event as it enters the system. It groups these sets in a hierarchy of a communication source, and subsets of destination couplings.
Scoring in a coupling gives stronger weight to unique information and information related to the malicious activity. This means RiskScore gives priority to groups of events – not a single event. It then groups with the malicious activity that shows supporting anomalies are prioritized.
The result is that alerts that demonstrate supporting issues are prioritized to the top for further validation and automated response. The RiskScore system is a must, as the amount of information being collected is staggering. Due to how Internet communications work, even small customers generate millions of events.
RiskScore events that hit a significant threshold appear on the Notification page. To see these events select Network Behavior in the Notification facet and then search.
A quick overview appears on timeline. Clicking the RiskScore Record button on event will bring you to that particular event on the RiskScore page. If there are a number of the RiskScore events that you want to review, click the "Pin this Page" on the top right hand to hold the page in place. When you are done reviewing a RiskScore, close the windows open for that analysis util you see the pinned page again.
Once you click a the RiskScore button, that RiskScore card should appear on the RiskScore page. Once again pin this page.
From here, analysis truly begins. Review the top scored sessions by opening them (click the Chevron). If you see a more chevron, click those too to see all the related data. You might quickly see the event as a false positive. If the issue is a bad signature, the analyst can click the signature to ignore future alerts.
Lastly, some events always need to be reviewed based on compliance. There is a dedicated Tag page, but this is used more for the management and not creation of Tags.
The most common means for issue/incidents tags are:
The summary page has a button to add a tag. This is good when the tag is not part of a scoping event. When scoping, the tag should be the name of the forum discussion.
Add the tag by clicking on the screen the IP address, file or hash you want to add the tag to, and then select
Tag as an Issue.
Once the dropdown is active the
Add Tag is on autofill, meaning that if you plan to give it an existing tag then the autofill will help. The description is available and useful to keep notes of why this system.
The term validation is the confirmation on an initial alert, while verification is the initial match itself. At this point we have verified that the trigger was correct and the system properly matched what we are looking for. Now the Validation step is to see if the verified alert meets the intent of what we are looking for.
This is the process of labeling all the players and attributes involved with an issue. The result is what people call Indications of Compromise (IoCs).
These are two different actions:
Response: Prevent the issue from occurring
Recovery: Get assets and network capability back to full operations
Response is an immediate time frame, while recovery takes time. Recovery includes possibly adding new devices, updating/creating processes or updating/creating policies.
This is watching future activity of an event by watching its IoCs.