Author Archive for PCI Guru


Information Supplements Versus The PCI DSS

At various times over the years, the Council has repeatedly told QSAs, Participating Organizations (PO) and anyone else that has asked questions about statements in the Information Supplements the following.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

So what are the point then of the Information Supplements?

Boy is that a good question. As a QSA, I often ask myself that very question after some of the inane conversations with clients and prospective clients regarding Information Supplements and their supposed “guidance”.

The first thing everyone should remember about Information Supplements is that they are developed and written by a committee at the suggestion of the Council, POs or as part of special interest work groups. These committees are made up of personnel from interested POs, QSAs, ISAs, vendors and anyone else willing to participate in their development. They are edited by a representative from the Council and reviewed by the Committee and are then submitted to all POs, QSAs and ISAs for review and comment. Similar in concept to the development and review of RFCs by the IETF.

The other key point about Information Supplements are that they are developed to give QSAs, ISAs and organizations ideas and guidance on how best to appropriately meet the requirements of the PCI DSS and the Reporting Template testing. Again, as the Council has repeatedly stated, the Information Supplements do not replace the explicit guidance and testing requirements in the PCI DSS and the Reporting Template. They are merely suggests on an approach.

Yet time and again, QSAs and ISAs get these priceless documents tossed in our faces and are told we do not know what we are talking about. “The Information Supplement says …” is always put out there as the justification as to why an organization is doing something it should not be doing or as the rationale for why the organization is not in compliance with the PCI DSS. And we again are forced to explain that the Council never has said that an Information Supplement replaces the guidance and testing in the PCI DSS or the Reporting Template.

The first question anyone, and I do mean anyone, should ask about any statement in an Information Supplement is, “Does the PCI DSS and/or the Reporting Template explicitly say the same thing?” Those are the only two documents that matter and the only documents that your organization will be assessed against. If it is not explicitly called out in either of those documents, then it is not accurate and does not reflect the compliance requirements.

As an example. I was on a conference call recently regarding the Council’s Information Supplement on penetration testing. This supplement was issued in March, 2015 and is possibly one of the most confusing and contradictory pieces of “guidance” we have ever encountered. In fact, it has created more confusion than it has actually clarified. In my very humble opinion, the Council would be better off taking it out of circulation because of all of the trouble it creates for QSAs, penetration testers, ASVs and clients. It is possibly one of the worst written of the Information Supplements and, while people both on the Committee that developed it and externally supplied the Council with numerous suggestions for changes, those changes were not incorporated into the document. Why those changes were not incorporated is anyone’s guess. But we in the PCI community ended up with possibly the worst expressed and misunderstood guidance available.

As usual, the client was arguing over the scope of their penetration testing. I get the fact that organizations want to minimize costs and scope as much as possible. However when you listen to some security professionals arguments on this topic, you just wonder how they got to their positions as they argue over not testing systems and devices that are painfully obvious to be in scope.

And as also is usual, the first piece of confusion regarding scope is in Section 2, page 5, first paragraph after the bullets and states the following.

“It is not a requirement to test from within the CDE to the servers inside the CDE; and testing exclusively from within the CDE perimeter will not satisfy the requirement. However, when access to the CDE is obtained as a result of the testing, the penetration tester may elect to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.”

One would think that to any reasonably intelligent information security professional, the first part of the sentence, “It is not a requirement to test from within the CDE to the servers inside the CDE;” would be considered a pure line of garbage. Never mind that none of the recognized penetration testing methodologies ever suggest such an approach. But people arguing never consider that fact. Nope. The people arguing are so focused on cutting their PCI compliance bill that it does not matter that the statement is pure and unsupported garbage. It is considered the gospel truth. Otherwise, why would the Council allow such a statement? Good question. We have asked the Council that question and the answer back is? You guessed it.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

Again, never mind it is in no way supported by the guidance provided by the PCI DSS for requirement 11.3 which says:

“The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks.”

But argue that point they do even when you point out that arguing this point is basically arguing that any attacker would stop at the perimeter of the CDE and would go no further.

Seriously? If you believe that fact, you must also believe in Santa Claus, the Easter Bunny, the Tooth Fairy and any other of the multitude of mythical fictional creatures. Or you are just lying to yourself and are in serious denial about your organization’s security posture. But argue on they do.

