Jan 21, 2013

Security testing and QA

Generally, those companies who are conscious about their applications’ security have introduced several practices to design, develop and roll out their software. Within these practices we could found the now well-known dynamic security tests, code analysis to find vulnerabilities (both automated and manuals) and penetration tests.

Even, the most mature ones in this sense begin to integrate security into their SDLC (Software Development Life Cycle), taking into account several security requirements in different phases of the cycle, although there are not so much in which the integration is total. The current level of integration in most cases does not include the security in the QA processes of the company.

I wonder why they are keeping out security of the rest of QA processes. Is insecure software, perhaps high-quality software? Of course it isn't, and the user’s perception of insecure software is that the product is poor quality product.

Historically, QA responsibles didn’t focus too much into applications security, being focused mainly into functional requirements, scalability and performance. Most of the time, security tests are holded over until the product is rolled out, instead integrate them into the SDLC. Even in some cases people think that security must be managed after production deployment.

The Security integration into QA processes, in my opinion, is justified considering the SDLC cost-justification curve that it shows the bug fix cost in each of the SDLC phases.

It’s obvious that it becomes more profitable to find any kind of bug in the earlier phases of the cycle, than at the end, when the software it has been deployed in the production environment; and this includes, of course the security vulnerabilities kind of ‘bugs’.

Besides that, the fact of implementing Security requirements into the earlier phases is a key point to reduce the number of vulnerabilities that will appear later. As an example you can think in the architectural design of a product, taking into account the security requirements from the beginning.

Integrating Security tests in QA processes could be a hard task. In fact, a common excuse of the QA teams when they must assume these responsibilities is that the task requires high technical knowledge and a very specific security background.

Any testing would be hard unless there is a pre-defined process and methodologies are available and practiced. In order to be successful it’s critical to first understand the existing processes, tools and methodologies the QA teams use today and then adapt security testing protocols, tools and methods to fit within those existing processes and be minimally invasive or disruptive.

Security testing executed by a specific team of Security experts will remain, but everything that you can integrate in QA processes is time earned in the whole cycle.

One of the approaches, then, to integrate both functions could be to split security testing into separate tasks:
-Things we can define/test – (automated and executed by QA teams).
-Things we need experts for.

Security is everyone’s responsibility as it has severe impact on the business if not taken seriously. So the responsibility must be shared by all the teams involved in the software creation.

Some interesting references regarding this topic:


Post a Comment