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
the threats present in each tier (or components)
the kind of vulnerabilities that might exist in each component
the business impact (consequence and cost of failure of software) of
risks<
the probability (likelihood) of the risks being realized
existing and recommended countermeasures to mitigate identified risks
Use the above information from the risk analysis report to
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. The following section discusses test strategy in
detail. For detailed research on risk-based test planning.
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.
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.
