Monday, 3 December 2012
13:30 - 17:00

Windsor

Requirements engineering defects cost 10 to 200 times more to correct during implementation than if they are detected during requirements development. A study found returns on investment of 12 to 21 percent when security analysis and secure engineering practices are introduced early in the development cycle. It is very difficult and expensive to significantly improve the security of an application after it is fielded in its operational environment. When security requirements are considered at all during the system development life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. A systematic approach to security requirements engineering will help to avoid the problem of generic lists of features and to take into account the attacker perspective. In this tutorial we provide a broad overview of security requirements engineering, covering topics from elicitation through review, along with pointers and links to additional resources.

Prerequisites. Experience or academic background in software engineering or information security.

Outline:

1. Introduction and Software Requirements Fundamentals (15 minutes)

Why requirements are important and why attendees should care about security requirements. Many cost/benefit examples are available to support this.

Definition of a Software Requirement. Definitions and brief examples of software requirements and software security requirements.

2. Requirements Process (45 minutes)

Process Models. It is important to choose a security process model. This tutorial will describe the CLASP, SQUARE, and SREP process models.  These multistep models provide broad support to security requirements development.

Roles. In addition to the usual roles, security specialists also need to be included among the stakeholder groups. These could be software or systems engineers specializing in security, members of a security process group, or operational security specialists.

Linkage with NIST Processes. Discuss connections with NIST processes such as determination of impact levels, selection of security controls, and other security requirements related topics.

3. Risk Analysis and Modeling (15 minutes)

Security Risk Analysis.  Discuss risk analysis methods that are specific to software security and modeling techniques such as threat modeling and attack trees. 

4. Requirements Elicitation (30 minutes)

Requirements Sources. Discuss the need to identify assets and to set high-level security goals and give examples. Discuss whether the domain has specific security requirements e.g. finance, defense, critical infrastructure. The operational environment may contribute to the overall security picture e.g. remote access.

Elicitation Techniques. There are a lot of elicitation techniques that are well-suited to security. Some of the usual requirements elicitation approaches are not so great (for example JAD) as they are focused exclusively on end-user features, and this does not typically do a good job of eliciting security requirements. Examples will be given for selecting elicitation techniques on a particular project.

5. Requirements Analysis (15 minutes)

Requirements Classification. There are a number of approaches for classifying security requirements. For example, they could be classified as system level, software level, or architectural constraints. The idea of classification will be discussed along with examples.

Requirements Negotiation. Here we would cover methods such as AHP for prioritizing requirements and other methods of performing cost/benefit analysis. Here we would also discuss tradeoff analysis with other types of requirements, such as performance and usability. In order to properly prioritize and tradeoff, security risk analysis needs to be discussed.

6. Requirements Reviews (15 minutes)

Requirements Inspections and Peer Reviews. Focus on reviews and inspections as they relate to software security requirements. Are there new inspection roles? Are the security requirements consistent with the other software requirements or are there conflicts?

7. Requirements in Acquisition (30 minutes)

Acquisition security requirements. Discuss security requirements as they relate to various types of software acquisition, including custom contract software as well as COTS. Note linkage with supply chain risk management topic in the Software Assurance Methods tutorial. 

8. Practical Considerations and Wrap-up (15  minutes)

Iterative Nature of the Requirements Process. Certain changes, such as architectural changes or operational environment changes should cause security requirements to be revisited. Also, over time, priorities may change. New threats may emerge, etc.

Requirements Tracing. Discuss the unique aspects of tracing security requirements as well as the usual lifecycle requirements traceability to design, etc.

Measuring Requirements. Techniques for measuring security requirements process and product exist but this is still very much of an open research area. Describe what has been done so far and what remains to be done. Note linkage with measurement topic in the Software Assurance Methods tutorial.