[31865] in North American Network Operators' Group
Incident response (was Re: whois )
daemon@ATHENA.MIT.EDU (batz)
Tue Oct 24 10:40:25 2000
Date: Tue, 24 Oct 2000 05:53:04 -0400 (EDT)
From: batz <batsy@vapour.net>
To: Valdis.Kletnieks@vt.edu
Cc: tme@21rst-century.com, nanog@nanog.org
In-Reply-To: <200010241411.e9OEBun22454@black-ice.cc.vt.edu>
Message-ID: <Pine.BSF.4.21.0010240536520.67382-100000@vapour.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Tue, 24 Oct 2000 Valdis.Kletnieks@vt.edu wrote:
:Umm... would you be satisfied with a "We've referred it to the appropriate
:people" response?
:
:At least here, and probably many other universities, we're stuck not being
:able to say much more than that due to student confidentiality rules...
:Yes, we take action. No, we usually can't say what we did.
A general incident response capability would be usefull, but unfortunately
this requires more cooperation than most companies are willing to give.
Would it be worthwhile to include security incident handling policies
and procedures in peering agreements? i.e a peering agreement also
includes a testable disaster recovery plan, and a security incident
response plan.
It is fairly obvious by now that a peering agreement is more than simply
an agreement on a router configuration.
I'm wondering if anyone would consider something like this a little more
robust than the centralized CIRTs and industry associations, as it would
be relative to local policy, and the participants have a direct existing
relationship with each other. This, as opposed to dependance on a neutral
co-ordinating centre which may be dealing with other problems.
--
batz
Reluctant Ninja
Defective Technologies
