In my work I give customers advice about software security testing. In most of these organizations the testing of security isn’t done. In 2009 something that may not happen, but if it did so, we have to deal with this.

Software testing engineers can force a change in projects for the sake of software security. If they address the software security by finding bugs related to security, the team  becomes more aware of this part of the quality. These engineers can create test cases focused at the misuse/abuse with the design technique Abuse case. In this post I`ll explain the benefits of this technique.

Most testers are positive minded and they test what the design describes.

The testers that I meet and train in courses or in projects are mostly focused at the positive things. This is partly caused by design techniques that describe a step by step approach for software testing based on the documentation.
The benefits of these tester is, they work very structured an can therefore give an insight in the quality of the application.

Testers are familiar with reading the positive formulated designs and requirements.

You cannot blame these testers because they have learned it. Besides that most of the designs are formulated positive. This is caused by the fact that most of the requirements are positive. Because everything is positive the testers write positive test cases.

Example: If I use for example the Proces Cycle Test to test a sequential series of windows, the PCT describes how to test them in what order. If I see in first screen the URL page.com/pageid=1, in the second pageid=2, pageid=3 in the third etc. Using the PCT this is not more than a fact. If you`re testing security you would try to first go to step 5 with pageid=5, and see what happens. Then screen 3, 1, 4 for example. You`ll be amazed what the application does. It happens sometimes during my test that it was possible to jump from step 1 to step 5, and everything was processed correctly.

Security tests are focused at parts of the application that aren’t in the documentation, or extra in the application.

Where a test is focused at the things that are in the documentation, in a security test you try to find extra features. There are lot of extra pages (check the comments in the source), extra functionality is in the application. This is caused by the extras of a framework of library.

An Abuse cases can describe the possible misuse of an application

I think most of the testers are familiar with use cases. I found this definition for “use case”:

We define a use case as a specification of a type of complete interaction between a system and one or more actors¹.

An abuse case is a use case with some extra information. This extra delivers the information of the possible misuse. There for an extra actor is needed. This actor is the hacker with the goal to steal information.

Abuse cases can create the mindset that is needed to define the right requirements and test cases!

The more negative abuse cases give insight in the possible misuse. This can create another mindset that is needed for security testing. A lot of security defects are caused by flaws in the application (some people say 50%). Train to detect the flaws in the application. Click here for a good example and try to find these things in your test object.

Possible misuse in an abuse case

Defining abuses cases takes place before the requirement phase.

Defining the abuse cases is maybe not the task of the test crowd. But if they are not in place follow the techniques to define use cases with the negative point of view to get the right insight. In the best situation, defining abuse cases takes place before the requirements phase in the Secure Development Life Cycle (SDLC).

A possible goal of abuse cases is to decide and document a priori how software should react illegitimate use².