Author Archive for PCI Guru


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.


A Better Mouse Trap?

I had the pleasure of recently talking to David Marsyla, CEO of PocketKey ( about their new solution to secure card transactions. PocketKey is an independent attempt to address security issues with card transactions, particularly card-not-present (CNP) transactions such as those related to eCommerce. If any security solution was needed, it is in the CNP space.

While PocketKey seems to provide a very secure method of conducting transactions, during our conversation, I expressed my concerns about their business model.

  • We have seen this before. Back around the turn of the century, Visa, MasterCard and American Express all flirted with similar schemes that required their EMV cards to be inserted into a serial device connected to a PC to be used online. Unfortunately, very few Web sites ever supported their application programming interfaces (API) so these solutions disappeared as quickly as they had been rolled out.
  • It is not as portable as I would have hoped. PocketKey needs to be plugged into your PC, smartphone or other device that can provide Internet access. If an application on your device supports the PocketKey API, then the application can store the encrypted CHD information from the PocketKey for use in future transactions.
  • It requires application changes. In order for PocketKey to work, applications must be modified to handle the PocketKey API to get the full potential out of the solution. This means that PocketKey needs to get application providers on board for their solution to be implemented. In my very humble opinion, the best solution is one that does not require any application changes at the merchant end.
  • It requires the cooperation of transaction gateways, processors or banks. Not only do applications need to be addressed, but then card transaction gateways, processors or banks need to support PocketKey to work because the encrypted data generated by PocketKey needs to be converted at some point to actual cardholder data (CHD) for approval.
  • EMV provides similar capabilities. EMV cards have the ability to secure transactions through the use of dynamic primary account numbers (PAN), dynamic card verification values (CVV) and other security features. However these capabilities also require changes with applications as well as with transaction gateways, processors or acquiring banks in order to work. Do not be surprised if once the US EMV roll out is completed that, wonder of wonders, Visa and MasterCard then tout these “new” security features and push for their implementation by merchants, gateways, processors and banks.

It is not that these limitations cannot be surmounted so much as they require cooperation within the application and transaction processing communities to make it work. It is nice to see that someone is trying do something to address fraud problems. Card present fraud is almost a thing of the past and will be once magnetic stripes are completely gone (still a long time before this happens). However CNP fraud continues to grow as attackers find it the only way to quickly monetize their illegally obtained CHD.

I wish PocketKey all the best and hope they attract the necessary partnerships to make their business model work.


The Third Party Dilemma

I am starting to see more and more of this situation with my mid-size and larger clients, the third party that is using the client’s network to process and transmit cardholder data (CHD).

Where I consistently encounter this are at internal cafeterias where a third party operates the cafeteria and is providing their own point of sale (POS) solution to process card transactions. Another example where this is common are mailrooms that are operated by third parties and employees can buy stamps and ship personal packages with the third party taking cards for payment. Finally, another place where this is common is health care facilities, particularly hospitals, where the cafeteria is operated by a third party, the gift shop is operated by another third party, the pharmacy is operated by a third party and so on. As we go forward, I would expect that this situation will become more and more commonplace as organizations outsource more and more back office functions to third parties and focus on their core business.

A lot of these third parties have ended up on clients’ networks. They may or may not have been segmented away from the rest of the client’s network, but they typically sit behind the clients’ firewalls and other security measures. With the focus on requirements 12.8 and 12.9 regarding the management of third parties, these outsourcing environments are receiving new scrutiny as clients begin reassessing how these third parties are provided network and Internet access as well as PCI compliance, contract and other regulatory and legal issues.

So what are your options if you are involved in such arrangements? Here are some thoughts.

  • Ignore the problem and hope it goes away. Yes, believe it or not there are a lot of organizations that have found out that their organization is chock full of such situations and have just tossed up their hands and have decided to put off addressing the issue. Unfortunately, if the organization is required to perform a PCI assessment, this is not an option and they end up having to address it as part of their own assessment. Unfortunately, the problem does not go away because the third parties ask for an AOC of the organization for the network services they are providing.
  • Wide Area Ethernet. In this scenario, your organization becomes a telecommunications carrier providing Internet access to any third party over a separate WAN. This requires Ethernet WAN or Metro Ethernet equipment that support WAN grade service versus LAN grade service. Third parties are provided access to the Internet but must provide their own infrastructure such as firewalls and switches. The bottom line is that your organization becomes no different than any other carrier such as Verizon or AT&T and will be out of scope.
  • Wide Area Wi-Fi. Similar to Wide Area Ethernet using the same WAN infrastructure equipment but using Wi-Fi (802.11a/b/g/n/ac) to deliver network access. While this avoids installation of wiring infrastructure, it means a separate secured Wi-Fi network from your existing Wi-Fi. In addition, depending on how it is engineered, it could suffer from device overload if all of your third parties are in the same general area of your facility. But as with Wide Area Ethernet, your organization is considered a carrier and out of scope.
  • Another wireless alternative is putting your third parties on cellular connections. Where this can be problematic is in facilities that have poor cellular connectivity. In these situations, the organization may have installed cellular repeaters for carriers throughout the facility to improve cellular signals. However, not all of the facility may have repeater coverage where the third parties are located so there could be additional costs involved to get the coverage needed. Like Wi-Fi, cellular repeaters have limitations on the total number of connected devices, so areas where employees and the third parties congregate such as cafeterias could have issues with cellular access at breakfast, lunch and dinner times. This can be mitigated, but could create service issues for all users at heavy usage times.
  • P2PE or E2EE. Use of either of these solutions depends on your third party’s ability to use such a solution with their POS. With these solutions, you can create a separate VLAN for your third parties and they can all attached their points of interaction (POI, aka card terminals) to that VLAN and the traffic will be encrypted out to their respective processors. Where this solution does not work is when the third party uses a POS solution that does not support P2PE/E2EE. In addition, if all your third parties do not support P2PE/E2EE you may have to have a second solution for them. So it may be simpler to use one of the other solutions for consistency.
  • Physically Separate Third Party Network. This is a feasible option if you want to avoid the Wide Area equipment costs and requirements. However, the equipment used must be physically separate from your existing LAN equipment so as to qualify as being considered a carrier versus a service provider. As with the Wide Area solutions, you will not be providing firewalls or any other security services, just access to the Internet. Any security measures on this network would be the responsibility of each third party.
  • Separate Third Party VLAN. This is the option I typically encounter in most organizations. The organization’s network has a VLAN separate from its other networks but still relying on the organization’s infrastructure. The problem here is that this is not a carrier network because it is not physically separate from the internal network. Yes, there are ACLs in place that isolate the VLAN from others, but the infrastructure is shared and could come into scope if changes cause that to happen. This can still be acceptable if all third party traffic is encrypted such as with a VPN or P2PE/E2EE. But where this solution gets into trouble is when the organization providing the VLAN is also doing the encryption on behalf of the third parties. In the end, a VLAN solution will have to be assessed as a service provider because the organization is providing network access as a service not as a carrier.
  • Contract with their own carriers. This is an option, but potentially a rather messy option. That is because your third parties will need to contract with their own carrier which could create a wiring nightmare in your facilities. Particularly when new third parties come in or change carriers. There are ways to manage this but it requires planning and working with your third parties to make this effort successful.

These approaches all have their pluses and minuses, but hopefully you now have some ideas as to how to handle this issue.


Pushing The Limits

Here are some situations that QSAs encounter way too often.

  • Organizations that conduct their annual penetration test 30 days before the deadline to file their self-assessment questionnaire (SAQ) or Report On Compliance (ROC).
  • Organizations that conduct their final quarter vulnerability scan 30 days before the deadline to file their SAQ or ROC.
  • Organizations that decide to implement a compensating control worksheet (CCW) within 30 days before the deadline to file their SAQ or ROC.

Why are these situations a problem?

For the first two conditions, it is because if any of these results in a remediation effort, you either (a) have to remediate the findings and retest before filing your SAQ/ROC or (b) you have to put compensating controls in place and test those to ensure you are mitigating the risk of not remediating. Both of these situations can easily result in missing an organization’s compliance filing date.

For any CCW, it is a problem because you need to test all of the controls you are using to compensate for not being able to comply with a requirement and prove they are functioning as designed. In a lot of cases, those controls are going to be new controls and will take time to implement and then test.

While this “fire drill” is going on, your QSA sits and waits for you to complete remediation or implement your compensating controls so that they can test things and ensure that you are in compliance. Unfortunately, while your QSA waits, the stress of getting things done accumulates and people lash out at the QSA for their organization’s poor planning with the expectation that the QSA will just look the other way.

As a QSA, I would really like to help you. But as the old adage goes, poor planning on your part does not create an emergency on my part. Unfortunately, clients never see it that way when they are trying to hit a deadline, but it is still true.

So the way to minimize these situations is to plan ahead. Make sure that your annual penetration test is conducted no later than the start of the fourth quarter of your reporting period. This will give you around 90 days to address any issues and retest. For vulnerability scanning, I would also highly recommend doing your final quarterly vulnerability scan no later than the start of the fourth quarter of your reporting period as well for the same reason. These both are particularly true if your organization has a history of not getting passing results.

For CCWs, you want your QSA to identify those as soon as possible so that you can work on getting the controls in place and functioning. As a result, you should schedule your assessment to start no later than the third quarter of your reporting period and as early in that quarter as possible. If your organization is large, you may even want to start in the second quarter of your reporting period.

If you have CCWs in place and you will keep them in place for your coming assessment, you should be conduct your own testing prior to your QSA arriving to make sure you can fix any out of compliance situations.

So before you chew off the head of your QSA for some self-inflicted wound, think about how you got into this predicament. Next year plan better and your assessment will likely go better.


FishNet 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 (, search for 'PCI' 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.


October 2015
« Sep    

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

Join 1,360 other followers


Get every new post delivered to your Inbox.

Join 1,360 other followers