In an ideal world, you would stop an attack before it happens. Who wouldn't? The problem is, we can't keep sophisticated, persistent adversaries out.
Let's say an intruder wants to break into your house (network). You can lock your doors and windows (firewalls). Maybe you install an alarm system (logs) or build a moat. Sophisticated criminals (hackers) are going to trick you (phishing) or tunnel under the moat (vulnerability) to find a way to get in and once inside start moving from room to room (escalate privileges) to find where you hide your jewels (exfiltrate your critical data).
It's a world of post-compromise—the attackers are going to get in. What you really need to know is how you are going to respond once an attacker is inside your network. To do this you need to first know how your network normally behaves, what the function of each device is, and who it should be talking to. Then when something is awry, investigate and respond.
It's Time to Define the "R" in Network Detection and Response (NDR)
There are very few people left in the world, if any, who believe that you can stop threats at the perimeter. Most would say "what perimeter?" We certainly need defenses like NGFWs to stop low level threats, and those with known signatures, but attackers are evolving their techniques as fast as their methods become known.
When we look at the NIST Cybersecurity Framework used by most organizations today, the CORE suggests five primary functions: identify, protect, detect, respond, and recover. Each of these terms except for 'respond' is immediately understood. For example, when you hear "detection and response," you can quickly grasp what detection means—unearthing the thing that is behaving suspiciously.
But "response" means something different to every category in cybersecurity. Response can have a very broad or very narrow definition. To some, it means a completely automated response, to others it's much more nuanced and manual. In our view:
"Response should honor the entire response workflow and enhance and aid the analyst to complete their investigation and remediate an incident in the fastest possible way with the highest degree of intelligence."
- Matt Cauthorn, VP of Cyber Security Engineering at ExtraHop
Automated or manual response? It depends.
Is "response" in the form of an automated quarantine of a suspect host going to be enough to stop a breach? Maybe, with a strong enough signal, but usually actions that could disrupt business require a human investigation first.
Using an automated action in every case is too risky. The hybrid network is far too complex to assume that you can solve a threat that quickly. Without knowing what came before and after, you are only solving part of the problem.
As Bruce Schneier wrote, "You can only automate what you're certain about, and there is still an enormous amount of uncertainty in cybersecurity." Can you automatically quarantine events? Absolutely, and then investigate them to know what the response should be.
In a recent Security Weekly podcast, An Honest Conversation About "Response", Matt Cauthorn stated:
"It's time to come out and say it: 'response' means something different to every category in cybersecurity. Yet, it's broadly used with little industry definition. In endpoint detection and response (EDR) systems, 'response' refers to a prescriptive set of actions that can be taken with little to no human intervention. For example, if suspicious activity occurs on a device, that device can be automatically quarantined by the EDR tool. In network detection and response or NDR, 'response' is broader. The network is too vast and interconnected for blunt responses and therefore requires more surgical precision and investigation."
In that same Security Weekly podcast, Juan Canales, a Senior Manager of Enterprise Security and Architecture in the healthcare field, was asked about "response" and stated, "It really depends on the type of event that happened." He went on to say his team may send an email or correlate with other logs, but the response is defined by an action according to the event.
Now, let's say you have been compromised. What is the best way to "respond" to an incident? Check out our next blog in the series for more tips.