Getting Back to the Basics

As the amount of cyber security technology vendors in the market continues to grow, we have seen an enormous amount of valuable tech emerging to aide in detecting security threats.  These technologies continue to produce more and more data that needs to be logged, normalized, and retained in order to make it useful.  Even as organizations begin to think about how to start leveraging machine learning concepts or SOAR platforms for automation, they struggle to capitalize on their return on investment with all of these technologies because, in most cases, they have not created and defined a logging strategy that makes it easy to use the data that is produced from the technology they purchase.

Data becomes a lot more useful when it is structured, tagged, normalized, parsed, and follows a consistent data model.   Being able to detect security threats isn't about buying every product on the market, sending all of those logs to a logging platform and thinking that these can just be easily used to detect a threat.   A very critical component to being able to build an effective threat detection program is ensuring that all of that data is useable.

Only once data is structured and normalized are you then able to use those data sets to begin building advanced detection content across multiple data domains.  Having the ability to be able to detect threat scenarios across multiple data domains, instead of just being able to detect multiple indicators of a threat within one data domain is a huge advantage.  This improves the quality of the detection, hence lowers the rate of false positives, and can get you to a high enough efficacy that allows you to be able to properly use SOAR systems to automate the mitigation of threat scenarios.  The only way for this to be possible is to have good practices when it comes to logging.

It is amazing to see how many companies continue to spend millions of dollars on security tools; however, aren't necessarily always improving their ability to detect or mitigate security threats.  This is because often times we forget about the basics needed for that data to become useful.  The only way you can properly use data from all the threat technology tools you have deployed is if you follow a consistent process for how that data gets stored.

Data normalization is not sexy, it's not fun, and it's not always easy, that is why often times those efforts get thrown under the bus.  But it is mandatory if you want to be serious about detecting actual threat scenarios, or even to begin using machine learning or automation concepts to help with detecting or mitigating threats.

Being able to detect cyber threats is not just about understanding the threat, the tactics, the techniques and the procedures.  It's not just all about purchasing a bunch of technology that can identify suspicious activity on your network.  It's all about ensuring that the data is useable.  Having a program that ensures you have the proper logging patterns and models is an extremely underinvested area, which can end up having major impacts to your ability to be effective in mitigating the risk of a cyber attack if not properly addressed.

Patterns of Collaboration in Enterprise SOC’s

Patterns of Collaboration in Enterprise SOC’s

Overview

As we continue building out our SOC Content Platform working with our enterprise design partners, we have had many conversations with analysts in SOC’s.  In this process, we have had many learnings on the key personas, their tasks and their challenges in addressing the mission of detecting and responding to cyber attacks within the enterprise. Most importantly, we have been impressed with how they collaborate together in addressing those challenges towards achieving the detection outcomes of threat relevance(are we looking for the right threats?) and high detection efficacy(are we meeting the high TP, low FP and low FN requirements?). 

Persona's

1.     Threat Analyst/Threat Operations/Adversary Research 

a.     Tasks. They research adversaries, their tactics, techniques and procedures, and track their evolution. They analyze research reports, and follow various threat intel sources, and stay on top of threat activity observed in the enterprise. In some orgs, Cyber Threat Intel (CTI) teams use Threat Intel platforms for this purpose. 

b.     Deliverable. They create use cases(“hypothesis”) for adversary detection for the threat detection content team. The use cases clearly specify the behaviors that the detection team must detect. Behaviors are more useful to look for than IOC’s which have a short shelf time. They may also specify as a detection target that are not just procedures but also an entire attack that is a sequence of threat procedures. 

2.     Detection Analytics/Threat Hunting 

a.     Tasks: They develop the detection content for detecting the behaviors specified by the Threat intel/adversary research team. They recreate the threat procedures as indicated in the use cases, collect the required events that log the threat behaviors including endpoint, network and cloud logs. 

b.     Deliverable. They craft the correlation search to detect the specific behavior. This is a complex process – the key is to maximize true positive detections (and reducing false positives) while minimizing false negatives. This is where statistical searches, correlations, and ML techniques are deployed for the detection. The detection analyst also offers guidance to the IR/Triage Analyst on what to do after an alert is generated from the detection. 

