If Not The PCI Standards, Then What?

I have just read a couple of articles as well as attended a couple of meetings where the topic du jour was the PCI standards.  They were a bash fest of the highest order.  Frustrated, I asked the participants at my last meeting, “If not the PCI standards, then what standard do you want to follow to ensure the security of cardholder data?”  Roaring silence.

This is the frustration that I and others have with people who complain about the PCI standards or any standards.  People complain and complain, yet they offer no solutions to address their complaints.  One thing I have always stressed with and required of people who work with me, if you are going to complain about something, you better have an idea for a solution.  Constructive criticism is fine, but if you do not have any ideas on how to make things better, then all you are doing is whining.  Children whine, adults have solutions.

But then you have the complainers who do offer a solution but that solution is to allow the marketplace to address the problem.  Hello!  How long was it going to take before merchants and service providers got a clue about securing cardholder data?  If it was such a priority, why did it take the card brands to come out with the standards?  For merchants and service providers, cardholder data security was not a priority, it was some other merchants’ or service providers’ problem.

The other problem with the marketplace approach is that each organization learns from its own incidents and possibly from incidents suffered by their business partners, not from the incidents experienced by all.  Under the marketplace approach, security protection only improves as each individual institution suffers a particular incident.  As a result, organizations reinvent the wheel with the majority of incidents.

Standards allow organizations to learn from the collective experience of all organizations, not just their own organization.  For example, if your organization does not have wireless networking but decides to implement wireless, a standard provides a guideline as to how to implement wireless securely.  Without a standard, you are on your own to do the best you can.  On your own you will likely get some things right, but you will also get some things wrong.  It is those mistakes due to lack of experience that come back to bite organizations.  With a standard to follow, the chance of getting bitten after the fact is often greatly minimized.

However, standards are not a guarantee.  Going back to wireless, just look at how things went wrong with WEP.  WEP is a standard and was well documented on how to implement it; supposedly securely.  WEP was also known to have the potential for security problems, but those problems were not widely publicized until organization began to have security incidents.  So a stop gap standard was provided called WPA which turned out to have its own security issues.  Ultimately, WPA was replaced by WPA2 which is the secure, permanent solution.

This is why early adopters of technology can end up getting burned.  When an organization decides to hop onboard the latest and greatest technology, there is a high risk that the security learning curve is not very far advanced.  As a result, the organization will be at a higher risk of suffering a security incident than an organization using a more tried and true approach.  As a new technology matures, typically its security posture matures and with a more mature security posture, the lower the likelihood that a security incident will occur.  However, the time it takes for that security maturity to occur can take quite a while and it is where things take quite a while where organizations are at the highest risk.

Unfortunately, in some instances, a new technology gets quickly usurped by an even newer technology and the original new technology never matures.  The bad news is that the early adopters get stuck with a solution that will never have its security shortcomings addressed, leaving the early adopters to either convert to the newer technology or find another alternative.  Many a career has been ended over such technology leap frogging events.

The PCI standards were not developed in a vacuum.  They are a consolidation of a lot of other security standards and guidance gained through root cause analysis of security incidents gathered over the years with the express purpose of protecting cardholder data.  If you follow another security standard such as ISO 27K or FISMA, a lot of what is in those standards is also in the PCI standards.  But there are also a lot of requirements in the PCI standards that are not in other standards as well.

The bottom line is if you do not like the PCI standards, then get involved in the process to make things better and stop whining.


