Re: threat/attack nomenclature/reporting / IDMEF

From: Azim, Ozakil (azim@netForensics.com)
Date: 03/28/02


Date: Thu, 28 Mar 2002 15:27:32 -0500
From: "Azim, Ozakil" <azim@netForensics.com>
To: "Matthew F. Caldwell" <mattc@guarded.net>, focus-ids@securityfocus.com


   I got carried away and talked about threats in the same
   breath as vulnerabilities and forgot to mention risks
   altogether :)

   hope this is clearer:

   Instead of seeing a running list of alerts that say
   'IIS unauthorized ODBC data access with RDS' or
   'W32/Porkis-A' or 'TCP Frag FIN Port Sweep', I would
   prefer to see a 'Application Exploit/Virus/Reconnaisance'
   alert (with associated risk/value of assets/threat
   assesment etc. ofcourse). The specifics of an alert are
   important and should be there - but they may not be
   required when reporting the big picture.

   IDMEF has a 'Classification' Class, associated with the
   'Alert' Class, that allows the alerts to be named/classified
   based on origin ('cve/bugtraq/vendor-specific/unknown').

   It would be nice if there were an additional type
   of 'origin' which classified alerts into higher
   level 'categories' like 'Web Server Exploit' or 'IIS Exploit'
   or just 'Application Exploit'. The names themselves
   do not matter as long as they become part of an industry
   vocabulary (they do have to be meaningful though). We
   can have sub-categories to provide an intermediate
   level of detail or go the whole hog and have an n-level
   tree of categorization like
   "AppExploit->Windows->WebServer->IIS Exploit"

   IDMEF also has a 'type' element in the 'Assessment->Impact' class,
   which has six categories of attempts represented by an alert -
   'admin/dos/file/recon/user/other'. These are helpful in
   categorizing alerts but are quite limited in their scope.

   Ideally, I would like to be able to create a rule that would
   take action only when I have a IIS attack on an unpatched
   IIS server. This can happen only when the alerts being reported
   conform to a standard vocabulary and do not change with the
   discovery of each new attack.

Matthew F. Caldwell wrote:

