One of the biggest initial resistors I have run across within Federal government employee stakeholders are information security personnel (and their supporting contractors). This is often because when they learn about how requirements are managed with user stories they don’t see a fit for their requirements; in the Federal space these are guided by FIPS 200 and NIST 800-53 (currently at rev 4). Other writings on the subject do little to help them. Most advocate a separate and distinct type of story such as this paper by SafeCode or relying wholly on Dark or Evil stories written from a point of view of someone trying to gain access to a system, or deny access to a system.
There is no reason software-centric security controls can’t become user stories and/or acceptance criteria to user stories. This post is going to attempt to show you a bit how to think on this. There is value in using dark stories as well, but I advocate first getting stories that incorporate NIST controls within the backlog.
First up, one must understand that the controls in NIST 800-53 cover a large number of dimensions including physical space control, configuration management, training, etc. When attempting to convert the controls into user stories and/or acceptance criteria, focus only on the ones that are software-centric. Controls that deal with authentication, authorization, audit logging, system monitoring, or encryption are great candidates.
Second, per NIST guidance, the organization is expected to establish the baseline needs of applications/systems and then select and tailor the controls needed. This responsibility can fall to the people managing the product features (in Scrum this would be the Product Owner) in concert with IT Security staff. By articulating these as user stories or acceptance criteria to user stories, these now have business value. The person managing what gets done no longer has to make a leap of faith or be told by someone externally that they just have to have it.
IN the following examples, we’re going to follow the Specifications by Example format and use a generics records review system as an example that places records in a list for authoritative storage (a separate system); it handles Personal Identifiable Information. Let’s start with a story…
User Login Story
As a User Requiring Authentication,
I want to Login to the DataReview application
So that I can review incoming survey data for quality//Standard Login Scenario
Given the username jsmith // valid userid
When I attempt a login using “nS3cure” // correct password
Then I the main home portal page is displayed for meGiven the username jsmith // valid userid
When I attempt a login using “123” // incorrect password
Then I see the login page again with the statement “Incorrect userid or password” stated along with a count of Login attempts.Given the username smithj // invalid userid
When I attempt a login using “nS3cure” //password correctness is immaterial
Then I see the login page again with the statement “Incorrect userid or password” stated along with a count of Login attempts.// Multiple Login Failure Scenario
Given two failed login attempts and the username jsmith // valid userid – 3 attempts require a lock out for a period of time
When I attempt a login using using “123” // incorrect password
Then I see the login page again with the statement “Third failed login attempt, your IP address has been locked out for 3 hours” // 3 hrs by policyGiven two failed login attempts and the username smithj // invalid userid – 3 attempts require a lock out for a period of time
When I attempt a login using “nS3cure” //password correctness is immaterial
Then I see the login page again with the statement “Third failed login attempt, your IP address has been locked out for 3 hours” // 3 hrs by policyGiven the IP address 130.3.55.121 is locked and the password lockout timer less than or equal to 3 hours // we’re testing using a static IP
When I attempt a login using any username or passowrd
Then I see the login page again with the statement “This IP address has been locked out.” and the password lockout timer is reset to 3 hours.
There could be numerous other additional acceptance criteria as well (password complexity for example), but at least now one can see how these user stories can articulate some of the NIST requirements (in this case AC-7 Unsuccessful Logon Attempts).
Let’s look at how security controls for auditing significant events might show up as acceptance criteria. In the following example from our records management system, post QC review, we are adding the person’s record into a queue for inclusion into the authoritative system. It is fundamental that we know when this data is placed in the queue for transmittal. This has been determined to be an auditable event per control AU-2.
Approve Record Story
As a QC,
I want to approve records
So that they can be queued for entry into the official records repository.//Approval
Given authenticated user jsmith has a valid QC role and bjones submitted the record “Mary Maryland” to jsmith for approval
When I approve the record “Victoria Virginia”
Then I see the message “Victoria Virginia record approved”, the record is appended to awaiting transmittal queue list, and an entry is made to the security audit log with <date-time>, “jsmith”, “QC”, “approved “Victoria Virginia” // policy requires approvals to official records to be logged//Disapproval
Given authenticated user jsmith has a valid QC role and bjones submitted the record “Mary Maryland” to jsmith for approval
When I disapprove the record “Mary Maryland”
Then I see the message “Mary Maryland record disapproved and returned to bjones” and the record is returned as the first item in the review queue for bjones
Here we can see how the record gets logged (one form of auditing) when approved. Because the record isn’t being readied to transition to the authoritative system when disapproved, it was determined that event wasn’t auditable.
Hopefully, this helps folk understand how NIST 800-53 security controls can be incorporated into user stories. By putting them into this format, the development tem now can develop to them and hook them into acceptance testing via something like Cucumber.
So I investigated how these normally got funded; any estimate done is simply reported up the chain (as requested Development monies), but the funds are actually provided by the programs that need the work done for them. These are used as a projection for the branch and nothing more. Any work really done goes through its own process of requesting and then actual money is provided.
Paul Boos' Nimblicious - Making Agility Tasty 