Classification Thoughts

At the last meeting we all struggled to get to grips with what a classification scheme actually is, the difference between a classification scheme and a taxonomy; and with mental challenges around how it would all fold up into a higher level message.

I thought I would spend a few minutes and put down my thoughts and see if we can all agree on a way to move forward.

I don’t claim these to be the answers just my thoughts in bits.

After the meeting I spent some time in dictionaries and tried to understand if there is a difference between a dictionary and a taxonomy and go back to basic of what we are trying to do with the classification scheme.

As you recall the aim of this part of the project was to create a set of common descriptions for problems so we could avoid the issue of one vendor called the same attack “Database Sabotage”, another calling it “SQL Injection” and another calling it “Direction Database Injection”.

In that respect the need for ordering of list elements was not a requirement but I see (and agree) that an ordering system or at least the ability to order the list would be very beneficial, especially for tools or researchers who are looking for vulnerabilities that may be realized under specific conditions.

It helps me to define a few terms and maybe we could all agree on a few terms as well ?

Vulnerability - a security vulnerability is a flaw within a software system that can cause it to work contrary to its documented design and could be exploited to cause the system to violate its intended security policy.

http://www.oisafety.org/process.html#_Toc42474363

Threat is the probability of an instance of a vulnerability being realized.

Impact – is the consequence to the end system and / or its users.

Attack - is an instance of a vulnerability (or several vulnerabilities) being realized on a system or systems.

This stays in line with the widely accepted basic risk model that risk is a function of the number of vulnerabilities, the number of threats and the business impact to the system and allows us to place theoretical financial constraints on the basic model.

So if you buy this, you could extrapolate and say any classification scheme would want to cater for the threat and also the impact and ultimately attacks that leverage these components. Think the risk ranking model may help here.

This leads me to thinking that we should NOT get wrapped up in a well defined hierarchy, but create an extensible scheme with attributes that would allow consumers to sort and search for vulnerabilities based on defined criteria and create their own heierachies.

Let me illustrate an example.

Cross Site Scripting

When looking for cross site scripting issues, I would be more interested in knowing that the impact is a transfer of trust, must be used in conjunction with a payload and that it can occur at any data boundary to the system that processes structured markup languages. This would lead me to start looking at XML data feeds, process privileges of parsing components etc and ultimately may start me thinking about how to build attacks specific to a system.

So what I am advocating we do is to create the atomic components that can not be broken down any more, document them and define a set of attributes such as

Needs payload

Passes System Boundaries

Can Escalate privileges

Passes Trust

….as examples

This is essentially what we did at OWASP although we never built a hierarchical instances because we never defined the criteria above.

An example of one hierarchy that someone may wish to build from this may be to say, show me all attacks that could escalate system privileges, or show me all attacks on the system and all attacks on the user. Show me all attacks that leverage poor input filtering.

So I guess the question is what does everyone else think about this ?

If its worth pursuing then I would suggest we define the attributes and the atomic components next and see how things look.

Any thoughts ? Better ideas ?

was message