Comments on: Agility and Risk Compensation: Exploring the Connection

By: Charlie Salomon

Charlie Salomon — Tue, 10 Nov 2009 14:26:26 +0000

Here’s an idea that my boss thought of: Why not develop a password enforcement mechanism that ties the length of the password to how often you have to change it?

If you want a 4 digit password, okay. You have to change it every 24 hours. If you have a 16 character pass phrase, you get to keep it for 3 years.

By: Rob

Rob — Tue, 22 Jul 2008 15:50:51 +0000

I have hundreds of passwords, of varying strength, that I manage for myself, my wife, and my children. I use an application on a PC at home and my Palm PDA (eWallet) which encrypts everything using a strong password. Some passwords we remember because we use them frequently, of course, but often, I’m called upon to relay a saved password.

While passwords are not the ideal security mechanism, they are common, so a scheme like I use would help Patrick with his 70+ passwords without the need to write them on paper.

By: Jens Laundrup

Jens Laundrup — Mon, 09 Jun 2008 17:11:20 +0000

I believe that the key is not that the policy fails but that the tools and processes necessary to support the policy are not put in place.
Patrick makes a great point about a policy that, though well intended, does not take into account the situation where 70+ passwords need to be maintained and remembered (even if it was more than 5 it would be pertinent). This raises the need for one of three efforts to resolve the situation:
1. The policy needs to be changed so that he is in compliance (not very desirable).
2. A single sign-on system needs to be set up for Patrick and those in his situation so that the passwords can be updated as required per policy but they are accessed through a separate system (a better system though it still relies on the weak username/password system).
3. A different system, such as a combination of a Smart Card and Biometric scan with a PIN, needs to be put in place so that the Username/Password system can be eliminated. The most expensive solution but it would enable compliance with not just the policy but the intent of the policy.
Thus, helping secure the environment through policy needs to be backed up with a reasonable manner/system/process for compliance. Too often this does not happen because of a well intended IT or security manager wanting to create a secure environment without thinking through the ramifications for the few (for the many, the password policy usually deals with one or two passwords only). In design engineering, this is often referred to as maintainability, in IT/security, this same scrutiny should be applied. We could call it “compliability” but what it really is: common sense.

The concepts of agility and risk that Jeff wriites of are greatly needed in modern IT environments. In addition, supplementing the what and how with why is very important to ensure that the users truly understand that it is not just to annoy. But as Patrick illustrated, policy needs to be tempered with “compliability”.

By: Patrick Florer

Patrick Florer — Mon, 09 Jun 2008 16:06:10 +0000

just a couple of comments about the password example:

not convinced about the relationship of risk appetite to your subject matter – policy non-compliance may be much simpler than that.

For example, I must have 75 different accounts – company, financial, software support – that require passwords.

So why do I write them down?

It’s not because I want to circumvent policy and it’s really got nothing to do with risk appetite – it’s
because I cannot remember them all.

Why do I resent having to change them every so often?

Because it’s a hassle, because I cannot remember the last n passwords, and because my job is not to be a creator of strong passwords.

Why don’t I comply with policy? Because the policies may not make sense for what I do.

What can security do to improve my life?

Design password policies that are relevant to different levels of access/different roles – for some things/roles, who cares? The data just doesn’t matter.

For other things, maybe strict policies are the right way to go.

As for taking control out of my hands – if you can do that in a way that doesn’t completely tie me down, then great.
But if your approach is going to force me into a box, I will resist you and ultimately defeat your misguided efforts, thereby possibly creating a security problem that I don’t really wish to create, but have no reasonable way not to create.

fyi – I am somewhat new to infosec, but have spent 27 years in IT on all sides of the fence – really like your ideas about agility and risk, but am just taking the user’s point of view in these comments.