Regardless of the type or complexity of the software you are developing, the software your development team produces is only as good as the requirements that drive the project. However, on the subject of security, virtually all well-run software projects-whether based on formal processes or agile methods-fail to address security during the requirements process. Security that isn't given proper attention is relegated to an afterthought.

There are many best practices that contribute to high-quality software requirements, such as high-bandwidth communication between the development team and customers, but these best practices offer no guarantees that the software will realize the intent of the requirements.

In fact, just about the only certainty that a development team has with requirements is that if requirements do not exist for a certain feature, then that feature will not come to fruition.

Millions of dollars and words have been spent on the importance of addressing application security throughout our software development to protect our businesses from compromise. Nevertheless, we expect that security just happens during our development-without our using formalized security requirements or committing to security at the beginning of a project.

Emergent Qualities
Security is an emergent quality of software, much like usability and performance, in that it comes together as the team implements all of the functionalities. Requirements for emergent qualities typically strive to impose some minimum standards on the software or specifically prohibit unwanted behavior, rather than stating expected software behavior like for functional requirements.

For example, a usability requirement might specify that a user should be able to perform certain function in a minimum number of clicks. A performance requirement might state that no page in the application should take longer than two seconds to load. Similarly, security requirements often spell out what malicious actions the application should not allow a user to do.

Writing Security into Requirements
Security requirements need to be very specific about the subsystems that should be protected in your application, what types of protection must be in place, and what types of application attacks must be specifically safeguarded in your system. For example, one security requirement that should be a part of every single Web application project is to validate all externally provided inputs on the server. Validating all inputs will prevent up to 80 percent of all application layer security attacks and should be explicitly required and tested in every project.

Security requirements should also require that sensitive parts of the application be protected. All confidential and restricted access portions of the application should be protected by authentication. Escalation of privileges from unauthenticated users should not be possible. All critical-level application vulnerabilities should be protected against and verified in security testing, including command injection, SQL injection, cross-site scripting, and parameter manipulation.

Your development and quality assurance teams should counter and test specifically for all application security vulnerabilities in the
Open Web Application Security Process' (OWASP) Top Ten Project. OWASP offers just a few examples, but the message is that you must be very specific about these security requirements or security will not get addressed during development.

Effectively Testing Security Requirements
If you have spent any time in software development, you've likely heard quality assurance teams complain about the inadequacy of requirements for test planning and test coverage. You might hear them say, "How am I supposed to test it when I don't know what it's really supposed to do?" This statement validates that security testing becomes an even bigger challenge for quality assurance when there are no security requirements. Keep in mind that the average quality assurance professional does not have security experience or training necessary to conduct exploratory security testing without adequate requirements.

Starting the software development project off with effective security requirements ensures that the quality assurance team will be able to address security in its project planning, during testing tool acquisitions, and in test coverage. With security requirements, team members can make educated decisions about the types of application security testing they are expected to conduct.

Early security testing planning provides quality assurance planners with insight into what portions of the security testing challenge are outside of their scope and need to be assigned to the security team, like network security and production environment configuration.