Misconfigurations: The Unforced Errors of Cybersecurity

If you’ve ever played tennis, you know about unforced errors. These are points given up by a player’s own blunder, rather than by the skill of their opponent. In security we see the same thing, only they’re called ‘misconfigurations.’ These are errors – our fault, and completely preventable – that didn’t need to happen and create holes in our defenses. I’m going to dive a little deeper into these admin-side errors and investigate what we can do as security practitioners to clean up our game.

Misconfiguration: The Silent Killer

When software vulnerabilities are exploited, the manufacturer (most often) issues a patch. We know what went wrong, and we know what to do to fix it. However, misconfigurations are not so easily noticed. Things can remain undetected for years, presenting “low-hanging fruit” for attackers as they ferret out our errors. No alarm bells sound and sometimes the only way we know something went wrong is if we audit – or if a bad guy finds it first. Which happens all too often.

It was discovered in a survey by McAfee that only 1% of internet-as-a-service misconfigurations are reported, and DivvyCloud revealed that misconfigurations were the cause behind nearly 200 separate cloud breaches between 2018 and 2019, totaling 33 million records and over $5 trillion in impact. Gartner even predicted that misconfigurations would be responsible for 80% of cloud breaches by 2020, as Forbes reported. And let’s not forget the breaches against Equifax and Microsoft Azure, two more unfortunate victims of things left unpatched and/or misconfigured.

Attackers are opportunists. Leaving a door open in plain sight for them to walk through is an irresistible invitation – especially when nobody knows to watch it.

Internal Misconfigurations

Internal misconfigurations aren’t necessary by accident. Oh, it’s possible to forget to restrict admin privileges on the occasional server, but more than likely those permissions are set on purpose because it’s convenient. You make too many trusting decisions, and the company goes on, forgetting those “ad hoc” rules set in the early days until a new employee abuses that trust or a hacker exploits the lazy security configurations.

External Misconfigurations

External misconfigurations are public-facing and happen on the edge of the network, either in the cloud or on the physical edge. Maybe they aren’t ‘mis’-configurations, just default settings on publicly exposed web servers. Also, even the most basic of firewall configurations can lead to needless holes in your network (remember when you fat-fingered that port?). And, perhaps most commonly, things that weren’t done wrong to begin with, but over time have turned into ‘configuration drift.’ We’ll get into that in a bit.

(By the way, when dealing with web applications, look to the OWASP Top 10 model. You’re probably familiar with it, but if not, it’s defined per their website as “a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.” This year, Security Misconfigurations ranked #5 in their list of prioritized concerns. You can also make use of the OWASP Dependency-Check to vet any applications that make use of open-source tools.)

Configuration Drift

Configuration drift is a term used to describe the creep of configuration protocol over time, and how – if we’re not careful, auditing, and updating – what was good then may not be good anymore. For example, you’re a system administrator who’s asked to add this port to the firewall here or remove that one over there, and it’s done, but not codified. As TechTarget explains so well, “Configuration drift occurs naturally in data center environments when changes to software and hardware are made ad hoc and are not recorded or tracked comprehensively and systematically.” Without careful attention to the details, the creep of unstandardized methods comes in and you’ve got a mess.

Solving an Unseeable Problem

So, what can we watch for, and what do we do when it comes to fighting misconfigurations we may not even know about? NIST issues some guidance on the subject, “Special Publication (SP) 800-128, “Guide for Security-Focused Configuration Management of Information Systems”, and that’s a great starting point. It may also be an overwhelming one, so let me recommend one other approach (in addition to NIST, which should never be overlooked). Start from the top down and begin battening down the hatches. Audit your system, and make sure it lines up with the CIS Controls. Although it might be impractical to stress-test every inch of your environment and scrape through it with a fine-toothed comb, take a look at where you stand in relation to the CIS Controls’ Implementation Group 1 (IG1 – “essential cyber hygiene”) and specifically, Control 4 – Secure Configuration of Enterprise Assets and Software.

As we’ve discussed before, support for Zero Trust and a new approach to the old defense-in-depth strategy all start with a solid strategy the embraces the basics. And tennis players know the “basics” they have the most control over: eliminating those unforced errors.

‍