Tech Misconfigurations vs. Vulnerabilities: How Different Are They?
By Aaron Ansari
As a DevOps professional working on a public cloud project, “Sri” is responsible for building, configuring, and deploying the environments her team needs to build, creating test environments, activating key services, and applying relevant data.
Traditionally, her role would focus on development and application building, not on setting up an environment as an infrastructure administrator. Given the convenience and speed of the public clouds today, Sri can now serve both roles.
But assigning a DevOps resource to build, configure, and maintain the environment can lead to threats like vulnerabilities and misconfigurations—and both types of threat pose serious risk to your organization. Putting together the right mix of resources, both human and technological, is paramount to reduce the risk.
Vulnerabilities and Misconfigurations
A vulnerability is anything an attacker can exploit to access an application or environment. If Sri had spun up the environment and had an outdated web hosting framework acting as the front end or loaded the data with an unpatched version of the software or container, this would be a vulnerability.
A misconfiguration is anything incorrectly set up in a system or environment. If Sri encrypts the database and storage containers but does not follow company policy to do so when spinning up a cloud-hosted application, she has misconfigured the environment. Her build doesn’t necessarily require a fix, as a vulnerability would, but the way she built the system exposes it to risk: with the “front door” left open, an attacker would have an easier opportunity to access the data and environment without needing to exploit a vulnerability.
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.
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.
Breaches caused by misconfigurations have resulted in hundreds of thousands of exposed records. In 2020, misconfigurations caused 10% of all breaches, according to Verizon’s Data Breach Investigation Report, and more than 39% of web applications were breached in this manner. Misconfigurations will cause 99% of all firewall breaches through 2023, according to Gartner.
Suppose Sri briefly populated her environment with production customer data that she tested and then deleted, but she didn’t build out her environment with the option to encrypt and protect it, as that would have added time and expense. Even during the few hours she had the environment exposed, an attacker could have found and accessed the exposed data. And if no one checked any logs (or even knew to check them), the breach might never come to light. This could cause serious harm to businesses, damaging their infrastructure and reputation, and compromise the data of employees, vendors, and consumers.
At Trend, we’ve seen this scenario play out many times. The Privacy Rights Clearing House, tracking breaches since 2005, is a repository full of organizations no longer in business due to a breach. A breach costs the average company $1.5 million, according to a Ponemon study, and organizations that suffer breaches are unlikely to remain in business by the following financial year.
Avoiding Risk
Many DevOps teams, keeping their focus on building their organizations’ environments, choose not to enable their cloud providers’ or other third-party tools to configure and secure these environments: a traditional responsibility of the site reliability engineer or infrastructure manager. But when an infrastructure team does not know the configuration it needs for building the app environment, a DevOps team might configure the environment in the way it believes the application will best perform.
Despite these challenges, a properly built and resourced configuration is vital to decreasing the likelihood of misconfigurations and breaches. Even small steps can have a large impact. Here are five ways to prevent misconfigurations and vulnerabilities:
- Check the “encrypt this storage” function as an IT security team member. This option is always available during the creation and running of an environment.
- Enable logging and always review the logs. Having alerts reviewed by either a machine or human process is fundamental.
- Automate only the good processes. Whatever you are doing well, and repeatedly, automate it to promote efficiency.
- Shift left—at the beginning of the pipeline, look for violations and vulnerabilities. Then have your DevOps teams own their code and securely maintain it.
- Do frequent releases—patch and fix as soon as possible and automate where you can.
Organizations must be vigilant in taking steps to avoid misconfigurations and vulnerabilities and the risks they pose. They share a responsibility with their cloud provider, internal teams, and partners to ensure the environment is as secure and correctly configured. But no organization grappling with misconfiguration or vulnerabilities is alone. With the right resources and team support, the risk of these threats can decrease and become easier to avoid.
See how Trend Micro can help your organization minimize the risk associated with misconfigurations and vulnerabilities.
Aaron Ansari is Vice President of Cloud Security at Trend Micro.