The OTHER problem with passwords.

There are some sites that I use very rarely, and I can never remember what I used for a password there.  But it doesn't matter, because honestly, the reset procedure is less onerous than trying a few passwords and risking getting locked out.  So I just don't bother: I put in a crazy strong password, forget about it, and when I come back to the site I just ask for a reset.  In many cases there aren't even security questions to answer; I just get a new password mailed to my address of record.  In the case of one site where they wanted me to change the password every 90 days, I did this dance every 90 days.

Yes, yes, I know, password manager.  But most of the public doesn't use one. And site designers know it.  Any site feature that makes it harder for a non-technical user to do a password reset causes that user to email or call the support desk, and every use of the support desk (as in actual humans) costs money.  So organizations are motivated to prioritize ease of use over security, if they feel their target audience won't be able to use more advanced features without support.  The end result is that the password reset process to an address of record is the easiest way to get into an account.

And of course attackers know this too: this is why many publicized breaches today started with the password reset.  If it's a simple enough process, getting into an account is no longer "something you know;" it's "something you have," as in control of the email address.  If you've broken into the address of record, you can collect password resets from as many sites as you can find without having to do any more homework. 

The next level up in attacking an account is to add a new email address of record that you control, which often requires social engineering of the support desk.  But support people are incentivized to help the helpless, which tends to make the process easier.  And as Mat Honan found out, the types of security verification data that support desks use can often be found out with a little Google action (and in his case, the clever use of an Apple process loophole).  This is why I've never liked the use of the last four SSN digits as an identifier; they're even more widely used than the whole SSN these days, and they're used for everything, including utility and phone service accounts. It's arguably less secure than a site-specific PIN.

Make no mistake: designing identity and access management while balancing cost and security is hard.  You can't control the biggest factor, which is the level of expertise for your users (particularly if they're all external to your organization).  With each of these breaches, we're learning more about what works and what doesn't in these designs.  But there's still a lot of risk out there.


 

CFP Karaoke.

I have to thank Wim Remes for coming up with the idea of CFP Karaoke:  you come up with a talk title, and someone else has to do the rest of the work.  Here are some of the gems he came up with on Twitter; feel free to take one and run with it.

@wimremes: "Two and a half clouds : how to keep winning on tiger blood as a service"

@wimremes: "Infosec and the God complex : we're better than we are and worse than we realize."

@wimremes:  "Exploit sales for the masses : do you want a patch with that?"

@wimremes: "Cutting through the infosec BS : is there an evangelist in the house?"

@wimremes: "Eeny, meeny, miny, mo, your QSA says it's secure but I say no."

When the mothers talk ...

Seeing as how I've been on the bench for roughly the past nine months, I'm looking forward to getting back to some conferences.  Here's what's planned, at least for now:

9/12-9/14/12 - Looking forward to speaking again at the UNITED Security Summit in San Francisco.  This year I'm talking about "Why Doing Application Security Remediation Is Like Building a Rube Goldberg Machine."  (If this sounds familiar, it's because I'm going green and have recycled it from SOURCE Boston 2011.)

9/18-9/20/12 - My employer's gala event, the North American Hosting and Cloud Transformation Summit in Las Vegas.  This isn't a pure security event, so I enjoy talking with a wider variety of attendees.  This year's panel is called "Security and DevOps: Table Stakes of Doing Business?"  And I've got some heavy hitters who will be contributing to the discussion.

10/9-10/11/12 - I'll be hanging around at RSA Europe, because I really love London.

10/25-10/26 - Of course I can't possibly miss the OWASP AppSec USA conference, especially as it's in the 512 this year.

12/3-12/7/12 - In what I'm sure will be the blowout of the year, Security Zone 2012 will be gathering a whole lot of security experts in Cali, Colombia.  Oh, and I'll be there too, talking about the Security Poverty Line.

It'll be great to see a lot of cool people again, and catch up on the latest research.

There is no spoon.

I just read this article from TechTarget, quoting Gartner research vice president Ramon Krikken as saying:

[...] it may be time to ask whether it’s faster, cheaper and ultimately just as effective to use a device like a WAF to shield an application from a security flaw than face the unending cycle of developing, testing and implementing software patches. [...] I have an increasing number of customers starting to question whether putting a Web application firewall in front of an application to fix something is all that much worse than fixing the code.

And I agree that some apps can't be remediated in a short enough time span, others can't ever be fixed, and so on -- for those exigiencies where there's no other choice, a WAF is better than nothing (assuming it's actually in blocking mode and properly configured).

However, I would strongly caution anyone against deciding that the wave of the future is simply to rely on the WAF or any other network-based security device for application security, because THERE IS NO FRONT.

