IDS data.

Wed Feb 11 04:09:18 UTC 2004

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, jamie.reid at mbs.gov.on.ca
Senior Security Specialist, Information Protection Centre 
Corporate Security, MBS  
416 327 2324 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TEXT.htm
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040210/c66aa017/attachment.ksh>