Then you pair that to the second part of that first sentence of this paragraph that says, “… and testing exclusively from within the CDE perimeter will not satisfy the requirement.” Just adds to the out of scope argument.

As I point out when bitch slapped with this terrible writing, if you go back and carefully re-read the second part of the first sentence, what it points out is that penetration testing from only inside the CDE is not sufficient to meet the penetration testing requirements of the PCI DSS requirement 11.3. In no way does that sentence say or even further imply that the CDE is out of scope. It is actually saying that penetration testing should be done from within the CDE, but that penetration testing only inside the CDE does not meet 11.3. But people will still argue that the CDE is out of scope.

That the CDE is in scope is further supported by the definitions of “critical systems” from section 2.2.1 of the document which defines that not only are systems within the CDE in scope, but also those that are outside the CDE but could affect the security of those systems inside the CDE (i.e., what the Council and the Open PCI DSS Scoping Toolkit refer to as “connected to” systems). However, people arguing over scope rarely, if ever, tie these two section together and then argue that because they are in separate sections they cannot be possibly together even though the entire document is about only one subject, penetration testing and requirements in 11.3 of the PCI DSS.

So before you go off telling your QSA or ISA that the Information Supplement says something. Think about what the information supplement says. Is the guidance from the Information Supplement even implied in the PCI DSS? Read the guidance in the PCI DSS and the testing procedures from the Reporting Template. If the PCI DSS or the Reporting Template do not explicitly have the same language in them that the Information Supplement has, then the Information Supplement is merely a suggestion.

And if the guidance from the Information Supplement does not make sense, pull your head out of your posterior and use some God given common sense. Ask your QSA or ISA to explain it, before going off halfcocked and thinking that someone could actually think such things made sense.

But again, why would the Council allow such statements? Good question. We have asked the Council that question and the answer back is? You guessed it.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

Clear as mud? You bet.

But what did you expect? It is PCI.

For all of you in the United States, have a happy and safe Thanksgiving holiday.


Small And Mid-Sized Businesses

At this year’s PCI Community Meeting, the push was to address the security issues faced by small and mid-sized businesses, otherwise referred to as SMB. However, in my opinion, the approaches being suggested are still too complex. Great security results from simplicity, not complexity. As a result, I propose the following approach for SMBs because SMB executives typically have little time to fully educate themselves in information security, let alone, PCI. And while I am of the opinion that executives should have such knowledge, it is just not happening.

There Are No “Silver Bullet” Solutions

First and foremost. There are no “silver bullet” solutions that will entirely remove your organization from PCI scope. Any vendor telling you that their solution removes your organization from PCI scope is lying to you. If you hear such a statement from a vendor, the vendor does not know what they are talking about and their statements regarding PCI should no longer be trusted. The bottom line is that, if your organization accepts credit/debit cards for payment for goods/services, the organization will always have some PCI scope. The least amount of scope an organization can achieve is complying with the requirements listed in the SAQ A. There is nothing less. Anyone telling you otherwise does not know what they are talking about.


This is probably the biggest single thing an SMB can do. In this day and age, there is no reason that any organization needs to retain CHD. Period. The most common business justification is that the organization does recurring transactions and that is the reason to retain CHD. Processors have a solution for that situation and many others. So I say it again. There is no valid business reason for any organization to retain CHD. None. Nada. Zip.

The first question out of an SMB executive’s mouth to a payment solution vendor should be, “Does your solution store cardholder or sensitive authentication data?” If the answer is anything other than an immediate and definitive “NO”, the meeting or telephone call is over, done, complete. There is nothing more to discuss. SMBs must stop being an easy target for attacks. The easiest way to do that is not having the CHD in the first place.

The second question that a payment vendor should be asked is, “How does your solution minimize my organization’s PCI scope?” If the vendor cannot provide you with a whitepaper on this subject, run away. If the documentation provided by the vendor leaves you with more questions than answers for PCI compliance, you also need to run away. In all likelihood, if this is what you encounter, the vendor’s PCI compliance is questionable, complex or requires too much effort on your part to be PCI compliant. This question should result in a one to three page whitepaper on PCI and how the vendor’s solution minimizes your organization’s scope.

So what solutions reduce scope to the minimum?