5 Responses to “If Not The PCI Standards, Then What?”

  1. 1 Marc Bayerkohler
    March 3, 2011 at 10:34 PM

    Amen. PCIGuru, I don’t always agree with you, but this is spot-on.

    Many IT admins like to rail against the standards, and often point out some particular example where they feel the standard is making them actively reduce their security. I find this is usually because of a misreading or misapplication of a requirement.

    Anyone who has been doing PCI or PA-DSS assessments for long has stories about the stunning lack of security present in even large, well known organizations. Millions of unencrypted PAN left in old batch files on web servers? Check. Unencrypted CHD sent over the Internet? Not uncommon. Super-encryption invented by a previous developer has no documentation? Seen that.

    The fact is that PCI has done a decent job of increasing the overall security of the industry, especially given the vast array of systems and organizations is is meant to apply to.

    As to the SAQ questions above, I believe this is a problem of compliance versus validation. I may be wrong, but this is how I understand it. Technically, every merchant must adhere to every requirement of the PCI DSS. If there is a compromise, they were not compliant unless they had every control in place. If a merchant can’t figure that out on their own, they can hire someone to help (this may seem unreasonable/expensive).

    The difference a SAQ gives is in how the compliance is validated. It is a risk-based approach, because a full assessment is expensive, and if you are only required to fill out a SAQ, you are not the highest risk to cardholder data.

  2. March 1, 2011 at 3:47 PM



  3. 3 Ns
    March 1, 2011 at 2:07 PM

    I personally think PCI is great. It helps companies make their security program stronger iF used correctly. However, I also have an issue around SAQ. We have processes that are subject to SAQ B. However, when reading SAQ B it says that the company must comply with all applicable PCIDSS controls. The trick is that there are controls that SAQ B does not have that are applicable to our company. So when we ask PCI council as to should we focus on SAQ or the entire PCI DSS, the answer was SAQ. However, when the same question was asked to QSA, the answer is all PCIDSS. Another prime example is the use of Virtual Terminal. We have dedicated desktop that can logon to 3rd party card processor website to process the transaction. The council came out with a SAQ just for VT. So as a company should we only focus on VT SAQ or on all PCIDSS? I personally believe that SQA are more of a risk based approach. Company must review all PCIDSS controls against each process and assess what’s applicable and not just focus on SAQ A, B, C etc… Any thoughts on that?

  4. 4 Carlos
    February 28, 2011 at 1:50 PM

    Self Assessment

    While I think the PCI DSS is a good standard because it provides coverage across all layers of the organization, I feel that it is very difficult to comply with and the playing field is not level for everyone. For example, Self Assessment, allows an eligible merchant or Service Provider to Self Assess. This means that we can go through the standard and state Yes or No to each item in the Self Assessment Quesitonnaire (SAQ) if we have addressed the requirements. On top of this we must make an Attestation of Compliance (AOC) to *Attest* that what we have said is true.

    So lets take for example SAQ-D which is the catch all of the SAQ’s becuase it covers *everything* in the standard. The SAQ process allows me to elist the services of a QSA to assist because the standard is complex and full of terminology that most merchants or service providers dont understand. The purpose of the SAQ is to allow entities to self assess so they are not forced to undergo expensive onsite assessments by QSA’s. But in order to make an Attestation you really need to know what the status of each requirement is. So if you dont understand the requirement, or how to test it, and you get a QSA to help, is it the same as doing an audit in any event?

    It is also made worse by the fact that in the SAQ there is only a Yes or No check box, so you can just say if you have met the requirement or sub requirement. But it doesnt ask you to write in there *how* you checked it. So it almost encourages you to just put a check in the Yes box. If you had to put there how you checked it you would have to blatantly lie to put a Yes in the box if you didnt actually follow the test procedures properly.

    For example, if the business owner is self assessing and asks the IT Manager “are all our systems patched up to date” and if he says yes can the business owner just put yes for that requirement? Do you have to check this? Same for Antivirus – is it installed and running and getting signatures? Also – do we have file integrity monitoring – and is it monitoring the right files? Are we logging etc etc.

    If you have to check each item to make sure it is in place the SAQ process is asking you to act like a QSA – but you arent trained as one. And if you hire a QSA to assist (and they put their name on the form) does it mean they need to do an audit anyway because they can only tell you if you met the requirement if they actually tested it in line with the testing procedures? If this is the case then there are no cost savings for SAQ because the QSA will have to charge a lot to assess your environment.

    Or does the SAQ process just let you put checks in boxes because the industry needs to say that they provided a way for smaller companies to validate PCI Compliance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


February 2011
« Jan   Mar »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,083 other followers


%d bloggers like this: