Software Requirements

Model | Design | Security Requirements | Software Requirements

Benefit

Understanding of key security requirements during development

Activity

Perform a review of the functional requirements of the software project. Identify relevant security requirements (i.e. expectations) for this functionality by reasoning on the desired confidentiality, integrity or availability of the service or data offered by the software project. Requirements state the objective (e.g., “personal data for the registration process should be transferred and stored securely”), but not the actual measure to achieve the objective (e.g., “use TLSv1.2 for secure transfer”).

At the same time, review the functionality from an attacker perspective to understand how it could be misused. This way you can identify extra protective requirements for the software project at hand.

Security objectives can relate to specific security functionality you need to add to the application (e.g., “Identify the user of the application at all times”) or to the overall application quality and behavior (e.g., “Ensure personal data is properly protected in transit”), which does not necessarily lead to new functionality. Follow good practices for writing security requirements. Make them specific, measurable, actionable, relevant and time-bound (SMART). Beware of adding requirements too general-purpose to not relate to the application at hand (e.g., The application should protect against the OWASP Top 10). While they can be true, they don’t add value to the discussion.

Question

Do project teams specify security requirements during development?

Quality criteria

Teams derive security requirements from functional requirements and customer or organization concerns
Security requirements are specific, measurable, and reasonable
Security requirements are in line with the organizational baseline

Answers

No
Yes, for some applications
Yes, for at least half of the applications
Yes, for most or all of the applications

Benefit

Alignment of security requirements with other types of requirements

Activity

Security requirements can originate from other sources including policies and legislation, known problems within the application, and intelligence from metrics and feedback. At this level, a more systematic elicitation of security requirements must be achieved by analysing different sources of such requirements. Ensure that appropriate input is received from these sources to help the elicitation of requirements. For example, organize interviews or brainstorm sessions (e.g., in the case of policy and legislation), analyze historical logs or vulnerability systems.

Use a structured notation of security requirements across applications and an appropriate formalism that integrates well with how you specify other (functional) requirements for the project. This could mean, for example, extending analysis documents, writing user stories, etc.

When requirements are specified, it is important to ensure that these requirements are taken into account during product development. Setup a mechanism to stimulate or force project teams to meet these requirements in the product. For example, annotate requirements with priorities, or influence the handling of requirements to enforce sufficient security appetite (while balancing against other non-functional requirements).

Question

Do you define, structure, and include prioritization in the artifacts of the security requirements gathering process?

Quality criteria

Security requirements take into consideration domain specific knowledge when applying policies and guidance to product development
Domain experts are involved in the requirements definition process
You have an agreed upon structured notation for security requirements
Development teams have a security champion dedicated to reviewing security requirements and outcomes

Answers

No
Yes, some of the time
Yes, at least half of the time
Yes, most or all of the time

Benefit

Efficient and effective handling of security requirements in your organization

Activity

Setup a security requirements framework to help projects elicit an appropriate and complete requirements set for their project. This framework considers the different types of requirements and sources of requirements. It should be adapted to the organizational habits and culture, and provide effective methodology and guidance in the elicitation and formation of requirements.

The framework helps project teams increase the efficiency and effectiveness of requirements engineering. It can provide a categorisation of common requirements and a number of reusable requirements. Do remember that, while thoughtless copying is ineffective, the fact of having potential relevant requirements to reason about is often productive.

The framework also gives clear guidance on the quality of requirements and formalizes how to describe them. For user stories, for instance, concrete guidance can explain what to describe in the definition of done, definition of ready, story description, and acceptance criteria.

Question

Do you use a standard requirements framework to streamline the elicitation of security requirements?

Quality criteria

A security requirements framework is available for project teams
The framework is categorized by common requirements and standards-based requirements
The framework gives clear guidance on the quality of requirements and how to describe them
The framework is adaptable to specific business requirements

Answers

No
Yes, for some applications
Yes, for at least half of the applications
Yes, for most or all of the applications

Stream Guidance

Want to contribute?

Complete this Google Form with guidance for this Stream.



To learn more about Stream guidance for the SAMM model, see the Stream guidance page.