Security Testing Roles - Expanding on Integrating Security Testing into the QA Process

If you haven't read my previous post: Integrating Security into the QA Process and/or listened to the podcast from Rafal Los: http://podcast.wh1t3rabbit.net/down-the-rabbithole-episode-3-qa-and-security-can-we-make-it-work-, do that first.  The content below breaks down my thoughts on the type of security testing that can be integrated into each role (developer, QA, Security). This covers security testing, and does not include any other activities like threat modeling, architecture review, design review, following secure coding standards during development, etc.

Development Team:

• Use an automated static code analysis tool  (for example: Ounce, Fortify, or Veracode)
• Perform peer code reviews
• Construct and run unit/functional/automated tests for previously identified security issues using libraries like Watir/WatiN/Watij/Capybara/etc

QA Team:

• Test security controls that can be broken down into positive, concrete tests with a clear start and end (may require step by step directions and training) -- possible focus mainly on controls that ALL application should have in place
• Construct (or have developers construct) and run unit/functional/automated tests for previously identified security issues using libraries like Watir/WatiN/Watij/Capybara/etc (listed for both QA and Dev.)
• Perform testing for business logic or domain specific vulnerabilities (a list of these business logic rules should be specified in the application's requirements)

Security Team (possibly a team within QA!?!):

• Manually Perform negative testing and using penetration testing experience to identify issues
• Perform automated static code analysis (for example: Ounce, Fortify, or Veracode)
• Perform manual code review
• Perform automated security scanning (for example: AppScan, Web Inspect, or Burp Suite)

I also want to emphasize that identifying a vulnerability through testing should ALWAYS result in the organization creating a new or correlating to an existing application security requirement (like a functional or business requirement) and an associated secure coding standard (specific code/configuration example and discussion showing how to accomplish the application security requirement in a particular development language, framework, and/or library).  The goal is to proactively avoid vulnerabilities in the future, decreasing costs and improving security for all projects within the organization rather than for one specific application.  Feeding solutions back into the requirements specification phase of software development will help accomplish this.