Scott is a software process improvement consultant, mentor, and trainer with Ambysoft Inc. He can be contacted at www.ambysoft.com.
For organizations of all sizes, security failures can have devastating consequences. But security is only one aspect of overall application reliability. Indeed, it is often possible to equate the cost of a security failure with a given level of downtime. Thus, overall assurance of an applicationthat is, its ability to perform as required and resist or recover from failure of any kindis really the key issue that organizations need to consider.
While the improved productivity achieved by agile software development practices is compelling, agile methods such as Extreme Programming (XP) do not explicitly address security and reliability. Why not? Because the assumption is that these issues will be addressed by the project's customers. Some have addressed the issues from the perspective of testing (www.testing.com/writings/ evaluating-test-suites-paper.pdf) and design (Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, by Scott Ambler, Wiley, 2002) or security (e.g., Beznosov, Towards Agile Security Assurance, presented at www.nspw.org/2004). Still, there needs to be a cohesive agile framework that addresses assurance.
The Importance of Design for Assurance
To avoid constantly saying "architecture and design," we use the terms "architecture" and "design" interchangeably. After all, an architecture is merely a high-level design, and for purposes here the distinction is not important.
Newcomers to some agile methods think that design is passé, a myth dispelled in many sources (www.martinfowler.com/ieeeSoftware/ whoNeedsArchitect.pdf). In Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, one of us (Scott) explains why long-term objectives need to be considered if they are important to the organization. For example, objectives such as maintainability may mean that certain kinds of documentation are required as deliverable artifacts. The key is to create "agile documents" (www.agilemodeling.com/essays/ agileDocumentation.htm).
Let's be clear about what a design is. A design is an enumeration or description of elements or attributes of an application's intended manifestation. Design may also address semantic elements, such as relationships between structural elements, sequence, cardinality, and in general, any aspects important for implementers to know to be able to produce an implementation that adheres to the design's intent.
The embodiment of a design is a set of artifacts. The artifacts can be code, unit tests, diagrams, or documented decisions about important technical issues. These are not mutually exclusive.
In 2004, Peter Neumann stated, "Good system and network architecture is perhaps the most fundamental aspect of any efforts to develop trustworthy systems..." (www.csl.sri.com/users/ neumann/chats4.html). The reason behind this belief is that a design embodies the concepts that ensure that the system has certain hard-to-test properties, such as being secure. The design addresses how these properties are achieved, via the components of the design and their required relationships.
A design should not only state what elements exist in an application, but it should also state why they exist. For example, if a particular software layer exists to protect an underlying resource, then the layer should not be eliminated in order to simplify the design. The layer exists to satisfy a security requirement, and the layer's design should state how that is achieved. To explain how, you must ask "why?"; otherwise, you are explaining how something happens that you do not even have an expressed justification for.
There is another reason that "why" is important: It expresses a conclusion about the adequacy of a feature. That conclusion is then open to challenge. Agile design is about evolving a solution over time, and about continually challenging each "why" and its associated conclusions.