Defending Assets You Don’t Know About

Not all assets are created equal. Back in the 90s, we all used to build massive firewalls around our systems and spent our day-to-day resources looking for holes to patch. In theory, an impenetrable wall is a great idea. However, if you’ve ever owned a house, you know that all walls form cracks over time. If a wall is your only defense, it needs to be 100% perfect, 100% of the time. You are never going to achieve that. But that does not mean you cannot defend all your assets. Perfection must not be a prerequisite for good security.

Even in an imperfect world, you don’t need to know about everything you own to protect it. Assets can be grouped and categorized such that the security procedure accounts for their weaknesses.

Think about all the ways you build security controls that affect a whole group of things.

• If your outbound rules are default-deny, you can still catch a compromised device, even if you don’t know how it got there.
• If your developers are all trained to build on default images, your hardening and logging guidance might be followed, even if they deploy using the wrong AWS token.
• Whole company phishing reminders don’t target an individual user, but might prompt a user to take a preventative action even if HR forgot to give them their individual new-hire security training.

We have all sorts of defenses that work even in the presence of unknowns or mistakes.

Use Categorization to Find Your Internal Paths

Your system is massively complex. So for an attacker like me, attempting to understand the entirety of an attack surface is a non-starter. I don’t need to know all your assets or everything about your security strategy. I have to think in terms of the attackability and the path to success — finding an entry point and stringing together bugs to get me to the goods.

This is how you should think about protecting your system: find the paths that exist between your attack surface and your sensitive assets and snuff them out. If the paths get you to a critical function, bottleneck your opponent there and bury them in fail safes and alerts. This way when an attacker does take advantage of that path, you will know long before they are able to exfiltrate data.

There is no magical formula to categorize your assets and how you protect them. There is an infinite number of ways you could categorize, and the right one depends entirely on the context of your organization. At Randori, we try to train ourselves and others to group assets into functional clusters. We look at which ones represent a “path” for an attacker, and then determine how many policies we have to create around them to ensure we feel good about “coverage.”

How do I categorize?

The simple answer is, you can categorize based on what needs to be talking to the internet and what doesn’t. Chances are, the vast majority of your internet-facing assets are components of SaaS apps or appliances that you don’t use, or don’t need to use. If you have an appliance that provides file transfer and VPN and you only use the VPN, turn off the file-transfer feature.

You can shut these features down and forget about them. If an employee comes to you and says they need it to do their job, simply turn them back on. (Default deny, anybody?)

Then there is the next category: things which are visible from the outside and necessary to company operations, like your corporate website or remote access protocol. These are no doubt some of the most prominent pathways between your attack surface and your crown jewels. They are meant to be — how else would your employees access anything? These assets must be secured with a lot of monitoring and alerting, and there should be a DMZ around them.

Know What Matters and Forget the Rest

You no doubt have already established a DMZ (demilitarized zone) in your network; this is where you put the assets that need to be internet-accessible and closely monitored. In fact, you probably have another: your corporate website lives on a server by itself totally isolated from your core business. Every time you’ve also got a VPN or some remote access tool, it goes in your “DMZ,” where you’ve got heavy-handed segmentation and monitoring. Anything in the DMZ gets intentionally implemented with least-privilege, and by being in the DMZ (or even deeper in your network) any service inherits segmentation, and some visibility or monitoring. There are some small ways in, but I stress these are small because you need to have thorough monitoring on them. Each layer deeper into your environment should inherit more defenses, and require more failures for a breach to occur.

Segmenting and hardening reduce your opponent’s options. Limiting the normal activity between assets where possible (such as between the DMZ and your core network) creates opportunities for detection. The security team is the advisor here, and creates policies to try to inherit defenses. At Randori, when developers are experimenting with code, I want them to “code securely,” but I also want that the unfinished or prototype work inherits some defenses even if mistakes are made. So we manage some simple additional layers: Everything gets deployed without direct internet access, and SSO-enabled proxies are used to provide access. Developers can do their work, but even if they accidentally disable authentication in the app they’re building, the application is still “defended” by a layer of SSO.

You’ve Got Too Many Bugs to Fix Them

If you get a Qualys scan and it reports back 3 million vulnerabilities on your attack surface, you can’t do much with that because you can’t ship out 3 million patches. So you cannot rely on a perfect wall alone — it’s that simple. But if you can know which vulnerabilities are in segments that matter and have inherited insufficient protections, then you can prioritize which to address. If the application server that is allowed to transit your DMZ is unpatched, you’re going to want to fix that first. Got an internal application server that’s only accessible to limited internal users? Maybe ignore that one for now. If there’s a place to panic about unknown vulnerabilities, it’s most likely the application server transiting your DMZ and not your internal one.

There Will Always Be Unknowns

We all know that Shadow IT is a massive problem (something like 40% of IT spend?), and ideally you’d use an attack surface management platform to help you find surprises in your attack surface (have a look at Randori sometime, we can help). But when you’re planning your security posture, you need to assume that this shadow-problem will continue to exist, and make sure that one or two surprises doesn’t become an associated press headline.

Someone will always “plug something into the internet.” If your DMZ requires network access control (NAC), denies access to the internal network by default, and generates alerts to your MSSP, then “plugging something into the internet” then requires a lot more than one failure for a meaningful breach to occur.

You have to design your security systems with the assumption that an attacker can break any asset and own its controls, its privileges and its functionality. You can defend an asset, even when you don’t know about it, by practicing defense and depth — knowing what matters, and implementing many disparate controls, with no single point of failure.