Security Scribbling: ISO 27001 vs. PCI Misunderstanding

Thursday, November 17, 2011

Andrew Weidenhamer


This blog is an attempt to clarify and potentially refute some comments made in a blog titled "ISO 27001 vs PCI-DSS: Security Management vs. Security Controls Standards" which can be found at the link below: 

Indicative by the blog title, the blogger, Matt, attempts to explain the difference between the PCI DSS and ISO 27001, and why the PCI DSS can be so prescriptive while ISO 27001 cannot.  

He makes the following statement:

"The reason that PCI-DSS is able to be so prescriptive in its security controls and auditing requirements is that there are a significant number of constants in play, regardless of the size of business. The data requiring protection is always the same type (card numbers, cardholder name, expiry date, etc) and the controls for each data type are therefore constant."

"The threats to the data are the same and the level of impact is only dependent on how many payment cards are being handled. The Risk Assessment side has already been done in advance and the controls defined to appropriately reduce them. This is all defined regardless of the type of business, size of business or other threats that may be present in wider enterprise of the businesses in question."

The only thing I am willing to agree with him on in regard to his statement is the fact that the data that needs to be protected is a constant.

First off, how are the threats to the data the same?  It's obvious that the blogger does not consider all aspects of performing a threat assessment by making this statement. Threats are not just dependent on the type of data that needs to be protected, but also the type of business, industry in which that business operates in, number of assets, etc. 

I could write an entirely different blog on performing a threat assessment (and maybe I will), but the point is, that a financial institution required to be PCI compliant has different threats to the data in which it holds than a mom and pop restaurant chain taking credit cards via dial up terminals.

Secondly, he talks about the impact only being dependent on the number of payment cards handled. Again, this is a fallacy.  Although certainly the number of payment card transactions an organization takes factors into the overall impact incurred during a breach, it isn't the only thing to consider.

Other items that need to be considered are the potential reputational impact a company may face in regard to breach of credit card numbers.

How about any other regulatory compliance mandates that a company has to adhere to and what type of liabilities that company may face regarding breach of information? Is it possible that a company could not only face fines from the Card Brands, but also may be subject to other fines based on contractual or legal obligations? 

Again, all these things, as well as others, need to be factored into the overall impact of a potential breach. Matt's point is that ISO 27001 certification can't be prescribed such as PCI DSS for the points mentioned above.  Obviously, this is not true based on my rebuttal points.  

ISO 27001 doesn't prescribe controls because the assessment procedures and intent are much different.  In the case of ISO 27001, you choose controls based off the Risk Assessment.  So in theory, you could have a company that has a business process ISO 27001 certified and not be secure as the acceptance of risk for not having a specific control was justified through the Risk Assessment.  

In PCI, this is not the case.  Although a Risk Assessment is required to be performed within the PCI DSS, applicable controls are not based off that Risk Assessment.  The controls within PCI are always applicable to the organization unless otherwise determined that the controls are not applicable to the organization but not based off the Risk Assessment, but simply because it doesn't make any sense for their organization.  

An example of this would be ensuring the company has a formalized SDLC.  If the company needing to be PCI compliant doesn't develop any software, this control would obviously be "non-applicable" to the subject organization.  However, a company needing to be PCI compliant who develops in-scope software cannot say they don't have a formalized SDLC because risk is low for compromise.  

In ISO 27001 certification, a company could do this, if the Risk Assessment in which they perform determines this control to be low risk So to summarize, the only reason ISO 27001 isn't as prescriptive as PCI is simply because the assessment procedures and intent don't allow it to be. It has nothing to do with the type of data or size of the organization that chooses to go through ISO 27001 certification as Matt's blog seems to suggest.  

ISO 27001 could be as prescriptive if it didn't allow an organization to choose controls based off their Risk Assessment and Risk Assessment scores.  With this said, the PCI SSC is potentially looking to move to more risk based approach to become PCI compliant.  

Again, the problem with using a risk based approach is the manner in which risk is defined and accepted.  As long as there is a good Risk Assessment methodology in place and further good reasons and justifications to deal with risk, then using a risk based approach is perfectly acceptable.

However, if organizations are just accepting risk based off the fact they don't have enough money to either mitigate or transfer the risk, then one can obviously see the problem with this approach.

Cross-posted from SecureState

Possibly Related Articles:
Information Security
PCI DSS Compliance Enterprise Security Risk Assessments SDLC ISO 27001 Controls
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.