Fw: [was] Blended threats

["Mark Curphey" <mark@curphey.com>]

In case it didnt make it through ;-)

----- Original Message ----- 
From: "Brass, Phil (ISS Atlanta)" <PBrass@iss.net>
To: <mark@curphey.com>
Sent: Wednesday, July 23, 2003 11:50 AM
Subject: FW: [was] Blended threats


I forgot to enable my oasis account so this got bounced from the list.
Feel free to edit/post if you like, just a reflection on the months I
spent developing a classification for all the RealSecure IDS events...

Phil

-----Original Message-----
From: Brass, Phil (ISS Atlanta) 
Sent: Thursday, July 17, 2003 3:27 PM
To: 'Nasseam Elkarra'; was@lists.oasis-open.org
Subject: RE: [was] Blended threats


Note that CodeRed is a threat, not a vulnerability.  Doesn't mean there
aren't blended vulnerabilities though.  The most classic blended
vulnerability is the one that sits in front of a monitor, keyboard, and
telephone, and believes everything they read and hear ;)

My experience with classification comes from devising a classification
system for all of our RealSecure events, which is now used by Fusion 2.0
to recognize certain attack patterns without needing to know the details
of specific events.

One thing I learned during that time was that one of the biggest threats
to a classification system is subjectivity.  In an organization where
five people are going to be classifying events, and not always the same
five either, it is important that objects be classified consistently,
and it is best if there is a quick way to settle any disputes about how
something is classified.  I found it was easiest to have categories that
were closely tied to observable phenomena, and a specification of what
observation should be made for an object to be slotted into a particular
category.  

For example, on the event side, if an event is to be stuck in the remote
root exploit bin (to pick a simple one), it should get flagged when I
exploit the vulnerability and get some kind of remote root access.  If
there is disagreement about whether it belongs in that bin, it can be
tested by going to the lab, exploiting the vulnerable server, verifying
that the event is generated, and verifying that you got root (as opposed
to "nobody" or "whoever apache is running as").

Another thing I learned is that security information is
multidimensional, and it makes sense to consider separate
representations for separate dimensions.  For example, separate
categories (MECE frameworks or strict taxonoma or whatever) of
information for target of exploit versus impact of exploit versus cause
of vulnerability, etc.

Also, when it comes to retrofitting a classification system onto an
existing set of security sensor information, you are likely to find that
sensors will report "atomic" events/vulns that really have multiple
meanings - a single event may mean that several things have happened, a
single vulnerability record may really signify a bunch of different
vulnerabilities or ways to exploit (NT4 SP3 not applied, for example.
I'm so glad I didn't have to classify all the vulns...)  So in addition
to allowing some multidimensionality, it may be useful to allow multiple
classifications to be attached to a single "vulnerability", depending on
whether you control the set of vulnerabilities or you are using or
interacting with somebody else's set.

Perhaps most importantly, I learned that it is very useful to know who
is going to be using this information, and what they need to do using
it.  A lot of the lessons I learned are probably specific to creating a
system that is going to be maintained by diverse people, used by
software programs for a specific purpose (pattern recognition), and
oriented towards a specific target.  

Of all these lessons, I would say that one that helped me the most was
tying categories to observable phenomenon.  I could spin pretty stories
about classification systems all day, but as it got pushed closer and
closer to production the biggest pushback from both producers (X-Force
people classifying information) and consumers (Fusion, Sensors) of the
information was that it be as divorced as possible from subjectivity, so
that it could be internally and externally consistent.

'Nuff said :)

Phil Brass
Senior Security Consultant
Internet Security Systems

> -----Original Message-----
> From: Nasseam Elkarra [mailto:nelkarra@opensec.org]
> Sent: Thursday, July 17, 2003 12:35 PM
> To: was@lists.oasis-open.org
> Subject: [was] Blended threats
> 
> 
> The CodeRed worm is a good example of a blended threat
> because it performs multiple attacks on different components.
> 
> It exploits a buffer overflow vulnerability, defaces the
> website of the exploited machine, attempts to spread to other 
> machines, and causes system instability.
> 
> It is more than a buffer overflow as someone mentioned in the
> call and can fit into more than one category. However, 
> blended threats usually have an entry point. In this case, 
> the buffer overflow provided CodeRed the necessary privileges 
> to perform the latter attacks. In scenarios like this, we can 
> try to classify the threat in multiple categories or simply 
> focus on the entry attack.
> 
> I imagine an assessment checking to see if a system is
> affected by CodeRed would perform an HTTP request and analyze 
> the response. In this case, the assessment would check if the 
> buffer overflow problem is present so this easily fits in the 
> overflow category. Maybe we can work backwards and start from 
> the assessment because whatever the assessment is checking 
> for is the category.  
> 
> If we want to discuss CodeRed, we should probably look at
> what Microsoft and eEye(they discovered the problem) had to 
> say about it.
> 
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/secur
ity/bulletin/MS01-033.asp
http://www.eeye.com/html/Research/Advisories/AL20010717.html

Symantec also has some good whitepapers about blended threats:
http://securityresponse.symantec.com/avcenter/whitepapers.html

Finally, I am still trying to understand the goals of WAS and how things
will fit together. Someone mentioned playing with the XML format early
to try to encode our thoughts. I think this would be a good idea to help
us visualize our goal and make sure we are all on the same page.

Thanks,
Nasseam Elkarra
nelkarra@opensec.org


---------------------------------------------------------------------
To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: was-help@lists.oasis-open.org