From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Wed Aug 04 2004 - 21:52:49 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id 74DBE26203
=09for <re-online@it.uts.edu.au>; Tue, 3 Aug 2004 23:05:36 +1000 (EST)
Received: from hotmail.com (bay12-f25.bay12.hotmail.com [64.4.35.25])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id BCE3C1D63A4
=09for <re-online@it.uts.edu.au>; Tue, 3 Aug 2004 23:05:28 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Tue, 3 Aug 2004 06:05:27 -0700
Received: from 128.237.11.72 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Tue, 03 Aug 2004 13:05:27 GMT
X-Originating-IP: [128.237.11.72] X-Originating-Email: [donald_firesmith@hotmail.com] X-Sender: donald_firesmith@hotmail.com
Dorfman suggested:
> So perhaps there are two approaches that could be used to at least
>give the developers a testable target:
>(1) Identify the known types of attack that the system must defend against
>(2) Identify the methods of defense that the system should use
Item 1 is an actual requirement, whereas item 2 is a design constraint. Item 1 can be stated in terms of an operational testing definition. Have security testers use specified attacks for a specified duration and see how many attacks succeeded. That provides a threshold to see if the system survived X% of attacks of specified type of specified characteristics. Don
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
>From: dorfman@rahul.net
>Reply-To: re-online@it.uts.edu.au
>To: re-online@it.uts.edu.au
>CC: dorfman@computer.org
>Subject: Re: [re-online] How should you specify Security Requirements
>Date: Sun, 1 Aug 2004 21:57:29 -0700 (PDT)
>
>
>
> > Don,
> >
> >> Rolf,
> >> One feeling I get is that because any modicum of security testing blow=
s
> >> holes in practically all systems, then writing testable requirements
> > means
> >> that no system will ever pass testing. A similar argument that I get
>is
> >> that no developer will sign up for such requirements because of the
>risk
> > of
> >> never being able to implement to them. Also, unlike other requirement=
s
> > that
> >> once passed tend to stay passed, security is such a rapidly evolving
> >> arms
> >> race that you can never be sure that you will pass the requirements
> > because
> >> an advance on the attacker side can immediately cause your security
> >> countermeasures to loose their effectiveness.
>
> > I see. Just one thing: I agree that it isn't hard to blow holes in ever=
y
> > system's security. However, the requirements should be negotiated in
>order
> > to end with testable, yet feasible requirements. Your example of a
> > security
> > requirement is e perfect one, it has a lot of parameters to adjust. It
> > also
> > gives the opportunity to define the means the attacker uses.
> > Doing so gives you both the current security status and a solid basis
>for
> > security improvements. Again, I can't see sigificant differences betwee=
n
> > security and other requirements here.
>
> Agreed that security requirements phased similarly to other
>performance or quality requirements are probably not very helpful:
>"Stop 99% of all attempts at unauthorized access," etc. (We don't
>generally know how many attempts have been made; we can probably stop
>100% of the ones we know about because they use known methods,
>otherwise we wouldn't know about them. Also security is a situation
>where we really need 100% success.)
> So perhaps there are two approaches that could be used to at least
>give the developers a testable target:
>(1) Identify the known types of attack that the system must defend against
>(2) Identify the methods of defense that the system should use
> In situation (1), the designers are free to adopt existing methods o=
r
>develop new methods of defending against these known types of attack,
>and testing would consist of launching these attacks on the system.
>Presumably 100% success against them would be expected. The weakness
>is that there is no required defense against other types of attack.
> In situation (2), testing would consist of verifying that the
>specified defenses are used. This could be by inspection, and/or by
>launching attacks that the specified methods are known to stop,
>verifying that they are stopped, and looking at the records/logs to
>verify that the defenses behaved as expected. The weakness is that
>attacks that can penetrate the specified defense methods would not be
>stopped.
> In either case, it would probably be necessary to update the securit=
y
>requirements during system development, to account for new types of
>attack and/or new methods of defense.
>--------------------------------------------------------------------------=
This archive was generated by hypermail 2.1.6 : Mon Aug 09 2004 - 09:00:25 EST