You can't put a WAF in your production DMZ and declare it done.  An attacker who bypasses that DMZ and gets into your internal network will have a field day inside the soft and chewy interior.  Dev and test applications, often with production data in them, will be vulnerable.  They may also have back doors -- excuse me, I mean "test harnesses" -- that don't get stripped out until the production build. 

So maybe you'll put a WAF on board every web application server on your network.  Are you ready to manage all those rules, as new security vulnerabilities are found?  (You may well have different versions of the same application throughout your enterprise.) And wouldn't it be tempting just to start loading any other functional fixes that you can onto the WAF instead of having to fix, test and release the code?

There's another problem, though:  portability of code.  You may not ever plan to make it available outside of your organization, but can you imagine giving it to a business partner, or selling it, and saying, "Oh yeah, you'll need to get a WAF and about 80 rules because we never fixed the code"?  That's just not an option for anyone who is shipping, releasing or sharing their apps.

And finally, don't forget that pesky cloud.  As applications become distributed among different sites and providers (not to mention mobile devices), there isn't going to be a choke point for all application traffic to go through in order to enforce policies and detect attacks.  As hard as it sounds, trust boundaries need to be built into the applications themselves so that they correctly handle and protect their own architecture components and processes.  Otherwise your app is going to be wandering around the Internet with its hair creepily following two steps behind.

A WAF is a Band-aid, not a cure.  And even though it can be very useful for defense, additional validation or data transformation, it still doesn't provide 360-degree protection for an app; only the app can do that.  Don't slip into becoming part of a popular blog.

Slide rules.

In my time as a CISO, and now as an analyst, I've seen more vendor presentations than I can possibly count.  Over time, I evolved a set of rules that you may want to know about if you're going to share a slide deck with me.

Here are the required elements:

1. First off, there must be a slide talking about The Problem We All Face, and indicate that it’s a scary, scary world out there.  Otherwise I would forget why we’re all here. 
2. Next, there must be a conceptual  slide that includes icons of people, the cloudernet, and either monitors or CPUs.  Extra points for locks, or creatively drawn bad guys.
3. Add a chart of your company’s growth with the arrow pointing skywards on the right-hand side.  Don't include any numbers or units on the axes; those details are irrelevant.
4. There must be at least one circle-shaped process flow, indicating that the customer will never be finished using your product.
5. Don't forget the obligatory page full of customer logos (whether they approved the use or not).
6. And tiny screenshots of your product, which I cannot possibly read.
7. Compliance.  The word compliance has to be on there; otherwise I’m not reading it.  APT is not a one-for-one substitute, although it’s close.
8. You must show your boxes replacing your competitor’s boxes in an abstracted network diagram.  If your product is only software, you should still use boxes.  Virtualized appliances should be depicted by cloudy boxes.
9. Please include some fancy transitions or build sequences so that I can watch them break, or miss them altogether, during an online presentation.
10. And finally:  I cannot take your presentation seriously without military references, a fortress metaphor, or an onion metaphor (depicting defense in depth).

Now, if you're feeling especially ambitious and would like bonus points, I would love to see:

1. The classic "risk = vulnerability x impact" equation.  I just can't get enough of that one.
2. Carefully chosen quotes from a couple of bank customers saying how wonderful your product is.  Because I hadn't been planning to buy until I saw those. Banks always know what they're doing.
3. A description of your bad-ass threat researchers, whose continuous stream of published vulnerabilities and exploits makes my job as CISO so much easier.
4. Add a percentage figure to your "low false positive" rate.  Better yet, make it zero; that saves us all time.
5. A reference to Kevin Mitnick is just the cherry on top.

Thanks for tuning in, and I look forward to the next 24-megabyte PowerPoint file in my inbox.

Conferring about conferences.

There's a great discussion going on right now on Twitter about what's wrong with security conferences:  do we have too many?  Are they focusing on the wrong things? 

Josh Corman threw out the figure that more than 60% of conference paper submissions these days were on Android security issues.  This sounds pretty excessive when you consider all the other security topics out there.  However, let's not forget that there are many different audiences for security talks, just as there are different sub-communities within the security industry.  For "breakers," Android security is a hot topic these days, and you would expect to see a lot of talks on mobile security in general at conferences "by breakers, for breakers."  And because that's a hot topic among breakers, you'll see defenders and builders eyeing it as well, because in the security ecosystem, what's getting targeted the most is what everyone will tend to focus on.

