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.
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.
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!
