When I coach teams on security in the SDLC, I ask them to first see
what mileage they can get out of existing artifacts, like Use Cases,
User Stories, and so on. While these artifacts and processes were not
typically designed with security in mind, there is generally a lot of
underutilized properties in them that can be exploited by security
architects and analysts.
The Use Case model adds traceability to security requirements, but
just as importantly it allows the team to see not just the static
requirements, rather you can the requirements in a behavioral flow.
Since so much of security is protocol based and context sensitive,
describing the behavioral aspects is important to comprehensibility.
At the end of exploring existing artifacts, then there needs to be a
set of security-centric artifacts like threat models, misuse cases,
et. al. The output, e.g. design decisions, of these security-centric
models are fed back into the requirements in an iterative fashion.
Security analysts and architects cannot do all the work that goes
into secure software development by themselves. There may be a
handful of security people supporting hundreds of developers. This is
why we need to educate not just developers on writing secure code,
but also business analysts on security Use Cases, requirements, etc.
(the main purpose of my article), testers on how to write/run/read
security test cases, an so on.
-gp
On Jun 26, 2005, at 5:37 AM, Johan Peeters wrote:
This topic is very pertinent. I agree that the lack of attention
paid to security in many development projects stems from an
inability to track security requirements in the software
development life cycle. By addressing security requirements in a
use case model, I believe that traceability can be improved
enormously. However, traditional use cases are not always adequate
to express security requirements. For example, whereas it may be
possible to say that a user needs to authenticate to perform an
action, it is not possible to express that attackers must be
prevented from executing their own code on the system. I therefore
feel there is a strong case for extending the use case concept to
abuse cases, as introduced by McDermott in C. Fox, "Using Abuse
Case Model for Security Requirements Analysis" in 1999 (http://
www.acsac.org).
In agile ecologies, use cases have transmuted to user stories. I
have proposed to also extend user stories to abuser stories (http://
www.johanpeeters.com/papers/abuser stories.pdf).
kr,
Yo
Gunnar Peterson wrote:
I have published a new paper on integrating security into Use
Case Modeling:
http://www.arctecgroup.net/secusecase.htm
-gp
--
Johan Peeters
http://www.johanpeeters.com
+32 16 649000
