If you’re in the world of DevOps, then you’re 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, I’d recommend that InfoSec, IT Ops, and developers 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 provisioning of SSL/TLS certificates to ensure that true end-to-end encryption is implemented in distributed applications? And, and why is this important?
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.
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. DevOps teams are no exception.
The open source and security vendors have started to tackle this problem, especially with regard to the modern, distributed applications frequently used in DevOps practices.
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.
To learn more about how Venafi can help support your security initiatives for DevOps, click here.
To trial our DevOps integrations, try our SaaS offering.