|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical IDS data.
We have built an experimental system that aggregates IDS alerts by sorting them into subnets, then associating them with routes from the a view of the global BGP table, and in turn associates them with their ASN. From there, we can create lists of security events as they are related to the network contact information available from the radb, ripe, arin etc. That is, we can divvy-up our IDS events by ISP (or rather, NSP) on a reasonably accurate basis, and provide a complete history of events that originated from networks announced by them. (A side project is watching for events that originate from bogons or reportedly hijacked routes. Nothing yet, but we'll see. I mailed someone ad d-sheild about getting a report of this kind of activity from them, but no answer. I'm still interested, btw) Anyway, my question is, will this actually change how we report 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 network, you may not, and there is little anyone can do to compel you to care unless a law has been broken. More to the point, should we consider using contact information in maintainer objects as security incident POCs? Another side project may be a standard XML report, which sites recieving reports can in turn aggregate and mine for what to respond to, but that's just a thought. So, now that we can link our security events directly to subnets and ASNs, how would you like this data served? Regards, -j -- Jamie.Reid, CISSP, [email protected] Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 <!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:[email protected]";>[email protected]</A><BR>Senior Security Specialist, Information Protection Centre <BR>Corporate Security, MBS <BR>416 327 2324 </DIV></BODY></HTML>
|