The best POCs have cool ASCII art. (source (opens in new tab))
“Who would actually go after us, anyway?”
A former client asked me this while refusing an internal vulnerability assessment. Months later, they called me back — after a ransomware gang had already answered the question for them.
“Who would actually go after us, anyway?” they had asked, invoking the minimum requirements for their annual SOC 2 audit (opens in new tab), which didn’t really require penetration testing to begin with.
They were a small business in a small city serving mostly local customers. To them, they held nothing of value to a hacker, so narrowing their pentesting scope to their external IP address made plenty of sense.
That is, until someone exploited a fresh, critical vulnerability (opens in new tab) in their office SonicWall and locked them up with ransomware hours after disclosure.
No patch available, no way to stop the perimeter break.
Unfortunately yet predictably, I heard from my old client soon after they recovered from the ransomware attack, and we did a comprehensive set of assessments of their internal security posture.
We did a lot of good in those assessments, but only after they had already lost operating capital and taken a heavy reputation hit, far more than the cost of an internal assessment.
Where the Model Breaks Down
See, when a zero-day exploit drops, two clocks start ticking: one is the heist clock, which counts down to when you’ll be specifically targeted. Maybe you’ve been on someone’s list of high-value targets for a while, and all they needed was the right moment to strike.
The other is the drive-by clock, ticking down to when the exploit will be indiscriminately sprayed across the internet, hitting every digital door in the TCP/IP neighborhood to see who has a faulty lock.
Unless you’ve been paying attention, you won’t know which clock you should have been watching until it’s too late. And as much as I dislike having this conversation after misfortune has befallen someone’s domain controller, it is usually the first time they’re willing to listen.
The internet is a great and terrible equalizer in this regard. Any organization, big or small, could be using a vulnerable appliance with an IP address.
Some of them learned this lesson seven years earlier in 2014 (though still the hard way) with Heartbleed (opens in new tab), one of the most reliable remote code execution (RCE) vulnerabilities in recent memory.
Sometimes, you don’t even need to be a company to feel the consequences. You just have to drive a Kia or Hyundai (opens in new tab).
If you’re only expecting a heist, you won’t see the drive-by coming.
The Missing Third Piece
For much of my career, I’ve taken the controversial but undefeated stance that unless you have the following three things, your security apparatus is inherently flawed and unreliable:
- Asset Inventory—you can’t protect what you don’t know you have.
- Network Map—If you don’t know how critical assets talk to each other, an attacker will probably figure it out for you.
- Threat Model—What are you protecting, how are you protecting it, and whom are you protecting it from?
The question “Who would actually go after us, anyway?” is humility or hubris depending on who is asking it.
One can only begin to construct a threat model with the answers to this question, but instead, many unaware organizations weaponize it against having to spend money on something they don’t see as worthwhile.
In the best cases, they never have to find out what their threat model is. At worst, someone comes along and shows them, often quickly and painfully, just how much they actually had that was worth taking.
Customer information, credit card numbers, bank account credentials, and even just plain old cash to pay a ransom are more than enough for someone to include you in their scanning target list.
Defensive Steps That Matter
It’s past time we changed the way we think about the likelihood part of risk measurement. Or, at least, non-patchable zero-day exploitation needs to be a part of every single company’s regular risk assessment.
The likelihood of a zero-day being tested against your environment is determined by whether you have IP addresses in the 0.0.0.0/0 space and whether you have computer systems attached to those addresses, not by the value of your data or the size of your organization.
The mitigations are boring but impactful. Here’s where to start:
Get a Full Inventory
If you’re going to spend money on an appliance or a piece of software, make it one that most reliably identifies your assets. This will require some manual validation, but the visibility is worth it.
Once, I performed an external network assessment for a company that had several data center colocations with systems in their racks that were decades old. When I found a server vulnerable to Heartbleed years after it was disclosed and patched, I couldn’t believe it.
Neither could they, since the IP address and hostname didn’t appear anywhere in their inventory.
I got the network admin’s VPN password from the first memory dump.
Understand What Is Reachable and From Where
With an accurate inventory, mapping out the packet conversations becomes much simpler. Passively capturing broadcast packets and analyzing the sources and destinations will reveal more than you could have imagined about how many systems may be interacting with each other.
Even better, if you have the access to do so, perform more active packet capturing on your switches and firewalls for unicast traffic to see as much as possible. When you’ve mapped out your IP space and correlated it with your asset inventory, you’ll have more than a lot of organizations have.
Few things have given me headaches more than well segmented, highly specific network setups in which there are only packet black holes.
Research Past Threat Activity
Once you know what is in your environment and what it’s doing, you can start looking at vendors and patch levels to understand what might cause you problems without notice.
For example, if your SonicWalls are the only device between your internal and external networks, a compromise can be a huge pain.
But if compromising the perimeter with a SonicWall exploit only grants an attacker network reachability to a few key hosts in a demilitarized zone (DMZ), and the firewalls between the DMZ and other segments aren’t SonicWalls, the attackable surface reduces dramatically without more unique exploits.
Exceptional threat modeling goes beyond this, however, and should inform decisions you make about how networks and assets are segmented away from each other based on what you need to protect.
As for where to start, begin by looking at your entire organization and asking the following questions (stolen from Centers for Medicare & Medicaid Services (opens in new tab)):
What are we working on?
What features are we building/network segments are we concerned about/software do we currently use, etc.?
What can go wrong?
Can it go down? Can someone bring it down? Is it already vulnerable, or could it become vulnerable based on past experience and research?
What are we going to do about it?
Can we eliminate risks entirely? Can we mitigate risks we cannot eliminate? How do we test the efficacy of changes we make?
Did we do a good enough job?
Did the changes make a difference? Is there anything we overlooked? Can we improve on the improvements we made? Can we apply these improvements in other areas?
And then, repeat.