[67512] in North American Network Operators' Group
IDS data.
daemon@ATHENA.MIT.EDU (Jamie Reid)
Tue Feb 10 23:10:31 2004
Date: Tue, 10 Feb 2004 23:09:18 -0500
From: "Jamie Reid" <Jamie.Reid@mbs.gov.on.ca>
To: nanog@merit.edu
Cc: als@bpal.com
Errors-To: owner-nanog-outgoing@merit.edu
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_AE8FCA04.97F7B651
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
We have built an experimental system that aggregates IDS alerts by
sorting them into subnets, then associating them with routes from=20
the a view of the global BGP table, and in turn associates them with=20
their ASN. From there, we can create lists of security events as they
are related to the network contact information available from the=20
radb, ripe, arin etc.=20
That is, we can divvy-up our IDS events by ISP (or rather, NSP) on a=20
reasonably accurate basis, and provide a complete history of events
that originated from networks announced by them.=20
(A side project is watching for events that originate from bogons
or reportedly hijacked routes. Nothing yet, but we'll see. I mailed=20
someone ad d-sheild about getting a report of this kind of activity
from them, but no answer. I'm still interested, btw)=20
Anyway, my question is, will this actually change how we report=20
incidents? It raises a few questions, like how many raw events
constitute an incident worth alerting a service provider to? Obviously
we would check the events before sending it off, but while we might
care about one of our /16's getting whisker'ed by 10 sites on your=20
network, you may not, and there is little anyone can do to compel you
to care unless a law has been broken.=20
More to the point, should we consider using contact information in=20
maintainer objects as security incident POCs?=20
Another side project may be a standard XML report, which sites recieving=20=
reports can in turn aggregate and mine for what to respond to, but =
that's=20
just a thought.=20
So, now that we can link our security events directly to subnets and =
ASNs,=20
how would you like this data served? =20
Regards,=20
-j
=20
--
Jamie.Reid, CISSP, jamie.reid@mbs.gov.on.ca
Senior Security Specialist, Information Protection Centre=20
Corporate Security, MBS =20
416 327 2324=20
--=_AE8FCA04.97F7B651
Content-Type: text/plain
Content-Disposition: attachment;
filename=TEXT.htm
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 8pt Tahoma; MARGIN-LEFT: 2px">
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>We have built an experimental system that aggregates IDS
alerts by</FONT></DIV>
<DIV><FONT size=1>sorting them into subnets, then associating them with routes
from </FONT></DIV>
<DIV><FONT size=1>the a view of the global BGP table, and in turn associates
them with </FONT></DIV>
<DIV><FONT size=1>their ASN. From there, we can create lists of security events
as they</FONT></DIV>
<DIV><FONT size=1>are related to the network contact information available from
the </FONT></DIV>
<DIV><FONT size=1>radb, ripe, arin etc. </FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>That is, we can divvy-up our IDS events by ISP (or rather,
NSP) on a </FONT></DIV>
<DIV><FONT size=1>reasonably accurate </FONT><FONT size=1>basis, and provide a
complete history of events</FONT></DIV>
<DIV><FONT size=1>that originated from networks announced by them. </FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>(A side project is watching for events that originate from
bogons</FONT></DIV>
<DIV><FONT size=1>or reportedly hijacked routes. Nothing yet, but we'll see. I
mailed </FONT></DIV>
<DIV><FONT size=1>someone ad d-sheild about getting a report of this kind of
activity</FONT></DIV>
<DIV><FONT size=1>from them, but no answer. I'm still interested, btw)
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=1>Anyway, my question is, will this actually change how we
report </FONT></DIV>
<DIV><FONT size=1>incidents? It raises a few questions, like how many
raw events</FONT></DIV>
<DIV><FONT size=1>constitute an incident worth alerting a service provider to?
Obviously</FONT></DIV>
<DIV><FONT size=1>we would check the events before sending it off, but while we
might</FONT></DIV>
<DIV><FONT size=1>care about one of our /16's getting whisker'ed by 10 sites on
your </FONT></DIV>
<DIV><FONT size=1>network, you may not, and there is little anyone can do
to compel you</FONT></DIV>
<DIV><FONT size=1>to care unless a law has been broken. </FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>More to the point, should we consider using contact
information in </FONT></DIV>
<DIV><FONT size=1>maintainer objects as security incident POCs? </FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>Another side project may be a standard XML report,
which sites recieving </FONT></DIV>
<DIV><FONT size=1>reports </FONT><FONT size=1>can in turn aggregate and mine for
what to respond to, but that's </FONT></DIV>
<DIV><FONT size=1>just a thought. </FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>So, now that we can link our security events directly to
subnets and ASNs, </FONT></DIV>
<DIV><FONT size=1>how would you like </FONT><FONT size=1>this data served?
</FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>Regards, </FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>-j</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>--<BR>Jamie.Reid, CISSP, <A
href="mailto:jamie.reid@mbs.gov.on.ca">jamie.reid@mbs.gov.on.ca</A><BR>Senior
Security Specialist, Information Protection Centre <BR>Corporate Security,
MBS <BR>416 327 2324 </DIV></BODY></HTML>
--=_AE8FCA04.97F7B651--
