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?
TEXT.htm (3.57 KB)