Rocky DeStefano had a great post today on FudSec, Liberate Yourself: Change The Game To Suit Your Needs, which you should read if you haven’t already. It nicely highlights many of the issues going on in the industry today. However, I just can’t agree with all of his assertions. In particular, he had two statements that really bothered me.
Information Security Leadership. We need to start pushing back at all levels here. It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally secure – or if you prefer having better visibility into real risk. Risk to the mission, risk to the business not the risk to an asset. We continue to create irrelevant measurements – irrelevant because they are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary.
In a perfect, security and risk oriented world, I would agree with this 100%. The problem is, that from the business perspective, what they have in place is usually sufficient to do what they need to do safely. I’m a big fan of using risk, because it’s the language that the business uses, but this isn’t really a compliance versus security vs risk issue. What needs to be communicated more effectively is what compliance to the letter of the law does and doesn’t get you. Where we have failed as practitioners is in making this distinction and allowing vendor and marketing BS to convince business folks that because they are compliant they are of course secure. I can’t count the number of times I’ve had folks tell me that they thought being compliant with whatever regulation meant they were secure. Why? Because that’s the bill of sale they were sold. And until we can change this basic perception the rest seems irrelevant. Don’t blame the security practitioners; most of the ones I know clearly express the difference between compliance and security, but it often falls on deaf ears.
But what really got my goat was this next section:
As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives? We sold our souls because we lacked the knowledge of the business and how to apply what we do in a meaningful way to the business. We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim?
I don’t know who Rocky has been talking to, but I don’t know a single security practitioner who thinks that compliance was the way to go. What I’ve seen are two general schools of thought. One is to rant and rave that everyone is doing it wrong and that compliance doesn’t equal security, but then engages in the compliance efforts because they have no choice. The other school is to be pragmatic and to accept that compliance is here to stay, and do our best within the existing framework. It’s not like we as an industry ‘let’ compliance happen. Even the small group of folks who have managed to communicate well with the business, be proactive, and build a mature program still have to deal with compliance. As for Rocky’s “buildng codes” and “point in time” snapshots, for a huge segment of the business world, this is a massive step up from what they had before.
But to answer Rocky’s question, the failure here is that we told the business, repeatedly, that if they installed this one silver bullet (firewalls, AV, IDS, and let’s not forget PKI) they’d be secure. And you know what? They believed us, every single time, they shelled out the bucks and we came back for more, like Bullwinkle the Moose “This time for sure!” We told them the sky was going to fall and it didn’t. We FUDed our way around the business, we were arrogant and we were wrong. This wasn’t about selling our souls to compliance. It was about getting our asses handed to us because we were too busy promoting “the right way to do things” and telling the business no rather then trying to enable them to achieve their goals.
Want an example? Show me any reasonable evidence that changing all your users’ passwords every 90 days reduces your risk of being exploited. No wonder they don’t always listen to us.
Reader interactions
39 Replies to “Changing The Game?”
We pentesters crack passwords all the time. However, basic crackonomics shows that it’s not worth it to leave a job running for 90-days, so that’s not a justification to change passwords.
There are other reasons. Users are stupid and choose the same password for their corporate accounts as their online accounts. Password rotation breaks that. I’m not sure the exact cost/benefit breakdown for password rotation, but I’m sure it’s not as simple to calculate as you might imagine. In any case, we never recommend it.
We are increasingly seeing “security compliance” managed separately from “security”. Security compliance is often driven by the audit subcommittee of the board. A lot of our customers are more afraid of being out of compliance than they are of being hacked.
I know of nobody who claims that being compliant means they are secure. It’s one of the one-hand-clapping arguments of the security community, there’s nobody who seriously debates the other side of the argument (although, I admit, maybe I don’t run in the right circles to hear the other side of the argument).
Just as an example of the CUDA technology mentioned, not to chime in on the 90 vs. 180 vs 380 days:
http://blog.red-database-security.com/2009/11/29/ighashgpu-cracking-oracle-passwords-with-790-million-passwordssecond/
I don’t want to take this position too aggressively, because I don’t actually have a strong feeling on password aging, I just think it’s a reasonable control in some environments. I’d be willing to bet that most small-to-medium businesses don’t have complexity requirements, either, which would moot this point, since the crack would be trivial.
Some experiments have been done with EC2 on how much it would cost to crack some (good) passwords in the cloud:
http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html
There has also been a fair amount of activity around nVidis’s CUDA in the password cracking arena, for the more modest budget.
Well, this kind of highlights the problems you were saying, doesn’t it.
Business doesn’t “get” us, and now we’re arguing about how much we need to piss off users with password rotation (which is probably the least of our problems).
To add to your bottom line, David, regardless of which “line” you take concerning compliance (piss & moan vs. begrudging acceptance) the important thing to do NOW is force these standards bodies and policy makers to include:
1.) Data sharing
2.) A set of formalized metrics and models.
3.) Evidence Based Evolution for #2 based on #1
It shouldn’t matter what you think of compliance, you need to be pushing for those.
Hugs & Kisses
Alex
Based on all the recent breach reports and investigations, it doesn’t look like password cracking is a major vector anymore (I’m not willing to stand behind that statement, but that’s my reading of these reports).
With modern systems (no more NTLANMAN) is it really a risk? Is that risk greater than the cost of password rotations?
@Steve
Okay so lets take your scenario. The question you have to ask, is how long is the hash going to stand up to attack. With a strong hash, it’s going to be a heck of a lot longer then 90 or even a 180 days, possibly years. In that case, what’s the justification for changing it on a 90-180 day schedule?
On the other hand, if the hashes are susceptible to a rainbow tables attack we are looking at seconds to minutes to crack. This leads to potential scenarios such as a theoretical attacker could be in your system for upwards of 90 days which means a world of hurt and if they are in that long a password change isn’t going to keep them out. Realistically though, what this means is that you now have a more complex risk question around how likely is it that someone is going to break in and get the hashes and how long are you willing for them to have use of those passwords? We at this point have little to no data on how likely this sort of attack is to occur so we can’t even take even a bad guess at if 90 days is a good number or a bad number. But until we have some data, we’re just making stuff up so make ourselves feel like we’re doing something.
Mort,
“They believed us, every single time, they shelled out the bucks”
You have clearly worked in different places than I, but I’ve never seen a place where security got everything they asked for.
Also, 90-day password change policies are stupid in >90% of scenarios. There are probably some DoD scenarios under active attack where they make sense. The clowns who insist normal business systems need 30 or 90 day password expirations don’t mean *all* users should disbelieve *all* professional security advice.
Steve,
If your passwords are realistically brute-forceable in 90 days, they’re too short.
Mort,
There are various ways you might get a UNIX /etc/shadow file from backups, so reversing password hashes is a real threat.
@David
The specific scenario I was thinking of involved cracking an Active Directory domain member, and then dumping the hashes of the last 10 logged-in users (which is used to authenticate users when the domain controller is unavailable). There’s a good chance that a regular user’s PC will have had a Help Desk or other more-privileged account logged in within the last 10, and by cracking that hash, the attacker would gain access to higher privileges.
It’s only one example, but I expect others could be brought up. I certainly don’t think the concept of password aging can be dismissed out of hand.
@Steve
It sounds like a realistic threat, except for the fact, that if someone has been able to get your password hashes, then they are unlikely to need to brute force passwords. They already have the access they need to get to the data that they want. If you own the authentication system, passwords no longer matter. Even if they need or want passwords, they now have the ability to capture them at will.
Aside from regular password change intervals, is there a way to mitigate offline brute-force attack? Assuming an attacker uses any of a number of methods to grab a password hash, and that the hash isn’t some sort of weak LM silliness, an attacker is left with a long-running brute force process, depending on the computational power available. For most organizations, a password change policy of 90 or 180 days would likely make the results of the brute force moot.
Given that offline brute-force is a realistic threat, isn’t a password change policy a reasonable control?