Perimeter
9/4/2011
09:19 AM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%

The Criticality Of Risk Assessments: FISMA, HIPAA, And Other Regs

Risk assessments are a critical part of regulatory compliance, but many organizations don't implement them well

One of the most important components in any security program is the risk assessment process. Regulations like FISMA, HIPAA, Red Flag Rules, and state privacy regulations require organizations to methodically assess risk and select security controls based on that assessment. The problem is that many organizations do not understand what it means to assess risk through a formal method. Worse yet, many IT people have a hard time understanding the practicality of formal assessments.

What is a formal risk assessment?

Formal risk assessments are processes that consider the value of the assets that are at risk, the business and technical threats to the assets, and the effectiveness of the business and technical controls that are designed to protect the asset. In the end, a risk assessment gives the organization an objective measure of the risk to an asset. The process forces the organization to acknowledge and accept the risk, eliminate the risk by terminating a business practice (e.g., stop offering access to the asset via the Web), transfer the risk by outsourcing or insurance, or, more often than not, select additional more effective business or technical controls to reduce the risk.

Benefits Of Formal Risk Assessments
Conducting formal assessments within a risk management program offers a number of benefits:

    1. requires business and technical representatives to reason about risk in an objective, repeatable, way 2. requires consistent terminology and metrics to discuss and measure risk 3. justifies funding for needed controls 4. identifies controls that can be eliminated 5. provides documentation of threats that were considered and risks that were identified 6. requires business and IT to acknowledge the responsibility for ownership of risk 7. requires organizations to track risks and reassess them over time and as conditions change

There is a good reason for so many regulations to include a requirement for risk assessment. It is only sensible that a regulatory body cannot dictate the controls that are necessary in every environment. What might be appropriate for a large company with a significant Web presence could be overkill for small organization with a few customers. If the threats are different and the environment is different, then it stands to reason that the controls might be different.

It is interesting to note that even the most prescriptive standards (e.g., PCI DSS) require risk assessments to determine the need for and effectiveness of controls. On the less prescriptive side of the regulatory spectrum, HIPAA and FISMA have very few required controls but expect the entire program to be risk-based. This approach makes sense when one standard needs to apply to everyone.

Choosing A Risk Management Framework
If your organization needs to comply with FISMA, then your risk management approach should be based on NIST Special Publication 800-39. This document provides an overall description of the risk management life cycle. Risk assessment, which is one part of the risk management program, is described in NIST Special Publication 800-30 (which is being revised). SP 800-30 provides a stepwise method for assessing risk that can be customized for a given organization.

Another good source of risk management documentation is provided by the OCTAVE project developed at Carnegie Mellon University. Both NIST and OCTAVE provide excellent sources for building a risk management program that helps organizations meet their security and regulatory requirements.

Richard Mackey is vice president of consulting at SystemExperts Corp.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0972
Published: 2014-08-01
The kgsl graphics driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, does not properly prevent write access to IOMMU context registers, which allows local users to select a custom page table, and consequently write ...

CVE-2014-2627
Published: 2014-08-01
Unspecified vulnerability in HP NonStop NetBatch G06.14 through G06.32.01, H06 through H06.28, and J06 through J06.17.01 allows remote authenticated users to gain privileges for NetBatch job execution via unknown vectors.

CVE-2014-3009
Published: 2014-08-01
The GDS component in IBM InfoSphere Master Data Management - Collaborative Edition 10.0 through 11.0 and InfoSphere Master Data Management Server for Product Information Management 9.0 and 9.1 does not properly handle FRAME elements, which makes it easier for remote authenticated users to conduct ph...

CVE-2014-3302
Published: 2014-08-01
user.php in Cisco WebEx Meetings Server 1.5(.1.131) and earlier does not properly implement the token timer for authenticated encryption, which allows remote attackers to obtain sensitive information via a crafted URL, aka Bug ID CSCuj81708.

CVE-2014-3534
Published: 2014-08-01
arch/s390/kernel/ptrace.c in the Linux kernel before 3.15.8 on the s390 platform does not properly restrict address-space control operations in PTRACE_POKEUSR_AREA requests, which allows local users to obtain read and write access to kernel memory locations, and consequently gain privileges, via a c...

Best of the Web
Dark Reading Radio