Discover PerformanceHP Software's community for IT leaders // March 2012
Separating security risk from security fear
Everything feels urgent where enterprise security is involved. HP security expert Rafal Los discusses a technique to bring logic to the highly charged issue of protecting your IT systems.
Owning the responsibility for making key security-related decisions in today’s agile business can be a thankless job. Balancing the good of the business against the perils of additional risks can create a charged environment, with decisions made on gut instinct rather than objective analysis. Information security tends to be an emotion-driven discipline, in which mistakes of the past are often repeated. Because hacking and data breaches can wreak havoc, and the threats to our enterprises are constantly growing, we tend to let emotions lead.
Our lead article this issue advises us to keep cooler heads. But when we see red marks on dashboards and reports, the emotional response is to do whatever is necessary to get rid of those red marks—now. Only after careful, objective analysis can we determine that sometimes a defect seen as critical by Information Security is neither business-critical nor in need of immediate resources and remediation. Take the typical CIO’s response a number of years ago when the first backup tape was lost … how many hours of productivity and millions of dollars were lost due to the “drop everything else” emotional response?
It’s difficult to divorce yourself from the highly charged conversations in the media and in your social networks and peer circles. When the corporate livelihood hangs in the balance, information security professionals and leaders need an analytical tool to ensure that their decisions are sound and practical. Fortunately, I’ve got one that’s been battle-tested and is ready for use.
Staring down failure
During my 15 years in the information security discipline and corporate IT, I’ve often used FMEA (Failure Mode and Effects Analysis) to assess the security risks of various efforts. An underutilized yet powerful tool in any executive’s toolbox, the FMEA can be a simple spreadsheet that doesn’t take long to master but pays dividends quickly.
The FMEA’s output identifies the biggest actual risks (failures) and thus helps to determine the most appropriate course of action regarding a product, project or operational task. Forcing the decision maker to weigh all possible failure scenarios leaves little room for emotion or subjective thinking—exactly how we want it when making mission-critical security decisions.
An FMEA-based analysis of a patch requirement will objectively determine, say, whether the risk of an unpatched system potentially open to hackers is greater than a patched system open to self-imposed failure modes; either way the decision is made with a cool head and objective analytics.
Doing the math
The FMEA analyzes potential failure by factoring three key components: likelihood of occurrence, potential severity, and ease of detecting that the failure/breach has occurred. The result is a risk priority number (RPN). There is no magic formula in an FMEA—Occurrence times Severity times Detection equals the RPN, an objective, emotionally divorced way to understand the risk priorities for a particular undertaking. The key, of course, is the numbers used, so that’s where the hard work comes in.
Enterprises must create an acceptable guideline for determining the severity, occurrence and detection numbers via collaboration between risk management and information security. Once that’s done, each project can simply be run through an assessment that calculates the risk of various options, and lets security leaders set priorities accordingly. (You might assign a value of 10 to high likelihood or severity, and 1 to low chance/impact.)
Let’s use patching as an example and run a quick, basic and incomplete FMEA on the impulse to implement a security patch immediately rather than follow the standard patching cycle. Is it overreaction or prudence to patch immediately? Here, assume we’re talking about a public-facing web application server performing company-critical e-commerce activities that needs a security patch:
If the numbers were to be trusted, particularly in the likelihood of detection column, then the wise choice would be to patch the system—but barely. In this example, the deciding factors were the difficulty of detecting stolen data and the sheer severity of the fallout of stolen customer data. An analysis of a less critical vulnerability might find that the risks of downtime outweigh the risks of sticking to the update schedule.
The occurrence input can be particularly tricky. It weighs how often this type of failure happens in other similar products or processes—internally or otherwise. This input needs to be tailored to your enterprise. When undertaking completely new products or processes, failure occurrences are unknown, so we can safely use similar occurrences across similar industries, platforms, etc.
The standard is to adapt the values and language below to your specific need:
10-9: very high (virtually inevitable)
8-7: high (failure likely, many known cases)
6-4: moderate (somewhat likely, some known cases)
3-2: low (few known cases)
1: unlikely (no known cases)
The logical choice
The FMEA is a fantastic and underrated tool for making critical analytical decisions when it relates to security and risk. As the needs of businesses become more complex, IT security must have the right tools to help the enterprise be more agile and responsive and to perform better overall—the FMEA is a tremendously valuable asset for that purpose.
Chief Security Evangelist Rafal Los is one of HP’s most prolific security experts. Join him in his SecBiz LinkedIn group, follow him @Wh1t3Rabbit, and read his blog, Following the White Rabbit.
HP Software’s Paul Muller hosts a weekly video digging into the hottest IT issues. Check out the latest episodes.
Introduction to Enterprise 20/20
What will a successful enterprise look like in the future?
Challenges and opportunities for the CIO of the future.
What the workforce of 2020 can expect from IT, and what IT can expect from the workforce.
Data Center 20/20
The innovation and revenue engine of the enterprise.
Dev Center 20/20
How will we organize development centers for the apps that will power our enterprises?
Welcome to a new reality of split-second decisions and marketing by the numbers.
IT Operations 20/20
How can you achieve the data center of the future?
Preparing today for tomorrow’s threats.
Looking toward the era when everyone — and everything — is connected.