Functional vs. Non-Functional Security Requirements

In the non security world, there is a lot of confusion between the definitions and meanings of the terms functional and non-functional security requirements. I often see, for instance, people defining things like authentication as an non-functional others do this as a functional requirement.

Both terms might become a bit easier to distinguish if we clearify what they both actually describe:

A Functional Security Requirement (FSR) is a security feature, a function that a system or system component must be able to perform (IEEE), something that we can test, a yes/or no requirement, that we can define in concepts and that we can build test cases for.

Security can be defined using functional security requirements such as authentication, authorization, input validation, etc.

We mostly define FSRs in a positive way (a positive requirement), since we describe the presence of a specific security feature. In contrast, when we discuss something in a negative way (a negative requirement), for instance a specific attack is not suppose to be successfull, then we are most likely talking about a non-functional requirement.

A Non-Functional Security Requirement (NFSR) is a quality property. Something that we can not test in a yes or no way, but something that we can measure using metrics.

Examples for NFSRs are availibility, integrity, robustness, fault-tolerance, trustworthiness, attack resilience, attack tolerance, attack resitance and so on. We can't that an application has one of these attributes or not, we can only say that it has it to a certain degree.

Unfortunatelly, the often referenced quality model presented in the ISO/IEC 9126 standard for product quality in software engineering only defines the functional part of security requirements. Which could be one reason for those confusions.

In the context of security requirements I also found a couple of other interesting terms.

First of all one that was referenced as a Derived Security Requirement in an presentation given by Paco Hope from Cigital.

Since I am actually not aware of a rule stating that a FSR or NFSR must not be derived from FSR or NFSRs, I do not see why this is not just an additional attribute or subclass of either one of these. In most cases it would be a functional one I guess. In other words, a derived functional security requirement or derived FSR.

The OpenSecurityArchitecture Group introduces two additional terms:

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

This is actually a classic example for a negative security requirement (see above), which is mostly non-functional in nature (e.g. "XSS have to be prevented").

Secure Development Requirements, "these requirements describe required activities during system development which assure that the outcome is not subject to vulnerabilities".

And this one could be both functional and non-functional. In fact most secure coding guidelines are non-functional. This is because they are ment to be used in all kinds of applications.

So, in the end, it all comes down to either functional or non-functional security requirements. We can use one of those discussed attributes here to clarify them more but they are still functional or non-functional.