> -----Original Message-----
> From: Azim, Ozakil [mailto:azim@netForensics.com]
> Sent: Thursday, March 28, 2002 10:16 AM
> To: Matthew F. Caldwell
> Cc: Jared A. Tucker; eddonega@WellsFargo.COM; Keith T. Morgan;
> xwu@anr.mcnc.org; focus-ids@securityfocus.com
> Subject: Re: threat/attack nomenclature/reporting [was Re: IDS
> Correlation]
>
>
> well.. this thread seems to be drifting from the original
> question that Keith had regarding 'standard threat/attack
> nomenclature/reporting' to IDMEF to new RFCs etc.
>
>
> So here is a slight change in subject and my two
> cents/lira/paisas worth... :)
>
> Correct me if I am wrong; from what I have been reading,
> I think that we are talking about two things here:
> 1) Threat nomenclature normalization at a level higher
> than CVE/bugtraq etc.
>
> I assume your talking about Vulnerability Information, not threat. I don’t even think we are talking about this yet. IMHO this should be separated into vulnerability information DTD or MIB (discussed later) because this information lacks key items in the data reported such as source and destination IP address.
>
> 2) Standard security event formats that use the normalized
> nomenclature for reporting.
>
>
> the event format first:
> the IDWG doesn't seem to be interested in security events.
> at least not right now.
> (check http://www.semper.org/idwg-public/archive/0346.html)
> they are focussed more on IDSs, IDS alerts and IDS comm.
>
> Yes, but the format could easily be adopted and expanded to add or allow for more flexibility in data types.
>
>
> I agree that the biggest technical issue that has to be
> addressed when formalizing a security event format is performance
> as anyone perusing firewall logs will tell you (whether all
> firewall log data should be considered as security events can
> be the subject for another thread).
>
> I seriously doubt that sending XML tags in each event is going to work. For large enterprises it might not be acceptable. I have worked in several SOC's and the XML formats we used where only for displaying data. Since, XML over TCP can be bloated and doesn’t offer true security only add on security levels. I would like to suggest we use SNMPv3 with a descent MIB. This would allow for authentication and encryption of the data without the use of SSL which has it's own weaknesses.
>
> XML has a tendency to get bloated but it still can be used
> very effectively, with acceptable performance, if you use
> smaller tags, flatter schemas and compression.
> (the biggest non-technical issue will be - will everyone use it?)
>
> threat nomenclature:
> most security correlation vendors are dealing with the
> same issue of reducing a huge flood of events from
> various security devices (and almost daily signature updates
> from IDS vendors) into something which is concise, meaningful,
> and normalized in terms of the threat faced by the enterprise.
>
> It might make sense to create a common vocabulary that all
> vendors use for threats/security events - a vocabulary
> that doesn't have to change when new IDS signatures come up,
> a vocabulary that is consistent across all vendors, a
> vocabulary the enterprise security administrators can rely
> on.
>
> I guess i'm confused by your nomenclature, Your Threats = Vulnerabilities right? Usually when IDS signatures come out they don't change in any extreme fashion, this is easily accomidated. However, when new IDS's come out they have new signature formats which need to be accomidated or conformed to?
>
> but here are a couple of questions...
> The IDWG has been working on a common language for intrusion
> detection for over two years now. How many of the IDS vendors
> have implemented IDMEF/IDXP yet?
>
> SNORT supports IDMEF/XML and SNMPv3
>
> given the time it takes to create standards, like IDMEF, and
> the fact that vendors do not always buy into these standards,
> is it even worth the effort to attempt to standardize?
>
> Thusly why I’m suggesting a MIB for SNMPv3 this would allow for easier adoption for the community. (Even with SNMP’s nasty previous problems being UDP etc.. at least this is tested unlike SOAP) since most IDS vendors support SNMP in some manner or fashion it would be a stepping stone to move into V3 some have already done so.
>
> -azim
>
>
> Keith T. Morgan wrote:
> > is there a movement to standardize threat/attack nomenclature/reporting
> > etc? Has anyone submitted an RFC? If this has been done, someone point
>
>
> Matthew F. Caldwell wrote:
>
>
>>XML is great but bloated,I think the IDWG (IDMEF,IAP etc) DTD could be expanded
>>
>
>>to cover not just IDS events, however it needs compression. All those tags multiply
>>
>
>>the data transmitted and in high traffic environments this matters greatly.
>>
>> -----Original Message-----
>> From: Jared A. Tucker [mailto:jared.tucker@terradon.com]
>> Sent: Wed 3/27/2002 8:52 PM
>> To: eddonega@WellsFargo.COM; Keith T. Morgan; Matthew F. Caldwell
>> Cc: xwu@anr.mcnc.org; focus-ids@securityfocus.com
>> Subject: RE: IDS Correlation
>>
>>
>>
>> For that matter:
>>
>> http://www.ietf.org/html.charters/idwg-charter.html
>>
>>
>>
>> -----Original Message-----
>> From: eddonega@WellsFargo.COM [mailto:eddonega@WellsFargo.COM]
>> Sent: Wed 3/27/2002 5:27 PM
>> To: Keith T. Morgan; mattc@guarded.net
>> Cc: xwu@anr.mcnc.org; focus-ids@securityfocus.com; Jared A. Tucker
>> Subject: RE: IDS Correlation
>>
>>
>>
>> You might want to check this out ...
>>
>> http://www.infosecuritymag.com/articles/june01/columns_standards_watch.shtml
>> -----------------------------------------
>> Ed Donegan
>> Network Intrusion Detection
>> Team Lead/CIPD
>> Security Product Services
>> (415) 243-6459
>> eddonega@wellsfargo.com <mailto:eddonega@wellsfargo.com>
>>
>> "I could never have invented the Internet without Ed's help." - Al Gore
>>
>> -----Original Message-----
>> From: Keith T. Morgan [mailto:keith.morgan@terradon.com]
>> Sent: Wednesday, March 27, 2002 12:40 PM
>> To: Keith T. Morgan; Matthew F. Caldwell
>> Cc: Xiaoyong Wu; focus-ids@securityfocus.com; Jared A. Tucker
>> Subject: RE: IDS Correlation
>>
>>
>>
>>
>> I've spoken with another security / software engineer here at
>> TCG who is willing to help out. We're likely to stir quite
>> the hornet's nest among IDS/Firewall vendors if this goes
>> very far. I'm all about the stirring. Count me in.
>>
>> > > > Has anyone submitted an RFC? If this has been done,
>> > > someone point
>> > > > me to the appropriate RFC number, because I have some
>> > > serious reading to
>> > > > do.
>> > > >
>> > >
>> > > None?
>> > >
>> > > Lets work on it.
>> > >
>> >
>>
>>
>>
>>
>>
>
>