Raising the security bar, or…

After one of my recent articles I ended up in a discussion with someone over blocking easy attacks by unsophisticated attackers. For example, I said you should not worry about Rainbow Crack. What is important is protecting the password hash database because the hashes are plain-text equivalent. If passwords get too difficult to crack, the bad guys will just build better tools that can use hashes directly in the authentication sequence. Of course, you should also ensure that the passwords are resilient against guessing and cracking the authentication sequence, but those are much easier to deal with. This means though that 14+ character passwords are not really all that important. 8-9 characters are fine for most purposes.

The argument against my claim is that unsophisticated attackers, say malicious internal users, can still simply go download Cain and, since it has a cracker built in, take over your network. If we ignore the issue that these users would already be administrators, this argument still hits the nail on a particular onerous head: easy access to rudimentary tools that create criminals of opportunity. My approach to dealing with the issue is a bit different though. I tend to focus on two things.

  • First, run the systems in such a way that you do not expose sensitive info, such as high privilege credentials on low privilege systems, and then protect the sensitive systems appropriately. That makes the crimes much more difficult to perpetrate. It also makes the systems harder to run, which is why we find so few environments doing it.

  • Second, focus on defeating the most skilled attackers the environment is likely to face. While it may be a bit more difficult to do so it will also defeat the attacks by the less skilled criminals of opportunity.

If we take the case of Rainbow Crack, there are two ways to defeat it. The first is to use very strong passwords (or pass phrases) which are unlikely (but not guaranteed) to be in the tables. The second is to stop the bad guys from getting your password hashes. No hashes, no cracking.

This is why I think we need a change in tactics in security. This field has spent the past 20 years responding to attacks by raising the security bar to just above where the attackers are at the time we raised the bar. This approach means we are always playing catch up to the newest attack. We raise the bar, the attackers jump over it. We raise it again, they jump over. I feel like I am in an old Basic program:

10 gosub detectNewAttack

20 gosub raiseSecurityBar

30 goto 10

How do we get out of this cycle?

Take an example: if you are paranoid, like me, you would agree that it is only a matter of time until Cain and friends, in “the interest of security,” will include pass the hash functionality. After all, since everyone will use 15 character passwords soon (and if you believe that I have some land I want to show you ) their current technique will no longer work. That means that if we primarily focused on mitigation number one above we will now once again playing catch up, and we will have made all our users mad in the progress by forcing them to use horribly long passwords without much help on how. On the other hand, if we thought differently about the problem and worked on fundamental design and secure operations instead we would stop not just the current attacks, but the new ones. Stopping current attacks is nowhere near as interesting as stopping future ones.

Don’t misunderstand me here. Strong passwords are still extremely important, and I an one of the loudest advocates of pass phrases. However, I also think that as security professionals we need to stop playing catch up. We need to stop reacting to every new move the bad guys come up with and start anticipating and get ahead. The information security discipline is heading for a crisis unless we start working on strategic security, not just tactical response. We need fresh thinking, new thought, and partnerships with those who use our systems. The bad guys know how we operate and they keep using that against us. To get out of this situation we need to stop just raising the bar and instead move it to a new playing field; one where we get to write the rules.
These are of course my opinions, and you are free to disagree, but it explains why I think the way I do.

Comments (6)

  1. Anonymous says:

    Eine meiner Lieblingssession von Jesper Johansson ist Anatomy of a Hack: How A Criminal Might Infiltrate

  2. Anonymous says:

    Eine meiner Lieblingssession von Jesper Johansson ist Anatomy of a Hack: How A Criminal Might Infiltrate…

  3. Susan says:

    Someone once said that computer security is like the health care in our world…we ‘react’ we are not proactive.

    Funny with the potential for the Flu Pandemic being discussed that we still do the same in Technology.

    We see it coming, we know we need the flu shots, but we just haven’t put the resources in the right places.

  4. Roger says:

    Putting the pass code length comments aside, I find need to comment on two things in what you have said.

    "Working on strategic security instead of tactical response" is point on accurate – as I mentioned to you in June, too much of what I am seeing labeled as security effort is just remediation. To be fair, many bar-raisers along the way have believed their innovations strategic improvements; and a number have been, for a while. What will we say of all the crypto infrastructure if cheap prime factoring becomes possible for arbitrary length factors? It may be not whether we can get out from the bar-raising game, but how far we can raise it at one time.

    You also allude to focusing on architecting the infrastructure so that protection efforts may be prioritized (ex. do not expose sensitive information needlessly, etc.). This is more simple for protecting the systems than it is for protecting the data. It is much more simple to protect sensitive credentials in the shape of administrative, or power user, etc. grants by controlling their usage to only appropriate modalities than it is to protect a user accessible store of sensitive data where one weak user or user account’s auth evidence can result in the leakage of the sensitive data (that is rightly) accessible to that user. Even moving to DRM systems does not have impact if the user credentials presented have a low confidence rating.

    Now, if we could shift, and we can, to using high confidence methods for identity confirmation it would seem that much of the specific issues in your post or this reply can be addressed. Either the OS does everything right but the creds are in the wrong hands; or, having proper creds is immaterial as the OS code is subverted. That seems to me to say there are two things to address.

  5. Keith Pawson says:

    I find this to be an interesting proposition and certainly one that IT security should strive for. Changing the playing field from a technology aspect may well be possible, but only for a given period. Of course there is still that “people” and “business” problem that we try to deal with. For example if we compare IT Security with everyday security, such as car, home and business theft, we can say that the authorities need to raise the bar and change the playing field – but how do they do that? Technology has assisted with car and house alarms, improved door/window locks and engine immobilises…. However the bad guys still get in and in most cases it’s due to a “people” problem.

    I believe we are simply dealing with an age old problem… there will always be bad guys and they will always find a way around technology or use “people” to get around the technology.

    So how do we get to that other playing field with both technology and people…. Maybe “Quantum Security” can fix that 🙂

    Don’t take the above as being negative, I’m all for getting ahead of the bad guys and having a strategic plan is obviously better than the current situation.

  6. Bo Rasmussen says:

    Interesting topic, and I agree that its not always the best option to raise the bar, in this case the bar being the length of your passwords.

    What i would like to see however is the possibility to work with different security levels (ie. password policies) for different groups (or OU’s or users) without having to make custom password filters / third party applications or setting up multiple domains. The "best" level of the bar for the domain admin is not the same level as it is for the intern user who’s only allowed to log on locked down server with minimal proviledges.

    Most people i come across either got a "functional" mindset where security is a nuisance and firewalls should be burned or on the other hand they’re paranoid security fanatics who wont be happy till all users biometrics is loaded into the authentication system and users are prevented from logging on unless they got firewall/antivirus/patched OS/IDS on their clients and tinfoil hats protecting their brains from alien mindcontrols… theres not one security setting thats best for all.

    So how abount a 2003 SP3 that gives us the option to apply different Password Policies to different user groups ? 😉