If you are a traditional brick and mortar retailer, end-to-end encryption (E2EE) from the card terminal, also known as the point of interaction (POI), to the transaction processor. PCI has a validation program called point-to-point encryption (P2PE). P2PE solutions are independently validated to ensure that they are secure. Solutions such as Shift4’s Dollars on the Net, First Data’s TransArmor and Verifone’s VeriShield are E2EE solutions that could meet the P2PE standard, but for various reasons the providers chose not to validate them to the P2PE standard. The key capability for any such solution is that the solution encrypts the CHD/SAD immediately when it is read from the card and none of your organization’s technology can decrypt the information and therefore read it.

If your organization does eCommerce, then you want to use a redirect or iFrame to process transactions in order to reduce PCI scope. The best example of a redirect is when a merchant uses PayPal for processing payments. The merchant’s Web site has a PayPal button that sends the customer to PayPal who then processes the customer’s payment transaction. At no time does the sensitive authentication data (SAD) encounter the merchant’s Web site. One of the concerns from merchants about redirects is the myth that customers vacate their shopping carts because they are redirected to a different site for payment. While this was true in the early days of eCommerce, with the increased use of PayPal and similar payment services, customers seem to have gotten over that practice and vacated shopping carts are no longer an issue. But if this is still a concern, use this as a teaching moment and educate your customer base that you do the redirect to ensure the security of their SAD.

An iFrame is essentially a Web page within a Web page. But the key thing from a PCI compliance perspective is that the iFrame is produced and managed by a third party, not the merchant. An iFrame can be a Web page, but more often than not it is a series of fields that gather the SAD for conducting a payment transaction. As with the redirect, the SAD never comes into contact with the merchant’s Web site.

Both of these solutions take your organization’s Web site out of scope so you do not need external and internal vulnerability scans and penetration tests. However, just because your Web site does not have to go through the rigors of PCI compliance, you still need to ensure its security. See my post on SAQ A and SAQ A-EP for a more detailed discussion on this topic.


Tokenization is the act of encrypting or tokenizing the primary account number (PAN) so that when it is returned to the merchant for storage it has no value to anyone if it is disclosed. Tokenization can occur at the time a card is swiped or dipped at the terminal or it can be done by the transaction processor at the back end of the transaction. Regardless of where the tokenization occurs, paired with E2EE or P2PE, tokenization further minimizes PCI scope.

If your organization needs to perform recurring transactions such as with subscriptions or automatic reorders, tokens can be generated by the processor so that they can be used just like a PAN. While a token is not a PAN, in situations where they can be reused for future transactions, it is incumbent upon the merchant to protect access to the token so that it cannot be sent to the processor for fraudulent charges.

And that is it. Not storing CHD, E2EE/P2PE and tokenization will reduce an organization’s PCI compliance footprint to the absolute minimum. It really is that simple. However, finding the solutions that bring all of that to the table is where the work comes in. However, any SMB that asks the right questions of its vendors can put together a solution that minimizes their scope and provides protection for CHD/SAD as good as with the big boys.


SSL Is Not Going To Go Quietly

A lot of organizations are finding out that just turning off SSL is just not an option. This is particularly true of merchants running eCommerce sites predominantly used by mobile customers or customers running older operating systems. To the surprise of a lot of IT people, it turns out that most mobile browsers do not support using TLS. And while most Western PC users have reasonably current browser software, the rest of the world does not and turning off SSL will remove a significant portion of some merchant’s customer base. As a result, for some organizations going “cold turkey” on SSL is just not an option without suffering significant consequences.

But there is a larger problem with SSL lurking inside almost every data center. That is with appliances and data center management software that have SSL baked into them for their Web-based management interfaces. A lot of vendors availed themselves of OpenSSL and other open source SSL solutions to secure communications with their appliances and solutions. To remediate these solutions, an organization might be lucky enough to upgrade the firmware/software. Unfortunately, a lot of organizations are finding that replacement is the only option offered by vendors to address these situations.

The bottom line is that because of these situations, SSL and early TLS will not be addressed by just disabling it and moving on. As the PCI SSC found out when they asked Qualified Security Assessor Companies and Participating Organizations about what it would take to address the SSL/early TLS situation, they were told about these issues and therefore set a deadline of June 30, 2016 to provide time to address these situations.

