How Shifting Left Helps Organizations Mitigate Cloud-Native Security Risks

Enterprises have Embraced Containerization. 

The cloud-native ecosystem has steadily grown over the past decade with the promise of faster deployments, cost-efficient infrastructure, and auto-scalability spurring its growth. Businesses are now developing and deploying easily scalable, cost-efficient, and more resilient applications, thus delivering innovative solutions faster and more efficiently.

Built on containers and microservices, cloud-native applications have a myriad of advantages: faster time-to-market, simplified innovation, easier scalability, and reduced risk.

New digital experiences can be developed, deployed, and ‘shipped’ to a customer in days rather than months - the most significant appeal to organizations of all sizes. According to a McKinsey report, companies who adopted cloud platforms have reported that they can bring new capabilities to market about 20 to 40 percent faster.

Cloud-Native Introduced Many Disruptions 

The promise of scale, resilience, and agility have lured many organizations to shift and lift their organizations to cloud and to fully embrace all that is cloud-native. And while the business benefits are many, the cloud-native space comes with it’s set of disruptions and challenges. First and foremost, the traditional approaches of perimeter-based security and security constructs are no longer applicable in this new domain.

Infrastructure Chaos

Companies are now doing tens, hundreds, even thousands of deployments and container builds a day. DevOps and developers are achieving their goals, and products are being shipped to customers faster, but where are the proper preventative security measures implemented? How are organizations securing their cloud-native applications? Are organizations securing their infrastructure against potential threats? Who owns and manages the cloud-native infrastructure?

All the above are fundamental questions and, consequently, challenges to the cloud-native sphere - giving rise to “Infrastructure Chaos”. At the core of this chaos is the major deconstruct of the monolithic applications into microservices.

Although this new modularity has simplified individual applications’ management, the larger and decentralized microservices-based architecture has increased the threat landscape. As such, it has become more challenging to manage, control, and secure this new decentralized infrastructure.

Factors Contributing to the Infrastructure Chaos:

1. Multi-cloud support: Most customers are moving away from being locked into one cloud provider, thus increasing its operations and infra-management complexity. Also, enforcing policies is more complicated now. There is now another control plane on top of all cloud providers or on-prem installations to get the right visibility.
2. Technology proliferation: Every team has its tech stack. Part of the new paradigm is that each team can use the right technologies and tools to solve the problem. Some teams might choose a SQL database, while others might opt for a document-oriented database; these databases might be run by the individual team or managed by the cloud provider. This technology proliferation adds another dimension of complexity and chaos.
3. The challenge here is how to monitor the various technology stacks, continually enforce best practices, and check for vulnerabilities in a sustainable and scalable way across the organization. Furthermore, how does a small team or security or ops gain the expertise required to run these different stacks securely and reliably?
4.  Software supply chain: Any engineer can now introduce a security risk to the entire company, such as 3rd party docker images and open-source libraries. A system is as secure as its weakest link. How can the company keep track of all these changes, maintain an inventory of all the software used, and ensure it is patched and vulnerability-free?
5. Performance Management: Managing performance and cost with such a distributed architecture and multi-cloud setup is chaotic - too many moving parts and a very dynamic environment. A single user-facing feature could require the cooperation of multiple microservices and databases. The question here is: how can the overall cluster performance be monitored and optimized while keeping the cost in check?

Much of this chaos stems from the decentralization and the increased complexity of microservices architecture and the new technology stack. It’s more challenging to manage and securely control things in the new decentralized world.

Security in the DevOps Era

Development speed and agility are the key cornerstones for DevOps teams. With the multiple daily container builds and deployments, it’s no longer feasible to introduce security at the end of the software lifecycle, as per the old waterfall model. The more frequent deployments translate into smaller windows of opportunity to find and fix security vulnerabilities.

In the new microservice-based architecture, both the developer and DevOps can secure or expose their application. Developers can now impact their application’s security in myriad ways: from selected libraries and container-based images to pod configurations in their Kubernetes manifests.

