Reducing Misconfiguration Risks Through DevOps Best Practices

A seemingly innocent problem, misconfiguration, is actually at the heart of many data breaches and cybercriminal exploits. Sure, hackers go after vulnerabilities such as exposed areas of the attack surface and holes discovered by cyber criminals and shared with their evil masses. 

But IT mistakes are one of the easiest and most exploited routes to network penetration. One simple configuration error can be propagated across thousands of devices that are all set up in the same mistaken way. 

Misconfiguration attacks hit even the most tech savvy firms. Misconfigured Amazon AWS S3 storages buckets have left the data of many enterprises, including Accenture, exposed. And last year a misconfigured server exposed the data of more than 548,000 Microsoft users. 

Misconfiguration Facts and Figures 

Estimates vary, but all experts believe misconfiguration is a huge and often overlooked source of breaches. Here are a few Gartner findings: 

  • Misconfigurations are responsible for 99% of all firewall breaches through the end of 2023, Gartner believes. 
  • Gartner also predicts that through 2025, over 99% of cloud breaches are from misconfigurations or end user error.
  • “80% of cloud breaches are due to customer misconfiguration, mismanaged credentials or insider theft, not cloud provider vulnerabilities,” said Neil Macdonald, Analyst – Gartner. 

The OWASP Take 

The Open Web Application Security Project (OWASP) says that security misconfiguration is one of the top ten security issues. Here are some common mistakes: 

  • “Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.
  • Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges).
  • Default accounts and their passwords are still enabled and unchanged.
  • Error handling reveals stack traces or other overly informative error messages to users.
  • For upgraded systems, the latest security features are disabled or not configured securely.
  • The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values.
  • The server does not send security headers or directives, or they are not set to secure values.
  • The software is out of date or vulnerable.” 

Four Common Configuration Errors 

Identity and Access Privileges Set Too Loose 

Least Privilege Access is the idea that people should only have access to what they absolutely need and only when they need it. Failure to configure access control policies properly results in hackers stealing your data and makes elevation of privileged attacks all the more dangerous. 

Using Default Credentials 

Did you know that using default credentials isn’t just an end user problem, but that IT itself often takes this dangerous shortcut? Sometimes it is a simple error such as installing new hardware or software and forgetting to change the default password. Other times admins don’t realize how easy it is for hackers to find the default passwords and crack the system.  

Misconfigured Storage  

We already mentioned problems with misconfigured AWS S3 buckets. All storage systems can be vulnerable to misconfiguration. Sometimes this is related to access controls, but could also include mislabeled data, making confidential data appear public. A lack of encryption and authentication controls is also a concern. 

Failure to Monitor and Log 

If your IT team is not monitoring your enterprise network and applications and logging the results, misconfigurations and the resulting attacks can go unnoticed. 

What is Misconfiguration and Why is it so Dangerous? 

The Harvard Business Review (HBR) in its article Tech Misconfigurations vs. Vulnerabilities: How Different are They? tackled the misconfiguration issue.  

“A misconfiguration is anything incorrectly set up in a system or environment,” HBR explained. “Cybercriminals are like any burglars: they use different methods of entry. With a misconfiguration, they would go right through the open front door. In the case of a vulnerability, they would need to pick the lock. Either way, they will gain entry.” 

Unlike vulnerabilities, IT can’t patch away a misconfiguration. “The difference between a misconfiguration and a vulnerability is one of malice, or its absence. A misconfiguration doesn’t require a patch as a remedy, the way a vulnerability does, just as an open door used by a burglar doesn’t need to be replaced, while a door broken into by a burglar would. While both threats can result in exploits and exposures, misconfigurations are incorrect settings made by the environment’s creator, not flaws in the system or code,” HBR concluded. 

How DevOps (and DevSecOps) Help Eliminate Misconfigurations 

DevOps is a way to develop, deliver and iterate software faster and more securely. “DevOps is about building high-velocity organizations. Everyone who practices DevOps is doing it to create these types of companies. DevOps is born from the experiences of its practitioners. Although many people assume that the original DevOps practitioners were web innovators, that’s not necessarily true. What does matter is that DevOps practitioners are always honing their skills and looking for ways to improve,” argued the Embrace DevOps eBook. 

DevOps can address misconfigurations by turning configurations into code. Once a configuration is proven, it is applied uniformly across all relevant targets. 

Infrastructure as Code (IaC): The Configuration Management Answer 

Configuration management is one area where IaC shines. For instance, setting up multiple virtual machines requires proper configuration — loading them with the right software and providing proper permissions. But how can you manage infrastructure when the number of machines you’re responsible for changes daily? The only way to eliminate this disruptive churn is to implement a policy as code-based automation solution that keeps environments consistent. 

With IaC, DevSecOps teams create pipelines that can cross both internal and external boundaries, standardizing environments and processes locally within the data center and up in the cloud. As a result, you get a dynamic environment that’s stable no matter how complicated your configurations are. When your application deployment and infrastructure changes move at the same pace, your entire IT organization functions better. 

Environmental configurations are foundational to application and business success. A  DevSecOps team that turns configuration into code can leverage the same tools and processes they use on applications to efficiently and successfully prepare environments to run applications. 

With IaC, DevOps can: 

  • Configure systems based on defined business policies 
  • Test systems and validate states across environments
  • Patch and remediate vulnerable systems 

Learn More About DevOps and Configuration 

Watch our on-demand webinar 5 Best Practices for Mitigating Configuration Risks for DevOps and explore best practices to mitigate configuration risks to dramatically improve your security posture. Our technical experts will dive into the following topics:  

  • Understanding how security misconfigurations can affect your organization.
  • Assessing your applications' compliance with security and governance policies before pushing changes to build and release pipelines.
  • Scanning and reporting on any system, regardless of how it was configured.
  • Balancing the need for speed while meeting security and compliance requirements. 
Watch now and learn on how to mitigate configuration risks in DevOps. Discover the best practices for effectively addressing security misconfigurations and raising the bar on compliance.  

Helpful Links 




Doug Barney

Doug Barney was the founding editor of Redmond Magazine, Redmond Channel Partner, Redmond Developer News and Virtualization Review. Doug also served as Executive Editor of Network World, Editor in Chief of AmigaWorld, and Editor in Chief of Network Computing.