While organizations have until June 30, 2016 to address SSL and early TLS, that does not mean an organization can just sit by and do nothing until that deadline. Here are some things your organization should be doing to address SSL and early TLS if you are unable to just turn it off.

  • Get a copy of NIST Special Publication 800-52 Revision 1 titled ‘Guidelines for the Selection, Configuration and Use of Transport Layer Security (TLS) Implementations’. This publication is the Bible for how to minimize and mitigate the risks of SSL and early TLS.
  • Identify all instances of where SSL or TLS are used and versions supported. It is not just those instances that need to be remediated, but all instances. The reason is that TLS v1.3 is in draft specification and its release is likely just around the corner in 2016. That is why a complete inventory is needed so that when TLS v1.3 is available you will know what remaining instances will potentially need to be updated, upgraded or possibly even replaced.
  • Implement TLS-FALLBACK-SCSV to minimize the chance of SSL/TLS fallback. This option was developed to address the issue created by POODLE. However, be aware that only certain versions of browsers support this option, so it is not a perfect solution.
  • Monitor your external Web sites for SSL and early TLS usage. Track statistics of how many sessions are using SSL or early TLS so that you can determine usage of those protocols and therefore know the actual impact of any decision regarding those protocols. These statistics will also allow you to know when you might be able to pull the plug on SSL and early TLS with minimal impact.
  • Modify any external Web sites to present a message to anyone using SSL or early TLS to warn them that you will be no longer supporting SSL/early TLS as of whatever date your organization chooses to drop that support.
  • Where possible, configure the Web site to only use SSL or early TLS as the absolute last resort. Unfortunately, a lot of vendors modified their SSL solution to not allow this sort of change so do not be surprised if that does not become an option.
  • Develop a migration plan for your remaining instances where SSL or early TLS are used. Contact vendors involved and document what their plans are for dropping SSL and early TLS.
  • Be prepared to create compensating controls for SSL and early TLS that you will not be able to remediate by the deadline. Unfortunately, I have a sneaking suspicion that some vendors will miss the June 30, 2016 deadline as will some merchants be unable to turn off SSL by the deadline. As a result, those organizations will have to put compensating controls in place to maintain PCI compliance. These compensating controls will likely be messy and complex as enhanced monitoring will likely be the only controls available.

Another Annual Community Meeting

Another year has come and gone and so has another North American PCI Community Meeting. This one held in the beautiful city of Vancouver, British Columbia, Canada.

I have to say that the new leadership of the Council is showing. I heard many comments from attendees that this year’s conference was better than in years past.

The Good

  • The ‘Mobile Forum Roundtable Discussion’ was probably the best session of the conference. That is based on comments from the attendees of this session as well as the comments from other conference attendees that went to the competing sessions. If the Council is looking for how to structure future sessions, this is the format. Participants sat at numbered tables and then each table was given a question on the topic of mobile payments to discuss for half of the session. The last half of the session was a representative from each table presenting the findings from those table discussions. I think the Council’s Mobile Working Group, of whom some members were present, as well as the other attendees of this session learned a lot in an hour and a half.
  • There were two notable sessions regarding point-to-point encryption (P2PE) that had nothing to do with P2PE. One was given by First Data regarding TransArmor and the other was given by Caesars International regarding Shift4. Neither of these end-to-end encryption (E2EE) solutions are P2PE validated. In years past, these sessions would never have occurred. Apparently the new leadership at the Council felt it was important to have their stories told to the Community Meeting participants as a more secure way of conducting transactions even though neither is a P2PE solution. I commend the Council for their foresight in holding such sessions.
  • Brian Krebs’ Keynote on Thursday was not what I was at all expecting. I expected Brian would mostly rehash stuff out of his latest book as most writers do at these sorts of events. But it was a very informative and enlightening session with a lot of good information. For those who regularly read his blog, a lot of the stories he gave we had already heard but not with the personal touches he gave them. If anything, people walked away with a better understanding of why card data is sought after by the underground.
  • As always it was great to get together with everyone involved in PCI and meet a lot of you. The nightly receptions were excellent as were the session breaks. It always amazes me how many people just walk up and introduce themselves to me at these meetings. I really appreciate the fact that so many of you find the blog so useful as well as providing people with a voice in sharing frustrations with PCI and the process. Thank you to all of you that read this blog and find it useful.

