[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: survey of isp security practices

comments inline....

On Nov 10, 2004, at 8:00 AM, Howard C. Berkowitz wrote:

At 8:42 AM -0500 11/10/04, jbenedict@ca.safenet-inc.com wrote:
> -----Original Message----- 
 From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
 Sent: Tuesday, November 09, 2004 9:03 PM
 To: opsec@ops.ietf.org
 Subject: Re: survey of isp security practices


 Here are a couple of stabs at reorganization.  This isn't a complete
 re-do but just an idea to show my thinking.

While I'm really, really not trying to do a comprehensive model, I do
think it's worth keeping three things in mind:

      1. Risk[1]/Threat:  An impact on the SP if the exploit
 takes place.
         It is assessed with respect to a revenue source or


UhOh!  Unless things have changed since i've been away from the IETF
(lurking, but haven't been to the meetings in a couple of years :)
putting a '$' in front of anything that isn't a variable name is
a no-no.

I agree with the concept though, but I would recommend we strictly
identify the threat in terms of service lost or systems compromised
(or any other non-denominational methods).  Justifying the cost
of said impact is an exercise for the deploying organization.

I'm not sure we are in disagreement. In no way am I suggesting that the IETF actually try to put numeric value to cost or revenue. Nevertheless, especially when a security program needs top management support, that support is going to be given because the top management sees a financial impacts. Financial impacts come from changes in cost or revenue. Such things as denial of (billable) service lower revenue; additional security measures incur cost. There's no practical way to quantify them in an IETF document, but that does not mean they should be ignored as qualitative factors.

The document will describe operational threats and service impact along with current mitigation techniques. That can be translated to quantifiable impacts by whomever chooses once the document is done. So, I think we are all in agreement in what the document itself will contain.




 cost seen by
         upper management, such as bandwidth, network element
 (e.g., router)
         availability, and host denial of service. By [1], I
 mean the expected
         financial cost multiplied by the probability of the event.

         I recognize that host denial of service is right at
 the edge of the
         charter, but I think we need to include things that
 prevent the host
         being used through the ISP network, such as a SYN-Flood.

      2. Exploit: a class of technical attack

James A Benedict
Software Developer

Tel:  613-723-5076 x3303
Cell: 613-797-1593
jbenedict@ca.safenet-inc.com
www.safenet-inc.com

The information contained in this electronic mail transmission may be
privileged and confidential, and therefore, protected from disclosure. If
you have received this communication in error, please notify us immediately
by replying to this message and deleting it from your computer without
copying or disclosing it. 


- merike