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@mbs.gov.on.ca Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324