Non-Negotiable Elements of a Secure Software Development Process: Part 1 - Security Requirements

In September, I gave a presentation focused on helping quality assurance professionals understand how they fit into a secure software development process (SSDP) and how they can take an active role in improving software security.  In that presentation, I discussed essential elements that make up a successful SSDP.  These elements are: security requirements (expectations); secure architecture, configuration, and coding patterns (how to satisfy an expectation); and validation criteria (verification that expectations have been met). These elements allow an organization to be transparent regarding its security goals and performance.  They also facilitate communication with customers, developers, managers, and other project stakeholders.

This is part 1 in a series of articles discussing Non-Negotiable elements of a secure software development process. This article focuses on security requirements. All three articles are listed below:

Part 1: Security Requirements
http://blog.securityps.com/2013/01/non-negotiable-elements-of-secure.html

Part 2: Secure Architecture, Configuration, and Coding Patterns
http://blog.securityps.com/2013/01/non-negotiable-elements-of-secure_15.html

Part 3: Validation Criteria
http://blog.securityps.com/2013/03/non-negotiable-elements-of-secure.html

What are Security Requirements?
Security requirements are intended to be language and framework agnostic statements that communicate the organization’s expectation around a security practice.  Security requirements are applicable for any project or team regardless of whether they are using ASP.NET MVC, J2EE with Spring MVC, or Ruby on Rails.  They use positive statements to describe the type of behavior desired, and use negative statements to provide additional clarity.  The ideal is to whitelist specific approaches to developing software.

An example security requirement intended to prevent SQL injection that meets this criteria might be:

“Applications that use an SQL database must use parameterized queries or prepared statements for all transactions, including SELECT, INSERT, UPDATE, DELETE, and stored procedure calls. Define the SQL query and use placeholders to denote the location in which parameter values will be added later. Then, add each value to the statement as a parameter. All variables must be added as parameters rather than being concatenated with the SQL query.”

This requirement is clear and understandable, it is easy to validate (more on this later), and it leaves the implementation up to the team.  Developers can choose to write dynamic queries that use prepared statements or they can use a framework, like Hibernate or LINQ to SQL that also follow this practice but abstracts the actual queries.

An example of a well intentioned but unsuccessful security requirement that also seeks to address SQL injection is:

“Write queries that do not allow untrusted user input to be interpreted by the database as SQL commands to prevent SQL injection.”

While this example is probably too simplistic, the reality is that most organization start with requirements that are just as ill-defined. The typical starting point is to focus on writing requirements that state what not to do instead of identifying the positive practice that will eliminate the vulnerability.  Ill-defined requirements like this one do not equip the development team with the means to succeed at meeting security expectations.

Benefits of Defining Security Requirements
Developers, customers, managers, and the organization at large benefit from security requirements in several ways.  First, security requirements can be discussed during the project planning stages with stakeholders.  Teams can decide how expensive it might be to satisfy a specific requirement and build that time into the software development process.  If these security requirements are linked with real business related consequences, customers or stakeholders can decide how much to spend on securing the application based on their budget, the sensitivity of data, or how critical the application is to the business.  

Developers benefit by having well defined requirements, clear expectations, and timelines that account for the implementation of agreed upon security components.  The team should also be able to articulate which types of threats the application is designed to repel as well as those that it is not, making security much more transparent.

Organizations benefit by being able to define collections of security requirements as assurance standards.  These collections of security requirements can be designed to satisfy PCI requirements, contractual obligations, or minimum security baselines.  Next, the assessors or evaluators of these standards can quickly and cheaply identify how an application meets the requirements.  In addition, organizations can leverage the security story of a specific application for marketing purposes or as a competitive advantage.

Security Requirements Wrap-up
Ideally organizations should define realistic, understandable, and measurable security requirements. By explicitly stating these requirements and using positive statements to define achievable development practices, the team is able to plan for, communicate, and meet the organization's security goals.  These software language and framework agnostic requirements naturally give way to specific implementation details for each project in the form of secure architecture, configuration coding patterns.  These patterns will be discussed in part 2.