'Shifting Left': It’s Time to Put Encryption at the Heart of Your DevSecOps Strategy

Introduction

The concept of "shifting security left"—integrating security early and continuously into the Software Development Life Cycle (SDLC)—has gained significant traction. It's an idea that security professionals like Jim Ivers have been talking about since 2017. This approach, often called DevSecOps, embodies the essence of proactive security. Quicker and more consistent security at scale has been the primary driver for DevSecOps, and more recently, Privacy Engineering and Compliance by Design are getting in on the act. Empowering developers to recognize the value of the information they are processing and equipping them with "pre-secured" processes and tools reduces friction and integrates requirements for preventive, detective, and corrective controls at the outset. This also generates audit evidence. Well-understood concepts include:

• Use of predefined secure builds
• Zero downtime patching and vulnerability management
• Automated code review, dependency analysis, and vulnerability scanning
• Automated deployments

One essential component of any strong security and compliance program is encryption. However, encryption is often overlooked in the initial stages of development. This article explores the crucial role of encryption in the "Shift Left" paradigm and provides guidance on including encryption as a security pillar in your DevSecOps model.

The Importance of Early Encryption

Encryption is the bedrock of secure data exchange and storage, safeguarding sensitive data from unauthorized access. Despite its importance, encryption is often retrofitted late in the development process or tick-boxed by enabling data encryption at rest. In many cases, this only mitigates the risk of physical data theft, which in a distributed cloud environment is an almost negligible risk. Why is this? It's because it often takes effort upfront to get it right. To implement field-level encryption of data in the cloud, we need to consider a host of things, including:

• Identify sensitive data: Know what data needs to be encrypted based on its sensitivity, value, and nature and whether it is subject to compliance or retention requirements.
• Clearly understand how the data will be used and where it needs to flow: Will the encrypted data be required for reporting, queries, and sharing with third-parties or restricted to individual roles and processes?
• Implement strong access, authentication, and authorization controls: How will you limit access to authorized individuals or processes only?
• Architectures and tools: What is the best approach? Should you roll your own architecture using approved algorithms and protocols or use a service provider to relieve much of the complexity?
• Key Management: How do you adequately segregate the decryption keys and encrypted data? What should your key lifecycle look like?
• Consider performance impact: How do I determine the effect on performance when moving from plaintext to encrypted data processing?
• Ensure regulatory compliance: Does the approach satisfy GDPR, HIPAA, or PCI DSS needs?
• Align backup and recovery strategy: Backups should also be encrypted, and you should be able to decrypt them during recovery; how does this figure into your encryption plans?
• Incident Response: What will our Incident Response and Disaster Recovery plans look like once we have encryption in place?

These are just some of the considerations involved in deploying field-level encryption, hence why early-stage companies often consider this approach weighty and onerous. Many of these companies will frequently progress development without encryption and "just figure it out later." This catch-up work often never materializes unless prompted by equally heavy regulatory compliance obligations. In these cases, when a breach occurs, the company is exposed to GDPR-related fines, loss of access to card processing networks, and negative media attention. Considering encryption early in the SDLC is the most effective solution. It allows for a more robust, secure, and cost-effective design. Using standardized APIs & Libraries and defining the processes once will allow organizations to apply encryption consistently and, in many cases, build compliance and security as code.

What needs to happen to enable the change?

Education and Training: Building a Security-Conscious Culture

Shifting left involves cultivating a security-oriented mindset in your development team from the get-go. This includes educating developers about secure coding practices and compliance obligations, particularly where to apply encryption. This knowledge empowers them to make more security-conscious and compliance-driven decisions throughout the development process.

Use known Secure Libraries and APIs: Don't Reinvent the Wheel

Using trusted service providers or cryptographic libraries and APIs reduces the risk of high-impact data breaches and non-compliance. By integrating pre-existing, well-tested cryptographic solutions as a standard process, you can leverage the expertise of cryptography professionals and ensure the robustness of your security measures. The option should be well-documented and developer friendly for this to work.

Secure Key Management: Essential from the Start

Secure storage, rotation, and access control of cryptographic keys should be designed into the system from the beginning. Late-stage integration of key management systems can lead to hastily patched-together solutions that are more vulnerable to breaches or, in some cases, a self-inflicted denial of service where encrypted data is no longer available for decryption due to mismanagement of the keys. Access Control as well as Monitoring should be in place covering key access and changes, as well as changes to groups with access to key material, with appropriate alerting.

Code Reviews and Automated Testing: Ensuring Ongoing Security

Including cryptographic implementations in code reviews and automated testing ensures that encryption is correctly implemented and maintained. Code review steps should include an assessment of data flow and where particular fields are subject to regulations and warrant encryption. Without data tagging and classification, they will rely on dev awareness or specifics in the product spec.

Regulatory Compliance: Anticipating Requirements

When encryption is part of the initial design, meeting regulatory requirements becomes less of a chore. Regulations like GDPR, HIPAA, and PCI-DSS have specific encryption requirements that can be seamlessly integrated into your system when considered from the beginning. In the case of the aforementioned regulations, where no cardholder data (CHD), sensitive category personally identifiable information (SC-PII), or electronic protected information (ePHI) is accessible, fines are extremely unlikely, even when data is lost or stolen. It is also worth including security and compliance in the conversations from the product planning stage and appointing champions in the engineering team where possible.

Conclusion

Integrating encryption early in the SDLC is essential in shifting security left. It promotes a proactive security culture, reduces the risks of high-impact data breaches, and can implement regulatory compliance and security as code. As we continue to grapple with the challenges of increasing regulation and a broader, more sophisticated threat landscape, it's certainly worth integrating encryption early into the developer mindset. At Evervault, we pride ourselves on product excellence and exceptional developer experience and abstract much of the complexity typically associated with an encryption implementation project.

We take care of all key management operations, encryption scheme and algorithm management, encryption, and decryption operations. We also have experienced in-house compliance expertise to lead our customers through their compliance challenges and bring them to a compliant-ready state.

Ready to shift left? Talk to one of our engineers about the challenges you and your team are facing, and we'll help you get there.