Risk Management and the CISO, or, What Do We Call Ourselves?

  • While I’m patiently waiting for Steve Lamb to post more information on his views of information security vs. information risk management, I’ll post mine.

    The issue came up when Steve posted, “What advice would you give to Chief Information Officers to improve the effectiveness of Information Security?” A reader named Ron answered: “If it’s all about risk, then why do we call it “Information Security?” Shouldn’t it be Information Risk Management?”

    Well, I for one believe that it should be called IRM. My recommendation for CISO’s was, “Unless you embrace risk as your ultimate metric — unless you understand risk and its impact — you’ll continue to chase every new control, every new fad, and be a slave to FUD.” This statement is something I believe.

    For example, a great deal has been said about NAC and effectiveness. These arguments all discuss NAC’s usefulness based on technical merits. Thing is, the answers aren’t as black and white as these folks would like to believe: value and probability (the prime factors of risk ) are specific to an individual organization. Unfortunately, neither side has really embraced the issue of value; and, furthermore, both are guilty to a lesser extent of not discussing probability of loss. Certainly we can speak in generalities — for instance, Control A will be relevant for 60% of organizations in a specific industry. But at the end of the day, too many factors in judging a control’s true effectiveness are dependent on the circumstances surrounding a specific organization. Fortunately, these circumstances can be effectively quantified by risk analysis.

    We know that we can run a FAIR analysis for different organizations and, based on the impact a NAC implementation will have on their risk posture, use our analysis to make recommendations. For example, an organization may not need NAC if it has other parts of its control framework producing a “good enough” Control Strength value. Another organization may simply not see a significant number of Threat Events that NAC would help prevent. For these organizations, rolling out NAC to all their desktops just doesn’t make economic sense based on risk reduction.

    Yet a risk analysis of a another organization might show that it has a number of expected loss events, or a significant amount of value to lose which a NAC implementation could help mitigate. In this case, FAIR can demonstrate how to implement NAC as a cost-effective control by reducing probability and magnitude of loss by a certain factor that would certainly pay for the implementation — and then some.

    This is one reason why a “Risk Management” approach has benefit over a “Security Management” approach for a CISO. If I were a CISO I’d want to be able to make my business case to the data owner (read executives) not because internal audit, a consultant, magazine article, blogger or the vendor’s sales guy said I should spend money; rather I’d want to make a business case by showing value to the business. Without a Risk Management Approach the CISO is left making the case for or against NAC using reasons that may work in the short term for this specific control, but not over the long haul or when security requires a significant investment from executives. Because we can’t easily quantify real ROI or payback periods, the ability to make a real business case using risk values is a significant benefit of Risk Management for a CISO.

    So how can we understand the difference between Risk Management and Security Management? That’s a long, long post for another day.

    Posted on

  • Leave a reply