Computing means processing Data. Therefore, it is only natural that Data Protection is one of the most important things when you discuss the Security of an Application, regardless how it is implemented, where it is hosted and how it is maintained.

Protecting Data is like storing it in a safe: you will have to choose the type of protection and you will get a key, that is a token granting access to that Data only to you and to the users who are allowed to access it. This key could be in the form of an Identity, in the form of a cryptographic key or in any other form; this is not really important for the sake of our discussion.

The key is very important, even if not as much as Data. Its importance is not due to anything intrinsic in it: you could safely discard a Key under controlled situations, and none will complain with that. It is important only because it allows access to Data; sometimes, the Key is the only thing that keeps attackers from accessing your Data.

So, you will want to keep your key safe as well. And this is the really hard thing to do: how could you protect it without involving another key, and then another key, and then yet another key? Sometimes you can leverage on services offered by the Operating System, like Microsoft Windows Data Protection API (DPAPI), or store the keys in hardware modules like the Hardware Security Modules (HSM). But really, this is only part of the answer. That is, even if you find a way to protect your keys effectively, you need a way to provide them to any instance of your Application, if it is installed on multiple servers in multiple locations, and to be ready to replace the keys – and discard the old ones – when (not if!) they are suspected to have been compromised or for any other reason.

It is all too common not planning for Key Management tasks like those. In my experience, I have found more than a couple of customers which had not planned for that: typically they placed the keys in code as strings or as resources, without planning for when they need to be changed. The net result is that they are not changed, and sometimes they are the very same in the Development as in the Production environment. The only thing that is worse than that, is not to put in effect ways to understand when you are under attack and therefore you need to change the keys. It goes without saying that those customers were more than happy with the situation, because they had no clue about actually being under attack.

Much better to Assume Breach and act accordingly.