That's not to say that security conferences are homogeneous.  There is a very different culture and flavor at work at a conference for defense-related security (law enforcement and military, and to some extent critical infrastructure), as opposed to a meeting of financial services CISOs, or civilian government, or academia, or "hacker ethos" tribal gatherings.  Even if the hot topics are nominally the same, the perspectives and timbre of discussions will be very different.  And a conference that features roundtable discussions will bring out information exchanges that aren't as readily forthcoming at classic "stand up and present" functions (even if you count the hallway track).

So even though the sheer number of security conferences these days is dizzying, I think the variety is healthy.  We need the grass-roots B-Sides just as much as the vendor-oriented RSA, or the raucous Shmoocon, or the Chatham House Rules-driven CISO roundtable.  If anything needs to be changed or tweaked, I simply think that we need to make sure that the same speakers aren't touting the same perspectives at all of these different venues.  Everyone wants to hear a sexy war story about mobile every so often, but I really admire the efforts to bring in first-time and local speakers to certain events as well.  The "democratization" of security conferences is a trend that I'd like to see continue.

Too many questions.

As an analyst, I have too many things I'd love to research and can't.  I'm in a target-rich environment (then again, so was Custer).  It doesn't stop me from coming up with questions, though, and hoping someone else will want to answer them.

Take the discussion I just had on Twitter with @jeremiahg, @chriseng, @attritionorg, @dakami, @rybolov and others.  I objected to the claim that everyone in the Fortune 500 is hacked, in the absence of two things:

1. A clear definition of "hacked," and
2. Some data supporting the assertion that everyone in the F500 fit that definition.

So we got to talking about what data would constitute proof, and I suggested that having one host in your IP range detected as being a member of a botnet could qualify as "hacked."  This could theoretically be straightforward to determine, if you had access to enough threat intelligence feeds and/or had enough sensors to compile a list yourself.  Now, there are some open source feeds, but for the most part companies that create their own feeds want to monetize them. (One laudable exception is Microsoft, which has been testing a feed that it would offer free of charge to law enforcement, CERTs, foreign governments and private corporations.)  If you have one machine on a botnet at some point in time, that could designate you as hacked, at least until you scrubbed it. 

But is it the tip of the iceberg?  Does having a bot automatically mean that more nefarious things are going on besides just selling V1agr4 or perhaps DDoSing the Anonymous target of the week?  This is the risk calculation that we need more data to perform, and it's one that the C-suite would really appreciate.

So I'd love for someone to comb through their incident response data and present statistics on what, if anything, followed after an initial malware infection.  If you could say that (for example) 70% of the time, it was simply used to grab CPU without necessarily trying to grab passwords or data, and 20% of the time it led to password compromise for financial theft, and 10% of the time it led directly to IP theft, those would let us infer probability.  It would depict in a more concrete way just why being part of a botnet is a symptom of something more dangerous.

By association, any company that found itself with membership in a botnet could reasonably suspect that it was even more compromised than that.  It might take the time to look further.  (There are plenty of enterprises that just wipe the affected machine, re-image it, and go back to work.)

The other question is whether membership in a botnet should be considered public data.  If anyone on the Internet can discover it, you could argue that it's the kind of compromise that anyone can report.  The fact of an enterprise's system interacting with another host on the Internet isn't confidential; it (like a public posting) is just assumed to go unnoticed.  Would a company have grounds to complain if its membership in a botnet were revealed, based entirely on publicly available information outside of its private network?  I am not a lawyer, but sometimes I want to ask lawyerly questions like this.

Following this chain of thought, anyone could set up sensors, collect data on botnet membership, and publish it widely.  Someone could collect statistics on just how many of a company's systems were in a botnet at any given time.  In the absence of any other data, could this be used as a poor man's Compromise Index?  It would be like someone noting how many broken windows you could see in a building: one indication of a breach, but without any way to know what, if anything, happened or was taken after the windows were broken.

And armed with that data, someone could actually make a substantiated claim that the whole Fortune 500 is hacked, without hearing the clackety-clack sound of thousands of eyes rolling.

After that comes the question, "So what?"  Would this kind of naming and shaming prompt any additional diligence on the part of these organizations?  Would it make regulators sit up and take notice?  Call me a skeptic, but I suspect that botnet membership is so widespread that people would assume it happens to everybody -- just like ant invasions -- and it wouldn't be condemned except within the security echo chamber.  I could be wrong.  Either way, I'd love to find out.

[DISCLAIMER: I am not encouraging anyone to compromise any systems themselves without the permission of the affected organizations.  I am not suggesting that anyone collect data that can only be gathered directly from those systems.  I am certainly not recommending that anyone leak confidential data, even if it's with the best of intentions.  Do not try this at home.  Ask your parents before calling.  And so on.]