Risk
1/30/2014
01:30 PM
Tom Bowers
Tom Bowers
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Finding The Balance Between Compliance & Security

IT departments can reduce security risks by combining the flexibility of ISO 27000 with the stringent requirements of PCI. Here's how.

In truth, compliance-based security rarely provides effective protection against determined attacks. This was clearly the case in the recent breaches of retailers Target, Neiman-Marcus, and Michaels Stores.

Compliance requirements like the Payment Card Industry (PCI) Data Security Standard (PCI/DSS) give the illusion of reasonable security. This is not to say that these requirements do not reduce risk -- because they certainly do. They are merely incomplete because they fail to provide flexibility or the means to adjust according to a company's true security needs. An effective information security program requires a framework that allows a company to adjust based upon both the risks faced by the company and the market vertical the company serves.

Security is simply another business risk like shareholder, market, and customer risk. Risk by its very nature is never black and white, but gray. In dealing with risk-based decisions, executives must look at the best information they can find and make the most reasonable decisions they can, given their current situations. This reasonableness is the cornerstone of not only business operations, but also Western case law, which is founded upon the "reasonable person" standard.

What that means in the context of enterprise IT is the answer to the question: Has the organization done what a reasonable person would do to protect sensitive information? Recent court decisions clearly demonstrate that simply meeting an industry-compliance requirement, like PCI, is insufficient in meeting the reasonableness standard. The courts want to know whether corporations have done what is reasonable for their companies or industries versus whether they have they simply met a compliance prerequisite.

The challenge for security professionals is how to bridge this gap. Is there a way to combine the flexibility of ISO 27000 with the stringent requirements of PCI? Many chief information security officers are faced with two competing directives: Adopt the ISO 27000 framework and improve PCI compliance. The former is designed as a security framework -- plan, do, check, and act  -- based on the groundbreaking work by consultant and statistician W. Edwards Deming. It’s meant to be a constantly evolving and improving standard.

PCI, on the other hand, is actually a subset of ISO 27000 security controls focused on the credit card payment zone, generally defined as anywhere on a network credit card information traverses and/or is stored. The answer to connecting the two seems to lie in the origins of PCI. Since PCI started with ISO 27000 security controls, then why not simply cross-pollinate them with one another?

ISO 27000 breaks information security into ten areas of focus and labels them from four to fourteen. Each of these has multiple security controls that provide specific guidance to reduce an organization's risk profile. They include:

  • Risk assessment
  • Security policy
  • Organization of information security
  • Asset management
  • Human resources security
  • Physical and environmental security
  • Communications and operations management
  • Access control
  • Information systems acquisition, development, and maintenance
  • Information security incident management
  • Business continuity management

PCI has two compliance sections: technology controls and administrative controls. While ISO 27000 does little in meeting PCI’s administrative requirements, it lines up very well with the technology controls that revolve around the PCI payment zone. Thus, the controls imposed on the network from ISO 27000 can also apply to those mandated by PCI. Simply add PCI as the eleventh category to the ISO 27000 framework (category 15) and cross-reference the requirements for items such as physical security, anti-virus, wireless usage, and software development with those of PCI.

This will allow an organization the flexibility of ISO 27000 and still meet the requirements of PCI. While not a perfect marriage, it should certainly improve your security stance.

Tom Bowers has 30 years of experience in the field of computer technology and information systems. He has served as the chief architect for information security structures and protections in numerous industries. 

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
AmmarNaeem
50%
50%
AmmarNaeem,
User Rank: Apprentice
1/31/2014 | 2:10:42 AM
Security
Flexibility is the key to make the balance between compliance and security. With ERP, our oganizations become more secure and flexible and more integrated
AndrewB871
50%
50%
AndrewB871,
User Rank: Apprentice
1/31/2014 | 8:10:19 AM
Balance Security - compliance isn't the issue
So often I read articles like this where compliance is compared with security.  This is always going to be a pointless debate.

This article references 27000 - which is actually the vocabularly document at the start of the series of security standards.

27001 references a Management system.  Its flexible sure, you could have very few security controls and a well thought out risk assessment with the emphasis on risk acceptance.  27001 is FREQUENTLY mistaken for its control annex - which lists a lot of controls that are sensible to implement if the risks affect you.

27002 - is a security implementation standard

27005 is a risk assessment standard

Problem - in MANY MANY business environments, there was NO security AT ALL before a compliance regime mandated it, either for a specific data type (PCI / HIPPA / SSNs etc), of for the 'infrastructure'.

Flexibility swings both ways, and in a lot of business environments is code for 'what can we get away with not doing'. 

Most security standards that are enforced with a compliance regime are asking for the right things to be done.  What then typically happens is the pre-compliance mentantality of 'how little can we do' over rides the - what happens if questions.

