How ‘Continuous Security’ Can Solve the Cloud Protection Conundrum
GitLab sponsored this post.
Cloud security breaches have dominated the news headlines over the last several years. What’s surprising is that almost every one of these breaches were due to a simple cloud setting that was misconfigured or too basic, and usually, avoidable application vulnerabilities.
That said, DevOps teams have their work cut out for them. Managing a vast number of policies, roles and interconnections between various cloud objects (EC2, S3, RDS, etc.) and users are, needless to say, a challenge to manage. In addition, these configurations involve interactions from multiple teams within the enterprise creating the potential for even more complexity.
Compounding the problem further is how application vulnerability detection poses challenges due to the polyglot nature of today’s applications running in the cloud. Detection is harder across multiple languages and different code libraries due to the rapid rate of updates and hence the introduction of vulnerabilities.
Hence, with billions of customer accounts and data records already exposed over the internet, it’s time to take a step back to assess the misconfigurations and vulnerabilities and rethink our approach to ensure that our cloud posture is secure.
Now, here is the good news: most misconfigurations and application vulnerabilities can be prevented with good hygiene and detected with the proper tools. However, risk identification and remediation are generally done during the pre- and post-deployment cycle of a service or app. This is the norm and, unfortunately, the process usually detects misconfigurations during deployment stages once it’s too late. Identification of these risks is hard but identification during deployment stages is especially necessary.
With the proper tools and best practices, DevOps are increasingly discovering how the concept of continuous security can serve what has been lacking in cloud security.
As a way to build security checks into the CI/CD pipeline, continuous security is also a subset of continuous verification.
Continuous Security gives the DevOps and SecOps teams a precise location to inject themselves into the development and deployment process without involving the developers. It provides an additional check they can analyze and act on to improve overall application and cloud security.
To understand the concept of continuous security better, let’s carefully look at some risks and possible solutions.
Resource Misconfiguration Risks
The underlying structure of public clouds is reasonably secure, while cloud providers continue to use new technologies, such as AI, to prevent breaches, and are thus arguably more secure than private data centers are. However, unfortunately, it’s end users’ resource misconfigurations that are very often the source of breaches and data leaks.
Apart from using firewall solutions, configuring other resources like Security groups (AWS) and route tables become critical. For data storage related resources like RDS, S3 or SQL, encryption and public access of these resources must be controlled.
Configuration-related breaches can result in two main kinds of security threats: data breach and compute Sprawl. Data breach involves loss of critical data. An example of a data breach and how to prevent it is described in “How to Detect and Prevent Data Breaches in AWS.” Compute sprawl ( or compute jacking) involves extensive deployment of compute instances to use it for bitcoin mining or other activities without the knowledge of the account owner.
To avoid these risks, we begin by validating the configuration and existing state of infrastructures for any security holes is important prior to deploying the application. Checks for specific misconfigurations, potentially leading to data breaches, should be added into a deployment state, such as a GitLab pipeline as a stage. You can verify this by deploying your resources in a staging environment and then use cloud security tool APIs to identify misconfigurations.
Some of the tools you may use for checks are Cloud Custodian (OpenSource), VMWare Secure State (Commercial) and even AWS Config.
Application Vulnerabilities
With many projects using software packages and libraries, you need to know whether the packages you’re adding are safe. Organizations want to verify if there are any packages used within your application that can be exploited. The application analysis needs to be completed at various levels including but not limited to static code analysis, dynamic code analysis, package dependency analysis and image scanning for containers and VMs. We describe how Gitlab can help with image scanning in our post “What did your developer violate today?”
Some of these checks are available out of the box with Gitlab CI, while for others, you might have to integrate with open source projects, such as Clair.
All the checks above should be performed by using a security policy that looks for a set of acceptable configurations, which when violated, can be used to alert the user of a possible exposure to a breach. Designing an effective policy is usually an iterative process that is focused on providing developers the flexibility to leverage cloud infrastructure, while also allowing SecOps teams to maintain points of enforcement.
By properly adding the right misconfiguration and application vulnerability checks into the CI/CD pipeline, you have begun the process to achieve continuous security.
Continuous Security: A Framework
Minimizing overall exposure and preventing data loss and security intrusion on the public cloud is an ongoing process. The rate of change in AWS, Azure and Google Cloud dictated a constant feedback loop from different parts of the operational pipeline. As we outlined above, it’s also important to add checks into the CI/CD process for misconfiguration risks. This “shift left” of security checks along with good hygiene of checking for application vulnerabilities significantly reduces the risk of breaches and data loss. This combination provides a truly comprehensive framework — continuous security — that serve as a solid foundation.
Implementing continuous security is also a multiteam effort. It requires “policies” from security operations team that is implemented by the DevOps teams. Hopefully, continuous security and concepts outlined above will provide the baseline to facilitate risk reduction of security breaches and data loss for the industry to follow, while news reports of major breaches and vulnerabilities will become very rare, indeed.
For more case study discussions on infrastructure best practices, attend GitLab Commit London Oct. 9. GitLab’s inaugural user event will showcase the power of DevOps in action through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development lifecycle, and more.
VMware is a sponsor of The New Stack.
Feature image via Pixabay.
