“How long does this have to be a secret for?” is a question not enough security professionals ask…
Jeremiah Grossman recently highlighted this forgotten aspect of information security in a Twitter post. That got me thinking — it’s been a long time since I’ve discussed this topic, and it’s probably worth writing a short post about.
Grossman uses the analog of safes, and the Underwriters Laboratories ratings as a comparison. I believe this is fair because security, much like fire protection, needs to know what we’re protecting, what we’re protecting it from, and for how long. Those are the three key questions I believe should be asked when formulating a security architecture or design.
The reality that is lost on far too many security professionals is that secrets expire. Encryption is the quintessential example of this. Encryption isn’t built to be secret forever, just long enough to where it’s not useful anymore as a secret. Designers of security mechanisms want to make it impractical, either computationally or human effort-wise, for you to break their controls.
Let’s apply that practically to your network, for example. Security professionals layer in security controls largely so they can either thwart an attacker entirely, or keep them working until they can detect their presence.
Think of the following scenario. A publicly traded company is getting ready to announce their quarterly earnings. At 9am Eastern time on Monday the CEO will get on CNBC and discuss the previous quarter and release the report. At that point, the information is considered public and no longer secret.
The reality is, that information was put together by a significant number of analysts and financial professionals over a few weeks time. From the time that information is gathered until the time the report is a public matter is the lifetime of that secret. Attackers want that information early, before it’s public, so they can trade on news yet unreleased and make money. So they’ll try their hardest to get that report or package of information before public release.
This example illustrates the lifetime component of the security design. “How long does this need to be a secret for?” After public release the organization simply won’t need to do the same type of monitoring and attack detection against that asset or assets as it does pre-release.
I felt it was important to highlight this, especially as security architectures become more complex and integrated into every aspect of our daily lives. The knowledge of the lifetime of a secret helps us understand how much effort (and therefore precious resources) security professionals need to build into the system that protects that secret. This helps us balance the risk scales effectively…and that is what we are paid to do.
If you have a story in this line of discussion, I invite you to share it either in the comments, on Twitter, or LinkedIn.