OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: WAS Classification Thoughts from Rick Carlton


As there has been little debate I am going to move to suggest we adopt the scheme I proposed and start creating content. Lets close out on Tuesday of next week and then move forward unless anyone has any other ideas....

----- Original Message ----- 
From: RCarlton@eteam.com 
To: Mark Curphey 
Sent: Thursday, July 31, 2003 1:15 PM
Subject: Re: [was] Classification Thoughts


Hey Mark,
 
I responded to your stream of consciousness with some thoughts of my own below.

R.A. Carlton
Vice President  - Strategic Technologies
Chairman EMIF - Sub Committee
949.433.4127 mobile
949.646.8853 land line


PRIVILEGED - PRIVATE AND CONFIDENTIAL

This email and any files transmitted with it are intended solely for the use of the addressee(s) and may contain information which is confidential or privileged. If you receive this email 
and you are not the addressee (or responsible for delivery of the email to the addressee), 
please disregard the contents of the email, delete the email and notify the author immediately. 
Before opening or using any attachments, please scan them for viruses and defects. We do 
not accept any liability for loss or damage, which may arise from your receipt of this e-mail. Our liability is limited to re-supplying any affected attachments.



-----"Mark Curphey" wrote: -----

To: 
From: "Mark Curphey" 
Date: 07/31/2003 08:37AM
Subject: [was] 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.

I view these two nouns as clearly different. At the highest level a dictonary could be classified as a "taxonomy," I guess, but only to the extent that it orders a larger collection of taxonomys. Sort of like a candy box that contains a hundred individually wrapped pieces.

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. 

Problem here is that threats and their axes are purely subjective and to large degree based on the specific operating and configuration vulnerabilities of a particular system or network, or the turgid and active intellect of the hacker community. Since, the permutations of how poorly operators can potentially screw up perfectly good baseline systems appear inifinite, I'd be careful trying to "order" elements in too granular a fashion lest we find ourselves in situation where we think we've thought of everything - and haven't. Maybe better to do a gross list of high level categories with lots of wiggle room for ad hoc specifics, i.e. "Denial of Service etc.," under which all the flavors could fall as necessary.   

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.

...and the wider interconnected community? "When a butterfly flaps its wings in Africa it rains in New York?" Given the rapid emergence of system to system integration it is entirely possible that a failure in Node 1 on one continent, could ultimately result in a spontaneous failure in Node 21 on another - for no apparent reason.

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

...or not. Are all things "security" about attack? What about configuration error, a poorly conformed user registry, or a public-switch router table error? Columbia was lost because physical damage accruing to a 1.5 pound block of foam striking the leading edge of the wing was simply underestimated. Seems to me that the most  prudent approach to general security is to define "bags" rather than a "boxes." "Bags" stretch "boxes" break. 

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.

How many vulnerabilities can you fit on the head of a pin? That's always been my issue with theoretical models, they're effective in a vacuum, but rarely appliciable to the real world.

 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.

So, "YOU can lead a horse to water but sometimes YOU have to shoot him in the head?" Again, it seems to me that one will either have to subjectively apply general criteria or be forced to become VERY granular. I don't see a middle-ground yet. 

 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.

I entirely agree with this thinking. 

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 ?

I love working with engineers that take the concept of logical modeling literally. This is good baseline thinking in my view. Now, ya think you'll be able to herd all your cats into one corner of the room? :>)

Rick


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]