Encryption! When/Why not?
I was recently asked about the reasons for not encrypting data, I was honestly a little confused by the question, isn’t the best guidance always encrypt at rest, and always use the best/algorithm you can, remembering to resist the decision on a timely basis, or when some thing changes, (No mention of Quantum here, not today please…).
At least with a cloud first approach, some of this issue / challenge is shared with the cloud provider! (No one mention, shared responsibility model, just yet.
Protect/Detect/respond.
With the above in mind, if you don’t encrypt your data, and if you miss a path to your data, and the bad actor finds/uses that path, they your data is gone.
The back-up of the service is an example of a potential path to your data, but there are countless others when you think about it, service principals, managed identities are but a couple, what about user level access, read?
How / When would you detect the exfiltration of the data, when it’s gone it’s gone, while encryption doesn’t protect against every risk, it limits what the bad actor can do, and delays or prevents them from getting to the readable version of the data.
I believe the worlds standard guidance is “ALWAYS” encrypt your data, always examine protections you have deployed, follow the vendors patching and current guidance for keeping the service secure, always do penetration testing/red teaming of the service, examine the service for weaknesses, both technical, process and people. Things can always be improved.
My personal guidance would be “always encrypt data at rest” always using encryption between your service components and certainly where you can use networking routing controls to offer some protection of the endpoints, limiting what is exposed to where’s and who. Follow the process of least access, trust but verify explicitly between the service tiers. It is a never ending “game” keeping your data secure from bad actors, and from misconfigurations! CI/CD can help, update configurations quickly at scale, but needs careful checking, and security through it’s supply chain, please be aware of the Defender for DevOps, and Managed identity protections available by various vendors to reduce the risk of abuse of those privileged devices and accounts.
PAW/DAD (Privileged access workstations, dedicated admin devices) please separate out administrative use cases especially for sensitive systems from standard user access/needs. – -Limit the blast radius or impact of badly implemented controls.
A suggested approach. A risk managed approach would be to list out the types of risks your project/environment/organisation is up against and to define standards (building blocks if you prefer) of common architecture standards your teams will use/consume and create.
I’ve heard a number of arguments that security delays delivery, and production value, but in these challenging times, what is the cost of a data breach or miss configured service?
It needs to balance governance and control
Perhaps the question should be “how’s encryption should you trust?” Maybe that’s a different post later.
Please encrypt your data, please pen-test/red team your environments, please check your security teams have the playbooks/automation to secure your environment as soon as they know there are concerns, make it difficult for the bad actors to get to your information.
If you’ve enjoyed this posts, or even if you haven’t please consider dropping me a X (Tweet) – IM or email, I’d love to hear what you hated, enjoyed or what you are looking at achieving going forward.
Making the World a more secure and resilient place, one deployment/project at a time.
Links I hope help with the above. (Correct at the time of writing)
Shared responsibility Models
3rd Party links
NiST
NCSC (National Computer security Center UK)