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.caSenior
Security Specialist, Information Protection Centre
Corporate Security,
MBS
416 327 2324