3 Key Capabilities of a SOC Detection Program

3 Key Capabilities of a SOC Detection Program

Data Hygiene
Future SIEM

In today’s SOC, analysts spend most of their time struggling to keep up with Incident Response.  It’s a sad but unfortunate truth.

The typical Security Operations Center (SOC) aggregates alerts from the variety of security solutions deployed in their enterprise, including alerts for both malicious and suspicious activity. SOC’s also collect raw logs from specific domains (networks, servers and devices, and users) in an attempt to address existing detection gaps by developing specific attack detections. The data needed to protect the attack surface is overwhelming.

Modern SOCs are doing something different…

They are enabling analysts to spend less time responding to a deluge of alerts and more time threat hunting, by building out an automation program to continuously measure and improve the detection and threat hunting function.

Avilogic Automated Detection Engineering Platform SOC Maturity Scoring
Anvilogic Automated Detection Engineering Platform SOC Maturity Scoring

Breach Detection and Threat Hunting - Top Priorities

Prioritize the Enterprise Threat Landscape

Understanding of the enterprise’s current threat landscape to prioritize which specific threats are critical for breach detection. This goes towards building out “hypotheses” that drive the hunting and detection activities.

Alert and Log Feed Analysis

Understanding of security solution alerts and log data that are aggregated at the SIEM(s). This data is what the detection and threat hunting rules will run against. Knowing the data well is critical to understanding what threats can be detected against that data, and what additional alerts and log feeds need to be collected for those prioritized threats.

Detection Logic Development

Expertise in detection logic development and tuning for detecting specific threats using the SIEM. These include SPL (Splunk), KQL (Sentinel), SQL (data lakes) for developing the searches, and detection rules for hunting down threats.

How can each of these be used in an effective breach detection and threat hunting program at the SOC?  What are the frameworks and automation that support them?

Prioritize the Enterprise Threat Landscape

How do analysts identify which specific threat behaviors or procedures (the “P” in “TTP”) to prioritize for detections?

Notice that “threat procedures” is used and not “IoC Indicators.” It is quite straightforward to go look for IoC’s such as file hashes, URL’s, IP’s that characterize known threats. Analysts are aware that IoC’s are short-lived as adversaries can easily change those; however, threat behaviors i.e., the “procedure” in “TTP” are long-lived as adversaries have long-lived preferences for procedures; for example: encoded PowerShell, WMI for lateral movement as in Cobalt Strike, persistence via scheduled tasks and/or registry entries, credential scraping, lateral movement via RDP and/or pass-the-hash. Adversaries tend to chain together these procedures over and over again in different attacks. We have detailed examples of these activities here.

Mapping to the ATT&CK Framework

Avilogic Automated Detection Engineering Platform ATT&CK Framework
Avilogic Automated Detection Engineering Platform ATT&CK Framework

Experienced detection analysts are aware of what attacks are ongoing against the enterprise and what specific threat behaviors they should be looking out for. In some cases, there may be a threat research/intel team prioritizing threats; in others inspecting the incoming alerts can offer a useful point of view. The Mitre ATT&CK framework is an excellent tool to track and prioritize these threat behaviors and measure progress over time. Specific procedures can be mapped to the techniques that they are used to implement.

From Alert-Orientation to Attack-Orientation

Being able to view the alerts laid out in the ATT&CK matrix or the kill chain phases is very useful to identify unfolding attacks across their various stages and tactics when grouped by the targeted entity such as machines, users, applications, and so on. They may observe many phishing detections at the gateway solution targeted for high-value users, a rash of suspicious PowerShell detections at the endpoints reported by their EDR solution, and many failed and/or suspicious logins at their O365 accounts indicative of brute force activity or account takeover scenarios. Viewing your alerts overlaid on the Mitre ATT&CK framework and/or the Kill Chain Phase is often used as a starting point for hunting ongoing attacks.

Critical Systems Monitoring

Detection analysts overlay enterprise security context on top of this attack view. For example, they may be aware of vulnerabilities of workloads that may be running in public IaaS clouds; they may be aware that the workload protection may be less mature compared to the endpoint protection program; identifying critical assets and identities for targeted detection activities is another example of overlaying enterprise context.

Alerts and Log Feed Analysis

Experienced detection analysts are very familiar with their alerts and log feeds. They know which feeds contain what data sets, and what level of logging is available from which assets– is PowerShell logging available at the AD servers, is process command line logging available at their database servers and so. Often enterprises may be collecting alerts from many security solutions and raw log sources in their SIEM’s.

Detection analysts maintain an accurate map of what fields are available, their field names, which event codes are logged, and from which asset classes. They map which alerts and logs are critical for which classes of detections. They also map techniques and procedures to your alert and log feeds. The Mitre ATT&CK framework does track data sources, and maps which techniques require which data sources for their detection.

For example, the technique Credentials from Password Stores requires access to the following data sources: API Monitoring, File Monitoring, PowerShell Logs, Process Monitoring, System Calls. Mapping your feeds to these data sources is a convenient way of identifying which techniques (and the underlying procedures) depends on which data feeds. You can learn more here about Improving data hygiene in the SOC.

Detection Logic Development

Once the threat behaviors are prioritized for detection and the relevant alerts and data feeds that they can be used to search for those TTP’s are known, the detection analyst develops the search in his SIEM programming language which could be, for example, SPL(Splunk), KQL(Sentinel), SQL (Cloud data lakes – RedShift, BigQuery, Snowflake).

Critical functions include:

  • Classifying the suspicious and malicious detections into attack stage (e.g. Kill chain phase) and attack intent (.g. MItre ATT&CK Tactic/Technique) helps correlate the alerts into multi-stage attack pattern detections.
  • Analysts develop detection code to look for specific suspicious detections (low fidelity) and also develop correlation rules that can stitch together distinct alerts and suspicious events into related attacks (high fidelity) for further analysis. Read details of using a no-code environment for detection logic development here.
  • Tuning considerations require developing safelists to reduce the noise while not missing suspicious behaviors. Often past usage of safelists in relevant detections can offer guidance on which safelists to use for new detections.

Applying Automation Towards Detection

Mastering all three domains can be very challenging for the detection and hunt analyst. Automation can help in the following ways for each of those three areas:

  • Continuously assess the global threat landscape and your local threat landscape and help prioritize which threat behaviors to hunt for.
  • Automatically assess the log sources and identify which are the relevant logs for which TTP’s and offer a quality assessment of those feeds to indicate the likelihood for developing successful detections.
  • Recommend detection rules out of a repository that can be rapidly adapted to the enterprise’s alerts and log feeds for their environment and recommend tuning activities.
 Avilogic Automated Detection Engineering Platform Weekly Detection Summary
Avilogic Automated Detection Engineering Platform Weekly Detection Summary

Anvilogic is the only no-code automated detection engineering platform that helps SOC teams assess their environment and quickly build/deploy attack-pattern detection code resulting in highly accurate & enriched alerts for automated triage & response.

Schedule a demo to see how you can be more secure by applying automation to the detection and threat hunting tasks in your SOC

Chat with our team to receive a free maturity assessment

Get in Touch

Ready to learn more about Anvilogic?

Kickstart your security operations

Anvilogic provided the necessary threat detection automation for our small SOC, adding a significant force-multiplier advantage for my team.