From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Fri Jul 30 2004 - 17:10:33 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id D627A26208
=09for <re-online@it.uts.edu.au>; Thu, 29 Jul 2004 23:01:40 +1000 (EST)
Received: from hotmail.com (bay12-f40.bay12.hotmail.com [64.4.35.40])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id 332911D62ED
=09for <re-online@it.uts.edu.au>; Thu, 29 Jul 2004 23:01:34 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Thu, 29 Jul 2004 06:01:28 -0700
Received: from 141.158.72.194 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Thu, 29 Jul 2004 13:01:28 GMT
X-Originating-IP: [141.158.72.194] X-Originating-Email: [donald_firesmith@hotmail.com] X-Sender: donald_firesmith@hotmail.com
Rolf,
One feeling I get is that because any modicum of security testing blows
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 requirements tha=
t
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. Another feeling I get is tha=
t
mandating constraints of using best industry practice is adequate. Also, I
hear that you can't really understand the system until it is built because
you don't know the vulnerabilities until you have an
architecture/design/implementation to work with. Also, the vast majority o=
f
security people have no real experience with requirements and are used to
doing their work independently of the requirements team. While there is
some feeling that requirements people just don't understand the security
field and so can't understand why it has to be different, I do not feel lik=
e
it is a fear of loss of guru status.
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: Didar Zowghi <didar@it.uts.edu.au>
>Reply-To: re-online@it.uts.edu.au
>To: RE-Online <re-online@it.uts.edu.au>
>Subject: [re-online] How should you specify Security Requirements
>Date: Thu, 29 Jul 2004 21:50:49 +1000 (EST)
>
>
>---------- Forwarded message ----------
>Date: Thu, 29 Jul 2004 12:17:12 +0200
>From: Rolf.Goetz@sophist.de
>
>Hi Don,
>
>I agree completely with your arguments. Security requirements are no
>special case. The "moderate sophistication" may be a weak point in your
>example requirement, but that can be fixed easily.
>In situations like the one you described (unfruitful discussions,
>apparently/seemingly unlogical arguments etc.) I assume there's a problem
>on a different level. Maybe the situation is the somewhat classical scene
>where a stakeholder pretends that his area of expertise cannot be
>formalized, quantified, tested, or just written down, because he could
>loose his guru status if it were.
>
>Don't get me wrong, I don't want to condemn or mock the security experts.
>These human traits can and should be considered like all other problems.
>But a first order solution (that is, more of the same, e.g. more good
>requirements, more logical arguments, ...) may prove inappropriate. Then I
>like to ask: "What would he (personally) loose if we wrote requirements
>like this?," or "What is his personal benefit of adhering to his opinion?"=
=2E
>Or sometimes going just the first little step helps. You could agree upon =
a
>single requirement to be stated your way. Then you could prove your
>arguments right with this single case.
>
>Hope this helps
>
>Rolf
>SOPHIST GROUP
>Germany
>
>owner-re-online@it.uts.edu.au (Majordomo) wrote on 29.07.2004 06:40:42:
>
>
> > Everyone,
> > Can anyone think of ways to quantitatively specify security requirement=
s
> > that capture "how much" security (e.g., identification, authentication,
> > authorization, confidentiality, integrity, availability,
>non-repudiation,
> > etc.) is needed and required?
>
> > I am having an ongoing (and relatively unfruitful) discussion with some
> > security experts who state that it is essentially impossible to specify
> > quantitative security requirements and that architectural constraints t=
o
>us=3D
> > e
> > certain state-of-the-practice security countermeasures, mechanisms, and
> > tools is as good as it can get (e.g., "The system shall incorporate an
> > intrusion detection mechanism.")
>
> > Basically, my arguments that we can specify testable requirements is me=
t
> > with the counter arguements that developers will not sign up for such
> > requirements, that security testing always breaks the security of
>systems,
> > and that the arms race between systems developers and attackers
>obsoletes
> > any testable requirement anyway.
>
> > I propose various testable requirements based on the concept of a
>quality
> > criteria (a statement about the system that provides evidence either fo=
r
>or
> > against the existance of a security quality subfactor) combined with a
> > threshold on some scale. Examples of my suggested requirements would b=
e
> > something like:
>
> > "Authentication: The system shall correctly verify the claimed
> > identification of the user a minimum of 99.9% of the time when under
>attack
> > by an attacker of moderate sophistication using readily-available tools
>whe=3D
> > n
> > the attack lasts no more than 30 minutes." whereby moderate
>sophistication
> > and readily-available tools are properly defined terms.
>
> > Such requirements are rejected as infeasable to implement and not
>acceptabl=3D
> > e
> > to those responsible for ensuring the security of the system.
>
> > I believe that:
> > - Security requirements should be testable like all other types of
> > requirements.
> > - Security requirements can be quantified like all other types of
>quality
> > requirements.
> > - Security requirements should be based on the needs of the clients and
>not
> > watered down because of securities immaturity as a field, especially
>with
> > regard to requirements engineering.
> > - Systems should be built to pass security tests of a specific
>quantifiable
> > level based on an analysis of the associated security risks.
> > - Just because a system passes security tests at the time of acceptance
> > testing and does not pass the same tests later as attacks become more
> > sophisticated is not a problem with either the requirements and tests,
>but
> > rather a consequence of the arms race and merely means that the system
>must
> > be updated over time to remain secure to the level needed by the
> > clients/users of the system.
>
> > What do you think? Am I being unrealistic to push for the same kinds
>and
> > characteristics of requirements for security that we as a discipline
>have
> > demanded for all other kinds of requirements? Is security fundamentall=
y
> > different, making such requirements impossible? Are my arguments
>flawed?
> > Can you think of other arguments to use with the security community?
>What
> > would you recommend if you were required to write or review security
> > requirements?
>
> > Don
>
> >
> > Donald Firesmith
> > http://www.donald-firesmith.com
>
> > _________________________________________________________________
> > Don=3D92t just search. Find. Check out the new MSN Search!
> > http://search.msn.click-url.com/go/onm00200636ave/direct/01/
> >
>--------------------------------------------------------------------------=
This archive was generated by hypermail 2.1.6 : Mon Aug 02 2004 - 09:00:21 EST