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.
More Security Insights
- Forrester Study: The Total Economic Impact of VMware View
- Securing Executives and Highly Sensitive Documents of Corporations Globally
- Innovations in Integration: Achieving Holistic Rapid Detection and Response
- Optimize Your SQL Environment for Performance & Flexibility
"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.