Risk Analysis

Security is always relative to the information and services being protected, the skills and resources of adversaries, and the costs of potential assurance remedies; security is an exercise in risk management. The object of risk analysis is to determine specific vulnerabilities and threats that exist for the software and assess their impact. White box testing should use a risk-based approach, grounded in both the system’s implementation and the attacker’s mindset.
White box testing should be based on architecture and design-level risk analysis. This content area will discuss how to use the results of risk analysis for white box testing, while the Architectural Risk Analysis content area discusses risk analysis in detail.

Risk analysis should be the guiding force behind all white box testing related activities. The following paragraphs briefly introduce how the risk analysis results are used in white box testing. The subsequent sections discuss the activities in detail.

The risk analysis report, in combination with a functional decomposition of the application into major components, processes, data stores, and data communication flows, mapped against the environments across which the software will be deployed, allows for a desktop review of threats and potential vulnerabilities. The risk analysis report should help identify

1. the threats present in each tier (or components)
2. the kind of vulnerabilities that might exist in each component
3. the business impact (consequence and cost of failure of software) of risks
4. the probability (likelihood) of the risks being realized
5. existing and recommended countermeasures to mitigate identified risks

Use the above information from the risk analysis report to

1. Develop a test strategy: Exhaustive testing is seldom cost-effective and often not possible in finite time. Planned testing is therefore selective, and this selection should be based on risks to the system. The priority (or ranking) of risks from the risk analysis should be the guiding rule for the focus of testing, simply because highly vulnerable areas should be tested thoroughly. The test strategy captures all the decisions, priorities, activities, and focus of testing based on the consequence of failure of software.
2. Develop test cases: While a test strategy targets the overall test activities based on risks to the system, a test case can target specific concerns or risks based on the threats, vulnerabilities, and assumptions uncovered during the analysis. For example, tests can be developed to validate controls (or safeguards) put in place to mitigate a certain risk.
3. Determine test coverage: The higher the consequence of failure of certain areas (or components), the higher the test coverage should be in those areas. Risk-based testing allows for justifying the rigor of testing in a particular area. For example, a specific component or functionality may have high exposure to untrusted inputs, hence warranting extra testing attention.