The challenge of evaluating IT security initiatives
Business stakeholders are constantly evaluating security initiatives. These initiatives span the gamut from minor control changes to capital expense projects. For Fortune 500 organizations, that list of initiatives can number into the hundreds. Managing that book of work is no simple task; initiatives have to be prioritized based on perceived need, budget, changes in compliance landscapes, changes in the threat landscape, etc.
To compound matters, new initiatives are regularly tossed onto the pile in the form of findings , which usually result from security tests or audits. Just like control changes or capital expense projects, findings have to be evaluated and prioritized within the larger book of work. So how do we evaluate audit findings among the other items that compose the larger book of work and vie for our time?
Using FAIR to conduct cost-benefit analyses
First, we can measure the common risk factors that are inherent to any security initiative. Since each initiative has an effect on either the frequency or the magnitude of loss events, we can evaluate them all in FAIR terms using RiskLens' Cyber Risk Quantification (CRQ). Second, the risk related to the various initiatives can be compared against each other to prioritize efforts. This is true regardless of the type of loss event: outage, breach, or integrity event.
Anytime a 'finding' comes up, an organization can - and should - review and compare the current-state risk against the resulting risk if resolution recommendations are put in place. Once a risk reduction is quantified for a particular initiative, it can be compared and prioritized against other initiatives in the book of work. These comparative risk analyses are the underpinning of cost/benefit analyses and of cost-effective risk management programs.
A case study
During a routine audit, a Fortune 200 manufacturing company was faced with repeat findings claiming that the patching process for the Enterprise Resource Planning (ERP) platform was not meeting policy expectations. As is usual in these cases, when the actual patching of systems occurs in a time frame that is much longer than the security policy states, this risk scenario was categorized as high.
The remediation recommendations provided by the audit stipulated the organization should execute upgrades ahead of schedule and optimize patch management efforts to ensure compliance with patch management policies. The IT team argued that the level of effort and cost associated with those recommendations would exceed the benefits in terms of risk reduction. A stalemate ensued as both parties felt they were right, but had no factual arguments to prove their case.
This stalemate was resolved by conducting a quantifiable before/after risk analysis to evaluate by how much the application upgrade and the shorter patch window could reduce risk compared to the associated cost. Armed with the risk reduction and cost data, management was able to make an informed decision on the best course of action to take.