Changing The Game?

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.

39 Comments

Chris Hayes 2009-12-11

@Ben

Rich 2009-12-11

Chris, I can't thank you enough for the insight you are bringing to this and the related threads. When I first joined Gartner I was schooled on risk by our financial services team, lead by someone who came out of executive management in the insurance industry. It dramatically changed my naive perspectives at the time. The problem I think we have in infosec is that the economics are skewed to distort risk analysis (see my post on the anonymization of losses), and we fundamentally lack the proper data to make truly informed risk decisions. I do think we are creeping slowly in the right direction- the Verizon report is one example on the data front, and it's the main reason we are focusing so much on metrics models. One area where I do think we need to be cautious is the need in many financial and insurance models to tie everything to monetary value. Since "loss" has a different meaning in the digital world due to us usually not losing access to the asset as with physical loss, the models don't fully translate. That said anyone following this post who hasn't studied both ERM and some of the major financial models should give them a look.

Russell Thomas 2009-12-11

>One of the best ways I have had the probability vs. possibility concept explained to me is from > Jack Jones the founder of the FAIR methodology. Imagine you have a revolver with one bullet in > the cylinder and a semi-automatic pistol with a full magazine one round in the chamber. I thought of a different interpretation, just thinking of the revolver: "Possibility" is defined by the logic of the pistol -- firing pin, trigger, ammo chambers, barrel, etc., plus the existence of bullets. Whether it's possible to fire on the next squeeze of the trigger is determined by this logic. If there are no bullets in existence, or of the pistol logic is screwed up, then there is no possibility of firing. "Probability" of firing a bullet on the next squeeze of the trigger is defined by the configuration of bullet(s) in the chamber(s), relative to the firing mechanism. (Or, it's defined by your information about bullets and chambers, from a Bayesian perspective).

Ben 2009-12-11

@Chris Hayes - thanks for the link, I've grabbed the file, will give it a read in the coming days/weeks. @Chris Hayes, Rich - What concerns me is that, in looking back at previous FTE security gigs, I don't recall any direct interaction between info risk mgmt proponents and people performing business risk analysis on a daily basis. In fact, I'd be hard-pressed to tell you who on the business side was doing the risk analysis and mgmt. I'd wager that I'm not alone in that experience. I understand the ties between info risk mgmt and traditional business risk mgmt, but it makes me nervous that we often talk about things like "business alignment" and yet we're not necessarily interfacing with the business, or at least not with the right business people. So, my concern is perhaps less about how we're doing things (formal info risk mgmt methodology) and more about who we're engaging on the business side, or if there is even consistently someone on the business side with whom we could interface. I think we need to also remember that the vast majority of businesses in the US are small businesses. Citing the big insurance and finsvcs companies is great, because it provides an anchor, but is that just the 20 of the 80/20 rule? Or can one safely estimate that the vast majority of companies, regardless of size or industry, are doing formal risk mgmt? I don't know the answer, but the possible answers make me nervous. It's hard to be credible with the business if they have no idea what you're talking about...

David Mortman 2009-12-10

@Chris Hayes We are so on the same page. And you are right, this is much easier said then done. As you said, there are a ton of factors that go into such a calculation. The question is how do we get to a more reasoned estimate? You have a ton of data from your employer, any chance you can do a FAIR analysis and tell us what you get?

Ben 2009-12-10