On the other hand, DevOps can make the infrastructure more vulnerable to potential threats by changing the configuration of their Kubernetes clusters and the rest of the lower layers in their cloud infrastructure. The lapse of applying access control or a misconfiguration of a network policy can go unnoticed, leaving mission-critical services exposed.

The “Security” Lines are Blurry

As the shift towards cloud-native took place, a corresponding cultural change also took place in the workplace. It’s not only IT and security professionals with an in-depth knowledge of the security process who touch the cloud infrastructure, now both developers and DevOps team impact the cloud with their changes.

It’s now a commonplace occurrence to see up to 3000 people deploying applications and making structural changes to infrastructure. Factor in continuation integration and deployments, and frequent production deployments, leads to security teams unable to control and secure all that is cloud.

Impact of these Disruptions 

Information security teams are now struggling to secure, govern, and add compliance to all applications - leaving enterprises more vulnerable and exposed to threats. This vulnerability often comes with costly and devastating consequences such as data breaches.

 In the first three quarters of 2020 alone, a staggering 36 billion records were exposed, and 2,935 publicly reported breaches according to Risk Based Security data. According to IDC, 67% of security breaches are due to misconfigurations; in other words, preventable.

In 2018 and 2019, 33.4 billion records were exposed due to security breaches, primarily due to cloud misconfigurations. The average cost per lost record globally is $150 as per the Ponemon Institute, and this means that companies' security breaches are costing companies nearly $5 trillion in monetary losses.

Misconfigurations and security breaches mean that developers, DevOps, and security teams spend more time in firefighting mode, churning time and resources to fix infrastructure and adding the necessary security checks to prevent them from reoccurring.

Then there’s the long-standing adage that security implementations impede DevOps teams’ speed and agility, causing adversarial relationships between the DevOps and Security teams. Ultimately, this friction between the two groups negatively impacts productivity, and subsequently, leads to loss of faith in security. This misalignment creates the possibility that DevOps will not participate fully in the security process or will circumvent security completely.

The Rise of the SecDevOps and the Shift-Left Paradigm 

Historically, the security teams were seen as gatekeepers where security is handled at the tail-end of the software development process, hindering releases and slowing deployments, affecting the overall agility of any organization.

For a more agile, friction-free and secure environment, shifting-left has become essential. By shifting-left, organizations are instilling security measures into the DevOps workflows, not just at the tail-end of the process giving rise to the SecDevOps.

The SecDevOps is much more than injecting the right tools to the security engineers. It involves a cultural shift from the current way of developing, with the whole team adopting a security-first mindset and becoming security practitioners. By using the right workflows, necessary tools - such as security automation, policy enforcement, and remediation tools, - and proper analytics, companies will then start to yield the benefits of SecDevOps.

By instilling security practices into the software development and delivery process, companies will be able to remediate critical vulnerabilities quickly. About 45% of companies with full security integration can remediate critical vulnerabilities within a day whereas those with low-security integration, only 25% can remediate within a day, according to the State of DevOps Report.

Shift Left Now with Magalix

Kubernetes governance, also known as policy-as-code, provides the ability to incorporate security into existing workflows.

Magalix allows you to define and manage these policies, and their lifecycle, in an easy and user-friendly way. Internally, Magalix uses OPA as the policy execution engine. Magalix, by default, will run global policies based on Kubernetes’ best practices for the relevant Kubernetes objects in your cluster.

Also, it will allow you to define custom policies (KubeAdvisor), run these policies periodically against your cluster, and track violations and compliance overtime to report regular updates (via dashboard or through integrations with Slack, etc.). Additionally, Magalix offers webhooks that you can use to pass your object specs, and we’ll run all relevant policies and respond to you with any violations. You’ll find this is a great way to integrate your CI/CD pipeline, and easily prevent policy violations.