“Don’t worry, information is encrypted so y/our data is secure!” – Everyone
Before we start: this article is part of a series aimed at covering the basics of encryption in its use as a security control, what levels of protection different implementation strategies can achieve, gaps I’ve identified throughout the years of consulting, and my view of MANDATORY requirements for a robust solution. If any information hereby shared doesn’t sound right, feel free to correct me.
As a security professional, I have to confess that the opening sentence gives me the chills, and clearly demonstrates a gaping hole in the security industry that even seasoned professionals fall for.
Ok, let’s roll back to a couple thousand years ago: cryptography, the use of ciphers and codes to protect secret information, has been used throughout the centuries by armies, emperors and nations to keep prying eyes away. It’s been pretty good at that when correctly implemented, one must say… And when poorly implemented, it’s also known to end wars.
So going back to cryptography 101, it boils down to:
- Message: valuable information to be protected. Let’s compare it to.. hmmm… a gold bullion.
- Cipher: the algorithm used to “protect” or “wrap” the Message. As an analogy in the real world, think of a secure room with a lockable door.
- Code: Most of the times it’s a complex string of characters… our equivalent to a brass key.
Now you ask me: That’s it?
In a nutshell, yes. These are all the components underlying the basic concepts of cryptography.
So, back to our mission to protect the gold bullion. Let’s think about some of the risks this hypothetical secure room is vulnerable to:
- The walls/door are not thick enough (weak encryption algorithm)
- There are known cracks to the walls (known vulnerabilities to the encryption algorithm)
- The door is left open (hardcoded or poorly protected encryption keys – poor key management)
- The key to the door is left lying around (hardcoded or poorly protected encryption keys- poor key management)
- The key is lost (lost encryption key – poor key management)
- The key is simple and easily reproducible ( weak key policy – poor key management)
You get the idea… with such an illustrative example to the problem, things become easier to visualise. And yet, when we transpose the same logic to the digital world, these risks are forgotten about, or at least remain unaccounted for.
In my experience, this is a consistent scenario I find in organisations with lower levels of maturity on the encryption lifecycle:
1- Sysadmin enables encryption to “make a system more secure” (1.a – Sysadmin enables SSL for “secure”communications) – the equivalent of selecting the materials and building the secure room
2 – Sysadmin creates a “hard to guess” password (2.a – Sysadmin creates a public/private key) – this is the cutting of the door key
3 – Sysadmin saves the password in a protected folder, or password vault (3.a – Sysadmin saves the private key in the shared drive, in a protected folder, or in an inconspicuous folder on his desktop) – storage of the key in a deemed “safe” location, let’s say, your cubicle drawer.
4 and 4.a – Process is repeated time and again for all the keys used to protect distinct systems or channels
5 – Sysadmin leaves the organisation, his/her successor is left with a ticking atomic bomb.
Have you seen that before? Yeah, me too.. And that’s the beginning of the end.
To be continued…