(no subject)

From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Sun Jun 13 2004 - 17:51:52 EST



=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id 852D226210
=09for <re-online@it.uts.edu.au>; Sat, 12 Jun 2004 03:36:54 +1000 (EST)
Received: from hotmail.com (bay12-f96.bay12.hotmail.com [64.4.35.96])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id 184691D63CF
=09for <re-online@it.uts.edu.au>; Sat, 12 Jun 2004 03:36:47 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Fri, 11 Jun 2004 10:36:44 -0700

Received: from 128.237.11.72 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Fri, 11 Jun 2004 17:36:43 GMT

X-Originating-IP: [128.237.11.72]
X-Originating-Email: [donald_firesmith@hotmail.com]
X-Sender: donald_firesmith@hotmail.com

From: "Donald Firesmith" <donald_firesmith@hotmail.com> To: re-online@it.uts.edu.au
Subject: [re-online] Measuring security requirements for protecting availability from D= OS attacks
Date: Fri, 11 Jun 2004 12:36:43 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=3Dflowed Message-ID: <BAY12-F96g4jMWlhYqY00059f7f@hotmail.com> X-OriginalArrivalTime: 11 Jun 2004 17:36:44.0362 (UTC) FILETIME=3D[A9CF5AA0= :01C44FDA]
X-Spam-Status: No, hits=3D0.0 tagged_above=3D0.0 required=3D6.3 tests=3D X-Spam-Level:
Sender: owner-re-online@it.uts.edu.au
Precedence: bulk
Reply-To: re-online@it.uts.edu.au

Everyone,
Does anyone have any suggestions for quantifying security requirements for protecting service availability from denial of service (DOS) attacks. I am assuming that the requirement will take the form of some application-specific quality criteria regarding either preventing successfu= l
DOS attacks or maintaining availability of some service(s) in spite of DOS attacks combined with some minimum required level or average level of some measurement scale. But what is/are the scale(s) being measured? How do yo= u
recommend making such requirements quantifiable, unambiguous, and yet verifiable (in a practical sense)? Also, you should be able to include something specifying the desired graceful degradation of the system in term= s
of essential services (although strictly speaking, this is actually a survivability requirement rather than a security requirement). I am also thinking that there should be some parameterizable template in which the quality criteria, unit of measure, and required value can be inserted to yield the actual requirement. Perhaps something along the lines of:

"System A shall provide service B at a minimum of at least C requests per D [unit of time] in the presence of type E denial of service attack of sophistication F."

I am assuming that the denial of service attack could be the classic Internet sending of excessive amounts of valid requests or partial requests or it could also be some kind of jamming of wireless communication. Actually, there are many other types of DOS attacks such as bringing the system down or cutting wired communication links, etc.

What I am NOT looking for is an architecture constraint requiring some specific security countermeasures or controls (e.g., the use of redundant hot--standby back up servers with different URLs if one URL is targeted or the use of lasers, narrowbandwidth, and frequency hopping for protecting wireless communication from jamming). Instead, I am looking for real requirements that do not unnecessarily tie the hands of the architects and security engineers.

Any ideas?

Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
Software Engineering Institute (SEI)
Carnegie Mellon University (CMU)
Pittsburgh, PA 15213-3890
(412) 268-6874
dgf@sei.cmu.edu
http://www.donald-firesmith.com



MSN Toolbar provides one-click access to Hotmail from any Web page =96 FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/

To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.

This archive was generated by hypermail 2.1.6 : Mon Jun 14 2004 - 09:00:18 EST