Security Tools Must Support An Existing Process Not Define a New One

Any time we introduce change in an organization, people, regardless of how professional they are on the surface, typically "freak out" at some level. Introducing something as significant as Security Testing where it's never been seriously implemented before may cause some to break out into a cold sweat and develop unseemly rashes. Recently our organization faced this challenge and came up with a method to introduce change in the middle of the organizations comfort zone – automated builds.

After evaluating several great static analysis tools, we found one that fit our budget and our organizations’ unique technical environment. Since this brief article is about implementing a security testing process and not about a specific tool, what we ended up choosing is not relevant. However, one of the required features of the tool is – that of having a command line interface that plugged into our build environments using Maven for our Java builds and Team Foundation Server (TFS) for the .NET builds – is relevant. We developed a simple script that would kick off the scan as soon as the build was deployed. We did NOT want to block or modify the existing build process, just add to the tail end. We did end up having to define a few new roles in each team, a “security lead” that would do the initial security audits, but we found that with 30 minutes of training most test engineers were more than happy to take on this new role.

There were a few things we wanted to seriously avoid: any change to the Developer’s job pattern, and the fire-hose effect of introducing too many security defects against software that was probably pretty dirty. To solve the first problem, we only delivered security issues to Developers in the same manner they received any software defect - through our bug tracking software. That way they only had to work on defect issues as they could get to them, and the bug scrub team already prioritized the issues so they could stay heads down. The second issue was a bit more complicated to solve – the first security scan was going to reveal tens if not hundreds of issues and the fire-hose effect would discourage any from diving in and logging anything meaningful. The solution was to have our own security team define a few filters that could be applied to the report in phases. For example, our first phase only revealed the most critical OWASP issues found. When those defects were fixed, we went to the next phase filter which revealed another subset of manageable defects, and so forth. In this manner, most projects, even with their first scan, only revealed a few defects that could be consumed by the project team without any emotional outbursts.

Briefly, this is what we ended up implementing:

1. Security Team defines initial filter phases.
2. Static analysis script kicked off at the end of the build process, producing the following:
   1. Static analysis tool generates report.
   2. Report is automatically sent to the security server for later analysis.
3. Security Lead (assigned by the Test Lead or Manager) performs the initial Audit and logs defects.
4. Bug Scrub team determines priority and assigns to specific Developer.
5. Developer fixes assigned bugs.
6. Regression is accomplished by Security Lead in subsequent audits on any given milestone (you do NOT want to audit every build).

Obviously, this is a high level view of what we did, but so far it has raised awareness of what software security testing is and the value it can bring to the project. Admittedly, this is only scratching the surface, but this is a cost effective first start. Think of it as a delicious doggy treat soaked in beef broth – a hint of what is to come…