RE: IDS Correlation

From: Keith T. Morgan (keith.morgan@terradon.com)
Date: 03/28/02 

Date: Thu, 28 Mar 2002 09:57:48 -0500
From: "Keith T. Morgan" <keith.morgan@terradon.com>
To: "Jared A. Tucker" <jared.tucker@terradon.com>, "Matthew F. Caldwell" <mattc@guarded.net>, "Kurt Seifried" <bugtraq@seifried.org>, <eddonega@WellsFargo.COM>

I think the first thing that should be analyzed is the types of data coming from various systems. Some things are more or less common across most security devices. Examples: Timestamp, Source IP, Source Port, Dest IP, Dest Port. These are items that you can pretty much bank on being present in all firewall and IDS logging mechanisms. However, almost no logging system notes the local time-zone in each log entry. That's an example of something that should be critical to log aggregation and analysis across diverse systems. Development of a list of capturable information would seem to be a critical primary step. First, you would identify what data could be captured. Standardize that. Then, what data *might* be captured. Standardize and make provisions for that. Then, we would standardize the nomenclature, required fields, and data normalization issues. I think we may be way ahead of ourselves thinking down the road of data-formatting. We haven't even defined the data! Then, this could be me working in my standard "network and security guy" mindset instead of "application developer" mindset.

Application proxying firewalls are going to grab lots more information than a packet filter. An IDS will contain attack signatures, possibly captured packet data, possible references to central repositories explaining the meaning of the attack signature, and lots of other information that a firewall doesn't gather (normally). Some systems go down to the granularity of logging user-id (app proxies/firewalls requiring authentication etc...) and other organization specific information. My focus would be less on standardizing data transmission and storage mechanisms and more towards standardizing the data itself.



> -----Original Message-----
> From: Jared A. Tucker
> Sent: Thursday, March 28, 2002 9:43 AM
> To: 'Matthew F. Caldwell'; Kurt Seifried;
> eddonega@WellsFargo.COM; Keith
> T. Morgan
> Cc: xwu@anr.mcnc.org; focus-ids@securityfocus.com
> Subject: RE: IDS Correlation
>
>
> As an application developer, it makes more sense to use a
> language that just about any programming language can parse,
> query, and disect using inherent APIs. Why not use XML, just
> for the sake of not re-inventing the wheel?

 

Relevant Pages

  • Re: Exporting to text files
    ... attempting to parse in visual basic 6.0. ... retrieving the position of each tab in the file. ... w/in that line get the tab position of each tab to break up each column or ... another programming language had the same result. ...
    (microsoft.public.sqlserver.dts)
  • Re: How can you dump the revision log in WORD to an EXCEL file?
    ... dealing with tracked changes, because the information that Word exposes to ... the programming language is not complete and does not always work very well. ... It would be great if Microsoft WORD had a feature built ... Our developer who used to work for Microsoft ...
    (microsoft.public.word.docmanagement)
  • Re: Analysis of some common 5.25" brand floppy diskettes
    ... It is so long ago that I don't know how Turbo would differ ... If I remember correctly, the developer had ... I suppose a switch of programming language - if the developer ... Once I used an automated converter which did a half-hearted job, ...
    (comp.sys.cbm)
  • Re: Simulation of Sizeof operator
    ... >one of the developer asked me "Can u implement one user defined funtion ... >similar to the sizeof operaor in C Programming Language". ...
    (comp.lang.c)
  • Re: Delphi in more schools (was Re: Microsoft here I come)
    ... it concerns me that core professional skills for any developer still seem to get widely neglected. ... I often see Delphi developers in particular micro-focussing - see many of the threads here, ... You wouldn't get to be an electrical engineer just because you could draw a circuit diagram :-) Too many of those people either don't realise or don't care that there is more to it than knowing a programming language. ... Jim Cooper jcooper@xxxxxxxxxxxxx ...
    (borland.public.delphi.non-technical)