Home > Articles

Regulatory Requirements and Risk

📄 Contents

  1. Risk Methodologies: NIST, OCTAVE, and AS/NZS
  2. Frameworks: CobiT, COSO, and ISO 17799
  3. Tricky Business
  • Print
  • + Share This
Regulatory requirements are driving companies to look into risk management more than ever before. SOX, HIPAA, and GLBA all require risk analysis and management. But organizations looking for a solution can quickly find themselves swimming in a sea of acronyms. This article by bestselling author and trainer Shon Harris discusses the importance of understanding risk methodologies and frameworks.
From the author of

From the author of

Regulatory requirements are driving companies to look into risk management more than ever before. SOX, HIPAA, and GLBA all require risk analysis and management.

But organizations looking for a solution can quickly find themselves swimming in a sea of acronyms, including NIST 800-30, AS/NZS 4360:2004, OCTAVE, COSO, and CobiT.

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 depends on the level it's applied to. 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 then examine 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." In reality, however, most of these products are not true risk management tools.

Instead, many of these tools are actually vulnerability assessment and vulnerability management tools, which are much different from risk management tools.

The easiest thing to do in security is identify a vulnerability and get rid of it. One of the most difficult things is calculating the risk associated with that vulnerability, which 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 completely different skill set.

Risk Methodologies: NIST, OCTAVE, and AS/NZS

The most commonly used risk methodologies are the National Institute of Standards and Technology (NIST) 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 approach.

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:

  1. System characterization
  2. Threat identification
  3. Vulnerability identification
  4. Control analysis
  5. Likelihood determination
  6. Impact analysis
  7. Risk determination
  8. Control recommendations
  9. Results documentation

This methodology focuses mainly on systems and is commonly used by security consultants, security officers, and internal IT departments. 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 it 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 so they 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. 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 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 if 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 by 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.

  • + Share This
  • 🔖 Save To Your Account