Have you ever thought to yourself - "How do they decide what's Critical / High / Medium / Low in the security defect findings?"
If you have then you're not alone. I get asked that question on a regular basis, and unfortunately the answer is not what I would like it to be. You see, risk-ratings on security defects (I'm using defects vs. vulnerabilities here purposefully... if you follow my talks/posts you already understand why, if not, read some of my earlier posts to catch up) are black/white when it comes to a tool (like WebInspect) which does automated analysis. The reality is, a tool can't make a conscious decision on a defect rating because (a) it requires conscious thought, and (b) it requires analytical skills a machine won't possess. This leaves us with an interesting situation where "SQL Injection" is always considered a critical defect, right?
As far as tools are concerned (and this is a limitation of finite-state machines) that SQL Injection defect is always critical, on matter what the context.
Given that we want to do a more, logic-based approach to security defect ranking/rating, we need to understand what exactly that requires. Here's my proposal (rough draft for now, until I get some more momentum) on what the context of a security defect should be:
- Criticality of the containing application (business-critical or not?)
- Sensitivity of the data a resultant exploitation would lead to (customer-credit information? medical information? brochureware?)
- Placement of the defect (landing page? buried in an administrative interface requiring multi-stage authentication, etc)
- General exploitability (XSS is generally easy to exploit, whereas, buffer overflows are not...)
There you have it. Obviously this is grossly over-simplified for now, and a significant amount of work needs to be done to standardize, re-word and further formalize the contextual parameters of security defects - but I think that doing this work is paramount in order to start to understand the concepts of risk analysis better. How can you present security risk to a CIO when you have no idea what the actual risk context is?
If you'd like to participate, or have done work in this area already please ping me directly and I will contact you. This is a critical area of research and it requires the input of business... otherwise vacuum-think is relatively useless and we'll have more of what we have now - defects without context.
Thanks for reading!
Posted
10-31-2008 5:51 AM
by
RafalLos