A Practitioner's Guide: Detections within Security Operations

A brief history

Most folks might be familiar with the standard detection methods of the past, as they actually haven't changed a whole lot apart from a few exceptions. The two worth mentioning: static correlation rule and IOC match.

Static correlation rule

Think of your classic signature-based detections within your security information and event management (SIEM) solution. You can also think of these rules as "if – then this" detections. Traditional SIEMs would offer hundreds and hundreds of these out of the box. The hard part was mapping the data models correctly and keeping your alerts tuned. The logic within these can be complex or simple, but for simplicity's sake let's use the following example:

index=windows sourcetype="WinEventLog:Security" OR sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational"
EventCode=4688 OR EventCode=1
(Image="*\\powershell.exe" OR ParentImage="*\\powershell.exe")
(CommandLine="* -enc *" OR CommandLine="* -encodedcommand *")
| table _time ComputerName User Image CommandLine ParentImage ParentCommandLine

The above rule is simply looking for all Windows security event logs and Sysmon data, with powersehll.exe as the process name or parent process name with a command line option of "-enc" or "-encodedcommand".  (Attackers often use Base64 encoding to obfuscate their malicious PowerShell commands.) This rule is simple enough when looking at 10,000+ endpoints in your environment; within that lies the problem. Many legitimate tools encode PowerShell as well to alleviate any formatting mishaps. It is then up to the analyst to decipher and determine the maliciousness of the PowerShell attempt.

Indicator of compromise (IOC) match rule

Using a threat intelligence feed, or some type of static list, match on indicator of compromise (IOC). IOCs can typically be bucketed into three categories: IP addresses, domains and hashes. If an IOC within the feed is witnessed within a log — say a firewall log of all inbound communications — throw an alert. These alerts are still used today with some success, but success depends on your threat intel feed. IP address reputation changes with the wind, so the feed must be updated as close to real time as possible to maximize benefit.

Honorable mention: Intrusion Detection System (IDS) 

IDS alerting is commonly seen within Snort or Suricata and now is being seen as the backbone for network detection and response (NDR) systems. IDS is very similar, at least at a logical level, to the correlation rule, but they differ in implementation. While SIEMs would use the correlation rule to match alerts based on previously ingested logging, IDS technology matches signatures at near real time at the IDS sensor. IDS alerts are still very much signature based. As such, we can expect many of the detections here to be noisy, and the technical prowess needed for tuning is high (especially when breaking out packets in hexadecimal).

While classic correlation searches won't disappear anytime soon, it's no longer enough to just flag something like "Encoded PowerShell Detected" with no additional details. Going forward, security teams will still need to fine-tune and customize detections, tailoring them to their environment and continuously improving the context given to incident responders.

Modern detections

I do not love the term "modern," but it's simply the easiest way to delineate between the classic signature-based detections of yonder years to more current detections. Modern detections are just a way of explaining some of the black magic in many OEM platforms (think endpoint detection and response (EDR), incident detection and response (IDR), and NDR here). We know that this black magic is simply AI/ML crunching datasets and using linear algebra to find anomalies. The biggest negative with the push toward EDR platforms (as well as IDR, NDR, and extended detection and response (XDR)) is that the major OEMs in this space treat their detection methodology as intellectual property, and therefore mask and obfuscate many of the finer details. I would argue those finer details are paramount to incident responders assessing and tuning these alerts, but I digress. The following are examples of modern detections seen within enterprise environments: 

• Chaining detection: Commonly used in EDR alerting. A single event without context may not be malicious, however chaining various events together, or chained events in certain sequences, could be.
• Behavioral analytic detection: Seen commonly within the identity and user and entity behavior analytics (UEBA) spaces. Profiles are built around a certain entity. These profiles contain a baseline of behaviors. Whenever an entity performs a behavior OUTSIDE its established baseline, an anomaly is detected.

Detection philosophy: A question (and half answer)

An interesting thought experiment pertaining to any detection platform: Where does one simply use the native detections of a tool (such as EDR, IDR, and non-security tool alerting such as multi-factor authentication (MFA) security alerts) and when do we let the analytics engine crunch data and create detections for us?

Let's discuss some key points about real-time alerting that are baked into so many different technologies nowadays.

Primer: We can think of EDR, for example, as its own mini "analytics engine." This is the same for Okta security detections in their MFA suite, or any other tool providing security alerts. These detections are built into the specific tool and can be ingested in a magnitude of ways (you can also ingest the underlying telemetry data): 

1. All vendors do not create security detections the same. It is up to you and your team to decide which are worth their salt.
2. Vendor specific security alerts will almost certainly lack context around their detections. This makes sense, as they are only creating alerts using the data available within their tool.
3. EDR, IDR and NDR, in my experience, are all great high-fidelity alerts. Is tuning required? Absolutely. If you operate in the security operations space, assume you need to be tuning detections. However, you may still lack context even in the highest fidelity alerting. This is where platform plays are gaining so much traction. Being able to stitch datasets together and providing meaningful enrichments to responders is a huge win. (CrowdStrike EDR + IDR + cloud is a great example here).

The rule of thumb here is simple: Take inventory of your current alerting capabilities. Bucket these capabilities into the below categories: 

We should strive for every single alert to be high fidelity and high value. High fidelity and low value alerts should be pushed for automation. Low fidelity and high value alerts are ripe for tuning. Low fidelity and low value alerts can be generally removed, or automated after tuning is performed. 

Once this exercise is complete for all alerting and a detection gap analysis is performed, decisions can be made whether to use native tools for detection or to use a detection engine for detecting specific threats (using the underlying logs and telemetry data). Regardless, it's important to remember we as responders want high fidelity, high severity alerts in our faces as quickly as possible. This is where it is paramount to understand your current detection capabilities and alerting pipelines.

Analytics engine: Notable OEMs

• CrowdStrike, Palo Alto and SentinelOne are all mentioned within an excellent data pipeline and storage blog found here.  It is important to remember that each OEM will have strong detection capabilities for their native tools, but some custom correlation rules will be needed for third-party data sets.
• Anvilogic sits on top Splunk Cloud, Snowflake and Azure Sentinel and maps the data within those platforms to your MITRE ATT&CK priorities for detection capabilities. Additionally, AI is levered to detect anomalies from your environment's established baselines. According to the vendor, the solution "breaks the SIEM lock-in that drives detection gaps and high costs for enterprise SOCs. It enables detection engineers and threat hunters to keep using their existing SIEM while seamlessly adopting a scalable and cost-effective data lake for high-volume data sources and advanced analytics use cases." 
• Hunters SOC Platform, like Anvilogic, maps out of the box detections rules to the ATT&CK framework, and AI-assisted triage is provided.
• Traditional SIEM technologies have been the backbone of security operations for over a decade and include giants such as Splunk, Sentinel, QRadar and Elastic.
• Honorable Mentions: Panther and Abstract.

Analytics engine: Key considerations within your SOC

I cannot stress enough the importance of understanding where your detections come from, how they are formulated, and how long it takes from the time of the event(s) to show up in a console somewhere. The more we understand these processes, the better we understand possible alerting gaps, and the better we can understand the influence any detection delay may have on MTTD/MTTR metrics. It also enhances our ability to quickly tune alerts when needed. Here are a few questions and considerations to consider when planning and implementing your analytics engine and alerting pipeline: 

• How much real-time alerting is needed?
• Are you already heavily invested within a specific OEM such as CrowdStrike or Palo Alto? 
• Custom ML applications will be severely limited within the OEM landscape; where the OEMs shine will be their native data set.
• You need to understand the underlying data model to correctly map correlations across disparate data sources.
• Have you performed a gap analysis around your current detection library?
• Do you understand the underlying datasets that your detections are built upon?

Final thoughts

At some point, all organizations need to change to keep up with today's evolving threat landscape. Detection mechanisms are evolving, and more data is getting pumped to our analytics engine. If you have questions, our experts at WWT are here to help. Whether you need support with transforming your SOC or expanding your detection coverage, we have the experience to guide you every step of the way.