Organizations have spent a lot of time, effort, and money securing their perimeter and transport layers. This is a necessary first step, but insufficient as more needs to be done for data to be really secure from a strong attacker. The problem with an over reliance on perimeter and transport security is that organizations often make compromises on cryptography. These compromises sometimes include not studying best practices before implementing their system, or worse, deploying an approach that they know to be weak. A refrain we often hear is that these weaknesses are okay because there’s an access control layer that prevents the attacker from exploiting the weakness. For instance, “Yes, we put the encryption keys in the production database, but it’s inside the VPN.” or even worse, “No, we don’t encrypt the database, it’s behind the firewall.”

The Golden Rule: When designing cryptography, imagine that a strong attacker can defeat your access control. To prove how valuable this rule is, just imagine yourself telling the story of your systems being hacked in the future.

Bad Outcomes:

“Yes, we deployed a firewall and transport security, but they got root access on the server and then got everything.”

“Yes, we encrypted everything in transit, but it didn’t matter because our keys were compromised and they got everything anyway.”

Much Less Bad Outcomes:

“Yes, the laptop got stolen, but we used full-disk encryption so we’re safe.”

“Yes, we got phished and the PII got leaked, but we used encryption at rest, so all of the data is secure.”

The Adversary

As you are designing your application, you should imagine your attacker as someone who has the patience, skills, and resources to work around your access controls. Keep this perspective in mind when building your encryption approach and align each assumptions with the “therefore” to keep in mind for each case.

• An attacker will get into your network or app somehow, and is going to be able to read all of the data on the network or stored in the system, therefore you must make sure there is no way they can get to the keys on the same network (or at all) so they can’t decrypt the data.
• An attacker can figure out a way to change all the encrypted and plain text data, therefore you must make sure there are digital signatures to catch those changes.
• An attacker will figure out the algorithm you are using and the format of the data, therefore you must follow key management best practices to foil them.

You Need a Secondary Means of Security

Cryptography is there for when access control fails. Assuming a strong attacker means thinking beyond your access control. It might be helpful to imagine the adversary as an insider or controlling a key piece of your infrastructure.

“What if a strong attacker got into our API server? How can cryptography stop or slow them down?”

Of course you could take it a step further and build a proper threat model for your system. One way to do that is to use the STRIDE method: Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. There are also more formal approaches like Dolev-Yao that can be used to model your protocol under specific attacker assumptions.

Practice Being a Strong Attacker

Another way to improve your thinking about this is to practice being the attacker. For some exercises in this area, check out the cryptopals web site. Cryptopals walks you through progressively more difficult but real-world vulnerabilities in cryptography. They’re fun and very satisfying when you solve a problem. This type of exercise is extremely useful for a developer, not just because you learn a few specific techniques, but you practice shifting from a “build” mindset to a “break” mindset. This is harder than it appears as Bruce Schneier has pointed out,

“This kind of thinking is not natural for most people. It’s not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don’t have to exploit the vulnerabilities you find, but if you don’t see the world that way, you’ll never notice most security problems.”

Look at your own application from the point of view of an attacker. What information is most valuable to them or most embarrassing to your company? What data do you rely on the most to be correct? How many systems are touching and potentially modifying data that they don’t need? How can you modify your infrastructure to limit a user’s interaction with data they don’t need to access?

If you have questions about how to approach analyzing your application’s security posture, or encryption in general, please reach out and schedule a free consultation with one of our encryption experts.