Why True End-To-End Encryption is Important for Distributed Apps

If you’re in the world of DevOps, then you are aware that compliance won't succeed in an organization that isn't building secure and compliant code—which includes end-to-end encryption (E2EE) functions—into their DevOps practices. Rather than treat PCI-DSS compliance or other regulations that require E2EE as an afterthought or a burden, InfoSec, IT Ops, and developers should embrace the challenge of E2EE and address it head-on. The evidence suggests that when implemented correctly, DevSecOps can actually improve security and make compliance goals easier to achieve.

But, how are teams supposed to scale up and automate the provisioning of SSL/TLS certificates to ensure that true end-to-end encryption is implemented in distributed applications? And, and why is this important?

The Case for End-to-End Encryption

Today, most organizations still rely on load balancers and web application firewalls (WAF) to protect the communications within their applications. This means dozens, if not scores, of different machine-to-machine connections need to work together to deliver a given service or application to an end user. Considering that sophisticated attackers can penetrate the outer layers of protection and then pivot to gain access to clear text data, terminating HTTPS at the edge is no longer sufficient.

In the age of distributed applications deployed in dynamic production environments, organizations need to improve security posture by not only protecting the edge—with load balancers and WAF—but also consistently securing all inter-service communications deep within applications.

End-to-End Encryption and the PCI-DSS Standard

The Payment Card Industry Data Security Standard (PCI DSS) is a technical standard aimed at protecting debit and credit card details, also referred to as cardholder data. For anyone just learning about PCI-DSS, here’s a quick primer. The objective of the PCI-DSS standard is to prevent payment card fraud, by securing cardholder data within those organizations that accept card payments or are involved in the handling of cardholder data.

Many organizations point to the PCI-DSS standard 4.1 as their guidance for encryption of cardholder data. Requirement 4.1 states, “Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.” One would conclude that it would be sufficient to terminate HTTPS at the load balancer or web server so that all communications open public networks between a user’s browser and the web application are authenticated and encrypted, right? Perhaps yes. But, perhaps not.

Digging deeper into PCI-DSS standard, requirement 6.5.4 states, “verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.” What’s interesting here is that this guidance does not specifically state that these sensitive communications need to be encrypted only if they occur over public networks. So, what does this mean in a world where distributed applications handling cardholder data run in dynamic production environments in the cloud and are packaged using containers running microservices?

A strong emerging argument is that PCI-DSS requirement 6.5.4 suggests that all machine-to-machine communications should be encrypted, which means that SSL/TLS certificates (also known as X.509) need to be used to encrypt all internal (and external) application communications, not just those communications going over open, public networks. Applications built using DevOps workflows are no exception.

Solutions for Implementing End-to-end Encryption in DevOps

Open source and security vendors have started to tackle this problem, especially with regard to the modern, distributed applications frequently used in DevOps practices.

• Istio, an open source independent service mesh, is working to support true end-to-end encryption.

• Jetstack, a UK-based company has created cert-manager, an open source certificate management controller for Kubernetes that helps issue certificates from Let’s Encrypt, HashiCorp Vault, and other sources via plugins. Cert-manager automates the management of key and certificate life cycle for Kubernetes workloads, ingress and egress controllers.

• Venafi is actively working with Jetstack to integrate with cert-manager. Using the power of the Venafi Platform, Jetstack will achieve another industry first: enabling security administrators to validate and audit the current state of certificates used in Kubernetes.

DevOps is not just a philosophy or a technological approach. It can be a way to get security and compliance and availability “baked in” to the application from its very inception. When we realize that the DevOps tactics that address compliance issues are actually the same as those that are applied to development from the start, solutions start to prevent themselves. For enterprises to improve their security posture, achieve compliance and do so at the speed at which DevOps runs, they should programmatically automate key and certificate orchestration from within DevOps toolchains. This means both in planning as well as build phases, whether teams are using Kubernetes, Chef, HashiCorp Terraform and Vault, or other tools.

Given that DevOps teams are already using automated, programmatic tools to instantiate software-defined infrastructure from within their CI/CD pipelines, adding one more programmatic component for standardizing and automating certificate issuance and provisioning is clearly a smart, scalable, logical next step to improving security and compliance for distributed applications.