When converting the risk assessment into a risk mitigation plan, the risk elements may need to be verified because the risk assessment is a point-in-time assessment and the threats and vulnerabilities may have changed. Additionally, the approved countermeasure needs to be verified to ensure it can still mitigate the current risk.

The same steps used in the risk assessment can be used to verify the risk elements. For example, the risk assessment may have used a vulnerability scanner that discovered an SQL injection vulnerability, and a penetration test could have been used to verify that the vulnerability could be exploited.

Then, three months pass before the risk assessment is approved. The same vulnerability scan could then be performed to see whether the vulnerability remained. If the vulnerability still exists, the penetration test could be rerun. If the vulnerability can be exploited, then the risk remains.

However, in this example, application and database developers may have taken immediate steps to resolve the problem. Many simple programming techniques can mitigate this risk. A common reason application developers omit them is because the developers are unaware of the risks. Based on this scenario, reevaluating the risk and the solution would be worthwhile. The application developers can be interviewed to determine what they did to resolve the vulnerability, and then the solution can be evaluated to determine its effectiveness.

The IT administrator may even decide to recommend this solution as a countermeasure. He or she would write a policy to ensure that all code that is vulnerable to SQL injection attackers use this countermeasure and that all applications be tested for SQL injection vulnerability before being released.

Perhaps the original solution was to purchase a product. However, if the risk is no longer present, money shouldn’t be spent on the countermeasure.