The Not So Good

  • The Thursday “TED Talks” format was so-so. While it was definitely the talk at lunch and afterwards at dinner, it was not viewed as a highlight. As I coalesced the comments I heard, I do not think it was not the format as much as not all of the topics presented belonged in such a format. For anyone that has seen or been to TED Talks, they are very, very high energy and involve a passion for a topic that was not completely present in those Thursday sessions. If this is a format the Council wants to use going forward, then the topics are going to have to have a much higher energy to them and be much more important to discuss.
  • I had to chuckle at the vendor booths that were pushing their “silver bullet” solution for PCI compliance. There were only a very few of these “snake oil salesmen” present, but there they were saying they could put parts of your environment completely out of scope for PCI compliance. I thought we were long past such claims, but apparently not.
  • As with any such event, I saw a lot of people that I really wanted to talk to and just did not get the chance to catch up with them.
  • I unfortunately ended up with a number of client and emergency meetings I needed to attend during the conference. As a result, I had a few interruptions and could not attend a number of the sessions I really wanted to attend.

The Notably Missing

  • Professional Breakout Sessions were missing. This is a PCI conference that brings together qualified security assessors (QSA), internal security assessors (ISA), approved scanning vendors (ASV) and participating organizations (PO). Yet, there were no breakout sessions for those participants to meet with anyone from the Council. You would think that getting feedback from each of these important groups would be important to the Council. Other than these groups going individually to the Council’s office on “Card Brand Row”, there was no program for these important constituents to get together and voice their concerns. One would think this is a key part of why you hold such an event yet this piece was missing.

Overall though this year’s Community Meeting was probably one of the better ones I have attended.

See you all next year in Las Vegas.


Where Compliance Fits

Based on some of the comments I get from blog readers and articles I see espousing the “compliance is not security” mantra, I think it is time for a refresher on where compliance fits into an organization’s security program or any other audit/assessment program.

As a reminder, Miriam Webster defines compliance as:

“Conformity in fulfilling official requirements”

Therefore, for PCI, an organization is conforming to the PCI DSS when they assess. For ISO 27K, the organization is conforming to the ISO 27K standard. For a financial audit, an organization conforms to the Generally Accepted Audit Principles (GAAP). The list can go on and on.

Where things get confusing and messy is whether or not the compliance program is detailed and tight enough to ensure security. Programs such as the PCI DSS, ISO 27K and others have to be written in such a way that any organization (regardless of technology, architecture, applications, etc.) can assess to it. Whether we are talking about the PCI DSS, ISO 27K, COBIT or any other assessment program, there must be flexibility to allow for all sorts of solutions, not just a preferred or “perfect” one. As a result, there is a lot of flexibility built in that produces a not so tight security program. This therefore means that being secure requires going beyond what the compliance program requires.

But compliance is only a part of an overall security program. I have discussed the control triad in prior posts, but it bears repeating here. There are three parts to any effective security program: protection, detection and correction.

Control TriadA good compliance program is part detection and part correction. The detection side of compliance relates to detecting controls that are not functioning as designed or are missing altogether. Changes to the environment are always the culprit in controls not functioning properly or missing. The correction side of compliance is defining what needs to be corrected in order to address the shortcomings determined during an audit/assessment.

Where the “compliance does not equal security” naysayers first go wrong is with ignoring execution. A compliance program is all about assessing the execution of an organization’s security program and ensuring that an organization is executing that program flawlessly. But an annual assessment such as with the current PCI process is only part of the overall compliance process. Compliance must be assessed constantly which is why the PCI SSC is introducing the concept of business as usual (BAU). BAU is meant to drive organizations to constantly assess compliance with requirements based on their risk assessment. Some requirements may have to be assessed daily, whereas other requirements might only be assessed weekly, monthly or even semi-annually

A working compliance program points out any execution issues with the security program and recommends solutions. To paraphrase the numerous security professionals that has pointed this out over the years, “To ensure the security of our organization, we have to get it right every minute of every hour of every day. Attackers only have to get it right once.” Therefore a compliance program is the mechanism that keeps the security program functioning as close to “right” as is humanly possible. But as I always point out, security is not perfect. So even with a good compliance program, security issues will still occur.

But that is where security has its biggest issues are with execution. If organizations could execute any security program, even the PCI DSS, with almost 100% accuracy every day, the number and seriousness of data breaches would be virtually non-existent. But that is where most organizations get burned is with execution. I have yet to encounter any organization that can execute all parts of any security program above 90% and that is on a good day. In most cases organizations are well below that percentage. As a result, regardless of the security measures in place, the controls are not functioning as defined and therefore security holes abound resulting in a myriad of ways to defeat security. Add in the human errors that occur and I think you start to understand the challenges of keeping a security program working effectively.

