SMB: Can I Have Decent Detection and Visibility on a Badly Managed Network?

Let me ask you this: do smaller businesses (say, SMBs) get more security vendor lies than large enterprises? My past analyst experience…

---

Let me ask you this: do smaller businesses (say, SMBs) get more security vendor lies than large enterprises? My past analyst experience certainly seems to suggest so. When I was an analyst, the most ridiculous claims, the craziest “features” and the sleaziest marketing decks were most often seen from the vendors that target just such businesses. The word “target” here is sadly very appropriate…

By the way, my favorite was a vendor that claimed to sell a combination SIEM, UEBA, NTA, “AI”, EDR, SOAR, NIDS and, if I recall right, malware sandboxing in a 1U appliance. Did the appliance also bake bread and serve as a kitchen sink? Perhaps.

It is not always clear why that is. I think some of the more “ethically challenged“ vendors assume that SMB security leaders, or perhaps even SMB CIOs, are less enlightened and won’t be able to tell an ML unicorn from a kitchen appliance …

In this post, I wanted to touch on one particular aspect of a common experience of smaller companies: achieving good (well, decent, at least) threat detection and visibility in a poorly managed IT environment. In essence, how to do good threat detection when both prevention and even IT management are sub-par.

OK, you may say: why even attempt such a thing? Why not spend your money/time improving basic hygiene and focus on things like network segmentation and system hardening?

A good question indeed!

First, you cannot hygiene your way to detection, and ultimately no amount of prevention will help you when prevention fails. Please meditate on this one! Layered prevention is still prevention, and when prevention fails you need detection. Damn, I feel like it’s freaking 1997 when I say this, but I do know for a fact that there are organizations where this is news in 2019 …

Second, I have an intuition that if you have a really creaky IT and security foundation then it is easier to build decent visibility and detection than good prevention (but please argue if you feel I am way off here). Logically, I should be able to focus on prevention and hardening first, but then what do I do when my efforts in this direction hit the wall, be it technical, cultural or political.

Third, if you don’t start on your visibility, detection and monitoring early, and instead focus on prevention alone for a number of years, then later you will have to run the re-balancing and perhaps re-architecting projects. Many companies today are still on their re-balancing journey from overweight, unhealthy prevention-only security programs. BTW, you can venture a guess why that is the case despite the fact that most 1990s and early 2000s security books really hit hard on the prevention — detection — response triad. Some data of unknown provenance I’ve seen a few years ago had the security spend split between prevention / detection / response as 80% / 15% / 5% at many companies.

Before we proceed: can we shortcut the process and just pay an MSSP or a good MDR to do this? Well, sure, but they will face the same exact problem — asset discovery, sensor placement, data collection, etc. Moreover, my experience suggests that a third party (like an MSSP) will fare very poorly in an environment where assets are lost, changes just happen, system roles are not tracked, connectivity is random and system hardening is non-existent. My imperfect analogy would be inviting a contractor to do work in a very messy house, where nobody has any idea where everything is and there are piles of stuff everywhere …

So, can I offer some practical tips on what to do to improve detection and response? Well, no, because I am no longer paid to offer advice, but I’d like to offer some pointers.

One, use more SaaS to secure … well … everything. The reason here is not so much better effectiveness, but dramatically lower cost of operation. Seriously, use more SaaS for security and leave your cloud fears to rest. In 2019, the concept of buying a server to install and run security software should start to sound like buying a horse barn to keep your commute horse in it …

Two, it pains me to say this, but at poorly managed networks and in poorly managed IT environments, agents are extra-extra hard. Hence the arguments from this post shine: you are likely to end up with more network monitoring, even if at the cost to endpoint and log monitoring (yes, despite this). Overall, use detection and visibility controls and technologies to then drive better targeted prevention, even as your environment remains somewhat chaotic and partially unmanaged (and mismanaged).

Three, the advice I offered in the past still stands. Even an SMB need to spend some time thinking intelligently about detecting threats and responding to incidents, and the above links offers a framework you can borrow.

Four, admit that some amount of outsourcing is likely in your future. Sure, there are always pros and cons, but you do need help, and this means an MSSP or an MDR. Pick a good one (find some of my prior writing on how)

Five, admit [some] defeat. Well, what I really mean is “invest in tools and processes for recovery and resilience.” If your network is essentially indefensible, you will have incidents, and recovery measures is what would save you in the end.

Six, fight complexity and reduce the number of security tools. Sorry, but if you can barely handle one SIEM, please don’t buy two. If you cannot deploy EDR, don’t buy a standalone one, seek to combine with anti-malware. Overall, one decent tool that you know how to use is much better than two excellent tools you don’t truly operationalize and have no people/skills to run. You may have heard that “the best of breed has won” in security, but I assure you, this is NOT about SMB.

There you have it, enjoy!

---

