Well that’s a weird title, right? Now that the dust has settled to some degree, let’s look at a not-so-obvious takeaway from the latest security news that simultaneously set everyone’s hair on fire?

The latest Shadow Brokers dump is bad on so many different levels. Let’s not concentrate on the potential levels of government and private industry collusion our guts told us existed, but we weren’t sure of. Even now, Microsoft is claiming the vulnerabilities were fixed as part of a routine patch cycle… Exactly 1 month before the data dump… On one of the worst remote code execution vulnerabilities the industry has seen in a long time… Righhhhhhhhhhhhhhhhhtttt! I’ll take BS for $1000, Alex. While we are at it, I might have some really cheap ocean front property in landlocked Kansas for you if you’re buying Microsoft’s claim. 😉

Political arguments aside and regardless of whether it is right or wrong for a government entity to hoard zero-day vulnerabilities, it shows some serious capabilities that we didn’t realize existed until recently. Here’s the reality though… While you should be aware of these capabilities regardless, how worried you should be depends on 3 key factors.

1) Are you a nation-state?
2) Could you or your organization potentially be targeted by a nation-state?
3) Are you following best practices?

Clearly, one of these things is not like the others (cue Big Bird). So what does #3 have to do with #1 and #2? As it turns out, everything. We all know the mantra that has been ingrained in us as security professionals, i.e. if someone wants access to what we have and it is “accessible,” it’s only a matter of time. We won’t go into a long discussion on what accessible, although it is relevant to the discussion.

Instead, let’s focus on the fact that it is our job to raise the bar and make the adversaries job difficult. In a nutshell, make sure you are following best practices. Best practices in the truest sense of the phrase are not what someone thinks should be done. Instead, best practices are the common ground that a roomful of intelligent professionals can come to a consensus on (which can be nearly impossible to accomplish by itself).

Some best practices are difficult. Some best practices are easy. I’ll point to the hardening guides and benchmarks at the Center for Internet Security (CIS) as examples of both. How deep you want to travel down the security rabbit hole and how closely you want to follow them depend entirely on the sensitivity of your data, who your adversaries are, and your risk appetite.

So back to what we *should* have learned… At the very least, best practices mitigate a ton of the possibilities from the dump. Is your network segmented? How much segmentation is acceptable? Continuing the segmentation theme, what if you can’t segment absolutely everything? Then are your machines able to talk [laterally] to one another? If so, why? Is that capability needed? Do you still use SMBv1 in your environment? Probably not, but if it’s still enabled, then come on! You’re not even trying!!! And while hindsight is 20/20 and patching would have mitigated the exploits (for the past month at least), is this the first time you’ve heard someone talk about the importance of patching?

While there are thousands of other best practices, I’ll end with one in particular – logging. This is one I hold near and dear. I’ve now presented on my “Uncovering Indicators of Compromise…” at several conferences and recently at BSides Oklahoma. I always provide the caveat that checking for event log clears is completely valid and a step in the right direction, although you should also send said logs elsewhere for safekeeping. In my presentation, I use Windows Event Forwarding because it is cheap/free and easily implemented, but the truth is there are likely thousands of possibilities depending on your environment. Why check for event log clears *and* still send the logs elsewhere? 1) In the event of a log clear, we would still have evidence of what was done prior. Often times, that is a huge part of the battle. 2) The capability to delete Windows log entries individually has not existed for some time. The dump proved this capability exists in recent versions of Windows… Now that we know the capability definitively exists, what does that change? In reality, not much. Why? We should have prepared for its existence. After all, it existed before. And now a new patch supposedly removes this capability, but why trust this patch, this time? We didn’t before… At least we didn’t if we were following best practices.