3.     IR/Triage Analyst

a.     Tasks: This persona consumes the detection content generated by the Detection engineering team, deploys the detection content, and reviews the alerts being generated. 

b.     Challenges. They usually notice many false positives in the early iterations of the detection logic. This may require changes in the detection logic, require additional baselines to safe list known good activity, and also require additional use of safelists and blocklists to refine the search. 

Collaboration Patterns

We observed the following patterns of collaborations between these personals to meet the mission outcomes of threat relevance and high efficacy.  Where collaboration is fluid and friction-less, continuous improvement is enabled where analysts spent more time in search development and refinement and less tine in chasing alert false positives. 

1.Use Case Refinement During Detection Development. During this process, the Detection Analyst works closely with Threat Analysts to refine the use cases and bring to attention the available log sources that can be used in crafting the detection. They inform the Threat Analyst team of the tradeoffs between detection scope, accuracy and the risk of false positives. The MITRE ATT&CK (https://attack.mitre.org/) framework is an important part of the collaborations workflow

2. Analyst Feedback for Efficacy Improvement. The IR/Triage Analyst can offer feedback to the Detection Analyst to improve the search. As the IR Analyst get new drafts of the detection content, she can compare the results with the previous searches, and offer feedback on accuracy improvements. This can be challenging as the people triaging alerts may not be the author of the detection logic. Developing high efficacy analytics remains an art,  and takes quite a few iterations working with the IR Analyst and Threat Analyst in getting this right. 

3. That Intel from Adversary Observables During Alert Review. The IR Analyst can inform the threat intel about true positive alerts observed, and what indications (e.g. behavioral, signatures)  they offer about adversary tradecraft. 

In future blogs, we will offer specific examples of collaboration that has led to better outcomes.  We hope you found this useful, and stay tuned for more. 

Enterprise SOC collaboration is a MUST!

Enterprises tend to work in silos. That's because security groups are guarded about their data and their methods, for good reason. However, in order to significantly improve our detection (and hence mitigation) game, we need to know more about attacks & breaches. Collaborating with peers in the industry will help understand trending attacks, obtain detection & mitigation plans that actually work, get access to best practices and exchange actual code to implement in their SIEMs (or other run-time environments). Such collaboration has to be secure, selective and result in exchange of implementable instructions, preferably code.

The best collaboration that has happened thus far in security operations has been the ISAC - however, participants will agree that it has degenerated to simply becoming a mailing list of noisy IOCs sent to 1000's of recipients with no clear instructions on how to detect & mitigate. This is not materially useful.

The level of enterprise SOC collaboration must evolve significantly to contain implementation-ready instructions and code, with enriching analytics to provide context and guidance, and must be easy to use with targeted sharing amongst trusted groups. The most common questions we get from CISOs who are willing to share detection logic are:

1. What are we sharing?
2. With whom are we sharing?
3. How are we sharing?

The platform that provides simple, usable and elegant answers (and actually implements it!) will win.

Being a SOC Content Platform

From the perspective of a SOC manager, a primary challenge always is developing and implementing the right content (= logic in the form of rules or more advanced code) that the organization needs. An average enterprise doesn't always have the luxury of threat researchers, content authors/developers and analysts to triage/investigate/remediate. Therefore, having quick access to the best content that is suited for your enterprise needs is key to a SOC's success. Such content must also be of the highest efficacy such that downstream actions such as automation/orchestration can be performed more predictably and with simpler playbooks.

Imagine if your SOC had access to a streaming content service from which an analyst can pull desired content, vis-a-vis threat priority frameworks such as MITRE ATT&CK, as well as receives recommendations for content that you must implement based on current industry trends, peer activity, available data sources and other influencing attributes of the cyber-security world. And imagine if this content is readily deployable, in SIEM format of choice, in your SIEM with minimal to no coding or scripting necessary. Wouldn't that fundamentally shift the SOC into higher gear and enable better detection and hence better rates of automation downstream? Not to mention the problem of not having to deal with "skills shortage", and dramatic reduction in costs.

This is how SOC tools, especially SIEMs, must evolve. They cannot continue to remain data collectors and run-time engines for simple rules with heavy dependence and onus on humans. That world is coming, and it will be cloud-powered.