[prev in list] [next in list] [prev in thread] [next in thread]
List: dragonidsuser
Subject: RE: [Dragonidsuser] Pushing dependant events to the next level
From: "Fitzgerald, Barry" <Barry.Fitzgerald () bisys ! com>
Date: 2003-03-31 17:39:27
[Download RAW message or body]
I, personally, would love to see a correlation tool implemented - but I
generally feel that it would be best to implement this as a part of the
infrastructure, rather than as a tool that parses the current Dragon data
files. Although, any analytical assistance is a good thing. :)
-----Original Message-----
From: Robert_Huber@bankone.com [mailto:Robert_Huber@bankone.com]
Sent: Monday, March 31, 2003 11:06 AM
To: dragonidsuser@enterasys.com
Subject: RE: [Dragonidsuser] Pushing dependant events to the next level
I haven't seen or heard this mentioned for some time, but there was
discussion of the ECT (Event Correlation Tool) which would have had similar
capability. Can someone from Enterasys comment? I thought the ECT was
tabled some time ago, but the concept is outstanding and would provide a
huge benefit in the accuracy of the tool.
Bob
-----Original Message-----
From: Fitzgerald, Barry [mailto:Barry.Fitzgerald@bisys.com]
Sent: Monday, March 31, 2003 10:06 AM
To: dragonidsuser@enterasys.com
Subject: [Dragonidsuser] Pushing dependant events to the next level
Hey there guys,
I was thinking over the weekend and had a thought regarding Dragon's
event signature functionality. Right now, Dragon's signature database is
essentially a flat-level database where all signatures are (usually)
processed equally. The exception to this is the dependant events, that are
only searched for if another event is captured (like the SUCCESS: events).
I was wondering if anyone at enterasys had ever thought of building the
signature engine to work beyond this logic. What I had in mind was a tiered
sig database format, like so:
EVENT1
Eventa
Eventb
Eventc
EVENT2
EVENT3
EVENT4
EVENTA
EVENTB
EVENTC
Let me explain this a bit. EVENT[2-4] Are standard Dragon IDS signatures -
processed the same way that Dragon processes signatures right now. EVENT1,
in this representation, is a container signature, where Event[a-c] are
references to EVENT[A-C], respectively. EVENT[A-C] are standard Dragon
style signatures, except that they're definition events only, and are not
searched for by the event engine unless referenced elsewhere in the database
(this could be a bit field, like the disabled setting). The signatures
listed as Event[a-c] could take one of two forms:
1) search for this signature if the container is found to be positive in
the search of the packet (for this to work, EVENT1 must either be defined
elsewhere, or the other nested Events must adhere to form 2.)
i.e., if EVENT1 is defined in a definition signature, then look for
Eventa in the packet (assuming that Eventa is marked as being a follow-up
signature within the container.)
-or-
2) Register EVENT1 as being found IF the nested events are found to be
present in the packet search.
i.e., if Eventb and Eventc are found, then EVENT1 is caught. This
example assumes that Eventa is a form1 signature as above.
I know that this is complex, but the power of this kind of processing should
be fairly evident. You could create event containers that exemplify the
composite of mixed generic events and create complex attack patterns. For
instance, you could generate a web attack event ONLY in the instance that it
is successful. You could also use this to tell certain worms from generic
attacks if the worm can be considered to reliably generate a combination of
events in the same packet.
At first glance, this format looks like it would actually increase the
processing requirement for the Dragon sensor. However, I would propose that
if the Database were able to go beyond two container tiers (Which does add
complexity to the code) and it were organized properly, the speed of packet
searches may actually improve because you could (using form 1 above) create
dependant searches of the packets.
The following scenario exists, however:
EVENT1
Event2 (form1)
EVENT2
Event1 (form1)
In this case, you have an infinite search loop. You'd have to counteract
this in the database parser and/or in the engine by catching this scenario
and either erroring on it or working around it.
Just bouncing this idea off of the list/any interested Enterasys employees.
I hope everyone sees how powerful this idea could be. :)
Please send me any comments or requests for clarification. :)
Barry Fitzgerald
BISYS - IT Department (Insurance Services Division)
Phone: 860.321.3044
Fax: 860.321.3701
www.BISYSinsurance.com <http://www.bisysinsurance.com/>
The opinions expressed here are my own and do not represent the opinions of
my employer.
_____
This e-mail message has been scanned for Viruses and Content.
_____
**********************************************************************
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
#####################################################################################
This e-mail message has been scanned for Viruses and Content and cleared.
#####################################################################################
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.3504.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=062393717-31032003>I,
personally, would love to see a correlation tool implemented - but I generally
feel that it would be best to implement this as a part of the infrastructure,
rather than as a tool that parses the current Dragon data files. Although,
any analytical assistance is a good thing. :)</SPAN></FONT></DIV>
<BLOCKQUOTE>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Robert_Huber@bankone.com
[mailto:Robert_Huber@bankone.com]<BR><B>Sent:</B> Monday, March 31, 2003 11:06
AM<BR><B>To:</B> dragonidsuser@enterasys.com<BR><B>Subject:</B> RE:
[Dragonidsuser] Pushing dependant events to the next
level<BR><BR></DIV></FONT>
<DIV><SPAN class=519140316-31032003><FONT color=#0000ff face=Arial size=2>I
haven't seen or heard this mentioned for some time, but there was discussion
of the ECT (Event Correlation Tool) which would have had similar
capability. Can someone from Enterasys comment? I thought the ECT
was tabled some time ago, but the concept is outstanding and would provide a
huge benefit in the accuracy of the tool.</FONT></SPAN></DIV>
<DIV><SPAN class=519140316-31032003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=519140316-31032003><FONT color=#0000ff face=Arial
size=2>Bob</FONT></SPAN></DIV>
<BLOCKQUOTE>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Fitzgerald, Barry
[mailto:Barry.Fitzgerald@bisys.com]<BR><B>Sent:</B> Monday, March 31, 2003
10:06 AM<BR><B>To:</B> dragonidsuser@enterasys.com<BR><B>Subject:</B>
[Dragonidsuser] Pushing dependant events to the next
level<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>Hey there
guys,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> I was
thinking over the weekend and had a thought regarding Dragon's event
signature functionality. Right now, Dragon's signature database is
essentially a flat-level database where all signatures are (usually)
processed equally. The exception to this is the dependant events, that
are only searched for if another event is captured (like the SUCCESS:
events). I was wondering if anyone at enterasys had ever thought of
building the signature engine to work beyond this logic. What I had in
mind was a tiered sig database format, like so:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENT1</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003>
Eventa</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003>
Eventb</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003>
Eventc </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENT2</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENT3</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENT4</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENTA</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENTB</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> EVENTC</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>Let me explain
this a bit. EVENT[2-4] Are standard Dragon IDS signatures - processed
the same way that Dragon processes signatures right now. EVENT1, in
this representation, is a container signature, where Event[a-c] are
references to EVENT[A-C], respectively. EVENT[A-C] are standard Dragon
style signatures, except that they're definition events only, and are not
searched for by the event engine unless referenced elsewhere in the database
(this could be a bit field, like the disabled setting). The signatures
listed as Event[a-c] could take one of two forms: </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> 1) search for this signature if
the container is found to be positive in the search of the packet (for this
to work, EVENT1 must either be defined elsewhere, or the other nested Events
must adhere to form 2.) </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> i.e., if EVENT1 is defined in a
definition signature, then look for Eventa in the packet (assuming that
Eventa is marked as being a follow-up signature within the
container.)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003>-or-</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> 2) Register EVENT1 as
being found IF the nested events are found to be present in the packet
search.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> i.e., if Eventb and Eventc are
found, then EVENT1 is caught. This example assumes that Eventa is a
form1 signature as above.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>I know that this
is complex, but the power of this kind of processing should be fairly
evident. You could create event containers that exemplify the
composite of mixed generic events and create complex attack patterns.
For instance, you could generate a web attack event ONLY in the instance
that it is successful. You could also use this to tell certain worms
from generic attacks if the worm can be considered to reliably generate a
combination of events in the same packet.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>At first glance,
this format looks like it would actually increase the processing requirement
for the Dragon sensor. However, I would propose that if the Database
were able to go beyond two container tiers (Which does add complexity to the
code) and it were organized properly, the speed of packet searches may
actually improve because you could (using form 1 above) create dependant
searches of the packets. </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>The following
scenario exists, however:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003>EVENT1</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> Event2
(form1)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003>EVENT2</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003> Event1
(form1)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>In this case,
you have an infinite search loop. You'd have to counteract this in the
database parser and/or in the engine by catching this scenario and either
erroring on it or working around it.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>Just bouncing
this idea off of the list/any interested Enterasys employees. I hope
everyone sees how powerful this idea could be. :)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=031250914-31032003>Please send me
any comments or requests for clarification. :)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=031250914-31032003></SPAN></FONT> </DIV>
<DIV>
<DIV class=Section1>
<P><SPAN style="FONT-FAMILY: Arial">Barry Fitzgerald</SPAN> <BR><SPAN
style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">BISYS - IT Department (Insurance
Services Division)</SPAN> <BR><SPAN
style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Phone: 860.321.3044</SPAN>
<BR><SPAN style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Fax:
860.321.3701</SPAN> <BR><SPAN style="FONT-FAMILY: Arial; FONT-SIZE: 10pt"><A
href="http://www.bisysinsurance.com/">www.BISYSinsurance.com</A></SPAN> </P>
<P>The opinions expressed here are my own and do not represent the opinions
of my employer.</P>
<P> <o:p></o:p></P></DIV></DIV>
<HR>
This e-mail message has been scanned for Viruses and Content.
<HR>
</BLOCKQUOTE><CODE><FONT
size=3><BR><BR>**********************************************************************<BR>This \
transmission may contain information that is privileged, confidential and/or
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, distribution,
or use of the information contained herein (including any reliance thereon) is
STRICTLY PROHIBITED. If you received this transmission in error, please
immediately contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank
you<BR>**********************************************************************<BR></BLOCKQUOTE></FONT></CODE>
<HR>
This e-mail message has been scanned for Viruses and Content.
<HR>
</BODY></HTML>
_______________________________________________
Dragonidsuser mailing list
For help please follow the below instructions.
You can make subsciption adjustments via email by sending a message to:
Dragonidsuser-request@enterasys.com
with the word `help' in the subject or body (don't include the quotes), and you will \
get back a message with instructions.
You must know your password to change your options (including changing the password, \
itself) or to unsubscribe. If you forget your password, don't worry, you will \
receive a monthly reminder telling you what all your enterasys.com mailing list \
passwords are, and how to unsubscribe or change your options.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic