July 24, 2023
Fernando Diaz (Resourcely User)
Infrastructure misconfiguration occurs when the underlying infrastructure of an application is not properly configured. Misconfigurations account for a significant percentage of breaches caused primarily by user error. These preventable breaches can cause a great deal of harm to an organization, including fines, legal costs, time wasted responding to the breach, and damaged reputation.
According to CheckPoint's Cloud Security Report [1], over 25% of organizations experienced a cloud security incident last year, citing the primary cause as misconfiguration. Furthermore, the report shows that preventing misconfiguration is the greatest security priority for the majority of organizations.
As more and more developers begin leveraging the cloud for their applications, so grows the potential for cloud misconfiguration.
Some examples of misconfiguration include:
In this blog post, we will cover some of the causes of infrastructure misconfiguration and recent occurrences. Then we will show you how developers can leverage Resourcely to prevent misconfigurations from occurring and enhance their productivity.
The main cause of infrastructure misconfiguration is a lack of knowledge of the proper configuration options to use. Misconfigurations happen so frequently because developers today must not only write code, but also create and manage complex infrastructure. According to CheckPoint's Cloud Security Report [1], the biggest struggle for organizations in protecting cloud workloads is the lack of qualified staff.
Developers must now understand how to configure their infrastructure properly, creating more risk and reducing the time spent on actual application development. Take, for instance, a Terraform module for an AWS S3 bucket. This module has 53 different inputs, each of which can contain numerous possible configuration options [2].
With all this added responsibility and choice overload, it’s easy to make a mistake. A simple misconfiguration deployed at scale can easily become a nightmare and cause widespread security issues across multiple environments!
Let’s go over some recent notable leaks caused by misconfiguration. I’ll cover both the Washington DC Health Link breach and Toyota's recently discovered data leak, which went undetected for over 10 years.
On March 6, 2023, a breach of Washington D.C. Health Link’s customer data was detected [3]. The breach was found in Health Link’s AWS instance for filing reports. In this breach, anyone with knowledge of the IP address of the AWS instance could effortlessly access sensitive personal information from Health Link’s customers.
By exploiting the misconfiguration, hackers were able to get ahold of names, dates of birth, home addresses, social security numbers, and insurance policies for over 56,000+ customers, including several members of Congress. To make things worse, the data was posted on a now-defunct hacker forum providing many malicious actors with the information.
Mandiant, a cybersecurity firm was brought in on March 8, 2023, to find the source of the breach. Within days, Mandiant was able to detect the source of the breach – a misconfigured Jenkins server. The server was configured with anonymous permissions which allowed any user to download files and read logs as long as they knew the Jenkins server IP address.
Developers password-protected the files which could be downloaded thinking they were following best practices, however, the passwords were stored in the logs which anyone could read.
This is a clear example of how not fully understanding configuration options can cause developers to create vulnerable and unnecessarily complex infrastructure. If the Jenkins server was configured correctly from the start, then there would be no need to password-protect every file (which adds the complexity of managing secrets) since permissions would be assigned correctly from the start and users would only be allowed to access what belongs to them.
D.C Health Link offered customers 3 years of credit monitoring. However, several Health Link customers are filing lawsuits due to the breach. The cost of credit monitoring and lawsuits, along with substantial damage to its reputation is a large price to pay for such a preventable issue. Developers have so many responsibilities, which makes human error unavoidable. But, if the server was configured secure-by-default this breach could have been prevented.
In May of 2023, Toyota reported that data from over 2 million customers had been exposed over 10 years [4]. The data exposed in the breach was the in-vehicle GPS navigation terminal ID number, the vehicle chassis number, vehicle location information (including time) as well as videos taken from the car.
Very similar to the Washington D.C. breach mentioned above, the data breach was caused by a cloud misconfiguration. The misconfiguration allowed anyone to obtain vehicle location data from Toyota’s cloud infrastructure. While Toyota did not go into details on the breach, they did issue an apology to those affected.
In this case, Toyota was lucky that there was no Personally Identifiable Information (PII) [5] found in the breach. Regardless, the breach has still caused significant harm to Toyota’s reputation due to the duration of the exposure.
This is yet another example of a breach that could have been easily prevented. While the cloud makes it easy to create infrastructure, we are beginning to learn that it’s not so easy to secure and manage it.
The above brings the following questions to mind, “How can I prevent infrastructure misconfiguration without requiring security reviews for every change?” and “How can I allow developers to focus more on application development and less on managing infrastructure?” The answer is Resourcely.
Resourcely makes it easy to manage infrastructure by removing the need for developers to learn the whole infrastructure catalog along with every possible configuration. Developers can build out infrastructure with ease using secure and conformant resource blueprints which prevent misconfigurations and other security risks.
Blueprints contain resource definitions for many different types of infrastructure (S3 buckets, VPCs, VMs, etc.) for various uses across cloud providers. This makes it easy to create secure infrastructure without the need to understand the vast amount of configuration options.
Guardrails can be applied to blueprints to ensure that best practices are being enforced whenever a resource is created or changed. Infrastructure teams can select what types of restrictions they wish to place on their blueprints which cover security, access control, cost savings, and more. If required you can also apply custom context fields to blueprints for collecting additional information from developers.
Once a blueprint has been configured, a pull request (GitHub) or merge request (GitLab) can be generated directly from Resourcely. These resource generation requests and their owners can be tracked from a single interface, making infrastructure management a breeze!
Once a pull/merge request has been created, a Terraform runner validates the infrastructure resources and integrates with Resourcely to ensure all guardrail requirements are met. If the guardrail check fails, then the request can be blocked and a valid reviewer will automatically be assigned to help approve a policy exception or guide developers back on the right path. Guardrail checks not only prevent misconfigurations but also enable separation of duties by making sure the infrastructure definition is reviewed by another person.
Help developers regain their power and prevent infrastructure configuration today! Checkout resourcely.io and schedule a demo to learn how Resourcely can help you:
References
[1]https://pages.checkpoint.com/2022-cloud-security-report.html
[2]https://registry.terraform.io/modules/terraform-aws-modules/s3-bucket/aws/latest?tab=inputs
[3]https://statescoop.com/mandiant-report-dc-health-link-breach-cloud-server/
[5] https://studentprivacy.ed.gov/content/personally-identifiable-information-pii
