Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk //

Compliance

5/17/2013
12:22 AM
Connect Directly
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
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft Patches Windows Vuln Discovered by the NSA
Kelly Sheridan, Staff Editor, Dark Reading,  1/14/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Give us your best shot! You might win an Amazon gift card!
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
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-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.