I have a dumb question (it's apparently my theme for the week)... are businesses actually doing formal risk analysis and risk management today /at the business level/? Except for M&A, I can't think of any time that I've seen it done. It reminds me of taking Decision Analysis in grad school... as I sat in the class drawing decision trees I wondered "who actually does this stuff?!?" The same now occurs to me around formalized risk management... it almost seems like most decisions are made off the cuff, with discussion, but not with much in the way of formalized calculation or consideration... it seems that only the "really big decisions" have much rigor, while everything else is just "managed" as part of daily operations/SOP. Thoughts? Observations? TIA!

Chris Hayes 2009-12-10

@Ben

Ben 2009-12-10

I'm talking about *business* risk, not *information* risk. I know people are doing info risk management. What I'm wondering is what we're allegedly mapping to in terms of business risk management. It seems like we're doing a whole lot of formalized "stuff" while the business just intuits its way through things.

Chris Hayes 2009-12-10

@Mortman. Interesting request. A FAIR analysis can be used to demonstrate variance in resistance strength (formerly referred to as

Alex 2009-12-10

Hi Ben! I know of several companies with ERM programs. Thank you, Alex

David Mortman 2009-12-10

@Chris Hayes "I have performed password frequency related risk assessments for a business unit wanting to accommodate some of its

Chris Hayes 2009-12-10

@Ben - I would submit that information risk is business risk. Regardless, yes - I see business units at my employer that employ formal and at times very complex decision making methods. I have also witnessed non-information "risk issues" that are managed very formally - often in manners more stringent then information risks because of the implications (market risk, product risk, legal risk, etc..). In financial services - specifically insurance and given our economy - how would we even stand a chance of being ethically competitive?

Chris Hayes 2009-12-10

@Mortman. Yes. It would be both a pleasure and a privilege. I will DM you my contact info.

Ben 2009-12-10

@Chris Hayes - yes, true, hopefully one in the same, but I was more concerned that we were once again, as an industry, promoting a bottom-up approach to people who neither understood nor cared to understood the language we were using. I'd love to see how those discussions of business risk run in daily operations. How well do our info risk conversations align with that? I still see a lot of blank looks on the faces of business folks when the topic of info risk mgmt comes up...

Ben 2009-12-10

"...cared to understood..." - obviously should be "cared to understand" durrrrr

Pete 2009-12-08

I think it is pretty clear that password changes reduce risk by increasing the cost of attack, albeit slightly. I am not convinced, however, that it is worth the effort. Full analysis can be found here: http://spiresecurity.com/?p=1093. Pete

Mark C. Wallace 2009-12-08

Fascinating discussion. There are three points that I think are key here. First, LonerVamp's point confidence that the password provides security is not a static value, but decays over time. I think that is a useful restatement of the question, rephrasing it from a choice between two arbitrary standards to a question that can be studied with data. (of course isn't that the core of Mr. Mortman's point?). Second, password cracking may be more relevant to elevation of privilege than to acquisition of privilege. Slightly different threat model. Third, and most important, analysis of security standards relies on a coherent threat and risk model. Except in trivial cases, you can't exploit hashes unless you already have access. But are there ways to get hashes? Interception of remote workers & VPN? PWDump from a compromised machine? Fundamentally we're analyzing defense in depth - where no protection stands alone, but is backed up by other protections. I know that if I were the person responsible for accepting risk that I'd be more comfortable with a policy attempted to exploit passwords, and forced a password change on any password that was cracked in less than a week. (Actually, I'd be most comfortable if they ran the password cracking long term, spotted the inflection points in the curve and forced a change on anything under the curve). That is going to cull out the easy passwords and force the attacker to spend time (his opportunity cost). Without real data to back the various hypothesis, the discussion will not terminate. And that is the reason for compliance. The people involved in this discussion, if given an infinite funding line, could acquire the data, identify the risk drivers, build a model and come up with a standard - to achieve risk X, change passwords every Y hours. Six months later we'd have to acquire a new infinite funding line and repeat the study to capture changes in practice and attack techniques. Since most of us don't have an infinite funding line available every six months, we pick an arbitrary number. Which takes us over to the discussion at Rybolev's blog.

David Mortman 2009-12-08

For those who don't read Rybolov's blog, @Mark Wallace is referring to this post: More on the Rybolov Information Security Management Model (http://www.guerilla-ciso.com/archives/1406)

David Mortman 2009-12-08

@Chris Hayes You make a great point. Namely that there are other risks other then passwords being cracked that need to be worried about, such as password sharing. Other concerns, include password theft from phishing and whatnot. My concern is still that 90 days is completely arbitrary. We as an industry made up a number that made us feel happy on the basis of absolutely no evidence whatsoever that 90 days is useful. Now we are stuck with it because it is ensconced in various regulatory requirements such as PCI, so now this debate is moot (cue 1980's Jessie Jackson SNL skit). "Finally, changing passwords on a frequent basis for IDs that are

Rich 2009-12-08

This debate on the email question inspired another post on controls vs. outcomes: http://securosis.com/blog/security-controls-vs.-outcomes/. It was too much to squeeze into a response...

Chris Hayes 2009-12-08

@David Mortman

Ben 2009-12-06

I'm not sure I fully agree with you here, David, though in some cases it was the beginning of a paragraph where I took issue, and the end of the same paragraph where I found agreement. A couple points of contention... You said: "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." People believe what they want to believe, typically based on what most reinforces their pre-existing opinions. To make matters worse, organizations typically turn a deaf ear to their own people in favor of those outside their organization, as irrational and insane as that may be. They wantonly ignore those who see the organization for what it is in order to hear fairy tales from those who see the organization they way they'd like it to be (that is, adorned with their products, of course). I also would not say that we practitioners are "allowing" these faulty perceptions to exist. We're doing what we can to fight them, but we're not being successful. Why? If I were to guess, it's because we don't have the resources necessary to leverage the same techniques marketeers use in pushing their own agenda. On a large scale we call this Congress and Lobbyists. ;) You said: "...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." What rational, reliable, mature security professional in their right mind is selling point solutions as "silver bullets" these days? Is this really still a problem, at least from the practitioner perspective (putting aside vendor marketing)? This is a patently unfair accusation. Unless, of course, you're talking about analysts and how they position and promote technology solutions instead of promoting a balanced approach. The same goes for FUD (unless you're Anton, apparently)... As for your password example, what's your point? Here again is another compliance-driven requirement that has been foisted upon us. Where did it originate? In somebody's confused notion of how to address a specific threat (a notion that makes auditors happy, but with no basis in sound reasoning or measurement). However, don't blame this on current practitioners. It's lore, now; part of the mediocrity that is best practices. I think this rather reinforces the point that we really do need to throw out everything we're doing and start with fresh eyes and ears.

Rocky DeStefano 2009-12-06

I think we

Jack Merlot 2009-12-06

Greetings & Salutations, SECURITY --I::::::::::::::> It's a process, not a product. It's a marathon, not a sprint. It's a war of attrition to some degree. My computer has enough resources (think of it as a piece of real estate) to treat parts of it as Embassies. If I give you a login on my OpenBSD 4.6 laptop, and make some further adjustments to suit your needs, you basically get a shell that can help you stay turtled come hell or high water. I can and have managed (systems admin) a fleet of mobile & workstation machines before, and I have only gotten better at it since then. So. That is how negotiations and diplomacy start. (Or call it Duplomacy, that's always funny.) Agent Provacateur, I'm talking to you, too. And I'm talking to others as well. So hold your horses and think about how many times YOU would prefer me to replace my hard drive, because each time, it costs me like $50 and 4 hours of the most fun times I've ever had. Seriously. Reinstalling on my compy is like going to a hooker. Even if I have something terminal lurking in my BIOS, not everyone has the key to that particular minerva. So change your passwords, I'm starting to lose patience, I am **not** here to swipe your stuff or stalk you, I am just here to pick up my mail and get more coffee. Thanks, - Jack Merlot

Chris Hayes 2009-12-06

@mortman. If we can agree that risk can be defined as the probable frequency and magnitude of loss, then I think we can find numerous examples of how changing a password on a frequent basis can impact the

Robert David Graham 2009-12-05

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).

Russell Thomas 2009-12-05

Great debate, gents! Here's my commentary: http://newschoolsecurity.com/2009/12/can-risk-management-guide-policy-regarding-password-change-frequency/

LonerVamp 2009-12-05

I like to think of password changing as an insurance. It helps prevent the lingering knowledge of passwords to bite you in the ass 6 months or 6 years into the future. That would include people who quit and take shared passwords with them, share them with others ("please check my email!"), get them snarfed when they log into a VPN or email from an untrusted network or system, get them snarfed by malicious or curious employees who crack their local SAM, or simply have them leak out from a lost/stolen laptop...the weight of which all depends on how important a target you may be. And, as mentioned, it breaks the trend of re-using the same password for everything, in which case you're only as strong as your weakest use (that non-SSL online forum with the 2 year-old forum software and non-encrypted database run by kids with no ethics...). It all helps demonstrate that you can be confident that every 90 days, passwords are only known to those who set them. Of course, then your timer resets and over time confidence reduces, until you repeat the whole process again. And if you don't change them, you fall further down the slope of being able to prove someone did something, i.e. non-repudiation and, what some people will argue is highly important, attribution. :) And while pen testers will do crack runs every time, attackers still don't necessarily need to unless you're targeting someone and latching onto their laptop while they're at the hotel bar. There are still other ways to get things, but cracking passwords certainly gets you pretty high value when you do bother. At least that window might only be 90 days...? It's a benefit that the security measure is easily understood, demonstrated, and executed by non-technical managers!

LonerVamp 2009-12-05

Anyway, back to the issue and not a small example! :)

Rocky DeStefano 2009-12-05

I think we

Steve 2009-12-04

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?

David Mortman 2009-12-04

@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.

Steve 2009-12-04

@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.

Chris Pepper 2009-12-04

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 Mortman 2009-12-04

@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.

Rich 2009-12-04

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?

Alex 2009-12-04

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

Steve 2009-12-04

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.

Wolfgang 2009-12-04

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/