Can I Have Decent Detection and Visibility on a Badly Managed Network?
[Reposted from Anton on Security.]
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…
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!
The problem for those going Splunk Ent/ES/UBA is mostly in the lack of SCCM and continuous Active Directory object contextualization for adds, moves, and changes. Not that Exabeam or Securonix save you there; they actually make things worse. To me, it's not about a poorly managed network or tackling on tech debt. It's not about spend. These problems go deeper than SOC and CIRT level issues. From my perspective, even SMBs are going to need some form of Cyber Response/Operations integration with Cyber Threat Intelligence features. You can't just say SIEM/EDR for maturity zone 1, SIEM/EDR/SOAR+/SIRP for maturity zone 2, and SIEM/EDR/SOAR+/SIRP/TIP/AaaS for maturity zone 3. You don't bolt on or add-on components. It's IACD, and you add in Credibility and other features. It's a single framework, a single reference architecture... it's the orchestrator pattern and picture. We need to start visioning a single architecture and a single architectural pattern to absorb the dynamic ontology that is cybersecurity defense.
I really like this post. You briefly mention it and it bears emphasizing: A poorly run IT shop likely doesn't have the money or management interested in the cost of agents (direct and indirect), or the cost of storage to achieve historical detection. Enter cloud/SaaS suggestions. I may feel a little led to the watering hole, but I agree with your points. If your IT is poor, diving even harder into IT may not yield any better results. If you can pull things out and separate from your poor IT practices, the security team can at least gain visibility into the badness and float above the top of it. And better detection is going to fuel better surgical efforts at combating poor IT, inserting actual prevention value, exposing the worst hygiene issues, and expanding transparency to everyone.
Decent visibility and badly managed negate each other so NULL state.
Good points. I’d also argue that you could if you have equally good outputs and reporting on what exactly you are detecting and how that effects the business. I think most fail to make sound, risk-based decisions because there isn’t an easy “translate” button for executives on what detection and visibility is providing their business.