As Aesop says, “Good things come in small packages” and this week’s post we’ll label as a small package.
The book I finished this week is called “Crafting the InfoSec Playbook”, which is written for those looking to improve their SOC or incident response (IR) teams.
This book does a good job laying out all the major considerations any SOC or IR team should incorporate into their “playbooks”.
A playbook is simply a series of instructions that security analysts or incident responders should follow in specific scenarios. This is a huge oversimplification and a good playbook includes every department within a company, but this definition will do for now.
This book revolves around four questions that every playbook is based on…
- What are we trying to protect?
- What are the threats?
- How do we detect them?
- How do we respond?
Interestingly enough most security groups struggle to answer the first question and without fully answering question one, the remaining answers are incomplete. This initial question can be difficult because it includes mapping every device on your network while connecting each device to a user, which can be a herculean task.
As I mentioned before we’re going to keep this post short, so here are two ideas that stood out to me…
Tradeoffs
In every aspect of life, we’re constantly making tradeoffs, either consciously or subconsciously and InfoSec is no different.
The major tradeoffs we’ll pull from this book are detection and alerting methods.
Inline vs. Out of band
When creating a security team within any company it’s important to know the where, what, who, and why of the traffic moving around your network. This is done in different ways, but the two main options are placing a box that detects traffic either “inline” or “out of band” (see simple diagram below).
- Inline (IPS): When a box normally called an intrusion prevention system (IPS) is sitting directly in between two points it’s considered “inline”.
- Pros: Prevents known bad behaviors from entering or leaving the network.
- Cons: Could slow down the traffic moving through the network due to it needing to check every piece of traffic or even worse block legitimate traffic due to false positives.
- Out of band (IDS): Here we take another box called an intrusion detection system (IDS) and place it “out of band”, which means it’s sitting outside the direct line of traffic, but still able to observe
- Pros: This box isn’t likely to cause network failures, slow down traffic, or prevent legitimate traffic due to it sitting “out of band”.
- Cons: This is “detection”, which means it’s able to observe bad things entering and leaving the network, but is unable to take action. Imagine watching someone rob your house, but you’re unable to do anything about it… This is similar.
The beauty of this tradeoff is that we’re able to counteract the weakness of each method by placing boxes in different locations. For example…
- Inline: If you have valuable internal databases or SCADA networks that should only have specified traffic allowed in/out, then an IPS box is perfect.
- Out of band: For your demilitarized zones (DMZ) that need to be accessed by the internet, placing an IDS box works well.
Put simply, if you have super-secret or valuable internal data use inline methods, for everything else use out-of-band methods.
General vs. Specific Alerts
Creating security alerts is both a little science and an art. There’s a constant tradeoff being made when writing the queries for these alerts, which is walking the line between alerts that are too general or too specific (see diagram below).
- General: A general alert will collect too much data overwhelming your security analysts with false positives, diverting their energy to the things that don’t matter.
- Specific: An alert that’s too specific will be accurate, but will only catch attacks identical to previous attacks, leaving plenty of room for mutations of this attack to roam free within your network. An example of a specific alert would be tracking a single hash, domain, or IP address.
Sadly, this skill of balancing between specific and general alerts is only built through experience and familiarity with a network. Time and reputation are the way forward… At least until AI takes over, then we can just pass it off to our machine overlords.
Don’t Block, Subvert
There are different levels to this InfoSec game and the more advanced a security team becomes the more their strategic mindset evolves. Starting out most security teams focus on blocking all evil, but this prevention mentality fades over time due to reality smacking us InfoSec folks in the face over and over. I’ve said this before and I’ll say it again, every network will be successfully breached, but that doesn’t mean that as a security team, you’ve lost.
As defenders, our goal is not to only prevent, but to detect and mitigate. More advanced security teams selectively decide on their reaction to an attacker depending on the scenario and this is where “Don’t Block Subvert” comes into play.
Once an attacker has breached a network, their next move is to “phone home” (e.g. reach out to the command & control server (C2 Server) and get instructions on what’s next. Instead of simply blocking this communication between the malware and its C2 server, we can divert this communication using a method called “Sinkholing”. Let’s say we have two points A and B communicating, but during that conversation, we insert ourselves and begin diverting all communications to C instead, this is a “sinkhole”.
Taking this “sinkhole” idea a step further we could actually divert this communication to a honeypot allowing the malware to communicate with the C2 server, but we’re secretly observing every action. After observing these communications we’ll be able to create alerts protecting our network against similar future attacks.
That’s it! Remember, good things come in small packages. 🙂