3 REASONS YOUR SITE NEEDS SECURE KEY MANAGEMENT
We would not be able to have the technological convenience that we have today without encryption. Private social media, paying our bills remotely, shopping online – none of these things we take for granted could exist without a way to protect data in transit.
Encryption, of course depends upon encryption keys. The growing complexity and demands of our web environments is forcing us to find better ways to manage these keys. Let us look at the top three reasons why modern websites need secure key management.
1. Keys in the central code base are vulnerable
We like to think of website security as a matter of keeping malicious parties on the outside from getting in. That of course is the problem solved by login credentials and increasingly by the use of two-factor authentication. However, if you think about it by design the outer membrane of a website is porous – we need to make it simple for authorized users to access the site.
The consequence of this is that you can expect your outer defenses to be permeable. All it takes to penetrate them is a really good social engineering attempt (spoofing, spear phishing, etc.). This is why pretty much every reputable security standard (PCI DSS, HIPAA, FISMA) requires that data residing in the innards of your system be protected through adequate encryption. Think of it as a vault with many smaller compartments that all need to be locked up securely.
Web developers generally like to get things done and get them done quickly, or sometimes they have to cut corners due to market pressure. When it comes to securing the data located on a web site or the data going back and forth between the outside world, they often gravitate to quick and dirty models. They may place encryption keys in an easily-accessible file, a database, or even in raw source code. In this case an enterprising attacker that can sneak in by obtaining the proper credentials will immediately gets all the keys to the kingdom.
The proper solution to this is to store keys in a completely different environment from the production code.
2. Passwords and passphrases also need protection
Applications must often use password credentials in much the same way that users do. This is more common in legacy applications and can often be seen with database connections. If it is not possible to re-engineer the system to a solution that does not require login credentials then the passwords will need protection and management.
On top of passwords we must also protect passphrases. A passphrase is essentially a password associated with a particular private key. Its purpose is to ensure that within a security framework simply obtaining the key will not be enough for an attacker to decrypt data. A passphrase is an essential failsafe but as with passwords it needs central management due to the increasing complexity of website architecture. Note that if the passphrase is ever lost then the key itself along with the data it encrypts could be rendered useless.
3. The Need to Define User Control For Key Access
We must also note that different environments demand different types access for different users. For example under PCI software development engineers are not allowed to have the access to production systems – such access is restricted to operations/release professionals and systems administrators.
When we bake encryption into the code as discussed in the first item in this article we potentially invalidate our user access controls. If the same key follows from development to production then the data encrypted in production becomes vulnerable.
Development environments are usually cordoned off very carefully from production to minimize the risk of leaks. However, it is difficult to keep development environments as secure as production environments – they are the generally the first level in from the permeable outer layer. If there is no mechanism for ensuring that different keys are used in different environments, it becomes significantly easier for an attacker to gain the means to decrypt production data.