The Agile process is quick, flexible and continuous for both development and testing. Proven effective for software...
development, Agile works well in most situations. But how deep can it go? Is the Agile process the right approach for integrated, complex applications that require and rely on layers of security? Can a test team incorporate security testing into Agile iterations?
If you're like many organizations, your QA test team has gotten by without doing basic security testing. But it's time to change.
Granted, a test team won't be able to conduct all of the necessary security testing within an iteration, let alone within a release. But it's critical to establish security tests and execute them frequently.
In this article I'll explore what test team managers need to do to add security testing to their the Agile process, and explain how to effectively execute security testing within iterations.
How deep can you go?
Doing some security testing is better than doing nothing at all. It's not possible to execute full security testing with a single test team; you can devise effective security test suites that your test team can execute.
Once you create a test suite and execute it on a regular basis it becomes easier to fit security testing into iteration timelines.
The first step is to define what layers to test and at what point. Start with the database, move to network security and finish with application security. Database experts usually have in place their own security safeguards that consist of multiple firewall layers, intrusion detection systems, encryption and virus protection software. Typically, secured databases do not allow direct connections to the network.
However, when a team is developing software, frequent code changes can inadvertently create gaps where malicious commands can be injected. Another thing that could happen during coding is that access rights to the database are mistakenly reset, making the code susceptible to SQL injection attacks. Your test team needs to develop regression test cases that address these database security gaps. You can automate tests and execute them as part of a continuous integration process, or your team can work with the development group and create unit tests that check for database security vulnerabilities.
Many Agile teams use open source automated security vulnerability scanners. Most can be executed in a command line rather than a GUI, making it easier to incorporate a scan into your automated security test execution for the database. Your test team members can parse the results and report any security holes the scanner finds. One open source scanner is called Nessus. (You can find a host of other possibilities by searching on the phrase network security scanners.)
The final layer to test is the application security layer. Even if the test is as simple as setting user security levels and logging in, it's essential to do this. Your test team is armed with the knowledge of how your application functions. Using this knowledge, your team has what it referred to as the "attack surface." In other words, your testers have the background information required to search for security vulnerabilities. Be creative. Plan a day to hack away at the application. After you've done a round or two, prepare a test suite that can be executed manually as part of your regression. Do it often, unless your application doesn't change much, and make this process as standard as any other testing you do.
Security impact to other test coverage
If you're adding more security tests, what are you going to leave behind? As an Agile team you'll need to prioritize testing efforts. Take your functional, security, performance, system and smoke testing suites and rank them by priority. Where is your application at greatest risk? Where is your company most vulnerable? There are no easy answers to these questions. Perhaps you can incorporate your security testing by reducing the amount of the functional and performance testing you execute? Perhaps you can replace smoke testing with security testing? Incorporating security testing into your regression execution cycle is vital because security defects pose a significant risk for the company as a whole.
It's essential security tests are executed as frequently as possible. Will your test team be able to execute security testing within an iteration? Probably not at the beginning. However, if you can leverage automated tests, automated tools and manual testing on a regular basis, then you can likely incorporate portions of it into each iteration, or every other iteration. It boils down to doing the best you can as frequently as possible. However you do it, for an Agile team the creation of standard, repeatable tests for security defects is critical. Once you create a test suite and execute it on a regular basis it becomes easier to fit security testing into iteration timelines.
For Agile teams, the key to testing security is integrating secure development practices into existing workflows and making security testing an integral part of the QA testing plan. Granted, your test team can't be responsible for all security testing because security requires a unique skill base that takes more time and expertise than your team is likely to have. However, executing a suite of security tests is essential part of your Agile process.