From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Thu Jul 29 2004 - 14:40:42 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id C17CA261EA
=09for <re-online@it.uts.edu.au>; Wed, 28 Jul 2004 01:45:43 +1000 (EST)
Received: from hotmail.com (bay12-f36.bay12.hotmail.com [64.4.35.36])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id 655491D62B2
=09for <re-online@it.uts.edu.au>; Wed, 28 Jul 2004 01:45:38 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Tue, 27 Jul 2004 08:45:37 -0700
Received: from 68.162.170.178 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Tue, 27 Jul 2004 15:45:37 GMT
X-Originating-IP: [68.162.170.178] X-Originating-Email: [donald_firesmith@hotmail.com] X-Sender: donald_firesmith@hotmail.com
Everyone,
Can anyone think of ways to quantitatively specify security requirements
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 to us=
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 met 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 for or against the existance of a security quality subfactor) combined with a threshold on some scale. Examples of my suggested requirements would be 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=
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=
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 fundamentally 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
This archive was generated by hypermail 2.1.6 : Mon Aug 02 2004 - 09:00:20 EST