I've recently been looking into what security Non-Functional Requirements (NFR) we should be specifying, with the aim of providing some useful guidance.  I've come up with a basic set of security NFR's - as shown in the diagram below.  I know some of the wording is a bit vague – you might want to review this before using it as the basis for anything contractual.

At the top level is the good-old "The system shall be secure..." which as we all know is not very helpful as it's not testable; to get around this we start breaking it up into meaningful areas and drilling down until we start establishing some useful (and testable) requirements.

Some security NFR's. (Click for full size image - 116KB)

Notable Gaps:

• Specific technologies: you sholuld include any internal security related standards if you have them - technologies, systems, components or products that are to be used.
• Single Sign-On: this is more of a functional aspect, but you might include or refer to it in your NFR's.

I then came up with what I've called "System Contexts"; how sensitive is the data? is the system externally facing? and so on. 

• User input that is stored would be anything which the application stores during normal use (profile info, etc).
• User input that is not stored might include criteria entered into a search field (although this might be logged - does that mean it's stored? Obviously you need to think these sorts of things through).  If its a web-based system you might want to consider other forms of user input such as the querystring.

Some of these system contexts are directly related to some of the NFR's - and some more than others.

High level relationships between system contexts and the security NFR's. (Click for full size image - 120KB)

The result is this matrix (below and attached, MS Excel - 32KB) which you can use to help you decide which security NFR's to include in your spec (or which ones you need to discuss with the business stakeholders); you should also use it to help you decide what MoSCoW rating to give it.   For now, I've just dumped all the NFR's in here - regardless of if they are a specific one or a high-level 'concept'.  As a general rule: Within each system context, the further to the right the column is the higher the risk ('high" data sensitivity presents more of a risk than "low").

You'll notice that each of the NFR's is defined along the lines of "The system shall…", when you actually specify the NFR's you should be using MoSCoW ratings (most likely either "Must" or "Should").
The MoSCoW rating in the matrix are based on what I think should be applied in a given scenario - but they aren't signed-off as an official standard.  I imagine the Security & Infrastructure Architect will want to look at this (and extend it?) when they get appointed.

How Do I Use The Matrix?

Let's take a hypothetical example. 

1. First identify the system contexts which apply to the system.  In this case it:
   • Doesn't have particularly sensitive data.
   • It's externally facing.
   • It allows users to enter data (in this case it might just be a search field.
   • The use population includes external users.

2. Then, for each NFR (as listed in the left-hand column) take the highest MoSCoW rating.  So:
   • Because the system is externally facing, we MUST encrypt data transmissions.  Obviously we'll need to identify which data this applies to; even though the data isn't sensitive as it's an externally facing system (maybe it's on-line) and we have restrictions on who can access the system/data then we need to encrypt it where applicable.  If the system was internally facing then this would be SHOULD.
   • Alternatively if the data was highly sensitive then we'd need to be more careful. 
   • The only time the majority of NFR's won't be mandatory is when you're at the lowest level of risk.
   • For a given project you might be able to negotiate a lower level of risk for one or more of the columns if there is a sound reason.  For example: if access to the system is restricted by IP address you might be able to classify the system as "Internal" as far as data encryption goes.  The data might not be confidential but the system providing it to external parties might not be intended (or able) to serve the public at large - so the restriction is more from an "access to resources" issue, rather than data sensitivity specifically.

Remember: the matrix is a guide only (and this is the first draft), so the NFR's will need to be applied with some thought.  I'd also suggest changing the C/S/M values in th emartix to match your expectations; it's not so much the actual values as I have them that's important - but the process of actually thinking about things.

Finally, these resources might be helpful when thinking about this sort of thing:

• http://cwe.mitre.org/index.html (the Common Weakness Enumeration Project).
• http://www.sabsa-institute.org/the-sabsa-method/the-sabsa-model.aspx (the Sherwood Applied Business Security Architecture model).
• http://www.owasp.org/index.php/Main_Page (OWASP - the Open Web Application Security Project).

I'll be giving usability NFR's a similar treatment soon.