On cgisecurity, Robert has a good post on QA and security. My take is that in security we are in no position to turn any allies away, and need to in fact actively seek allies by identifying common interests whether they are in development, QA, business analysis, legal, or even customers and partners. Robert has a checklist approach which should work well for many organizations, taking your own Top X list and then asking the following
- Identify which issues require a human to identify
- Can this be identified by QA?
- Can this only be identified by development?
- Identify which ones can be tested in a repeatable automated fashion
- Using existing QA tools
- Using Security tools in the QA department
- Identify which vulns are automatically identifiable in a reliable fashion based on the tools you have
available to you/after a proper tool evaluation.
I have found similar issues in working with QA where you sometimes have to connect the dots, but the good news is that the more the security message is advocated outside of the security group the better. And in many places QA has authority to get fixes into the code.
Robert brings up another good point on QA - "they understand business use cases provided to them, and ensuring that the business use cases work (positive testing)...Good training programs should use wording that makes sense to QA", totally agree, they are not going to read the whole OWASP guide as much as we might like them to. QA can however read Use Cases, and in my experience they can also read Misuse Cases. The latter is important, Use Cases give QA functional specs - "execute order, place trade, update customer", but they don't tell you anything about security. Security is just implicit and based on whoever is reading assumptions. Misuse Cases describe the threats to the system and analyze the countermeasures to deal with those threats. These are then concrete requirements for QA testing.
Finally, QA is a great ally to have because its a generally accepted preexisting gate in the SDLC. They run the bug checks, they maintain the database, they execute the checklists and so on, basically security needs to get them some better tests and they can run with it. Its not a case where security needs to reinvent the process, just enable QA to do some security work through training and introducing a new artifact such as a Misuse Case, its an area where Infosec can often get a good bang for the buck.
Update: from Adam Shostack, erstwhile Emergent Chaos bandleader (via mail): QA also tends to think about "what could go wrong?" If you teach them about security, the orientations merge pretty well. At MS, I push for test to own threat modeling, and to think of it as a test planning
approach.
Given the long history of threat modeling at MS, different teams have different disciplines (in the sense of dev, test or PM) who successfully drive TM. But when asked for advice, I always say test.
Comments