Implementing security requirements to ‘shift left’ and create ‘secure by design’ software

Implementing security requirements to 'Shift Left' and create 'Secure by Design' software

In this blog post we want to have a look at why good security requirements are important and how these should be constructed, based on our experience working with development teams at various organizations, large and small.

Security requirements will help you in your process to ‘Shift Left’ and create ‘Secure by Design’ software, terms that are not only buzzwords sparking your interest in this blog post, but also valuable concepts in application security.

The importance of security requirements

Everyone will agree on the importance of functional requirements, defining what an application should do, based on users’ needs, and which can be tested at the end of the development lifecycle.

A similar principle applies to security requirements, defining security properties of software, based on the security profile of the application [1], and which can be tested at the end of the development lifecycle.

As such, security requirements help to prevent both security flaws (design mistakes) and security bugs (coding mistakes).

How to construct a security requirement

Once development teams are convinced of the importance of testable security requirements, we see that the question many development teams struggle with is how these requirements should be drafted. In the next paragraphs, we give you some direction.

Security requirements must have certain granularity

The requirement can be defined organization-wide, application specific, or something in between. Obviously, the closer a requirement applies to a specific product, the more detailed it will be. Conversely, business-unit- and company-wide requirements will be less specific because of the need for decoupling from technology- and development stacks. Both levels are important to have in your security requirements.

Security requirements must be based on various sources, such as:
  • Earlier vulnerabilities
  • Industry standards
  • Applicable laws and regulations
Security requirements must contain a modal verb², with a specific and organization-wide known meaning:
Modal verb Explanation
MUST NOT This phrase, or the phrases “SHALL NOT” or “DOES NOT”, mean that the definition is an absolute prohibition.
MUST  This word, or the terms “REQUIRED”, “DOES” or “SHALL”, mean that the definition is an absolute requirement, (a.k.a. “hard requirement”) and exceptions/acceptance of a deviation MUST NOT be possible.
SHOULD  This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item. However, the full implications of doing so MUST be understood and carefully assessed before ignoring any behavior described with this label.
This being a semi-hard requirement, exceptions can be granted by the appropriate risk owner and MUST be regularly evaluated, e.g., through the risk register of the CISO office.
SHOULD NOT  This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances where the behavior is acceptable or even useful. However, the full implications of doing so MUST be understood, as well as having the case carefully assessed before implementing any behavior described with this label.
The same risk acceptance process as mentioned under “SHOULD”, also applies here.
COULD This phrase is used to point to a list of options from which at least one must be chosen. Hence, this phrase is meant to leave you a choice between different implementations.
Security requirements must comply with some meta-requirements
  • Uniquely identifiable
  • Versioned
  • Focused
  • Unambiguous
  • Testable
Security requirements should follow a syntax template

To help write security requirements that comply with the meta-requirements mentioned above, we provide a syntax template[3]. This helps to write in a systematic way, avoiding inconsistencies.

<Logical and Temporary Conditions> + <Subject> + <Modal verb> +

<Security mechanism> + <Object> + <Security attribute>

Example:

If login-input or password-input contain wrong data, the system must provide the user the error message ‘credentials are incorrect.’.

In the below table, you find an explanation of every syntax component, as well as the applicable part of the example given above.

Syntax component Explanation
<Logical and Temporary Conditions>
[optional]
The conditions under which the requirements apply
Example: If login-input or password-input contain wrong data
<Subject>  [mandatory] The person or thing that the sentence is about. It’s often the person or
thing that performs the action of the verb in question and it usually comes before the verb.
Example: the system
<Modal verb> [mandatory] A verb (a modal auxiliary), expressing the mandatory nature of the requirement.
Example: must
<Security mechanism> [mandatory] Describes the type of method used to enforce a form of security:
Example: Provide the error message: “Credentials are incorrect.”
<Object>
[optional]
The person or thing affected by the binding character and security mechanism
Example: the user
<Security attribute>
[optional]
A group of words that explains or justifies the security requirement.

To show that the syntax template is not a goal in itself, observe the following requirement regarding secrets management, failing to achieve its goal.
Any data that is considered a secret SHOULD NOT be hardcoded into source code.
This is a mediocre requirement, because:

  • It is ambiguous: what is considered a secret ?
  • It is not testable without a lot more information on the operational details of how a violation would be identified.
  • It is prohibitive, rather than prescriptive. This would not be a problem, if prescriptive guidance is added, but lacking other requirements with regards to secrets management, this is an issue.
  • The use of the verb SHOULD is not necessarily a problem, assuming that the risk acceptance process is clear enough to dictate when a deviation is acceptable.

We could solve this by creating a context through defining multiple requirements that work on different levels.

  • Firstly, a clear understanding of which data points are (not) a “secret” should be clearly established first. For this, a global data-classification requirement can be used.
  • To be able to determine absence of these secrets in source code, there must be a process requirement that dictates how to go about that, either for the product or in general.

We hope these directions help you to set up a qualitative security requirements stack!

If you are still looking for ways on how to create or improve a secure SDLC and if you want some tailor-made help, then contact us!

Don't know where to start?

Is your organization an SME?

[1] Depending on the risk profile of the application, more or less security effort (aka time and money) should be invested.

[2] A modal verb is a type of verb that contextually indicates a modality such as a likelihood, ability, permission, request, capacity, suggestion, order, obligation, or advice. Modal verbs always accompany the base (infinitive) form of another verb having semantic content. In English, the modal verbs commonly used are can, could, may, might, shall, should, will, would, and must.

[3] Please note that adhering to the below syntax template should not be a goal in and of itself. If requirements (or requirement-sets) comply with their meta-requirements, they are good to be implemented. Still improvable, perhaps, but nevertheless a good starting point.

Start typing and press Enter to search

Shopping Cart
Copy link
Powered by Social Snap