By Shon Harris
Sorting through the array can be confusing. While some are truly risk management methodologies, others are frameworks that can help with compliance, but provide only high-level risk management goals.
Adding to the confusion is that risk management has different connotations in different industries and on what level it's applied. At the operational level, risk management deals with technology; at the strategic level, it has more to do with business drivers and decisions.
We'll make sense of the soupy mix by taking a closer look at the various methodologies and frameworks, and examining what each has to offer.
Since companies are paying more attention to risk management these days, more vendors are jumping into this space. Unfortunately, almost every vendor with a product pontificates on how it carries out "risk management," but in reality most of these products are not true risk management tools.
Rather, many of them are actually vulnerability assessment and vulnerability management tools, which are much different than risk management tools. The easiest things to do in security are identifying a vulnerability and getting rid of it. One of the most difficult things is calculating the risk associated with that vulnerability -- that requires estimating the probability of the vulnerability being exploited, the frequency of this occurrence and the associated business impact. Just finding an open port is one thing, but understanding how it will or will not affect the company is a whole other skill set.
RiskWatch has a suite of analysis tools that follow the NIST 800-30 methodology. While most risk assessments are carried out in a qualitative manner, RiskWatch provides quantitative analysis, which is more useful to management when they need to understand how security affects the bottom line.
This suite provides questionnaires and reports, and illustrates a company's level of compliancy to a range of standards and regulations.
One of the most powerful assets of the RiskWatch suite is that it pulls data from trends and incidents in the industry and its customer base to give the quantitative values true meaning. A quantitative risk analysis is dangerous and misleading if the formula variables are populated with guesswork and unsubstantiated values.
Since SOX and other regulations require that organizations be more responsible for understanding the risks that third parties introduce, there are products that help -- mostly for financial organizations -- with this task.
Accuvant's AccuCERTT provides extensive questionnaires and tracking mechanisms to identify risks outside of your company. This tool is also built on the NIST risk methodology. Risk Management Technologies (RMT) has a very robust ERM tool, First Priority Enterprise, for larger organizations that are more sophisticated in their risk management processes. This tool is based solely on AS/NZS 4360:2004.
These tools incorporate and automate the risk methodologies, but just purchasing and using a tool does not relieve you of the task of actually understanding the necessary steps and liability issues of risk management. A tool can only automate and control manual steps of the risk management process.
Risk methodologies: NIST, OCTAVE & AS/NZS
The most commonly used risk methodologies are the National Institute of Standards and Technology's (NIST's) approach, as outlined in its 800-30 document; the Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE) approach; and the Australian/New Zealand Standard (AS/NZS) 4360:2004.
It's important to understand the difference between risk and a vulnerability: A vulnerability does not represent risk; risk determines the business impact of someone exploiting the vulnerability. Businesses also have different types of risks, including information and computer security, business decisions and finances.
The NIST approach is specific to IT threats and how they relate to information security risks. It lays out the following steps:
- System characterization
- Threat identification
- Vulnerability identification
- Control analysis
- Likelihood determination
- Impact analysis
- Risk determination
- Control recommendations
- Results documentation
This methodology is commonly used by security consultants, security officers and internal IT departments, and focuses mainly on systems. An individual or small team collects data from network and security practice assessments, and from people within the organization. This data is used as input values to the risk analysis steps outlined in the 800-30 document.
OCTAVE also focuses on IT threats and information security risks, but looks beyond the system level to people and processes. It uses a self-directed workshop method in which a team made up of management, operational personnel, security and business heads walk through several scenarios, questionnaires and checklists. The scenarios cover a range of potential security incidents, from someone gaining unauthorized access to sensitive data to how a lack of redundant controls affects availability.
The goal is to train these employees on risk analysis steps and have them use these steps as a group to identify and control the company's risks. Team members are chosen because they are closest to the processes, technology and issues that result in company risk.
While both the NIST and OCTAVE methodologies focus on IT threats and information security risks, AS/NZS 4360:2004 takes a much broader approach to risk management. This methodology can be used to understand a company's financial, capital, human safety and business decisions risks. Although it can be used to analyze security risks, it was not created specifically for this purpose.
If your company is not sophisticated in risk management and needs to comply with SOX, HIPAA or GLBA, it's best to start with the NIST risk analysis approach. You will likely have a small internal group -- made up of security and IT staff -- overseeing the compliancy steps, and this methodology is based on security and IT.
After this group understands the ins and outs of the NIST methodology, your company can look at implementing OCTAVE, which is the more time-consuming approach; it trains others outside of the security group in risk management.
A company cannot understand its business and technology risks unless both security and business managers are engaged and involved. Workshops provide a way for managers to understand other risks outside of their areas. OCTAVE also is a great tool to increase the awareness of security initiatives and helps the security team members to get more people on their side.
Once a company evolves in its understanding and practices of risk management at a basic level and can map business objectives to security and technology requirements, it can then start incorporating other business risks and start building an enterprise risk management (ERM) system. At this stage, the company can advance to AS/NZS 4360:2004.
Although it seems as though a company has to learn three different methodologies, they have about a 70 percent overlap. Each lays out a roadmap for identifying and controlling risks. A company can start off with applying a focused risk management process (NIST), expand into the business units with a broader method (OCTAVE), and then grow into a holistic approach to risk (AS/NZS 4360:2004). The real key is to get going and keep the ball rolling.
Frameworks: CobiT, COSO, & ISO 17799
Frameworks such as the Control Objectives for Infor-mation and related Technology (CobiT) and the Committee of Sponsoring Organizations of the Treadway Commission (COSO) framework aid regulatory compliance, but don't provide actual risk management methodologies. Rather, they include some high-level goals for risk management as part of their overall scope. While CobiT helps a company define risk goals at an operational level, COSO helps a company define organizational risks at a business level.
Developed by the Information Systems Audit and Control Association and the IT Governance Institute, CobiT is a framework that defines goals for the controls used to properly manage IT and ensure that IT maps to business needs. It's broken down into four domains: Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate. Each category drills down into subcategories. For example, the Acquire and Implement section includes information on acquiring and maintaining application software and managing changes.
Although CobiT is not a risk methodology, it does spell out the goals an organization should aim to accomplish in its risk management processes. These goals are outlined in these subcategories: Business risk assessment; risk assessment approach; risk identification; risk measurement; risk action plan; risk acceptance; safeguard selection; and risk assessment commitment.
While CobiT is a model for IT governance, COSO is a model for corporate governance. CobiT was derived from the COSO framework, which was developed by the Committee of Sponsoring Organizations of the Treadway Commission in 1985 to deal with fraudulent financial activities and reporting. COSO has these components:
- Control environment -- Management's philosophy and operating style; the company culture as it pertains to ethics and fraud
- Risk asssessment -- Establishment of risk objectives; the ability to manage internal and external change
- Control activities -- Policies, procedures and practices put in place to mitigate risk
- Information and communication -- A structure that ensures that the right people get the right information at the right time
- Monitoring -- Detecting and responding to control deficiencies
COSO focuses on the strategic level while CobiT focuses more on the operational level. You can think of CobiT as a way to meet many of the COSO objectives, but only from the IT perspective.
Like CobiT and COSO, ISO 17799 includes some high-level risk management guidance, but doesn't provide an actual risk methodology.
Updated last year, ISO 17799 provides guidelines on how to set up a security program from A to Z. Where COSO and CobiT call out requirements for various security structures and countermeasures, ISO 17799 provides the details on how to develop and implement these components.
The newest version of this framework includes the following categories: security policy; asset management; physical and environmental security; communications and operations management; access control; and information security incident management.
These categories are controls that need to be put into place to reduce risk. For a company to know the right type and level of access control, incident management and physical security, it must first understand its current risk level and its acceptable risk level. Risk management is a foundational piece of each component of ISO 17799 but the framework does not specify what methodology an organization should use to accomplish it.
No matter how a company goes about it, risk management is ultimately a complicated undertaking. For business people, risk management deals with business decisions, such as launching a product line or purchasing another company. For security professionals, it's more about operations, including fighting hackers and internal fraud. Each group has different vulnerabilities and threats to worry about.
In slowly recognizing the need for each group to understand how the other's set of vulnerabilities directly affects its own risk levels, the industry is having growing pains. Business and technology are complex in their own right; truly understanding their overlapping components and assessing risk at a more holistic level is the difficult hurdle we face.
But the array of methodologies and frameworks that deal with risk can help, depending on your organization's needs. Once you've sorted through the alphabet soup of risk assessment methodologies, you can choose the most appropriate one for your business.
It's important to at least start the process of managing risks. In an era of increasing security threats and regulatory requirements, it's something that no company can afford to ignore.
This was first published in June 2006