Vulnerabilities vs. Security Misconfigurations: An Essential Primer

These attacks typically take advantage of known vulnerabilities, the focus of databases (like CVE and NVD) that track vulnerabilities, and they drive most headlines in the media.

But the fact is that not all attacks involve malicious code or vulnerable applications. Sometimes, breaches result from simple misconfigurations. Misconfigurations create infrastructure flaws due to missing configuration data or incorrect settings in the infrastructure layer of an application environment. Misconfigurations are a distinct category of risk from vulnerabilities, and they require different mitigation strategies.

Keep reading for a breakdown of how security vulnerabilities compare to security misconfigurations and what organizations can do to avoid the latter.

What is a software vulnerability?

A software vulnerability is a known flaw inside software that allows attackers to access the software or data that the software manages. Vulnerabilities are tracked in databases—MITRE being the leading one—that identify each vulnerability by name, assign them a severity rating based on how much damage they can cause, and record which specific versions of software are subject to the vulnerability.

Common sources of software vulnerabilities include:

• Lack of proper data validation by applications, which can enable injection attacks.
• Coding flaws that threat actors can use to execute buffer overflow attacks.
• Failure by applications to encrypt or otherwise secure data properly, leading to data exposure.
• The incorporation of vulnerable third-party code, modules, libraries, or other dependencies into an application.

What vulnerabilities like these share is that they all lie within an application or environment resulting from flaws in the way the software was designed or built.

What is a security misconfiguration?

A security misconfiguration is a configuration error that makes an environment or data vulnerable. While defining an “error” is somewhat subjective, organizations like the Center for Internet Security (CIS) define best practices for configuring infrastructure. This guidance is useful for identifying potential misconfigurations within a software environment.

Common examples of security misconfigurations include:

• Cloud storage configurations that make sensitive data viewable by anyone on the Internet.
• Applications, services, or devices that are configured to use default access credentials.
• Configuration ports (SSH or port 22, RDP or port 3389) open to the world, making it easier for bad actors to gain administrator access.
• Containers that are granted privileged access to the Kubernetes node.

Learn more about common Kubernetes misconfigurations and AWS IaC misconfigurations.

Configuration issues like these aren’t internal to software applications, services, or operating systems. Instead, they involve the settings that govern how applications, services, or operating systems run. It’s also important to note that individual organizations can set unique policies. Any infrastructure configuration that does not meet those policies would be considered misconfigurations

Vulnerabilities vs. misconfigurations: What’s the difference?

Thus, the main difference between a security vulnerability and a security misconfiguration is that security vulnerabilities are flaws in the software itself. In contrast, misconfigurations are flaws in the way the software environment is configured.

Let’s use the analogy of a lock on your front door. The lock mechanism is made up of multiple parts representing the different parts of your application, environment, and infrastructure.

In this analogy, vulnerabilities are akin to installing a lock with a manufacturing flaw, making it easy for attackers to pick and gain entry. In contrast, misconfigurations are akin to leaving your front door unlocked with a perfectly functioning lock. Functioning locks can be akin to cloud providers, which, under the Shared Responsibility Model, take ownership for protecting the infrastructure that runs all of the services and provide mechanisms to secure your part of the shared stack, like storage encryption. But even with a perfectly secure lock, the misconfiguration of forgetting to lock it (turning on encryption) creates an open door (in this case, literally) for attackers. The flaw lies not in the lock itself but the user error when using the lock.

The growing risk of misconfigurations

The threat of security misconfigurations is growing continuously more serious for the simple reason that in the age of multi-cloud, hybrid cloud, and scale-out everything, software environments are becoming more and more complex. With complexity, it’s both harder to avoid misconfigurations and without the right tooling, to identify them.

It may have been easy enough to avoid configuration issues that created security problems when you ran just a few monolithic applications hosted on virtual machines. But when you have scale-out applications hosted in containers, with orchestrators, container registries, and various types of cloud services tossed into the mix, it is exponentially more challenging to ensure that each of those layers of your stack is properly configured, especially if you use infrastructure as code (IaC) to provision the environment. A small error in one layer could lead to major security issues across the stack. For example, one misconfigured IaC resource block can be used in hundreds of deployments, causing thousands of security alerts.

What makes matters even more complicated is that threat actors may combine misconfigurations with vulnerabilities to maximize their ability to launch exploits. For example, consider publicly available container images and Helm charts, the majority of which are known to contain misconfigurations. The containers or Helm charts may, for example, leave an insecure network port open. Attackers could use this port to plant malware that escalates the attack to involve other resources beyond the container or Kubernetes resource where it originated.

It’s risks like these that have prompted OWASP to add security misconfigurations to its list of top threats.

How to mitigate security misconfigurations

The good news is that similar to identifying known vulnerabilities, detecting misconfigurations is relatively easy, provided you rely on a code-based approach to configure your systems.

When your configurations are defined in IaC, you can automatically scan that code to catch risks. Ideally, you’ll proactively scan the templates that you use as the basis for defining configurations as well as the actual “live” configurations that exist on your systems after they have been provisioned. This approach makes it easy to detect a wide range of misconfigurations, ranging from overly permissive IAM rules and failure to encrypt data to risks associated with logging settings.

Security misconfigurations may not receive as much attention from the media as security vulnerabilities, but they pose a serious threat nonetheless, especially given the vast scale and complexity of modern environments and the part they can play in complex, chained attacks.

To avoid these risks, you must systematically and continuously scan your configurations for risks. By detecting misconfigurations as soon as they emerge, you can remediate them before attackers use them to launch exploits.