CSA CCM DSP-07
Data Protection by Design and Default

Data protection and privacy should be baked into systems and products from the very beginning. Security can't be an afterthought - it needs to be a core design principle throughout the entire development lifecycle. Clear documentation on how data is safeguarded is a must.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full Cloud Controls Matrix here to dive into all the details. The CCM provides a comprehensive set of cloud security best practices. For more background, check out the CSA Security Guidance v4.0 and the OWASP Security by Design Principles.

Who should care?

This one is crucial for:

  • Software architects designing cloud-based systems
  • Developers building products that handle user data
  • Product managers defining requirements and roadmaps
  • CISOs responsible for an org's overall security posture
  • Compliance officers making sure regs like GDPR are met

What is the risk?

Failing to proactively address security and privacy can lead to:

  • Data breaches exposing sensitive user info
  • Regulatory fines for non-compliance (think GDPR, HIPAA, etc)
  • Reputational damage and loss of customer trust
  • Expensive and time-consuming redesigns/refactoring later

While security by design can't eliminate these risks entirely, it can go a long way in reducing their likelihood and impact. Finding and fixing flaws early is far cheaper than after a system is built.

What's the care factor?

For any cloud service or product touching user data, protecting that data needs to be priority #1. In today's threat landscape, it's not a matter of if but when you'll face an attack. Proactivity is key.

Plus, more regulations are making security by design mandatory, not just a nice-to-have. The GDPR, for example, requires data protection by design and by default. The consequences of non-compliance can be severe.

When is it relevant?

Security by design should be the default for any new system or product development. It's most effective when started at the very beginning of a project. Trying to retroactively add security to an existing system is painful.

That said, don't let perfect be the enemy of good. For legacy systems, an incremental approach to improve security is still worthwhile. Just biting off small pieces at a time is far better than doing nothing.

What are the trade-offs?

Proper security by design does require time and effort. It's an investment. Sometimes there can be tensions between security and usability or speed to market. Certain security measures like MFA can add a bit of friction to UX.

However, this is all about striking the right balance. The costs of a breach or regulatory penalty will pretty much always outweigh the costs of building security in from the start. And there are often ways to design elegantly secure user experiences with a little creativity.

How to make it happen?

Here's a checklist of to-do's:

  1. Train developers on secure coding best practices
  2. Use trusted, vetted libraries and frameworks
  3. Leverage secure defaults in cloud platforms (e.g. no public S3 buckets)
  4. Classify data and apply controls accordingly
  5. Encrypt sensitive data at rest and in transit
  6. Implement least privilege access control
  7. Use multi-factor authentication everywhere
  8. Perform threat modeling and risk assessments
  9. Test, test, test! Pen testing, code review, bug bashes
  10. Produce clear security documentation for every system
  11. Have an incident response plan for when the you-know-what hits the fan

What are some gotchas?

A few things to watch out for:

  • Developers will need AWS IAM permissions to implement many security features. For example, to encrypt an S3 bucket, you need s3:PutEncryptionConfiguration access. Work with your friendly neighborhood IAM admin.
  • Don't forget about third-party components and dependencies. Their security is your security. Vet them carefully.
  • Security is a continuous process. One-and-done checks aren't enough. Think regular pen tests, code scans, access reviews, etc.

What are the alternatives?

Doing nothing is certainly an alternative, just not a very good one! Some orgs try to bolt security on at the end of a dev cycle, but this is far from ideal. Catching bugs and design flaws late is expensive and time-consuming to fix.

If you're strapped for resources, at the very least:

  1. Use reputable, battle-tested components
  2. Configure secure defaults
  3. Encrypt and backup religiously
  4. Follow the principle of least privilege

Explore further

The keys to data protection by design: Make security a requirement from day one, follow best practices, test thoroughly, and never stop improving. Your users and your bottom line will thank you!

Blog

Learn cloud security with our research blog