Naturally, people wanted to know how it was done. A Twitter blog entry provided some vague detail:

The issue with these 33 accounts is different from the Phishing scam aimed at Twitter users this weekend. These accounts were compromised by an individual who hacked into some of the tools our support team uses to help people do things like edit the email address associated with their Twitter account when they can’t remember or get stuck.

What’s interesting about that paragraph is that the celebrity account hacks were not related to the phishing attacks, as one might assume, and they had nothing to do with an exploitable vulnerability in the Twitter app itself. Just a case of somebody getting hold of an admin account. Ho-hum.

Tonight, the “hacker” explained to Wired Magazine how he did it. I’ll try to summarize the attack, but you might have to read it several times because it’s subtle and complicated. Ready? Brace yourself… He used a dictionary attack to brute force a password.

Continue reading here after you’ve picked yourself up off the floor. Here’s the money quote:

The hacker, who goes by the handle GMZ, told Threat Level on Tuesday he gained entry to Twitter’s administrative control panel by pointing an automated password-guesser at a popular user’s account. The user turned out to be a member of Twitter’s support staff, who’d chosen the weak password “happiness.”

Now let’s consider the application security best practices that Twitter could have followed when designing their service, any of which would have foiled the attack.

• Password complexity. In case you were wondering, the only restriction on Twitter passwords is a minimum length of six characters. No mixed case, no numbers, no special characters, none of that. Although they do encourage you to “Be tricky!”
• Brute-force protections. Clearly there’s no account lockout mechanism, unless of course “happiness” was at the top of the word list. While there is no perfect solution to brute force attacks, it would appear Twitter didn’t even try.
• Segregation of administrative functionality. I won’t underestimate the amount of effort required to segregate the admin interface. That being said, the attack would’ve failed if Twitter admins had to perform privileged functions via a dedicated internal interface.

Any others? Leave them in the comments.

In all fairness, it’s hard to make security a top priority in ANY company, much less a startup with overworked non-security-aware developers using an agile methodology with tight iterations (making some educated guesses here about Twitter). Ideally you want to start prioritizing security before you become an attractive target. Twitter missed the boat on that one, but I bet they’re paying attention now.

At one point he asked: “Who likes their Information Security guy ?”

I raised my hand, to which he quipped: “Well, they aren’t doing their job then!”

To which I quipped: “Actually I do my job quite well.”

Stereotypes…

In ancient times skillful warriors first made themselves invicible,

and then watched for vulnerability in their opponents…

- from “Formation”, Art of War, Sun Tzu, 6th century B.C. 

“Invincibility” comes at a pretty significant cost.

Pro Dev: Who are We? What is Our Role?

The Reality Check Podcast with Gary McGraw focuses directly on software security practitioners and practical software security. Reality Check’s sister podcast, the Silver Bullet Security Podcast with Gary McGraw, follows a free form interview style tailored highlight the ideas and experience of security gurus. By contrast, Reality Check is concerned with practical questions centered on running large-scale software security initiatives in the real world.

Reality Check targets experienced leaders working to solve software security problems in large organizations every day. We use a standard script to guide each conversation with questions about history, methodology, best practice, and measurement. We plan to interview leaders of mature software security programs and leaders of programs just getting started.