The second place that the naysayers go wrong is not recognizing the inherent limitations of the assessment programs. Every security program I have ever encountered has a multitude of limitations due to the necessity that they fit all situations. Then there is the fact that they are, after all, mere baselines for security, not a “be all to end all”. To truly be secure an organization must go well beyond what the PCI DSS, ISO 27K or any other security programs call out. That is not to say that a company cannot be reasonably secure following only these programs. But then we go back to my earlier statement that the program must be executed close to 100% compliance every day which is where organizations get burned. It is not the program that causes the security issues; it’s the inability to execute the security program consistently that is the cause.

As I said earlier, all security programs are the bare minimum for security. As a result, in order to be secure an organization needs to go beyond the requirements specified by any security program. Unfortunately, it is the rare organization that goes beyond any of the recognized security programs. Why? For most organizations, the security personnel just do not have the time to develop their security program beyond what is already called out by ISO 27K or PCI DSS. Some of this is due to staffing issues, but more often than not, it is due to a lack of upper management recognition and understanding of what true security really takes in personnel, time and other resources. A lot of that lack of understanding comes from the organization’s risk assessment or more likely the lack of one. Without a good understanding of the information security risks to the organization, it is very hard to determine what measures need to be taken, why they need to be taken and what resources are necessary. Once everyone can understand the risks, then a true security program can be developed for the organization taking into account the PCI DSS, ISO 27K or any other security standards that need to be followed.

Finally, compliance programs are never ever static. They need to be constantly adjusted to reflect the introduction of new technologies, changes to the existing environment and the removal of technologies.

For example, if an organization implements a new security information and event management (SIEM) solution, the compliance program needs to be changed to reflect that new SIEM. The most likely changes are the addition of new conditions that will be monitored for and alerts generated. The compliance program needs to add those new conditions to their testing and make sure that alerts are truly generated when the conditions are encountered. In addition, if the new SIEM introduces any changes to existing alerts, those changes also need to be adjusted in the compliance testing. Finally, if some SIEM conditions are being removed, the compliance program needs to reflect that removal as well.

Changes to the environment also need to be reflected in the compliance program. Application changes can result in changes to the compliance program particularly if the application controls its own authentication processes, encryption of sensitive data and other critical controls. Another area is network changes that also need to be reflected in a compliance program. While adding new physical locations is typically only a minor change to a compliance program, changing firewalls, routers or switches can result in significant changes to the compliance program.

One of the biggest things neglected with compliance is when technology is removed from the environment. Nine times out of 10, the compliance team is never notified of the decommissioning of equipment. Security professionals might think that compliance is not affected if something is removed. However the control environment might be significantly affected with the removal of technology because security is unaware of other areas that are relying on a technology for controls. Then once the compliance team comes out for their assessment they find that, with the removal of certain technology, there are now numerous controls that are no longer performing as designed and security gaps exist as a result.

An example of a change that can adversely affect compliance but is typically overlooked is staff reductions. One of my clients a number of years ago terminated a number of personnel in an effort to save costs. A couple of the staff let go were performing manual processes that were critical to monitoring the security environment and identifying security issues that were critical to their PCI compliance efforts. Management believed that these people were superfluous to their operation, i.e., a nice way of saying they were unnecessary overhead, so they were terminated. Obviously when these people were terminated, those critical controls were no longer functioning. To add insult to injury, this situation was not identified until almost 10 months later during their PCI compliance assessment. Then the organization had only two months to somehow put these critical controls back into place without the necessary resources to do them manually. What eventually happened was that people had to step up and add these tasks to their own already heavy workloads. While that got the organization through their PCI assessment for the current period, the stress of keeping those controls operating as designed proved to be too much and some people quit creating new control failure situations. Ultimately management had to admit that more people were needed as well as some new tools were necessary to minimize control failures as well as minimize the number of people required.

The bottom line is that the compliance assessment process is the check and balance to make sure that an organization’s security program is designed appropriately and is functioning effectively. Hopefully you now have an appreciation as to the purpose of an effective compliance program and why it is important to the overall security process.

So the next time you say that “compliance is not security” think about this post and understand the implications of your statement. Without the compliance process, you have no idea as to whether your security program is effective or not.


