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