The beginning of a reasoned response was written by Aleks  on Andrew Gelman’s blog (http://www.stat.columbia.edu/~cook/movabletype/archives/2009/01/dont-blame-it-o.html).

Long-time readers of this blog will recall that I believe that Risk Estimation != Risk Management.

We security professionals have a really good idea of why Risk Estimation is not all there is to the management of risk based on our experience.  You, smart  guy or gal that you are, know that having a control in place, or even having a point-in-time positive test of that control’s effectiveness does not make you ’secure’.  It’s some evidence of security, sure.  But there are other variables that we must understand, like the ability of the threat to overcome/bypass the control, the skills and resources of those operating the control, our ability to properly manage those people, etc. These things all contribute to security (and therefore, ‘risk’).

Similarly, if Wall Street folks were only using VaR as a means to understand their portfolio risk, or just plain lazy while the market kept going up, that’s not necessarily a failure of risk estimation or risk analysis as it is of risk management.  But some very high profile critics of Wall Street are focusing on the means of estimation that VaR produces, and not the deficiencies in the concept of risk management.  The article does say one or two things about that:

You face the risk that, in the current state of the world (assuming you can estimate that perfectly), an unlikely event will occur. You also face the risk that the state of the world will change. VaR … can quantify the first risk, not the second.

And understanding the”risk” (what a poor choice of words there, mixing and matching terminology) of that change and our ability to adapt to it is the essence of risk management.  So speaking of the fact that Risk Estimation != Risk Management,  I finally got around to reading:

INTERNATIONAL STANDARD ISO/IEC 27005
First edition 2008-06-15
Information technology — Security techniques — Information security risk management
Technologies de l’information — Techniques de sécurité — Gestion du risque en sécurité de l’information

As you can probably guess, I’ve got opinions.  And since we’re both here (me writing, you reading) why don’t I let you know what those are.

I have a few disagreements:

ISO 27005 IS NOT ABOUT THE MANAGEMENT OF RISK

First, in agreement with our discussion above, is that 27005 has very little to do with the actual management of risk.  It’s really an issue management framework where we create a statement about risk for a very particular scenario, and then tie a Plan-Do-Check-Act cycle to the back of that wagon with the hopes that the issue doesn’t become “red” again.  27005 suffers from the same problems as those who on Wall Street who over-relied on VaR as the end all of Risk Management.  It’s whack-a-mole with a hamster-wheel-of-pain sprinkled on top, and does very little to address the root cause of risk - deficiencies in our capability to manage risk.

ISO 27005 HAS ITS PRIORITIES BACKWARDS

Second, and probably due to this inaccurate view of risk management, is their discussion on the purpose of risk management.  I believe that the purpose of risk management is to align the risk exposure of an organization to that organization’s risk tolerance.  The ISO, not so much.

In section 7.1 (which seems awfully late in the document to start discussing the reason we’re all here today) 27005 states:

It is essential to determine the purpose of the information security risk management as this affects the overall process and the context establishment in particular. This purpose can be:

• Supporting an ISMS
• Legal compliance and evidence of due diligence
• Preparation of a business continuity plan
• Preparation of an incident response plan
• Description of the information security requirements for a product, a service or a mechanism

This is all kind of backwards to me.  An ISMS, BCP, or IRP are not *reasons* for risk management. Rather the management of risk is a reason to have an ISMS, BCP, or IRP (or not have one, depending on the organization’s tolerance for risk).  Similarly, compliance and due diligence are executed because executive management has no tolerance for adding those sorts of losses to the risk they already face.

ISO 27005′S VIEW OF THE ROLE OF ASSETS IS FLAWED

Now with those two disagreements behind us, I actually have very little critique of section 8.2 - risk analysis.  I could launch into a rather wonkish discussion about controls and vulnerability and talk at length as to why FAIR provides better definitions, but I think these differences are less important because the fundamental differences in these differences are less pronounced than other significant deficiencies.  Deficiencies such as the one we’ll find in 8.2.1.2 -

8.2.1.2 Identification of Assets.
An asset owner should be identified for each asset, to provide responsibility and accountability for the asset.

Great, as long as the asset owner is really in the line of business that the asset generates revenue for.

The review boundary is the perimeter of assets of the organization defined to be managed by the information security risk management process.

WHOOOOAAAAAAAAAA! - This “Review Boundary” you speak of is dynamic.  Think Jericho.  Think Vendor Management.  Think 100,000 user networks in which 60,000 of the users are not w-2 employees.  Think of “The Cloud” (won’t someone please think of The Cloud?).

Consider the following - malware infects home PC, home PC used to capture home banking creds.  Those creds are then used to create fraud.  Bank is effected, but the Point of Attack (home PC) is not bank owned.  According to ISO 27005, this isn’t an important source of risk, as you’re not expected to measure it.  I really think there are problems with completely ignoring the fact that assets we don’t directly manage contribute to the amount of risk we have.

DESPITE ALL THIS, 27005 IS FORGIVABLE UNTIL YOU REACH THE ANNEXES

Next, lets talk about the annexes.  To be fair (*cough*) without the annexes the ISO isn’t a bad ’standard’.  It is purposefully vague where it needs to be vague, and purposefully specific where it needs to be specific.

Unfortunately, someone thought that we needed more direction and tacked on several annexes.  The first problem with these annexes is that they’ll be taken for gospel even though they are meant to be “informative”.   And if they were any good, that wouldn’t be so bad.  However the threat and asset valuation ones are disturbingly average for our industry, which is to say, not well thought out at all.  And in some places these annexes are just wrong.  To whit: Annex E page 50 asks you to perform mathematical functions on ordinal values:

The third step is to calculate the measure of risk by multiplying (b × c).

I just multiplied Peanut Butter by Airplane and that equals 723.58!

THE BIG PROBLEM

My final problem with 27005 is that it just wasn’t needed.  It doesn’t really add anything remarkable or special that we don’t already have in place in any number of other documents and standards.  It would seem that its only demonstrative use is for the purposes of auditing to standard compliance.  And I have to think that this is really what this document is all about, something more to serve the ISMS and the cottage industry that surrounds it.   And that’s a shame, because the field of risk management could really use someone like the ISO really putting forth a significant and good effort.