I often feel the arguments about quality assurance and what should be classified as testing, verification or validation detracts from the goal of a software development team; that is a secure, reliable product that does what it is intended to do. In my mind, software quality assurance (SQA) encompasses the entire software development process from start to finish. So the whole progression of evaluating and monitoring the security of an application should be part of a software quality assurance program, along with other processes, such as the design of the software and change and release management.
When it comes to security, the goal of software quality assurance is to confirm the confidentiality and integrity of sensitive data is protected as it is processed, stored and transmitted, and that the application can resist attack to agreed risk levels. This means that threat modeling scenarios and acceptable risk levels need to be established up front so developers and the QA team know what to expect and what to work toward.
Threat modeling, carried out during the application design stage, is the process of identifying and evaluating the risks to an application. The procedure identifies potential threats by categorizing the assets or sensitive information an application accesses. By having your security professionals and developers sit down together to analyze the application from an attacker's point of view, everyone will gain a better understanding of how and why a hacker may attack it and how the vulnerabilities can be removed. Threat modeling should take place when the user requirements for a new application have been gathered and work has started on the architecture and design of the application.
This exercise not only ensures architecture design issues are resolved early on, but it also creates a set of documents that identify and justify the security requirements of the application. Countermeasures can then be implemented and tested to ensure the application doesn't leave sensitive or personal information vulnerable to potential attackers. Any remaining security-related bugs or weaknesses should be tracked with an agreed escalation policy.
The aim of the software-testing stage is to uncover and locate bugs and also validate and verify that the software works as expected and meets the business and technical requirements that guided its design and development. It makes little sense to run security testing and validation as a completely separate process as it would only delay and disrupt the overall change and fix processes. Putting security within the software quality assurance program will ensure that it's not covered as an afterthought or in an ad-hoc fashion. It will also help ensure the security controls implemented meet any necessary security standards and regulations, such as ISO 27001 or the Payment Card Industry Data Security Standard.
This was first published in September 2009