+D-SR-A Stream A: Software Requirements
---+D-SR-1-A Identify security requirements
---+D-SR-2-A Standardize and integrate security requirements
---+D-SR-3-A Develop a security requirements framework

D-SR-A Stream A: Software Requirements

Software requirements specify objectives and expectations to protect the service and data at the core of the application.

1. Übersicht

D-SR-1-A Identify security requirements

Maturity level 1 objective of the practice: Consider security explicitly during the software requirements process.

Benefit: Understanding of key security requirements during development

Short description: High-level application security objectives are mapped to functional requirements.

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 specifically 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.
D-SR-2-A Standardize and integrate security requirements

Maturity level 2 objective of the practice: Increase granularity of security requirements derived from business logic and known risks.

Benefit: Alignment of security requirements with other types of requirements

Short description: Structured security requirements are available and utilized by developer teams.

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 analyzing 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. Set up 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).
D-SR-3-A Develop a security requirements framework

Maturity level 3 objective of the practice: Mandate security requirements process for all software projects and third-party dependencies.

Benefit: Efficient and effective handling of security requirements in your organization

Short description: Build a requirements framework for product teams to utilize.

Set up 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 categorization 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.

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.3 Zugehörige Regulierungen

2. Identifizierte Anforderungen

Anforderungen

3. Zugehörige Regulierungen

Regulierungen
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.