Risk Management 103 – Choosing Threat Agents

A key component in deciding a risk is WHO is going to be doing the attack. The above image is from the excellent OWASP Top 10 2010, and I will be referencing this diagram a great deal.

We’re talking about the attackers (threat agents) on the left today. So you’re busy doing a secure code review or a penetration test (how I loathe that term – so sophomoric) and found a weakness. You’ve written up a fantastic finding and need to rate it so that your client (whether internal or external, for money or for free) can do something about it. It’s vital that you don’t under or over cook the risk. Under cooking the risk looks really really bad when you get it wrong and the wrong business decision is made to go live with a bad problem. Overcooking the risk erodes trust, and often leads to the wrong fixes being made or none at all, which is worse. You can tell if you’re overcooking a risk if your clients are constantly arguing with you about risk ratings. Let’s get to a more realistic risk rating first time every time.

Risk Management 103 – Establishing the correct actor

I am more likely to be successful than a script kiddy who is more likely to be successful than my mum. Unfortunately, there’s just one of me, but there’s a million script kiddies out there. That doesn’t mean you should use them. Script kiddies are simply unlikely to find business logic flaws and access control flaws, such as direct object references. So you should reflect this in your thinking about risk – even though it might be simpler to go with what everyone already knows:

• Skill level – what sort of skill does the threat agent bring to the table? 1 = My mum. 5 = script kiddy (generous), 9 = webappsec master
• Discovery – how likely is it that this group of attackers will discover this issue?
• Ease of exploitation – how likely will this group of attackers exploit this issue?
• Size of attacker pool – 0 – system admins or similar, 9 – The Entire Internet (==script kiddies)

So you need to do the calculation for the weakness you found for these various groups to determine the maximum likelihood. This often leads into impact. Let’s go with an indirect object reference, such as the AT&T attack

Likelihood – AJV

• Skill level – 9 web app sec master
• Motive – 4 possible reward
• Opportunity – 7 Some access or resources required
• Size – 9 anonymous internet users (remember, this attack relied upon a User Agent header for authentication)
• Ease of Discovery – 7 easy
• Ease of exploit – 5 easy
• Awareness – 9 public knowledge
• IDS – Let’s go with Logged without review (8)

This brings us a total of 54 out of 72. I put this as a “HIGH” likelihood in my risk charts.

Likelihood – Script kiddy

• Skill level – 3 some technical skills (script kiddy)
• Motive – 4 possible reward
• Opportunity – 7 Some access or resources required
• Size – 9 anonymous internet users (remember, this attack relied upon a User Agent header for authentication)
• Ease of Discovery – 1 Practically impossible
• Ease of exploit – 1 theoretical
• Awareness – 1 Unknown
• IDS – Let’s go with Logged without review (8)

This brings us to 34. So we shouldn’t consider script kiddies when there might be a motivated web app sec master on the loose. But is that entirely realistic? Honestly, no.

Who is really going to attack this app?

Think about WHO is likely to attack the system:

• Foreign governments – check.
• Web app sec masters – Our careers are worth more than the kudos.
• Bored researchers trying to make a name for themselves – check even though quite dumb (see previous bullet)
• Script kiddies – check but fail. Realistically, unless someone else wrote the script, they wouldn’t be able to do this attack.
• Trojans – check but fail for the same reason as script kiddies.
• My mum doesn’t know what a direct object reference is. Not going to happen.
• Terrorists – check, but seriously, remember dying by winning lotto, buying a private plane with the lotto winnings, having the plane struck by lightning on its four leave clover encrusted hull eight times, parachuting out and then for the main and the secondary to both fail is more likely than a terrorist attack. Don’t use this unless you’re after Department of Homeland Security money as everyone else will just laugh at you. Especially if you use it more than once.

So let’s go with #1 as this is an attack that they would be interested in. They have resources and skilled web app sec masters, so this attack likelihood is a HIGH. So let’s work out the impact for this scenario:

Sample Impact Calculation

There’s a lot of subjectivity here. You can close that down significantly by talking it over with your client. This doesn’t mean you should go with LOW every time you have the conversation, but instead set out objective parameters that suits their business and this application. Yes, this takes a fair amount of work. You can either do it before you deliver the report, or you can do it after you deliver the report. If you choose the latter path too often, your reputation as a trusted advisor can be found in the client’s trash bin along with your reports and the client relationship.

Let’s do the calculations based upon the sketchy information I have from third hand, unreliable sources and vastly more reliable Tweets. i.e. I’m almost certainly making this up, but hopefully, you’ll get the picture.

• Loss of confidentiality. Check big time. All data disclosed (9)
• Loss of integrity. In this case, no data was harmed in the making of this exploit 0
• Loss of availability. If every government tried it at once, I’m sure there’d be a DoS but let’s be generous and say minimal primary services interrupted (5) as the system would have to be taken offline or disabled after it was discovered
• Loss of accountability. It’s already anonymous, so 9
• Financial damage. AT&T is big. Really really big. In the grand scheme of things, this probably didn’t hurt them that much. That said, it has to be in the millions. So let’s go with Minor effect on annual profit (3)
• Reputation damage. AT&T’s reputation is somewhat already tarnished, so let’s go with loss of major accounts (4) as I’m sure RIM will pick up all of those .mil and .gov accounts very soon now.
• Non-compliance. PII is about names and addresses, but AFAIK, e-mail addresses are not protected at the moment. Happy to hear otherwise – leave comments. Let’s go with “clear violation” 5
• Privacy violation. 114,000 is the minimum number, so let’s go with 7 and it could tip towards 9

This gives us 42 / 72, which is a MEDIUM impact (just shy of “HIGH at 46), giving an overall risk of HIGH. That is about right, and thus should have been caught by a secure code review and fixed before go live.

Next … Risk Management 104 – Learning to judge impacts