Perimeter
9/4/2011
09:19 AM
Commentary
Commentary
Commentary
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
Cartoon
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7441
Published: 2015-05-29
The modern style negotiation in Network Block Device (nbd-server) 2.9.22 through 3.3 allows remote attackers to cause a denial of service (root process termination) by (1) closing the connection during negotiation or (2) specifying a name for a non-existent export.

CVE-2014-9727
Published: 2015-05-29
AVM Fritz!Box allows remote attackers to execute arbitrary commands via shell metacharacters in the var:lang parameter to cgi-bin/webcm.

CVE-2015-0200
Published: 2015-05-29
IBM WebSphere Commerce 6.x through 6.0.0.11 and 7.x before 7.0.0.8 IF2 allows local users to obtain sensitive database information via unspecified vectors.

CVE-2015-0751
Published: 2015-05-29
Cisco IP Phone 7861, when firmware from Cisco Unified Communications Manager 10.3(1) is used, allows remote attackers to cause a denial of service via crafted packets, aka Bug ID CSCus81800.

CVE-2015-0752
Published: 2015-05-29
Cross-site scripting (XSS) vulnerability in Cisco TelePresence Video Communication Server (VCS) X8.5.1 allows remote attackers to inject arbitrary web script or HTML via a crafted URL, aka Bug ID CSCut27635.

Dark Reading Radio
Archived Dark Reading Radio
After a serious cybersecurity incident, everyone will be looking to you for answers -- but you’ll never have complete information and you’ll never have enough time. So in those heated moments, when a business is on the brink of collapse, how will you and the rest of the board room executives respond?