Engineering · 7 MIN READ · MATTHEW HOSBURGH · JAN 12, 2021 · TAGS: Cloud security / MDR / Tech tools
We’re often asked about how we create and prioritize detection at Expel. With so many factors to consider, it’s difficult to give a one-size-fits-all response.
We recently hosted an internal conference at Expel that included a detection writing lab to address this very question.
The lab resulted in an analogy that I trust most of you reading this can relate to: How D&R engineers are like Kevin from Home Alone.
By the time you finish reading this post you’ll have an understanding of our thought process when it comes to writing detections at Expel, how detection writing enables our SOC analysts to make smart decisions as they review an alert and how this process helps us gain a deeper understanding of our customers’ environments.
Detection while Home Alone
The most painful booby trap in Home Alone has got to be the nail through the foot as Marv walks barefoot up those tar smeared steps. Or possibly, when Harry grabs the glowing red-hot doorknob. You can almost smell his pain.
But rewind a few days before the Wet Bandits are running through Kevin McCallister’s “fun house” and you can see some of the planning that went into this burglary.
The Wet Bandits did their research and profiling before making their move. They knew who was on vacation and even when the timer for the lights would kick-on each night.
The difference between the McCallister home and those neighbors who were on vacation is that Kevin was able to identify the Wet Bandit’s objectives early and counter their plan with a battle plan of his own.
Throughout the well-loved movie, we’re presented with a master class on how to identify nefarious threat activity at the expense of some of the sharpest burglars that Hollywood ever produced.
Suffice it to say, you’ve probably had your fill of holiday movies (or maybe not), but they can serve as a point of reference for what we do at Expel in terms of detection writing.
You see, a detection is simply the identification of something interesting on your systems or network. But where it starts to get complicated is when you ask the question: Is this bad?
To help orient your detection writing, it‘s important to consider risk.
“But I thought risk was just for compliance activities?”
Well, understanding risk can serve you well in terms of threat detection and perhaps prioritizing your defenses.
What is detection anyway?
As noted previously, detection is basically identifying events of interest within your environment.
But it goes beyond that.
Detection is all about uncovering something that would otherwise remain hidden (or unchecked). Dragos has done a great job distilling the different categories into four major types that I can summarize into the following:
- Indicator Matching (IPs, file hashes, domains)
- Behavioral Matching (techniques, combinations of indicators)
- Configuration (exposed Amazon Web Services [AWS]S3 buckets, incorrectly configured authentication)
- Manual Efforts (threat hunting and threat modeling, for example)
In many environments, there are algorithms or baselines that help to detect things outside of the norm.
These are useful in the Expel context as they help us answer questions like: Has this logon exhibited this type of behavior in the past, or is this an outlier?
Having an idea of where to start your Detection Quest may rest in a familiar (or painful) practice.
Compliance equals security… (╯°□°)╯︵ ┻━┻
Risk isn’t just for compliance, Marv!
In the context of detection, it helps to serve as the guiding light to where we as security practitioners should start (or spend extra time).
Why?
Because risk represents the sum of threat (which could be an active adversary, opportunistic attacker or malware) and vulnerability (a hole in the fence – or system, network or cloud environment).
Risk informed threat detection
When Kevin first overhears the Wet Bandits talking about their plan to rob his home, he’s actually conducting an ad hoc risk approach to threat detection:
Threat = burglars eyeing his home (Wet Bandits)
Vulnerability = Unlocked doors and/or no one home (no alarm, just light timers)
Risk = likelihood the threat will take advantage of the vulnerability (imminent!)
By examining your vulnerabilities and threats, you can have a better understanding of your organization’s risk.
Understanding your known risks and vulnerabilities, you’ll have a greater chance of uncovering the threats that mean something to your organization. Put another way: your ability to create a meaningful detection will be more fruitful.
The battle plan
Kevin’s rapid assessment requires immediate action: The battle plan.
Adding up the known threat and known vulnerabilities, Kevin creates the overall strategy and tactical responses that will help to slow the Wet Bandits down.
Similarly, this plan is like your unique organization’s environment, which may incorporate your security tooling, identity providers and your cloud-based infrastructure.
Similar to a clever eight-year-old’s battle plan, detection writing requires planning
Your battle plan will more than likely have more detail, but largely it serves as a means to understand the areas of your organization that you can obtain data from. This data can be used as the basis for your alerting.
Alert data flow and where to start
The result of your detection is an alert.
An alert is really another way of saying detection (for sake of simple argument), but the key to getting to this point is bringing the relevant log data from the various sources identified in your organization’s battle plan. Notice: I did not say bring in all the data either.
Unless you have money to burn, having every log known to your organization is often unreasonable from a cost and storage perspective. Working your way back from your organization’s most notable risks and most important data, you’re able to more effectively prioritize the logs you need. This is often referred to as The Crown Jewel Analysis.
The next step is to establish which logs will help make up the most complete picture as it relates to these systems and data.
The second step is to understand who your adversary is.
Take a breath. This could mean you might need to do some threat modeling.
But the key is to understand what your adversary wants from their target (like protected client data, trade secrets or financials).
Your threats don’t care how much you’ve spent on your security; they’re more interested in if they’ll be successful in achieving their objectives and if they’ll be caught.
The best way to consider this is via a model coined by Josh Corman and David Etue which is known as the Adversary Return on Investment (AROI).
Adversary’s Return on Investment (AROI) formula
More notional than quantitative, this model helps you understand why your organization might be a target for a particular adversary.
Decreasing the adversary’s probability of success via deterrence measures can increase their chances of being caught. This can mean you’re a less appealing target because the return isn’t optimal.
With this established, it’s time to create your detection!
A rule
At Expel, we’re fans of Yet Another Markup Language (YAML). It gives us detection writers the ability to describe what we’re detecting and the detection’s priority, categorization and required investigative steps.
Beyond that, it’s the file we use to write our detection logic in – which you see in the image below.
Example YAML Snippet from Expel’s Sunburst IOC Detection
The result of the logic often results in an Expel alert, which is what our SOC analysts use to make decisions.
Remember when Kevin would celebrate when his adversary (the Wet Bandits) would have their face smashed by an iron or their head torched?
Similarly, we celebrate when we find something – but it doesn’t stop there.
Often an alert may require enrichment or additional details. These details may come directly from the rule itself or they may be provided by our automation robots. There’s no better way to burn out a SOC analyst than by having them lookup domain information for hundreds of alerts per day.
Instead, we pass most of the enrichment activities to our robots so our analysts have the most relevant information to make an expeditious decision, which keeps them in the proper mindset.
Investigative mindset
The Expel mindset is all about making a decision based on an alert, or multiple alerts, with minimal manual effort.
Our detection writing and response actions are centered around this.
Some of the common questions an analyst needs to answer in order to determine next steps (Is this an incident? Does the customer need to be notified? Do I need more information?) are dependent on the following:
- What am I looking at?
- Can I use open source tools, or is the information returned from our automation to identify suspicious behavior?
- If the alert is benign, should I suppress it?
- Do I need to investigate the activity further?
Spotting the trends
Spoiler alert: At the end of Home Alone, just when you think the Wet Bandits are about to claim their vengeance against little Kevin, Old Man Marley steps in to serve up his infamous shovel to the head.
Unbenounced to the Wet Bandits is that the police are on their way. Once apprehended, the officer states that they now know each and every house they hit because their indicator of compromise (IOC) was running water.
At Expel, we monitor and respond to alerts from a variety of customers across industries. Our analysts are at the center of all the action and have the ability to analyze trends over multiple customers, which aids them in the decision making process.
A word about communication
Effective communication with the customer is paramount. At the point when the determination is made that the alert does constitute an incident, an analyst would quickly assign the necessary remediation actions to put a stop to an active threat.
They would also recommend the required resilience actions to prevent similar threats to the customer’s environment in the future.
In certain cases where the threat is ongoing, analysts will arm themselves by creating a Be On the LookOut (BOLO) rule for an indicator, or a collection of indicators to quickly create a custom detection to alert on future malicious activity.
Finally, analysts may also add certain indicators to the customer context also known as the customer context (CCTX) database to quickly pass information among themselves and to help them further understand each customer’s unique environment.
All of this is key to detection and response at Expel.
Parting words
We hope this post has given you insight into how we write detections here at Expel in a more approachable manner.
Detection is simply the process of spotting interesting activity on a system or network. Where it truly proves to be valuable is when the alert can help a human make a decision about the bad-ness of what they’re looking at.
Similar to the way Kevin kept himself safe in Home Alone, a lot of consideration goes into creating a detection. It takes analysis of risk, vulnerabilities and the relevant threats to the organization.
Because not all threats or adversaries are created equal, it’s important to present detailed information, with minimal manual intervention, to the analyst so they can make a determination on next steps.
Finally, communication – just like how Kevin reported the Wet Bandits to the authorities – is an important step in response.
You guys give up? Or are you thirsty for more?”
– Kevin McCallister
