[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [was] Blended threats
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]