Originally published at Medium.

Does Your Incident Evidence Really Lead to Better Intelligence?

So I admit this post is not about security incident response in general (because I’ve written enough on that in the past), but about a…

---

So I admit this post is not about security incident response in general (because I’ve written enough on that in the past), but about a link between incident response (IR) and threat intelligence (TI) in particular.

We definitely talk about how TI helps us understand an ongoing incident. Without mentioning the dreaded “A” word — attribution — threat intel can separate run-of-the mill ransomware from elite state attacker. This has been covered enough in the past.

On the other hand, past incidents can and should generate intelligence, but in real life they don’t, in many cases. This is mostly the “Lessons Learned” phase of Incident Response, which is, frankly, often rushed through or approached very narrowly, in a non-intelligent manner.

This blog is a lament about it. Is lamenting useful? Perhaps as a motivation for the less motivated. Or as a reminder to the less informed. Or perhaps as a little push to those who sit on the fence about it…

Where does IR provide intel? For years, we’ve seen elite IR firms supply their TI divisions with intelligence, so why hasn’t this become more popular among the rest of the world?

After all, we all have incidents. We all want to not step into the same poo again. We all want to appear smart and save face (yes, I am preparing for a trip to Japan :-))

Creating intel from past incidents appears to be one more practice from the list of “everybody enlightened does it, but there is no trickle down to the mainstream” (as a funny aside, hunting perhaps started to trickle down a bit, but occasionally it takes the form of a “cargo cult” hunting)

So, why not learn from your incidents by creating threat intel?

First, there is a type of an organization that just does not learn. Security IR at such a place is really just the proverbial “nuke from orbit” and no investigating. So, all intelligence dies with the reimaged disk and powered down memory.

Second, some learn very narrowly like “oh, we got hacked via struts? Now, we are going to patch struts.” What can I say to this? Nothing, really, I am just going to leave it here :-) A degree of operational agility would also come handy here.

Third, occasionally people get in the way: while having a separate IR and TI teams is wise at higher maturity levels, it is assumed that (at said maturity level) the teams actually work together. Now, do they? I’ve seen examples where IR team deems incident evidence too sensitive to become intelligence, for example. Or just want to own it. Building a wall between TI and IR or having it open in one direction only is not a good idea.

Fourth, in some cases there is simply no good place to collect, keep and utilize this intel. Most TIP vendors nowadays seem to focus on pumping through large volumes of indicators and not on handling incident intel like local malware captures (sure, there is MISP and friends, but perhaps they are not for everyone).

Fifth, and this is a subtle one: extracting indicators and other intel from incident evidence implies that your threat model includes threat actors where such a practice is justified. For example, there is no sense in sandboxing and analyzing malware that is actually stopped by anti-virus (in most cases). What I saw in the past is that the operational process for processing incident evidence into indicators and other intel can be created only after the foundation of threat assessment (i.e. knowing who is out to get you), robust IR, robust TI is laid down.

So…. what should you actually do?

My conclusion today will bore literati to tears, but will hopefully help the mainstream: DO make use of your own incident data to create intelligence that ultimately helps you, the defender. As a first step, DO spend a few hours contemplating the most recent incident you had with the intel lens in mind (i.e. what can we extract and use for detection content, qualifying other incidents, share with peers, etc) This will imbue the Lessons Learned phase of your IR with specific value.

How do you accomplish that? How do you actually convert the “IR outputs” into “intel inputs”?

A classic IR process already implies that the Lessons Learned phases includes questions like “What did we learn during the course of this incident?”, “Where did our investigations lead?”, “How could this have been prevented?”, “How it could have been detected faster?” and so on.

If you extract indicators and gather intelligence from the evidence at hand, you may also shed some light on “Why were we targeted?”, “Have we seen this threat actor [group] before?” and perhaps even “What is the level of actor sophistication?”

In addition, the indicators extracted from logs and attacker tools should lead to new detection content for SIEM, EDR and other tools. For example, a piece of malware will render a hash (duh!), a set of IPs it connects to, a hostname or a URL where it came from, and perhaps a protocol peculiarity or two (if its communication is in any way unusual — it usually is).

Frankly, even a chain of your systems that the attacker went through may reveal something you can use in the future. Types of credentials utilized, a packaging tool used (if data was staged for exfiltration) may teach you something what this or other attackers may bring next time. What the attacker did at each step also may teach you about the weak spots in your layered defense.

Finally, I’d give you a quick bit of the opposite advice because “The opposite of a fact is falsehood, but the opposite of one profound truth may very well be another profound truth.” Use past incident data, but don’t obsess on it — the attackers may well throw something completely different at you next time…

Related blog posts related to threat intelligence:

• About Threat Intel Retro-Matching
• Detecting Threats by Matching Threat Intel to Logs — Oh Really?

---

Originally published at Medium.