Why Security Fails

I am writing this more than anything because I am dreading taking my lawn mower apart to replace the cable that engages the self-propulsion system. From what I have seen online, some sadistic engineer has made this an ugly job of taking the bottom end of the mower mostly apart just to get to the drive system to unhook the cable in the first place. But I digress.

The primary reason security fails at most organizations is the level of complexity involved in their IT. Organizations have legacy systems, other internal systems, outsourced systems, cloud solutions and a sundry variety of third parties and business partners. With all of these solutions in play, is it any wonder why organizations cannot identify whether or not they have been breached? Where do you start and where do you end? How do you determine if it is a false positive or real? It is such a hard task in fact, that no one wants to or has the time to take the effort to research every incident or they do only cursory research resulting in what they think happened.

Next to complexity the next reason security fails is the reliance on security tools. It is not that tools are not important, but there is mistaken belief that tools are all that you need to be secure. Tools are necessary to identify and focus personnel on potential issues, but tools by themselves are not the complete answer. All security professionals have to do is look to the ubiquitous intrusion prevention system (IPS) that almost every organization has as the prime example of a tool that does not live up to its potential. IPSs are installed but are hardly ever enabled to actually prevent intrusions nor can they truly prevent all intrusions even when fully enabled.

But tools bring other issues. You have organizations that seem to have every security tool under the sun. Now let us be clear here. Organizations may have lots of security tools; however in my experience very few of those tools are ever fully implemented. There are lots of reasons for this but one of the biggest is the revolving door of security leadership. A leader comes in and they have their own security vendor alliances and push their vendor tool agenda. However, that leader either moves on or gets ejected and the next security leader comes along with their security tool world view. As a result, organizations acquire a lot of tools but none are ever fully implemented because of the leadership revolving door.

The second reason security tools tend to miss full implementation is that the implementation runs into significant issues that halt or slow their implementation. There are two reasons for this situation. The first is vendor hyperbole about their solution. My example of the IPS is a prime example of hyperbole. How many IPSs were bought under the promise that it was a “silver bullet” solution?

The second reason tools miss full implementation goes back to the first reason security fails – the complexity of the environment. Environmental complexity makes implementation of anything difficult and, in some cases, impossible. In the case of security tools, the most common situation that stymies a tool’s rollout is the acquisition of a new company. Resources get reallocated to the acquisition and when the fire drill is over, people have forgotten about the tool implementation that was going on before that drill. In the end, the tools do not fully integrate into the environment for whatever reason and therefore leaves gaps in coverage.

But the last reason tools fail is due to a lack of ongoing care and feeding. The tool gets implemented and then gets turned over to the team that will keep it functioning into the future. As time goes on people rotate through the area, training on the tool is not kept up, maintenance on the tool suffers and slowly but surely the tool becomes ineffective.

My favorite example of this was a SIEM implementation at one of my clients. When it first went in it was amazing what it identified both from a security perspective, but also a variety of operational issues that had never had any exposure. However over the next five years, the SIEM system became a backwater for security. There was a belief by IT and security management that the SIEM was somehow self-managing and did not need high caliber personnel. That last year I reviewed the SIEM I was interviewing one of the personnel responsible for it and they said that they had practically tuned out all of the false positives. I inquired why and was shown in the demonstration of the SIEM. Sure enough, very few alerts were even generated and those were few and far between. But then it became alarmingly clear as to why when the person pulled up the systems network map generated by the tool. Most of the corporate network was missing. Further review of the SIEM generated diagram indicated that the organization’s move from their corporate data center to a better equipped co-location facility had apparently not been reflected in the SIEM. How this occurred was a discussion over the next months and it was never clear how the ball got dropped.

Then there are the organizational culture issues. A lot of personnel seem more interested in trying to dodge responsibility and accountability like it is the plague. The more I encounter this attitude, the more I think this behavior can be traced to employers making their employees feel like they are a dime a dozen and can be replaced on demand. But I also believe it is a result of the ugly corporate cultures that have been created over the last couple of decades.