I'm sure we will see some epic knee jerk responses in relation to the recent breaches in the USA.  Something that neither PCI or and ISO framework would have prevented IF the business didn't commit to the appropriate controls OR decided they would accept the risk because well - very few get published.

The single most important thing that happened was that these breaches have been published, which now makes the C-level community aware of the threats.  Implementing the security frameworks  should be focused around protection of the assets that are most valuable.  Clearly in these instances mag stripe card holder data is still valuable.

As is lots of other data - so the businesses with that data in their custody must focus on keeping it safe.  The PCI is focused on card data,  married with 27001 ( a robust management system incorporating risk assessment and treatment) is a very very strong pairing.  The 27001 management system would capture why certain controls are implemented in certain ways - perhaps because a contractual requirement from PCI would apply or because the business is going to accept the risk.  The difference with a ISO management system is it makes the risk based decisions visable to all.  This in itself forces accountability and can make people think twice before they say - well I'm not going to fix that.  Especially if the risk register says CxO said - he's accepting that risk because of XYZ.

 

 

 

 
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
1/31/2014 | 10:11:16 AM
Re: Balance Security - compliance isn't the issue
I think the single most important thing that might come from this breach is more urgency to overhaul the card processing system in the United States.

 
TomBowers1812
50%
50%
TomBowers1812,
User Rank: Apprentice
1/31/2014 | 10:15:03 AM
Re: Balance Security - compliance isn't the issue
Andrew I could not agree more that compliance is not true security. The harsh reality however, is that as a CISO I must do both. I used 27000 as shorthand for the entire 27000 series. This article is driven by the need to implement both 27000 and meet PCI requirements. PCI is very black and white, inflexible and narrowly focused. By changing my organizations focus to see credit card data as another type of sensitive data we are able to place PCI requirements in a more balanced context. Check box security (compliance) will NEVER be completely effective as it leaves gaps. 
TomBowers1812
50%
50%
TomBowers1812,
User Rank: Apprentice
1/31/2014 | 10:20:34 AM
Re: Balance Security - compliance isn't the issue
Drew I'd like to think that this will move point of sale (POS) systems to modernize....but I doubt it. I see great similarities with health care systems. The POS / health care software REQUIRES antiquated operating systems with full administrative privledges to run. I am familiar with a large warehouse store that only recently upgraded their POS from Windows NT to Windows XP. Some upgrade. 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/31/2014 | 10:53:02 AM
Re: Balance Security - compliance isn't the issue
Tom, if not government regs, what do you think it will take for organizations-- retail, healthcare and others -- to modernize POS systems. Apparently, the ROI of dealing with a breach (cost of bad publicity, identity theft, compromised data) is still tilted towards doing nothing.
TomBowers1812
50%
50%
TomBowers1812,
User Rank: Apprentice
1/31/2014 | 10:58:10 AM
Re: Balance Security - compliance isn't the issue
Marilyn the customers of POS systems and the government will need to put intense pressure on the POS companies to modernize. Unfortunately this will likely happen through the courts, which means a slower response. If the government is loathe to take haelth care software providers to court I see it as even less likely that they will take POS providers to court.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/31/2014 | 11:02:28 AM
Take software providers to court?
By "customers of POS systems" do you mean consumer or retailers? And by legal action, do you mean stronger enforcement of compliance regs or something else?
TomBowers1812
50%
50%
TomBowers1812,
User Rank: Apprentice
1/31/2014 | 11:18:42 AM
Re: Take software providers to court?
The term "customer" refers to those retailers that use POS systems (e.g. - Target, Neiman Marcus, Michaels...). While unlikely to make headlines, I expect those retailers to file suit against their POS suppliers for not providing them secure POS systems and placing the retailer at risk.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/31/2014 | 11:23:20 AM
Re: Take software providers to court?
That will be definitely be something to watch for -- and probably not something that will be resolved quickly. If it's a protracted litigation that ends in a settlement, we might never find out. But then again, maybe it will be the game-changer that the industry needs to address these serious security issues. (I hope so!)
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-4594
Published: 2014-10-25
The Payment for Webform module 7.x-1.x before 7.x-1.5 for Drupal does not restrict access by anonymous users, which allows remote anonymous users to use the payment of other anonymous users when submitting a form that requires payment.

CVE-2014-0476
Published: 2014-10-25
The slapper function in chkrootkit before 0.50 does not properly quote file paths, which allows local users to execute arbitrary code via a Trojan horse executable. NOTE: this is only a vulnerability when /tmp is not mounted with the noexec option.

CVE-2014-1927
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly quote strings, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "$(" command-substitution sequences, a different vulnerability than CVE-2014-1928....

CVE-2014-1928
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly escape characters, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "\" (backslash) characters to form multi-command sequences, a different vulner...

CVE-2014-1929
Published: 2014-10-25
python-gnupg 0.3.5 and 0.3.6 allows context-dependent attackers to have an unspecified impact via vectors related to "option injection through positional arguments." NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-7323.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.