Security Requirements

Security requirements can be formulated on different abstraction levels. At the highest abstraction level they basically just reflect security objectives. An example of a security objectives could be “The system must maintain the confidentially of all data that is classified as confidential”.

More useful for a SW architect or a system designer are however security requirements that describe more concretely what must be done to assure the security of a system and its data. OSA suggests to distinguish 4 different security requirement types:

Secure Functional Requirements, this is a security related description that is integrated into each functional requirement. Typically this also says what shall not happen. This requirement artifact can for example be derived from misuse cases
Functional Security Requirements, these are security services that needs to be achieved by the system under inspection. Examples could be authentication, authorization, backup, server-clustering, etc. This requirement artifact can be derived from best practices, policies, and regulations.
Non-Functional Security Requirements, these are security related architectural requirements, like “robusteness” or “minimal performance and scalability”. This requirement type is typically derived from architectural principals and good practice standards.
Secure Development Requirements, these requirements describe required activities during system development which assure that the outcome is not subject to vulnerabilities. Examples could be “data classification”, “coding guidelines” or “test methodology”. These requirements are derived from corresponding best practice frameworks like “CLASP”.