White Box Testing Approach to Security Testing

Internet has progressed from static content proving mechanism to more interactive application for e-business. A huge amount of transactions are happening over internet and thus security as a quality has to be embedded in internet application. According to report by Gartner over 70% of security attacks are targeted on web based application. Securing the network or system cannot check exploits targeted at application level. Different people have different suggestion to include security testing in different SDLC phase. Some are in opinion to start once the functional testing and load testing is done. The main disadvantage of doing this is lesser time to fix the security bug and cost associated with this is huge. I think we should include this right from the requirement phase and should continue till we install, deploy and maintain the software. In this paper I have come up with process how to integrate the security testing from the requirement phase also I tried to explain the key challenges in achieving this objective.

What is Security Testing?

Security testing in terms of web application can be defined as the process of verifying and validating the different vulnerabilities in a system which are exposed because of technical deficiencies in an application.

What is white box Security testing?

In order to understand the white box security we need to understand security testing and white box testing. We have already mentioned about security testing. The next section helps to understand White box testing.

White box testing: A white box testing is an approach to validate and verify the design of the system, the underlying code logic involved, the data flow, the control flow, coding practices and error and exception handling capabilities of a system.

So, white box security testing (WBST) can be defined as an approach to verify the code implementation as per design, to validate the implemented security functionality and to uncover the vulnerabilities that can be exploited.

What are inputs for WBST?

 Below are the inputs for white box security testing (WBST)

• Code
• Security requirements
• Design documents
• Architecture and design risk analysis document

In addition to above, we will also need to know quality requirement for the system in terms of performance and response. So we maintain an optimum level of security with desired performance. This is particularly important in Web services where the performance is greatly affected if security overheads are included. The Risk Analysis document should help identify the Threats/Vulnerabilities in components, Business Impact of these vulnerabilities, probability of occurrence of threat/vulnerabilities and Existing and recommended measure to counter risks.

This document will be basis for developing the test strategy and planning for security.

           

Test Strategy for WBST

As exhaustive testing is not possible and also is not cost effective. Risks identified in Risk Analysis document are ranked and prioritized and effort is made to focus on high risk areas .Test strategy should be designed in such a way that optimum coverage is achieved within stimulated time and budget. Test strategy includes identifying testing scope, testing techniques, coverage metrics, test staff skill requirement and test environment. Test strategy should focus on achieving great level of test effectiveness and efficiency.

How to Design Test for WBST?

There are various test techniques which will help in designing the test case. Some of them are explained below

• Data Flow Analysis: In this the path is analyzed from variable definition to its use. Variable values can be used for computing values for defining other variables or as a predicate variable. When used as a predicate, it can help in traversing a specific execution path .As it is really impossible to traverse all the paths for all variables. We can run for subset of variables from definition to use. The path and use of data can help in identifying the suspicious code block.

• Code Coverage Analysis: This technique is best way to measure the test effectiveness. Test are first created and executed and then the coverage tools are run to analyze which path or statement is not covered. This helps in determining which tests are redundant. Test can be added or removed based on output of coverage tools.

• Trust Boundary Mapping: Defining zone of various trusts in a system helps in identifying the vulnerabilities because of communication between the components of a system and attack path for security violation. This can be combined with data flow to arrive at test cases which checks the chokepoints between these components.

In addition to have test according to specification, we need to have some test executed as an ad hoc / exploratory basis. The subset in which we can have these test includes the Data Mutation, Environment, Component interface, Configuration and Error handling. Also test needs to be designed based on coding standards and input validation. This will avoid various vulnerabilities like Buffer overflow, Cross Site Scripting, Format String Attack, Denial of service, Automatic user generation, SQL Injection, LDAP Injection and others which are occurred because of improper coding standards.

Tools helpful in WBST

Below are some tools categories that are helpful in white box security testing

• Source Code Analysis: These tools helps in identifying the vulnerabilities based on fixed set of pattern and rules. Also some tools provide the data-flow and control-flow analysis. The output of these tools can help in test case development.

• Coverage Analysis: These tools help in how much of code is covered with the test we executed. This helps in increasing the test effectiveness.

There are other categories of tools which can be of use like profiling tool, Program understanding tools etc.

Key Challenges: Having said about the benefit of white box security testing, there are some key challenges in order to achieve that:

• The skills required for white box is more technical and requires good logic to find which unit/statement or chunk of code is malfunctioning. Skilled tester increases the cost.
• Access to source code is not always available to tester.
• Impossible to look into every bit of code.