Risk //

Compliance

5/17/2013
12:22 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Mapping Compliance Proof To Risk-Based Controls

Risk-based security decisions usually yield more secure environments, but some harmonization with regulations needs to be done to prove compliance

For years now, the risk management gurus of the world have lamented the scourge of check-box compliance, urging organizations to make more security decisions based on sound risk management. The philosophy is that risk-based decisions generally yield more compliant environments: if an organization manages its risks, then compliance will naturally fall into place.

It's a sound idea, but when organizations flip their world view from check-box compliance to risk-first decision-making, there's bound to be times when an organization may be managing most risks well but still falls short of compliance requirements. In some cases, the organization has not documented mitigation measures well enough for the auditors yet and in others they are not quite totally compliant yet.

"Controls that are implemented solely to manage a risk, and not related to a compliance requirement, are focused on minimizing exposure to risks that will affect the business," says Steve Schlarman, eGRC Solutions Manager at RSA. "So risk management and compliance are not always equal. Therefore mapping controls to both risks and compliance requirements is necessary."

[Sick of checking the box? See Can We Cease Check Box Compliance?.]

Taking a step back, though, before getting into how to do the mapping some security experts say it is important to remember that while check-box compliance may be a no-no, that doesn't mean organizations should treat compliance concerns lightly. They just have to remember that the threat of non-compliance is just a subset of an organization's overall risk profile.

"There is a risk to the organization of not maintaining compliance with the required programs," says Andrew Wild, chief security officer at Qualys. "This risk is typically quantified in terms of fines or loss of business, and this risk should be evaluated and considered along with an organization's complete enterprise risk assessment when evaluating potential controls."

And compliance can be useful for maturing organizations seeking a risk-first decision-making prioritization to make sure that they've accounted for all of the right risks on their radar, and that they're priorities for action are appropriate.

"You can use it as a double check to make sure your security story is straight," says Jeff Williams, CEO of Aspect Security and a key volunteer in the OWASP organization. "And if there's a compliance requirement you're not dealing with for some reason, you ought to think about why it's there."

Williams says that all too often businesses think they're engaging in risk management, but really all they are doing is writing down all their risks, ranking them, and then doing nothing to actually act on them. He's a big champion of articulating that security story as a way to both manage the risks and also help tie that back into documentation necessary for compliance.

"The security story goes all the way from the top level business risks, all the way down to the individual security controls you have in place and then the evidence [of those]," he says, "It's a whole line of sight. So, for every risk you're mapping back to some business concern. It's powerful because then you can easily map any kind of compliance document into what you're actually doing."

As organizations get into the nitty gritty of mapping specific controls to compliance efforts, they should avoid the hair-pulling task of doing it regulation statement-by-regulation statement.

"This mapping is absolutely maddening if you try to do it at the regulatory statement level," says Josh Ablett of Adelia Risk. "When we do this, after we've identified all the pertinent regs, we'll map the regulatory statements to categories. Then for each category, we can take the most stringent requirement and count it as satisfying the entire category, obviously with some double checking."

According to Yo Delmar, vice president of GRC Solutions at MetricStream, an even better approach is to avoid reinventing the wheel altogether. Instead, she suggests leaning on the work of others and harmonize controls according to a popular security control framework. It's one of the key reasons why many of them were created, after all.

"Security professionals are increasingly relying on harmonized IT and security controls from international standard control frameworks such as ISO27002 and NIST 800.30," Delmar says. "These frameworks have been pre-mapped to hundreds of complex regulations at the citation level – a great example of this is the Unified Compliance Framework that maps hundreds of regulations to thousands of harmonized controls."

At Bethesda, Md.-based DMI, CISO Rick Doten, says he used specific ISO section requirements to build out his own method of syncing up his existing controls with business risks and compliance requirements. He started by listing all of his controls in a spreadsheet that linked them to the risks that they mitigated. To the right of that were ISO section requirements they also fulfilled, as well as policies that mapped to requirements for each of the risk areas. From there he created an illustration to show the dependencies.

"I illustrated it with a triangle, where bottom side is my controls, right side is my business risks, and a set of arrows point from controls to business risk; then, the left side is my compliance," he says. "Most of the business risk controls satisfy compliance requirements, but then, there are a few control put in place (using) arrows just to meet compliance."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Devastating Cyberattack on Email Provider Destroys 18 Years of Data
Jai Vijayan, Freelance writer,  2/12/2019
Up to 100,000 Reported Affected in Landmark White Data Breach
Kelly Sheridan, Staff Editor, Dark Reading,  2/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8354
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.
CVE-2019-8355
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.
CVE-2019-8356
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.
CVE-2019-8357
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.
CVE-2013-2516
PUBLISHED: 2019-02-15
Vulnerability in FileUtils v0.7, Ruby Gem Fileutils <= v0.7 Command Injection vulnerability in user supplied url variable that is passed to the shell.