“Security Scribbling” ISO 27001 vs. PCI Misunderstanding

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 below link:

http://securityscribblings.blogspot.com/2011/11/iso-27001-vs-pci-dsssecurity.html?utm_source=twitterfeed&utm_medium=twitter

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.

Decrypting QSA Company Qualifications in a Diluted Market Place

One of the biggest challenges I have seen for organizations going through PCI On-Site Assessments, is how to determine which 3rd party QSA company to use. With 120 and growing QSA companies certified to perform On-Site Assessments in the USA, there is not an easy answer, unless of course price is the only consideration.

Unfortunately, sometimes this is the case. However, if price is not the only consideration, below are two items to consider, as well as some potential questions that organizations should be asking to potential vendors to, at the very least, attempt to decipher qualifications.

Determine Relationship:

First and foremost, the biggest complaint I hear from organizations is the impersonal relationship which occurs between the QSA and the subject organization, either during or after the On-Site Assessment. Most times, there are items which have to be remediated after the On-Site Assessment. In this case, the subject organization must have access to the QSA on a somewhat real time basis, as typically there is a deadline in which these items need to be remediated and guidance is necessary. Secondly, after compliance is achieved, a strong relationship will ensure that the client is being updated on any new changes or guidance to the PCI standard. This is necessary to avoid 11th hour situations. Some potential questions to ask to determine what type of relationship to expect are below:

• How many projects will our QSA be working on at a single time?
• What will the average SLA be on communication from our specific QSA?
• Is any guidance or updates provided after the On-Site Assessment is complete?

Experience:

The second biggest concern I hear from organizations is, “Our QSA wasn’t able to answer our question or didn’t appear to be knowledgeable.” It’s pretty obvious why this is a concern. Many times what will happen, is that consulting companies will sell with an experienced, seasoned QSA and then deliver with staff or less knowledgeable individuals. This becomes pretty clear early in the assessment and can cause a serious headache for organizations. If you hear your QSA say, “I’ll get back to you on that” in regard to interpretation on control requirements, there may be a problem. Typically, this means that the QSA is contacting more experienced QSAs within the organization to get clarification. In addition, less experienced QSAs use the black and white approach to assessments. There is no room for interpretation or movement for a specific control requirement. This inability to understand the business, the real intent of the requirement, and to properly make risk based decisions can seriously impact an organization from not only an operational standpoint, but pretty significantly from a financial standpoint. This is especially true if new technology must be introduced in order to meet the control requirement. Some potential questions to ask to determine experience are below:

• How many On-Site Assessments has our QSA performed?
• How many years of security experience does our QSA have?
• What level (i.e., junior, staff, senior) of consultant will be performing our On-Site Assessment?

To summarize, if upfront assessment cost is not the only concern for determining what company to use as your QSA company, then qualifying questions need to be asked to determine which company is best equipped and suited to handle the PCI compliance needs of an organization. In a sea of QSA companies, which in the future will become an ocean, failure to ask these questions can result in potentially unnecessary business, operational, and financial impact.