Security engineering in Agile

The Agile manifesto defines a number of principles, some of which present difficulties for the integration of security engineering approaches, such as frequent delivery of software. There are often numerous security requirements that a product must satisfy, and it is difficult to address these requirements in a short development cycle.

Also, a focus on security decreases the velocity that can be applied to functional user stories in Agile development.

When considering how to handle security requirements, it becomes clear that the same thought and attention must be given to these and to other Non-Functional Requirements (NFRs) such as reliability, performance, scalability, usability, portability, and availability. Some argue that these non-functional requirements should be handled as constraints that are pulled into the definition of done and are eventually met by each user story.

However, the transformation of all security (and non-functional) requirements into constraints does not scale well when the development team must deal with dozens or hundreds of security requirements.

A few years back, Microsoft developed an approach to handling security requirements within Agile developments (https://www.microsoft.com/en-us/SDL/discover/sdlagile.aspx). The process introduces concepts for categorizing requirements in a manner that reduces strain on the development team.

Microsoft's methodology introduces the concepts of One-Time, Every-Sprint, and Bucket practices to meet security requirements.

One-Time practices are applicable to the secure setup of a project, and also include other security requirements that must be met from the start, for example:

• Establishing secure coding guidelines that must be followed throughout development
• Establishing an approved software list for third-party components/libraries
• Establishing automated mechanisms for verification of security requirements
• Establishing a secure configuration management suite of tools
• Establishing a process for peer reviews and/or pair programming
• Establishing guidelines for documenting the product/system

Every-Sprint practices are applicable to each sprint. Hours are estimated for each requirement during sprint planning, for example:

• Performing peer reviews on code to help identify bugs, before merging into the baseline
• Ensuring that code is run through static code analysis tools within the CI environment

Bucket practices can be implemented and satisfied over the life of a project. Putting requirements into buckets allows teams to choose to import them into sprint planning when it makes the most sense—for example when there is excess team velocity available after planning the sprint's user stories, or when hard-to-find security staff expertise becomes available.

There are also functional security requirements that should be added to the backlog. An example of a functional security requirement for an IoT device may be to establish a TLS connection to the device's gateway securely. These requirements can be added to the product backlog and prioritized as needed by the product owner during grooming sessions.

You can turn these functional security requirements into user stories, and add them to the product backlog. Examples of functional security user stories include:

• As a user, I want to ensure that all access passwords on my IoT device or cloud service are strong (for example, in complexity, length, or composition)
• As a user, I want to be able to track IoT devices' authorized usage (for example, through entitlement tracking)
• As a user, I want to ensure that any data stored on my IoT device is encrypted
• As a user, I want to ensure that any data transmitted by my IoT device is encrypted
• As a user, I want to ensure that any key material stored on my IoT device is safeguarded from disclosure or other unauthorized access
• As a user, I want to ensure that any unnecessary software and services are disabled and removed from my IoT device
• As a user, I want to ensure that my IoT device only collects data that is meant to be collected
• As a user, I want to ensure that my IoT device credentials can be updated

Other examples of security user stories can be found in the SAFECode document practical security stories and security tasks for Agile development environments at http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf.

You'll notice that these user stories are relatively general in nature. For example, we don't specify implementation details in the user story.

In keeping with the spirit of Agile development, the team discusses each user story during a sprint-planning session, and breaks down the story into tasks based on a shared understanding of the story. This is the process by which additional detail is added to the user story—in a team environment, and not dictated by the individual that originally authored the user story. 

Remember that the product backlog should also include user stories that focus on hardware security, such as:

• As a security and QA engineer, I want to ensure that the UART interface is password-protected
• As a security and QA engineer, I want to disable JTAG interfaces prior to product launch
• As a security and QA engineer, I want to implement tamper response into my IoT device casing

As with the other development methodologies we've discussed, security testing is required in Agile. Automation of security tests is a key goal, and many tools are used within the CI environment to report defects found during each build.

Security engineers take on the roles of evangelists in Agile, promoting secure code development by working with developers to create secure coding standards, introduce pair programming techniques, and provide support for code reviews.