Cryptography, encryption, and key management systems are critical components of any secure cloud environment. But like any complex system, they require ongoing maintenance and occasional changes. The Encryption Change Cost Benefit Analysis control ensures that any proposed modifications to these systems are carefully evaluated to fully understand the downstream impact, residual risk, and return on investment before being implemented.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here. The matrix provides a comprehensive set of controls designed to help organizations assess the security posture of cloud providers and guide internal security policy development.

For more background on AWS encryption and key management best practices, check out the AWS Key Management Service Best Practices whitepaper.

Who should care?

This control is particularly relevant for:

• Security architects designing encryption and key management systems
• Risk managers assessing the impact of system changes
• Finance managers approving security budgets
• Compliance officers ensuring due diligence processes are followed

What is the risk?

Poorly planned changes to critical security systems can introduce vulnerabilities, break dependent applications, incur unexpected costs, and ultimately put sensitive data at risk.

Some specific risks that this control aims to mitigate:

• Upgrading to a new encryption algorithm that is not backwards compatible, preventing decryption of legacy data
• Changing key rotation schedules without understanding the performance impact on key management infrastructure
• Revising encryption policies without considering the user experience impact on productivity
• Failing to account for the engineering effort required to modify all affected applications

While incidents are relatively rare, the consequences of an encryption change going sideways can be severe - ranging from application downtime to catastrophic data breaches.

What's the care factor?

For most organizations, the care factor for this control should be high. Encryption is foundational to data security and privacy. Any changes need to be made very carefully.

However, the level of effort invested in cost/benefit analysis should be commensurate with the criticality of the systems and data being protected. A small change to a non-production environment probably doesn't warrant extensive financial modeling. Conversely, changes to the key management system securing your core intellectual property absolutely require thorough analysis.

When is it relevant?

This control should kick in any time a change to cryptography, encryption or key management systems is proposed. This could include both major architectural changes and minor policy tweaks.

Examples of situations that would trigger this control:

• Enabling a new encryption option for an S3 bucket
• Updating your application to use the latest cipher suite recommendations
• Revising your organizational policy on acceptable key lengths
• Re-deploying your key management system in a new region

This control is less relevant for net-new deployments, where you're building something from scratch rather than changing existing systems. However, forward-looking cost/benefit analysis is still a good idea to maximize your security return on investment.

What are the trade offs?

Conducting a thorough cost/benefit analysis for every encryption change consumes time and resources that could be invested elsewhere. Particularly for small, low-risk changes, the juice may not be worth the squeeze.

Some organizations may be tempted to rubber stamp analyses or skip this control entirely in the interest of agility. That's a dangerous game. If something goes wrong, the "we didn't have time to do the full analysis" excuse won't fly.

The key is striking the right balance. Tailor the level of rigor in your analysis to the magnitude of the change and the importance of the systems/data involved. A little planning goes a long way.

How to make it happen?

Implementing this control in a AWS environment might look something like this:

1. Define the change: Document exactly what cryptography, encryption or key management component is being changed. Be specific (e.g. "Rotating the DEK securing mysensitivedata S3 bucket").
2. Determine scope: Identify all systems and data flows that depend on or interact with the component being changed. For an S3 bucket encryption change, this might include cataloging all applications that read/write data to that bucket.
3. Assess technical impact: For each in-scope system, determine what updates will be required to accommodate the change. Will application code need to be modified? Are there compatibility issues to resolve? Don't forget to consider performance implications.
4. Assess risk impact: Analyze how the proposed change could affect your risk posture, both positively and negatively. Will it close gaps or introduce new ones? How will it impact your compliance posture?
5. Develop cost estimates: Based on the technical assessment, estimate the engineering effort required to implement the change across all impacted systems. Factor in planning, code changes, testing, and change management. Don't lowball it.
6. Quantify benefits: Articulate the security benefits of the change in concrete terms. Will it reduce the likelihood of a breach? Shrink the blast radius if one occurs? How much? Engage experts to develop credible impact estimates to inform your ROI calculation.
7. Calculate ROI: Compute the return on investment by comparing costs to benefits. Include security, compliance, productivity, and any other relevant factors. Use sensitivity analysis to model best, worst, and likely case scenarios.
8. Make a go/no-go decision: Based on the analysis, determine whether the change is justified. If the benefits outweigh the costs, proceed. If not, table it and move on. Be objective and err on the side of caution.
9. Implement the change: Follow best practices for change management, including rigorous testing and staged rollouts. Have a rollback plan ready. Murphy's law applies.
10. Measure results: Six months post-change, circle back and compare actual to projected costs and benefits. If there are significant deltas, dig in to understand why. Feed lessons learned into future analyses.

What are some gotchas?

• Ensure you have permissions to access all relevant cost data to inform your analysis. For AWS, this might require access to Cost Explorer (ce:*), CloudTrail logging config (cloudtrail:GetTrailStatus) or Cost and Usage Reports (cur:*).
• Beware of hidden costs like indirect productivity losses. If the change degrades performance, factor the business impact into your analysis. See the AWS whitepaper on Measuring the Business Value of Amazon S3.
• Don't shortcut the analysis for "minor" changes. Even a seemingly small tweak can have far-reaching impacts in complex environments. See the CloudTrail event reference docs for ideas on automating change detection.
• Engage compliance early, especially for changes involving regulated data. The compliance implications (both positive and negative) need to be well understood and documented.

What are the alternatives?

In some cases, encryption changes can be avoided altogether through compensating controls such as:

• Implementing strong access control and monitoring for sensitive data stores, reducing the need for encryption changes. See the AWS S3 security best practices.
• Isolating sensitive workloads, minimizing the blast radius of encryption issues. Consider using AWS Nitro Enclaves.
• Improving detection capabilities to reduce time-to-remediation if an incident does occur. See the AWS Security Hub best practices.

However, these are complements to, not substitutes for, a robust encryption change management program. Don't skimp on this control - the downside is just too high.

Explore further

• NIST SP 800-57, Recommendation for Key Management
• AWS Key Management Service Cryptographic Details
• CIS Controls v8 3.11 - Encrypt Sensitive Data in Transit

‍