Tuesday 1 March 2011

Security-risk assessment, reinvented

InfoWorld Security Adviser Roger A. Grimes offers a tool for more accurately ranking the threat levels at your organization

I'm forever reinventing the wheel, and this time around, I'm focusing my efforts on the oh so exciting field of risk assessment. In the process, I try to put aside conventional wisdom and cultivate useful, independent observations that would not have been considered without the additional hard thinking. When going on my squirrel logic trails, I try to forget the older, acknoweldged model; I don't like it polluting my thoughts.

Regarding risk assessment, the well-publicized, traditional quantitative model -- R=L x %, or risk equals potential loss times likelihood of occurrence -- is a great place to start, but it's too simple. Its optimized ease-of-memorization summary also leaves out a lot of detail necessary for real-life threat modeling in the computer security environment. The more accurately you assess a risk, the easier it is to prioritize which one to tackle first.

[ Looking for more security tips? Start with the basics in Roger Grimes's guide to the seven types of malicious hackers. | Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

When I hear of a new threat or discover an exploited client, my mind begins to frame the risk with a bunch of common questions. I've never documented the mental questions on paper before, but this column is the result of my first attempt. The only problem? I possibly came up with too many questions to consider. The simple R= L x % model is starting to make more sense now.

Still, I want to share my risk-ranking model, in case it generates a better way of ranking real risk inside your environment. It starts with the following nine risk-assessment categories and their subsets:

Knowledge of exploit by possible attackers
Publicly known and not popularly used (higher risk)
Publicly known and actively used in wild (higher risk)
Privately known and not being used against customer (lower risk)
Privately known and being used against customer (highest risk)

Level of access required for attack
External access (higher risk)
Internal network access needed (medium to lower risk)
Truly remote (no end-user involvement needed) and cannot be easily automated (high risk)
Truly remote and can be easily automated (wormable) (highest risk)
Conventional remote (end-user involvement required) (medium risk)
Requires access to local network (low to medium risk)
Can only be accomplished using physical, local, logged-on interactive access (lowest risk)

Level of requires authentication of begin attack
Highly privileged account (admin, root, and so on) (lower risk)
Standard user (medium to high risk)
Anonymous user (high risk)
No authentication needed (highest risk)

Reliability of exploit code against intended target systems
Unstable, rarely successful (low risk)
Relatively stable, usually successful (high risk)
Highly stable, almost always successful (highest risk)

Ease of detecting exploited system
Easy-to-detect problems (lower risk)
Moderate signs and symptoms (medium risk)
Invisible or silent, system functions apparently normal (high risk)

Payload for successful attack (detailed version)
Full compromise (highest risk)
Privilege escalation (high to highest risk)
Session hijacking (medium to highest risk)
Access to protected information (medium to highest risk)
Denial of service (medium to highest risk)
Damage to low number of assets (lower risk)
Access to large number of additional assets (high risk)

Payload for successful attack (alternate version)
Low damage (low risk)
Medium damage (medium risk)
High damage (high risk)

Available mitigations
Patch available directly from vendor (lower risk)
Patch not available directly from vendor or third party (higher risk)
Patch available from third party (medium risk)
Easy-to-deploy nonpatch mitigation available (low risk)
Complex nonpatch mitigation available (higher risk)

Likelihood of exploitation being used against target environment
Actively being used (highest risk)
Likely to be used (medium to high risk)
Unlikely to be used (low risk)
Cannot be used (lowest risk)

Wow, that's a lot. See what I mean?

To make it a little easier to use in the real world, I created a spreadsheet that helps calculates a threat's overall risk, on a scale of 1 to 5, with 5 being the highest criticality. To use the file, fill in the relative ranking that each question's outcome has to your overall risk decision. (I weighted each of the nine main categories evenly at 11.1 percent.) Rank each component on the five-point scale; your category rankings and risk ratings per question should lead to a final value, located in the bottom-right cell.

In the spreadsheet, I included a sample worksheet based upon a recent Microsoft vulnerability announcement. My example calculated outcome, a 3.6, indicates that the vulnerability is medium to high risk in my environment. It should be patched relatively soon, as Microsoft also asserts.

No doubt I've done more than a little reinventing the wheel here, but this more in-depth analysis helped me to confirm what I previously felt in my gut. Hopefully, I've added at least one component for consideration to your already existing risk model.

No comments: