Cloud security misconfigurations are the #1 incident type in cloud-native applications, according to the Cloud Native Application Security Report 2021 by Snyk. Misconfiguration is also the #1 concern for operations teams when it comes to adopting cloud-native technologies. 

Cloud misconfiguration happens when your settings fail to provide infrastructure and application security for your cloud resources. Often you'll find these misconfigurations occur by accident, by the lack of awareness for cloud security, or by the absence of policies and adequate oversight. 

This can cause a security misconfiguration vulnerability of any sort, from user permissions to unrestricted outbound access. Vulnerabilities open you up for misconfiguration attacks that can compromise your system and breaches that can cost billions of dollars.

This article will go through the most significant problems in security misconfigurations and offer a solution for them. 

Problem #1: Security is not a top priority for developers

One of the biggest challenges when incorporating security in cloud computing is that developers don't really want to think about security. It slows them down since their primary focus is delivering the application. 

With such deadlines and fast go-to-market streamlines, it's no surprise that security gets in the way of releasing. Unfortunately, writing secure code has a high price, and it deprives developers of a great deal of autonomy and expertise they want to have.

It quite often happens that there is a massive gap between developers and security. Security experts are involved quite late in the DevOps process. They only provide reports of vulnerabilities that are urgent to be fixed.

Instead of playing the blame game, companies need to handle security in a way that developers don't have to worry about it. Security vulnerabilities should be presented in a way to help developers fix the issue at hand. See it immediately and understand what to do next to get rid of it. 

Problem #2: Software release first, security second

Another big challenge is that security issues are often found too late in the development process. Typically in staging, but more so in production. After the review process, developers get tickets to fix the security vulnerability issues regarding a feature they were developing weeks before. This causes the need to switch back into that context and out of their current priorities. 

Even if developers discovered the issues earlier, they don't know what they need to do to remove the problem or simply don't have the time because of the pressing deadline to release. 

Problem #3: Cloud-native security

A recent Gartner study predicts that by 2025, more than 99% of cloud breaches will be because of user misconfigurations. With the adoption of cloud-native by more enterprise companies, the expectancies for human errors that will cause breaches to rise considerably. 

Cloud-native applications revolve around automation in almost every part of the development and delivery process. They do this mainly by implementing a CI/CD system that runs numerous builds and deployments per day, which means heavy, dependable workloads. 

Thanks to this automation, today's apps are able to innovate faster and scale more effectively. But with this change come the challenges of securing cloud-native applications. Traditional security models cannot provide the necessary mechanisms to secure infrastructure and apps as code. 

Infrastructure is now part of the application by defining containers and services. So it should be secured as part of the application security. Security tooling and insights should be available throughout the whole software development lifecycle. Things like automated scanning of the source code and security scans of the container images should be part of the process. 

Implementing the "shift-left" approach (security procedures early in the development process) is a common way to cope with the security misconfigurations risk.

Problem #4: Securing containers and Kubernetes 

Extensive cloud misconfiguration issues also affect Kubernetes and Docker containers. Attackers are trying to exploit vulnerabilities to get access to a container. They could also potentially move through the container environment to access other containers and steal sensitive information. They might infect the containers with malicious code that could be packaged into an image and infect others who download that image. 

As for Kubernetes, misconfiguration attacks can be prevented by applying a policy preventing pods from talking to one another. Unfortunately, this policy is not applied by default, so an attacker might compromise a single pod and then communicate with all other pods to get into the organization's data. 

Detecting a possible misconfiguration is not always feasible by manual means. This is why it's best to incorporate security into your DevOps process. Create an automated configuration management policy as code, and use best practices to identify configuration violations.

GitOps as a solution

In its simplest form, GitOps is IaC managed by a Git flow process. If we can treat infrastructure as code, we can apply software development quality assurance practices to cloud infrastructure, just as we do with application code. In addition, we can define and execute automated tests and security tests for cloud infrastructure as well. 

This workflow allows for configuration and security policies to be treated as code, version-controlled in Git. After a change is made, a pull request is created, reviewed, and pushed in the automated pipeline. The pipeline then tests and verifies the code, deploys it, and monitors the changes. 

GitOps is a model that promotes an environment for security. Developers don't need to have direct access to infrastructure or Kubernetes clusters to execute there directly. With GitOps, the CD now applies these changes to the cloud. Developers can propose a change, which can then be reviewed by senior DevOps engineers, QA developers, and security experts. After the checks have passed, then developers can merge the changes into the main branch. 

GitOps can also improve the speed with which modifications to the pipeline can be made. If a pipeline is infiltrated, you can resolve security issues quickly by identifying the pipeline vulnerabilities in the IaC repository. You can find the exact commits that caused the problem, assess the attack's scale, and forecast how much it will take to recover.

The GitOps model also works when implementing "policy as code", which is a way to automate the security process. Policies enable ops teams to define guardrails for infrastructure, from access control and limits to managing how the infrastructure operates. This gives immediate feedback to developers for the security level of what is developed before deploying to the cloud.

If GitOps is adequately implemented, it becomes a successful technique for shifting security further left. Catching security misconfigurations, bugs, and other code quality concerns of any type earlier in the development process.

How Microtica solves it?

Microtica promotes the idea of self-service for developers and control over the infrastructure for operations teams. With the possibility of ready-to-use infrastructure components that experienced ops team members develop, the chance for security misconfigurations is limited. 

When developing these components, a security expert can improve the infrastructure with built-in guardrails, precautions, and limitations, package it and expose it in the self-service catalog for developers to use. Developers can then provision the infrastructure via a template, so there is little room for mistakes or misconfiguration. 

Furthermore, each component and service consists of input and output parameters that need to be configured in a schema JSON file. This makes it possible to verify and validate the parameters before they are applied to the resource, add to an environment or the cluster. 

The same goes for Kubernetes infrastructure and services. Once you secure your infrastructure and Kubernetes services, the loop is closed, and misconfigurations are harder to get through. 

You can also integrate with security tools and embed them in your pipelines to perform security checks, functional testing for the infrastructure. 

By incorporating infrastructure security checks into your pipelines, you can configure Microtica to automatically stop the pipeline if a security or compliance issue is detected. Microtica will then rollback your environment to the previous healthy state that was deployed. 

Conclusion

With the adoption of cloud-native development, the security risks increase proportionally. New approaches and tools also emerge to help resolve these problems. 

Using the GitOps approach, organizations can improve cloud infrastructure security and increase visibility. This reduces the risk of cloud misconfiguration breaches. 

It's important to integrate security checkpoints across the whole software development lifecycle and use platforms that enable you in this process.