How to define the scope of functional security testing

In 2007 Forrester released research that states that as much as 85% of security breaches involve internal threats. From an application security point of view, these internal threat agents are authenticated application users, technologies used to develop the application and even open source code integrated into applications. Have you ever asked whether the source code you find on the Web will add security issues to your application? I doubt it. Most are satisfied if the code works functionally.

With all of those variables coming into play, functional security testing is essential. But before you dive in, you must consider these things:

• As a CTO/CIO, you need to determine the scope of functional security testing on your applications
• As a project manager, you need to decide what resources to allocate
• As a functional security analyst, you need to determine the priorities for your security assessment

Let me offer advice for doing those things by first saying that this process should be a collective effort between business analysts, developers and security analysts, and it should have proper management support. Further, this article focuses on providing a direction to defining the scope and does not venture into the technical details.

Security facet prioritization
Assign severity levels for Availability, Integrity and Confidentiality to the information assets managed by the applications. The person responsible for this should do the following:

1. Account for all the data, technologies (this includes any third-party toolkits/APIs) and user types defined in the application
2. Define a role matrix if not already developed for the data access
3. Identify the right information and technology owners

The next step should be to organize a comfortable platform for the information owners to qualitatively or quantitatively define and assign priorities to the identified information and technologies.

Employ the appropriate functional security tester
Security facet prioritization drives three important activities to be considered in employing appropriate functional security testing resources.

First, you want to baseline the functional security state of the application. Black box testing combined with automated testing tools can be considered during this phase.

Second, you want to define the security testing time for each functional area of the application.

Third, you want to scope out the technical skills required in performing grey box and white box functional security testing.

If you don't consider the above tasks when describing the functional security testing resources, you will end up with a totally different description after six months. Management then realizes that the skill set of the resources does not match the requirements.

SDLC integration
A daunting task for many project managers is to justify incorporating functional security testing into the software development lifecycle (SDLC). An easy way out that I have seen is to add a phase for security testing before going to production.

More information on application security Secure SDLC: Integrating security into your software development life cycle Software testing tools to help integrate application security throughout the SDLC Application security shouldn't involve duct tape, Band-Aids or bubble gum

The repercussions of this reactive approach result in the following:

1. The security tester takes shortcuts in his testing efforts to avoid being the showstopper, which results in signing off on the project without performing all of the test cases

2. Management moves forward into production with a false sense of the application's security state

3. There's less time available to apply fixes to the application for the identified security flaws, leading to short-term measures with inadequate analysis.

A solution to these lies with the functional security analyst helping the project managers gain knowledge from the security facet prioritization and designing a report for management that highlights the benefits of an SDLC-integrated approach. For better results from functional security testing, it should be integrated into the testing phase of the project with bug reporting following the regular reporting process. Impact analysis on each reported security flaw empowers the project manager to prioritize the corrective action plans.

Security testing strategy guidelines
Wide spectrums of applications following broad patterns pose many challenges for functional security testing. Largely due to lack of time, inadequate reporting and/or co-ordination deficiencies, testers find it difficult to complete their tasks. Integration of functional security testing into the testing phase of the SDLC is an important part of the solution. Additionally, spotlighting the following can help ease the process for testers:

• Functional pattern identification: Sometimes tedious, the pattern identification process is a one-time process of identifying the functional pattern of the application's behavior for the input. These patterns could be consistent across the functional areas of the application, but testers should not progress forward with this assumption.

• Test case definition: Role matrix, data flows and the technologies used in the functional area help define the test cases. A good approach is to prioritize the test cases based on the impact by running them by the functional analysts and architects. Mapping of impact analysis to the security facet prioritization can help greatly.

• Parameters definition: Various toolkits are available that point out the parameters and their variations for each test case. Output behavior testing and analysis leads to additional test cases and cross-functional test cases.

• Reporting results: Testing simplification, possible automation in reproducing the security flaws and impact analysis reporting empower management in reviewing and prioritizing remediation strategies.

Application security has been an uphill battle at many organizations, but this year's report on internal threats is a wake up call that cannot be ignored. With a considerable number of the internal threats originating from applications, functional security testing is one of the most reliable ways to identify internal security vulnerabilities.

-----------------------------------------
About the author:Vijay Vedanabhatla GCSC is a senior application security consultant . You may contact him via email at [email protected].