There is no denying that some organizations have created corporate cultures that stress “dog eat dog”, “step over the bodies” and similar tactics if you intend to get ahead. I chalk this up to Jack Welch and his GE corporate culture which he claimed weeded out all but the best of the best. But it is also the result of our own culture and society through reality shows like ‘Survivor’, ‘The Apprentice’, ‘Big Brother’ and similar shows that glorify underhandedness and other questionable tactics versus the virtue of pure teamwork to getting ahead. Because these corporate cultures want people to go after one another, is it even possible that any progress is accomplished in corporations. That is because everyone is so scared of being attacked and losing their job, they do anything to avoid that possibility by tossing anyone else under the bus at the first sign of trouble. It rapidly devolves into a gross and disgusting exercise in a swirling mess of finger pointing and the “Blame Game”.

You then add into this toxic environment IT Operations and/or IT Security personnel who are culturally emasculated thanks to that terrific previously discussed corporate culture borrowed from GE. These people care, but only to a point. The culture just implies that the boss will end your career if you ever bring them “bad news” because people are a dime a dozen. All this results in a situation where people might recognize an alert or something awry, but are reluctant to bring it to anyone’s attention because of the adverse consequences that will likely result. After all, it is the low level minions that get let go first in these situations long before the CISO or CSO. And those minions do not get the great golden parachutes that higher ups get. So why should they bother to put their necks out?

All you have to do is to take a look at the Neiman Marcus and Target breaches. In both cases security operations personnel received alerts indicating something might be wrong. In both cases, these personnel wrote off those alerts and moved on. According to the media, at least in the case of Target these personnel notified higher ups who in turn contacted their security solutions providers and then those people were told to ignore the alerts because they were likely false positive results. However, such a response reinforces the misconception that the tools are not factual when more research should be done to prove that fact.

A long time ago, I paraphrased Tom Hanks’ character Jimmy Dugan in the movie ‘A League of their Own’. “Security is supposed to be hard. If it wasn’t hard, everyone would do it.” Security is hard enough even without all of the other barriers some organizations put in the way.

As a result, is it any wonder that organizations outsource security to a managed service provider? Outsourcing takes security out of the corporate culture and away from internal politics. It also puts all of the tool implementation responsibilities on the outsourcer’s back, not your organization. As long as the outsourcer is kept in the loop regarding changes to the environment, you can have much better assurance that your environment is actually being monitored. And that is where most outsourcing arrangements end up going bad is that the outsourcer is unware of changes made and therefore cannot maintain security because now there are gaps.

Regardless of whether you outsource or you get your organization to own up to the responsibilities required to maintain security, security requires a significant commitment of any organization.

Oh and for those of you that ended up curious about the outcome of my lawn mower project. I finally stepped up after writing this post and got the drive cable replaced. It turned out to be quite the project, but thanks to the Internet and a few postings by people, I had a decent path to follow. The hardest part of the project was that the aforementioned sadistic engineer mounted the cable attachment on the top of the drive mechanism making it a true exercise in patience and manual dexterity to reconnect the new drive cable to the transmission. It took more time to get just that one task done than the teardown and reassembly processes. However, I now have a self-propelled lawn mower again.


They Are Just Words

QSAs get asked a lot of “what ifs”.

  • If I do ‘A’, will that result in ‘B’?
  • What if I do ‘C’, will that accomplish ‘D’?
  • If I do ‘E’, will that cause ‘F’?

Where this really hits hard is when an organization is trying to reduce scope in their cardholder data environment (CDE). Another area where this becomes problematic is when organizations are re-architecting their networks and want to take into account PCI or any other regulatory or security requirements. Nine times out of ten, the client wants a QSA to review the new network architecture and “bless it” as PCI compliant. We can discuss scope reduction strategies all day long but, until they are implemented and physically exist, they are all just a theory. And as I like to famously say, “In theory, theory works.”

I know this frustrates organizations, but the essence of PCI compliance is validation. A QSA can review proposed network architectures and state that they “appear” that they will be PCI compliant, but the proof is in the implementation. It is only when the organization can provide all of the configurations and penetration testing results for review that a QSA can then determine the PCI compliance of a network and the related devices.

So the next time you are asking your QSA a hypothetical question, do not get all wound up when the QSA responds with what appears to be a lame, “weasel worded” sounding answer. Until you provide concrete evidence, it is all just words, pretty pictures and a thought exercise.


Optiv Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (, and click on the 'Check Out Our Openings' button and apply.

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.


November 2015
« Oct    

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

Join 1,398 other followers


Get every new post delivered to your Inbox.

Join 1,398 other followers