Detect in Seconds is Part 2 in our series of blog posts on going from Zero to SIEM in Seconds. In Part 1 of the blog series we covered Operationalize in Seconds, where to truly add value to a security operations team, the SIEM must work in complex hybrid-cloud and geographically dispersed locations, automatically ingest and interpret any data source, scale predictably, and lower your management and storage costs.
In this second blog in the series, we will focus on what is required to accelerate detection of more than just indicators of compromise (IoCs), but accurately detect actual threats, and validate the full attack campaign.
At Gurucul we believe that the right platform can compress the time required by security teams across every part of the SOC lifecycle so they can get ahead of attacks. Once you are gathering all the data necessary and gaining complete visibility (per part 1), you can now monitor and detect threats with higher accuracy, more quickly.
Limitations in current SIEM and XDR architectures have led to challenges for Security Operations Teams in leveraging their SIEM for accurate detection. This includes threat models based on a single data source, behavioral analytics that just cause more alerts, and identifying puzzle pieces and asking analyst to put together the right puzzle.
Single-Stream Threat Models
A single-stream detection model means each set of analytics and detection methods are supported by a single data source. For example, Network Traffic Analytics (NTA) will trigger a detection event based on the threat model that is specific to network packet information. User and Entity Behavior Analytics (UEBA) will trigger detections based on analytics supported by machine learning models where events are considered “abnormal” from baselines. The problem with single-stream events is they generate independent alerts. The alerts are correlated, basically matched together often by time or IP address, and presented to an analyst regardless of whether they are truly related. This requires huge manual efforts by the security team to investigate and validate whether they are related or not and – if related – whether the presented alerts are part of an attack campaign.
Immature Behavioral Analytics
Behavioral modeling, especially rule-based for the purposes of security have been around for well over 20 years. The most familiar form has been network behavior anomaly detection (NBAD) that has leveraged primarily NetFlow data from network devices as well as some level of packet capture. Circa 2010, Gurucul was one of the first solution providers to build a set of analytics and behavioral models based on user and entities, classified a few year years later as User and Entity Behavior Analytics (UEBA). Both technologies typically start out by taking a baseline of current activity over enough time and using analytics to converge on what is normal behavior and activity. The actual models typically analyze when there are deviations from the established baseline and will trigger an event once any activity is considered “abnormal”.
Like NBAD, UEBA models require a lot of refinement and tweaking to make sure that out-of-the-box they are triggering alerts based on conditions being met within the model. It took years and for many even over a decade for cyber security engineers to trust the results of NBAD, of which the primary use cases were DDOS, Zombie, or other network-based attacks. This really required more than lab testing and years of real-world usage in a varying set of environments to get the models right. Gurucul UEBA has been “battletested” for over 12 years unlike UEBA products from many other vendors.
In addition, UEBA – from vendors other than Gurucul – tends to be offered as black-box analytics, where the actual models are hidden from users. This means no customization of the models to better meet the requirements of the organization. As a simple example, a behavioral model may trigger for a user that is remote and accessing their sales database from a different location other than headquarters. For an onsite-only company with limited salespeople beyond local operations, this certainly may be worth investigating. However, in a global organization that recently hired a new salesperson assigned a territory, this may seem perfectly acceptable. While that is an oversimplified example, it can certainly cause a security team a lot of problems if they are flooded with these types of alerts beyond their current situation of being mired in traditional log-based events.
A mature set of transparent and customizable UEBA models is more beneficial to security teams. This leads us to the next section, where single-stream UEBA and other analytics, along with rule-based machine learning (ML)/artificial intelligence (AI), can cause additional problems for security teams.
Wasted Time on Puzzle Building
UEBA by itself is a critical early warning that can help determine if an attack is under way. It introduces what is considered risky or abnormal behavior as an indicator of an attack campaign under way that may have been missed by the flood of log-based events or network activity. Even more important, it is an indicator of an attack that is leveraging stolen credentials to mimic acceptable usage and privileges by a user in the organization. However, as an early warning by itself with little context and with the actual models and conditions for alerting being hidden, the result is the security team will be chasing down anything unusual and will have to manually piece together whether it could be part of a set of malicious activity. The problem is that not all risky or abnormal behavior is malicious, even if all malicious behavior starts with risky or abnormal behavior.
Rule-based ML/AI, unlike trained ML/AI, is most used in traditional SIEMs. Unfortunately, this type of ML is not designed to learn what is acceptable usage or unacceptable or abnormal over time. Rule-based ML can only take a static set of inputs, run them through some conditional statements, like a flow-chart, and come up with a fixed set of outputs where a threshold is crossed in order to trigger an alert. Trained ML will continuously adapt the baseline and more importantly move the threshold accordingly based on what it learns from all the data and activity it sees.
Putting It All Together to Reduce Mean-time-to-Detect (MTTD)
Offering a set of unified analytics that can be chained together, often referred to as model chaining, with the ability to analyze the chain, often called link chain analysis, is critical to eliminate ambiguity in determining a threat through the cross-validation of the alerts. When you take UEBA, for example, using the early warning of seeing some risky behavior, then combining that with unusual lateral movement and potential command and control (C2) communications, plus geo-location, model chaining consolidates and unifies the analytics and context together to establish a true threat versus just a potential threat. This effort, as mentioned earlier, can take days or weeks for security teams to gather all the context necessary to manually validate the various events as part of an attack campaign. For security teams to truly respond and prevent a breach, it isn’t just about finding the right puzzle piece, i.e., a threat, it is about piecing those pieces together as quickly as possible to establish that a targeted attack is taking place.
In order to credibly achieve accurate detection in seconds, Gurucul Next Generation SIEM offers a solution that provides included (for free) threat content, model-chaining to detect and cross-validate advanced threats, transparent models that gather all the necessary context, trained ML to adapt UEBA and other analytical models (endpoint, network, cloud, IoT) to your organization, and identity analytics, for rapid detection of extremely difficult identity-based attacks.
Learn More About Gurucul Next Generation SIEM
To learn more about how Gurucul Next Gen SIEM can help you detect known and unknown threats in seconds: