Divided information security and QA teams face three major problems, and ignoring the impact of these problems can lead to disaster. In this week's column, Ryan English discusses the problems and offers three easy steps any organization can take to merge key teams and processes. Improve your QA with this method and avoid finding yourself on the increasingly long list of companies that paid the price when they ignored easily preventable security defects.
Many organizations are coming to the realization that security vulnerabilities should be treated just like any other software defect, so they're putting tools and processes in place to treat security problems with the same importance as software quality problems. Yet to get the biggest benefit from your software security efforts, you should go even further and fully integrate your Information Security (IS) team and the management of security defects into your current defect management process.
QA professionals have spent years developing and refining defect management systems that track and communicate the functional and performance issues discovered during the quality assurance processes. These defect management systems have amazing capabilities, but we often think of them as just QA tools. We think less about how we can extend the use to other groups outside development and QA.
One group that is a perfect extension point is your IS team. Not only is IS concerned about network security, but it most likely has a huge focus on application security vulnerabilities. According to Gartner, over 75 percent of security vulnerabilities occur at the application layer. These application-level vulnerabilities are usually the result of poor coding techniques that occurred during development. The only way to fix these vulnerabilities once they are identified is to have a developer modify the source code. In other words, these security defects need to be treated just like functional or performance defects.
Several major problems exist within most corporations when it comes to addressing application security defects:
- Problem one: Security defects typically are not identified by the IS team until the application is in production.
- Problem two: Once the IS team members find these security defects, they usually run over to the development manager's desk, throw down the security report, and say they want the defects fixed immediately.
- Problem three: This process completely bypasses QA, which in essence hides the fact that a security defect ever existed in the application.
If all of these teams used the same defect management system and processes, then they would have a consistent and overall understanding of the security of the application.
All three of these problems can be addressed easily by integrating your IS team and the management of security defects into your current defect management system using the following plan:
- Have the IS team start submitting security defects into the defect management system currently in use. The process IS follows should be the same one QA follows when it identifies and logs security defects. Once the IS team has identified the security defect in a production or the pre-production environment, IS should submit and assign the defect to the development manager or appropriate defect triage person so that the defect can be assigned to a developer for remediation. The QA team then should work with the security team to ensure that the defect can be closed.
- As a QA professional you should start working with your IS team to get the proper tools and training the IS team uses, so that you can begin testing applications that are in QA as early as possible. The only way to remediate a security defect is by having a developer fix the code. All security defects should be tracked and managed to closure in your defect management system.
- Train your developers how to code securely. Developers are often victims of random security reports being thrown over the wall by the IS team and are told to fix everything immediately. The problem is that usually the communication from IS is nothing more than a report. Developers are not trying to be malicious when they develop insecure code; they just might never have been trained how to code securely. You have two ways to properly train your developers. The first option is to hire a developer security training firm to train your developers. The second option is to persuade your IS team to come in and do the developer training. Either option will work, so it just comes down to determining which option is more appropriate for your organization.
The steps mentioned above are very broad. But getting your new, expanded team to communicate and use the same defect management system is the first step. The impact of not having a single defect management system to manage security defects alongside functional and performance defects can be extremely large.
No statistics are available for how many company Web sites have been hacked because a vulnerability was identified but never properly tracked and resolved. Yet there's a long list of company Web sites have been hacked for easily preventable security defects. Companies such as Netscape, MySpace, Google, PayPal, Eli Lilly, Victoria's Secret, and Go Daddy are just a few that have been publicly exposed with security vulnerabilities. Don't let your software or Web site be the next on this list.
