This content originally appeared on DEV Community 👩💻👨💻 and was authored by Justin Perkins
The Empire’s greatest and most powerful weapon was the Death Star aka the DS-1 Orbital Battle Station. It was the size of a small moon and struck terror across the galaxy as it was a planet destroyer thanks to the large Kyber-crystal powered super laser mounted on it.
This article will be discussing the importance of implementing security early in the continuous integration & continuous delivery pipelines (CI/CD) to mitigate cloud resource misconfigurations from being introduced. The story of the destruction of the Death Star will be used to aid in depicting poor cloud security practices used by the Empire. By implementing scanning of infrastructure, the Empire could have easily defeated the Rebel Alliance.
Thank goodness in this case the Empire had terrible security practices. Spoiler Alert!
Designing the Death Star
Now, this terrifying monstrosity of a battle station started just as any cloud project would. An idea or need was formed. A team was then delegated to turn this vision into a tangible design to be built, deployed, and, unfortunately for Alderaan, used.
Galen Erso was an engineer tasked to design key resources for use on the Death Star. As the Star Wars lore goes the Death Star had a misconfiguration by design. In the build blueprints, a fatal weakness lies within the Death Star in the form of a thermal exhaust port leading directly to the reactor. This critical misconfiguration was not clearly visible to the Empire.
Think of the Death Star architectural blueprint as an Infrastructure as Code (IaC) template using tools such as AWS (Amazon Web Services) CloudFormation or Terraform to build the Death Star’s cloud project.
- The Death Star will represent an AWS EC2 server.
- The Reactor will represent a business-critical application running.
- The Thermal Exhaust Ports will be the attached security groups.
What is Infrastructure as Code (IaC)?
For those who are new or unfamiliar, IaC is a process of provisioning and managing cloud resources through code. To use IaC, a configuration (blueprint) template file needs to be defined that contains instructions for the exact resources and specifications to build and deploy projects. With the building of these IaC templates, many benefits can be achieved such as improved consistency, version control, and faster time to deployment.
What are misconfigurations?
When using a Cloud Service Provider (CSP) such as AWS, tons of different services are offered to select from to create infrastructure that meets a need. These services are each unique and create resources that are configured by the customer. Imagine creating an S3 bucket to store some private information. However, when creating that bucket it is accidentally set to public. This is a misconfiguration. It leaves the resource exposed to risk.
Thermal Exhaust Ports and the Reactor.
As mentioned earlier the Death Star had flaws by design. The example below is an AWS CloudFormation template. In the template code defined is an EC2 server named the “Death Star” with a security group attached called “Thermal Exhaust Ports”.
From a functionality perspective, this template will deploy successfully, so the Empire decides to proceed to build and deployed this monstrosity. However, this lack of security and visibility in the Empire’s CI/CD pipeline would later come back to haunt them when Luke Skywalker exploits this misconfiguration by firing two proton torpedoes into the exhaust ports (Security Groups) that lead directly to the reactor (Running Application). Thus, destroying the once terrifying Death Star.
What is wrong exactly?
The Empire had not yet instilled any security features throughout their CI/CD pipeline to prevent such resource misconfigurations from reaching deployment. In the example above the following misconfigurations went unnoticed:
- Security group ThermalExhaustPorts allows unrestricted access to uncommon ports
When building it is important to check the EC2 security groups for inbound rules that allow unrestricted access (i.e. 0.0.0.0/0 or ::/0) to any uncommon TCP and UDP ports. In addition, restrict access to only those IP addresses that are required to implement the principle of least privilege and reduce the possibility of a breach.
- Security group ThermalExhaustPorts opens range of ports
Ensuring that security groups do not have a wide range of ports open for inbound traffic in EC2 instances can be better protected against attacks such as denial-of-service (DoS) attacks or brute-force attacks. It is recommended to open only specific ports within your security groups, based on your application’s requirements.
The misconfigured Thermal Exhaust Ports (Security Groups) allowed Luke Skywalker to fire proton torpedos (exploit) at the Death Star’s reactor (Critical application) rendering the Death Star useless.
How could this have been prevented?
The Empire could have leveraged a Cloud Security Posture management solution to span their entire development pipeline in three stages. Code, Build, and Deployment.
1. Code — Integrated Development Environment (IDE)
Most developers code on their local machine to start. By integrating a security plugin into the developer’s IDE, immediate feedback can be gained for the IaC developers to leverage. This feedback can be used to fix identified misconfigurations from the scanned template. Scanning IaC templates in the IDE shifts security as far left as possible and helps developers build more secure resources right from the start. Once validated locally the template can be pushed to a code repository for further workflows.
Galen Erso was the developer of these misconfigured resources. Although he planted these misconfigurations purposefully in hopes that the Rebels would have any chance of destroying the Death Star. By integrating an IaC security plugin into his IDE. Erso would have been able to without a doubt identify the misconfigurations.
2. Build — Scanning Templates in CI/CD Pipeline
Once a developer has pushed an IaC template to a code repository such as GitHub or AWS Code Commit. A workflow can subsequently be triggered to automatically build and deploy the defined resources. By integrating an IaC template scan provided by a Cloud Security Posture Management tool, CI/CD pipelines can be improved from a security perspective. Leveraging CSPM APIs (Application Programming Interface) can ensure every IaC template submitted in the pipeline is scanned to adhere to the well-architected framework best practices or some other compliance standard. If it does not, then the build is halted. Results from the scan can be sent to notify both developers and operation teams of any potential security misconfigurations.
The Empire should have had a CI/CD pipeline in place. Erso should have completed his Death Star build designs and pushed the template to a repository. The Empire’s build pipeline should have been fitted with a CSPM’s template scanning capabilities to prevent the introduction of misconfigured resources. The pipeline would have been started once the template was pushed. Erso’s design would have been scanned in this stage. The Thermal Exhaust Ports would have been identified as a misconfiguration. The build would be stopped. Lastly, notification would be sent to the Empire’s Developer and Operations teams for further action.
3. Deployment — Cloud Security Posture Management (CSPM)
A CSPM is a security tool that continuously monitors cloud accounts for recent changes and detects existing misconfigurations in multiple cloud service providers. With a CSPM development and operations teams can address security challenges such as current misconfiguration visibility, assist in adhering to compliance, scheduled cloud risk assessments, and audits, as well accelerate incident response teams.
The Empire would have had a final chance to gain visibility into the Death Star if they integrated a CSPM tool. The CSPM would have been capable of periodically scanning the Death Star as well to ascertain any misconfigured resources that may already exist. In addition, imagine if the Death Star was initially built without any misconfigurations and deployed. If Galen Erso or anyone made any changes to the Death Star’s configuration state a CSPM with real-time monitoring capabilities would identify that immediately. Then the Operations team would be notified immediately for further action.
Conclusion
Leveraging Infrastructure as Code whether Terraform or CloudFormation has many benefits when it comes to managing cloud resources. However, it is important as a CSP customer to ensure the proper configuration of each resource deployed. If the Empire had integrated security in any of the last two stages mentioned in this article — CI/CD (build) or continuously monitoring deployed resources(deployment), the Rebel Alliance would have been crushed easily. In the examples above the Empire ignored simple security practices that later Luke Skywalker exploited. Do not be like the Empire, integrate security as far left and throughout the development pipeline. May the force be with you.
This content originally appeared on DEV Community 👩💻👨💻 and was authored by Justin Perkins
Justin Perkins | Sciencx (2022-11-04T19:20:00+00:00) Fall of the Death Star — Why Scanning Infrastructure as Code Matters. Retrieved from https://www.scien.cx/2022/11/04/fall-of-the-death-star-why-scanning-infrastructure-as-code-matters/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.