I am getting a fair amount of questions (which is blogger speak for the more introspective “I keep asking myself”): why isn’t this blog more technical?  Why aren’t I persistently advancing threads about advanced persistent threats?  Am I intentionally filtering out packet filter discussions? (note to self: do not turn into cyber security’s answer to Maureen Dowd.)

No.  I am as concerned about how encryption keys are managed as the next information security professional.  And while I resist the idea that our efforts should always be framed as warfare, I am well aware we have a fight on our hands.  And a fight that requires many kinds of thinking.

The short answer is that I do not dwell on technical issues because I feel that except as they relate to a small group of engineers, the technical issues in information security should be an exercise that revolves around measurement.   And measurement belongs in tables and specifications.   In fact, I would argue that it is precisely when a technical exercise is discussed as if it were a matter of something more than measurement that the discussion gets uncomfortable.  Here’s an example: the next time a vendor tells you that they cannot log something or encrypt something because it would “impact performance”, try asking these two questions:

1. Can you show me the measurements you made that indicate how much performance is degraded by turning on encryption and/or logging?
2. How much faster would my hardware have to be to make up for that impact?

Nine times out of ten, that mumbling sound you hear as an answer can be translated as follows: we did not DESIGN the product with that feature and we are trying to use an ENGINEERING excuse to explain why we won’t SPEND THE MONEY to put it in now.

It works the other way too.  For years, the justification for password expiration times being set to no more than 90 days and no less than 8 characters was based on charts that are the result of ENGINEERING which purported to show how long it would take to crack a password based on its length and complexity as attacked with a certain level of computing power attempting a brute force attack.  But really, password expiration is a DESIGN choice.  Consider what Bruce Schneier says on the subject:

“The primary reason to give an authentication credential — not just a password, but any authentication credential — an expiration date is to limit the amount of time a lost, stolen, or forged credential can be used by someone else”

http://www.schneier.com/blog/archives/2010/11/changing_passwo.html

NIST’s  800-118 (DRAFT), Guide to Enterprise Password Management, provides the following advice:

“Organizations should consider several factors when determining password expiration requirements, including the availability of secure storage for user passwords, the level of threats against the passwords, the frequency of authentication (daily versus annually), the strength of password storage, and the effectiveness or ineffectiveness of password expiration against cracking.” (page ES-2)

In chapter 3 of the guidance they provide an algorithm to assist in determining expiration date based on how hackable your password storage is.  I’ll quote that below.

In his list, Schneier mentions “lost, stolen or forged” credentials, but he leaves out one that is, I believe, all too common: shared.  The more often a password changes, the more of a chore it is for users to share it and so the less likely they are to rely on sharing them as standard operating procedure.  Those of us that have worked in Information Security in large organizations can attest to the fact that every now and then a request comes across our desk that reads like this:

 “please make it so that my password does not expire.  Everyone in the department uses it to get into application X and it is difficult to communicate it each time it changes.”

Schneier and others make the good point that the more you make someone change their password, the more likely they are to make up an easy one or to write it down, making it more vulnerable.   That’s a reasonable point and needs to be considered.

But my point here is that DESIGN choices not ENGINEERING will ultimately determine how long you give users before their password expires.

And that is true despite the fact that you can quote this kind of measurement from the NIST document:  “A password with a character set size of 72 and a length of 8 characters has a maximum keyspace of 7*10.  For the example described above, hashes for this entire keyspace could be generated in 12 minutes. Increasing the character set size to 95 only increases the time to 2 hours. However, increasing the length to 12 characters, and keeping the character set size at 72, drastically increases the time needed to generate all the hashes—to over 500 years.” (page 3-13)

So, when it comes to discussion, I think looking at how to get users to construct complex passwords, change them often enough and keep them secret is far more fruitful than measurement from NIST.

Does this mean that technical issues, that the detailed measurement of controls, is not relevant?  Not at all.   But if I go back to the question I started with: why doesn’t this blog deal with more technical matters, I end up with the answer that the technical details better not be a matter of discussion.  They better be right when you use them in your DESIGN.

I’ve quoted Frank O’Hara elsewhere in my posts and, once again, his “Personism: A Manifesto” offers a good point on why you need to get the technical matters right, but that you can’t stop there: “You just go on your nerve. If someone’s chasing you down the street with a knife you just run, you don’t turn around and shout, ‘Give it up! I was a track star for Mineola Prep.’”

For “nerve”, read DESIGN.  And for DESIGN, read “an assessment of risk”.