Service Provider PCI Compliance Process

As a recent question pointed out to me, while service providers now seem to understand they need to be PCI compliant, they do not seem to understand the process under which they assess their PCI compliance.  As a result, I thought I would use this space to clarify this process.

When Do I Have To Be PCI Compliant?

The PCI SSC defines a Service Provider in the PCI DSS Glossary as:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data.  This also includes companies that provide services that control or could impact the security of cardholder data.  Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities.  Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.”

On the straight forward side of this definition, if your organization processes, stores or transmits cardholder data on behalf of one or more other organizations, your organization is considered a service provider and needs to be PCI compliant.  That point seems to be clear and most organizations that are processing cardholder data for others understand this fact.

It is organization that do not directly process, store or transmit cardholder data but could impact the security of cardholder data that get tripped up.  The bottom line is, any third party that has access to an organization’s cardholder data environment (CDE) needs to be PCI compliant for those services offered that come into contact with the CDE.

Based on this definition, the following are examples of services would need to be PCI compliant.  This is not a complete list but something to assist you in understanding why your organization might need to be PCI compliant.

• Management of firewalls that are considered part of an organization’s CDE.
• Management of networks that carry cardholder data that is not encrypted.
• Management of encrypted networks that carry cardholder data and the MSP manages the encryption keys for encrypting the network.
• Management of servers that process, store or transmit cardholder data.
• Management of PCs that have access to cardholder data.
• Management of applications that process, store or transmit cardholder data.

The first question service providers typically ask is, “How am I supposed to know if my customer needs our services to be PCI compliant?”  My rather indignant response is, “What, you cannot ask them?”

If you are a service provider and you are providing any value added services, you need to be asking every customer about their regulatory or legal requirements when going through the sales and contract processes.  It is not just PCI these days, but in the US there is HIPAA, GLBA, SOX and there all sorts of similar requirements in various parts of the world that you should be finding out whether your prospects need to comply.  If you are not, then you are sitting on a potential legal time bomb should something happen and your value add services are deemed the culprit.

SAQ D or ROC?

Service providers are broken into two levels, Level 1 service providers and Level 2 service providers.  Level 1 service providers are those that process more than 300,000 Visa, MasterCard or Discover transactions annually and are required to perform a full PCI assessment using a qualified security assessor (QSA) that results in a Report On Compliance (ROC).  Level 2 service providers are those that process 300,000 annual transactions or less and they can conduct their own assessment using the SAQ D.  SAQ D is the only SAQ that service providers are allowed to use.

The first issue most MSPs face is determining what parts of the ROC or SAQ are relevant.  There are no easy answers in this area as it all comes down to those value added services you are providing and how you provide those services.  However, before you can determine what parts of the ROC or SAQ are relevant, you need to determine the services that are to be assessed.

Where MSPs can miss the boat is taking the lowest common denominator approach and only assessing those value added services that all customers need to be PCI compliant.  Typically this results in an AOC that discusses physical security (requirement 9) and security policies (requirement 12).  If you take the lowest common denominator approach, then do not complain when each of your customers’ QSA have to traipse through your facilities and disrupt operations over the value added services you did not cover in your AOC.

The best approach is to assess all value added services you provide so that you do not have to worry about whether or not a given service is PCI compliant.  The reason this is important is that customers are required to make sure that all service providers that need to be PCI compliant are PCI compliant.  It is not that customers cannot work with non-PCI compliant service providers; it is just a lot easier to work with PCI compliant service providers.  The reason is that non-PCI compliant service providers have to be annually assessed as part of the customer’s PCI assessment as well as the customer is supposed to be monitoring the service provider’s PCI compliant efforts.  As a result, you will have an easier time and be easier to deal with if all of your value added services are PCI compliant.

Now back to what parts of the PCI DSS are relevant.  There are too many permutations of services and PCI requirements to go into this for every possible situation, so I am just going to provide some examples.

If you are providing firewall management services, then you are going to have to comply with requirements 1, 2, 4 (if your organization is managing any transport encryption), 5 (the PCs/servers used to manage the firewalls), 6 (change control for the PCs, servers and firewalls), 7, 8, 9, 10 (log management and analysis for the PCs, servers and firewalls), 11 (PCs, servers and firewalls) and 12.  Some tests in these sections may be Not Applicable for your organization, but you will need to go through all of the tests in the sections.

If you are managing applications such as in a software as a service (SaaS) environment, you are going to have to comply with requirements 1 (if you manage any firewalls or routers that could be in-scope), 2 (servers, firewalls, routers, switches), 3 (if your application encrypts the cardholder data), 4 (if your network encrypts cardholder data), 5 (servers running the application as well as any support PCs and servers), 6 (change management as well as any software development), 7, 8, 9, 10, 11 and 12.  Some tests in these sections may be Not Applicable for your organization, but you will need to go through all of the tests in the sections.

As you can see, even a “minor” service such as managing firewalls can require a significant amount of effort to be PCI compliant.

Do I Need A QSA?

A Qualified Security Assessor (QSA) is only required if: (1) your organization is considered a Level 1 service provider, or (2) you wish to have your organization listed on Visa’s Global Registry of Service Providers or with the MasterCard Registration Program (MRP).  In both of these cases, you will need to hire a QSA and produce a Report On Compliance (ROC) and Attestation Of Compliance (AOC).  If you can answer ‘No’ to both of these, then you can do your own assessment using the SAQ D.

Scope Of Assessment

At the 2012 PCI Community Meetings, the PCI SSC clarified scoping for PCI assessments.  The PCI SSC stated that:

“To be considered entirely out of scope, a network or system must be isolated from, with no connectivity into, the CDE (such that even if the system is “owned”, it cannot impact the security of the CDE).
If connections are limited to specific ports or services, those systems are included in PCI DSS scope to verify applicable controls are in place.
Applicable PCI DSS controls may vary for in-scope systems depending on the function of the system and presence of other controls.”

As a result, any of your systems that have access into a customer’s CDE are in-scope for compliance as they could be used to access the CDE.  This does not mean that these systems need to meet all of the requirements of the PCI DSS.  But it does mean that they need to be evaluated to determine those portions of the PCI DSS that do apply.  All of this is dependent on the potential to access cardholder data inside the CDE.

To minimize the impact of this clarification, we are seeing a lot of MSPs using “jump boxes,” PCs that do nothing but provide access into the systems to be monitored or managed.  This provides an air gap between the MSPs internal systems and the customer’s environment, including the CDE.  As a result, the jump boxes need to be PCI compliant and the internal systems at the MSP just need to have current anti-virus and anti-malware and be properly authenticated.

Hopefully this post helps all of you managed service providers that are facing PCI compliance.

This post was revised after a review by Walt Conway at 403Labs pointed out some inaccuracies.  A big thank you to Walt for his diligent eye.

Who Would Have Thought?

I never thought when I started this blog that I would have to write this type of post.

Apparently, my writing has attracted someone, maybe more, but at least one person I am aware of that decided to call my post their own on their own blog.

They say imitation is the sincerest form of flattery.  But this is not imitation, this is plagiarism and that is illegal.  I requested the individual remove the post in question and I would call it a day – no harm, no foul.  However, I have no response back and the post is still on their blog.  As a result, I feel I have no choice but to write this post and call this person out for their illegal act.

If this does not do the trick, then I guess I will have no choice but to resort to legal action.

UPDATE: October 27, 2012 – I checked the blog link and now it appears to be original, although the topic is still PCI-based.  So call off the mob with the torches, apparently he got the message.  Although the post makes it obvious that this person has never secured a VoIP installation because some of the recommendations make no sense and are very risky.

UPDATE: October 30, 2012 – I was officially notified by Google that the “offending post” has been taken down.

The Failure Of PCI?

Steve Sommers of Shift4 has posted an interesting take on the PCI DSS and its value to merchants and service providers, particularly in the wake of the Global Payments breach.  Steve has asked me to comment on his post and here is my take.

This quote speaks to the frustration a lot of merchants and service providers feel.

“The only thing PCI did was round up a bunch of existing security best practices, compile them into lists, and publish these lists as “guidance” documents.”

No doubt about it, the PCI DSS is an amalgam of various security “best practices” bundled together and published by the PCI SSC.  I remember back in 2003 when the PCI DSS was the Visa CISP, fresh off the presses as an Excel spreadsheet, still embedded with the review comments from Visa and the consultants that created the CISP.

But what are the card brands to do?  Breaches are occurring all over the place when they start down this road.  The media reports that so many Visa or MasterCard accounts are breached and then they talk about the merchant or service provider involved.  Visa and MasterCard are trying to protect their brand names because studies show that the public remembers the card brand names, but quickly forget the names of the merchants or service providers breached.  As a result, they feel the need to develop guidelines to protect cardholder data to minimize the number and sizes of breaches.

Was life better when Visa, MasterCard, American Express, Discover and JCB all had their own individual standards?  You all complain now about one ROC or SAQ, how would you like to be filling out a different form for each card brand every year?  I would guess your answer is a huge ‘No’.

But the bigger question is, if not the PCI DSS, then what standard?  ISO 27002?  FISMA?  FFIEC?  HIPAA HITECH?  I have yet to find a security standard that everyone can agree on, let alone agree to follow.  People complain about every one of the information security standards.  And then there is that ugly mantra of “compliance is not security,” but I have already covered that ground.  So see my posts on why I think that saying is just a dodge.

All security standards are just a starting point or ante into the game.  A number of friends of mine have all remarked that their security programs only have to be a little bit better than everyone else’s to keep them off the target list.  However, that is the key; you need to be better than the other guy.  But will the other guy tell you what he is doing when he has the same strategy?  Standards like the PCI DSS give you that benchmark to start from so you know where you need to be better than the rest.

But the biggest problem with standards all comes down to the fact that humans are really averse to being measured or assessed against a standard.  Why?  It makes people responsible and accountable for what they do and few people want that sort of accountability – we all much prefer “wiggle room” in how our jobs are assessed.

“Then the card brands attached fines and penalties to punish merchants if they failed to comply with PCI “guidance” 100% of the time.”

“To me, the issue is this: PCI SSC promotes their work as “best practices” or ”guidance”,  and then the card brands turn around and flog merchants for not following them when they are breached.”

Steve is right on the mark with these statements.  As he stated earlier in his post and what I frequently state here, security is not perfect.  All security does is reduce the risk of a breach but does not remove that risk in its entirety.  As a result, even with PCI DSS compliance, breaches will still occur, but the goal is to make them much less frequent and a number of orders of magnitude smaller in the amount of data released.

This brings us to the heavy handedness in how the card brands handle breaches.  All I can say is that some of my friends in the forensics field are telling me that there are a number of breaches that they have investigated that were not the result of PCI non-compliance.  So Visa and PCI SSC GM Russo need to back off on their statement that “No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach.”  According to my sources, this is patently not true anymore and the card brands are not happy about that fact.

The card brands, in particular Visa, seem to refuse the premise that security is not perfect and keep pushing that the PCI DSS, if followed to the letter, is the solution to breaches.  None of this is the truth and security professionals know those facts.  As a result, we end up with media quotes from the card brands, PCI SSC representatives and security professionals that are at times out and out asinine.  Until we can all come to grips with these facts, we will continue to be playing a game of spin.  And spin get us nowhere.

“I personally believe that PCI is written in such a way – and interpretations among QSAs vary so much – as to make it impossible for anyone to be 100% compliant 100% of the time.”

The flexibility in the PCI DSS is there because security professionals and their employers would not have it any other way.  Would you prefer a dictatorial standard that specifically calls out solutions and vendors?  What would people be saying if only Cisco and Juniper firewalls, routers and switches were allowed?  What would Microsoft say if Windows was not allowed?  What would other vendors say if only MICROS POS solutions were approved?  What if only VLANs with specific ACLs were the only allowed method of network segmentation?  Can you say lawsuits?

The bigger problem that the PCI SSC needs to address is the QSA/ISA training.  A lot of QSAs are great technologists, but would not know a good or bad control environment if it bit them in the posterior.  Fewer QSAs and most ISAs know controls, but would not know a proper firewall or router configuration to save their lives.  And finally, there are a very, very few QSAs and some ISAs that know the technology and controls.  Unfortunately, the PCI SSC has not found the way to winnow out the QSAs and ISAs so that only the ones that know both technology and controls remain.

But even in such a perfect world, each QSAC has its own tolerance of risk.  As a result, what is PCI DSS compliant to one QSAC is not necessarily going to be acceptable to another QSAC because of the risk they are being asked to accept.  Firms like mine are fairly risk averse, so we are going to be more demanding when it comes to what is PCI compliant than other QSACs.  But by the same token, I do not believe we are unreasonable in what we demand for PCI compliance.

At the end of the day, while the PCI DSS is not perfect, it does provide the following benefits to merchants and service providers.

• It provides a way to help everyone learn from the other guy’s mistakes.  As attack tactics change, so do the PCI standards to address tactics that might not be covered.
• It gives everyone the baseline of what they need to execute 24x7x365 if they even think they have a better than average chance at security.

Prior to the PCI DSS, Visa CISP and the other standards, it was a crap shoot as to whether or not an organization’s security was going to be up to snuff.  I do not think that is where anyone wants to go.

Steve, I understand your frustration and the frustration and pain of merchants and service providers.  But if what I have stated here is not a net positive, I do not know what is.  Is it perfect?  Nothing in the world is perfect.  But there are some changes that would improve the program and make it seem much less painful and frustrating.  We just need to continue to work on the PCI SSC and the card brands to see the light and make the necessary changes.

More On PCI Scoping

Everyone that is going through the PCI compliance process tries to get systems, processes, whatever, out of scope.  And while getting things out of scope is a good thing, it does not mean that they do not need to be assessed.  And this is one of the most contentious points of a PCI compliance assessment.

One of the biggest misconceptions about the PCI compliance assessment process is that, just because an organization says that something is out of scope, does not mean that it does not have to be examined.  The PCI compliance assessment process is all about trust, but verify.  So, when an organization says that a particular element is out of scope, it is up to their QSA to confirm that the item is, in fact, out of scope.

Take for example network segmentation that is used to delineate an organization’s cardholder data environment (CDE).  A QSA is required to confirm that the network segmentation implemented does in fact keep the CDE logically or physically separated from the rest of an organization.  That confirmation process will likely review firewall rules, access control lists and other controls on the network to prove that the CDE is segregated.  And going through these items can sometimes result in a lot of QSA effort, particularly as network complexity increases.

Another area where the out of scope effort can be messy is in the area of applications and whether they process, store or transmit cardholder data.  Proving that an application does not store cardholder data is typically fairly straight forward.  The QSA just examines the data schemas for files and databases looking for fields named credit card number or any 16 character fields.  A QSA will also typically run queries against the database looking for 16 digit numbers that start with known BINs.  I have been involved in a number of assessments where we have found cardholder data being stored in text and comment fields through our queries.  Determining whether an application is processing or transmitting cardholder data is more complicated and problematic.  It can take a quite a lot of effort to determine using an organization’s Quality Assurance or Testing facilities, but it can be accomplished.

The biggest clarification for v2.0 of the PCI DSS is that it is the responsibility of the organization being assessed to prove that their CDE is in fact accurate.  This had always been the implicit case, but with v2.0 of the PCI DSS, the PCI SSC has explicitly stated this fact.  Page 11 of the PCI DSS states:

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.”

As a result, the organization being assessed should provide proof to their QSA that they have taken an examination of all of their processes, automated and manual, and have determined what is in-scope and out of scope.  The results of this self examination are used by the QSA to confirm that the CDE definition, as documented by the organization, is accurate.

This clarification has resulted in a lot of questions.  The primary of which is along the lines of, “How am I supposed to prove that I have assessed my entire environment and made sure the CDE is the only place where cardholder data exists?”  While the implications of this question are obvious for the Wal*Mart’s and Best Buy’s of the world, even small and midsized merchants can have difficulties meeting this requirement.  And I can assure you that even the “big boys” with their data loss prevention and other solutions are not hyped on scanning every server and workstation they have for cardholder data (CHD).

For determining whether or not CHD is present in flat files on computers, there are a number of open source (i.e., “free”) solutions.  While I discuss a lot of tools and share my experiences, this is not an endorsement of any particular tool.

At the simplest are the following tools.

• ccsrch – (http://ccsrch.sourceforge.net/) – If this is not the original credit card search utility, it should be.  ccsrch identifies unencrypted and numerically contiguous primary account numbers (PAN) and credit card track data on Windows or UNIX operating systems.  One of the biggest shortcomings of ccsrch is that it will not run over a network, so scanning multiple computers is a chore.  The other big shortcoming of ccsrch is that unless the data is in clear text in the file, ccsrch will not identify it.  As a result, file formats such as PDF, Word and Excel could contain CHD and may not necessarily be recognized.  It has been my experience that ccsrch tosses back a high number of false positive results due to its file format limitations and therefore recognizing data that is not a PAN as a PAN.
• Find_SSNs – (http://security.vt.edu/resources_and_information/find_ssns.html) – While the file name seems to imply it only searches for social security numbers, it also searches for PANs and will do so for a variety of file formats such as Word, Excel, PDFs, etc.  Find_SSNs runs on a variety of Windows and UNIX platforms, but as with ccsrch, it does not run over a network; it must be run machine by machine.  Find_SSNs seems to have a very low false positive rate.
• SENF – (https://senf.security.utexas.edu/) – Sensitive Number Finder (SENF) is a Java application developed at the University of Texas.  If a computer runs Java, it will run SENF so it is relatively platform independent and supports many file formats similar to Find_SSNs.  That said, as with the previous tools, SENF will not run over a network, it must run on each individual machine.  I have found SENF to have a much lower false positive rate than ccsrch, but not as low as either Find_SSNs or Spider.
• Spider – (http://www2.cit.cornell.edu/security/tools/) – This used to be my favorite utility for finding PANs.  Spider will scan multiple computers over a network, albeit slowly and the fact that it has a propensity for crashing when run over the network.  However, it also seems to have a low false positive rate that is comparable to Find_SSNs.

I still use Spider and Find_SSNs for scanning log and debug files for PANs as I have yet to find anything as simple, fast and reasonably accurate when dealing with flat text files.  And yes, I use both as checks against each other for further reducing the false positive rate.  It amazes me, as well as my clients, the amount of incidental and occasional CHD that we find in log and debug files due to mis-configuration of applications and vendors who forget to turn off debugging mode after researching problems.

But I am sure a lot of you are saying, “Flat files?  Who stores anything in flat files these days?”  And that is the biggest issue with the aforementioned open source solutions; none of them will scan a database from a table schema perspective.  If the database data store does coincidentally store clear text PANs as legible text, the aforementioned utilities will find it but that is pretty rare due to data compression, indexing and other issues with some database management systems.  As such, if you wanted to stay with open source, you had to be willing to use their code as a base and adapt it to scanning a particular database and table schemas unless you were willing to go to a commercial solution.  That is until OpenDLP (http://code.google.com/p/opendlp/).

OpenDLP is my personal open source favorite now for a number of reasons.  First, it uses Regular Expressions (RegEx) so you can use it to look not only for PANs, but a whole host of other information as long as it conforms to something that can be described programmatically such as social security numbers, driver’s license numbers, account numbers, etc.  Secondly, it will also scan Microsoft SQL Server and MySQL databases.  And finally, it will scan reliably over the network without an agent on Windows (over SMB) and UNIX systems (over SSH using sshfs).

At least I have gotten fewer client complaints over OpenDLP than I have for Spider for network scanning.  That said, OpenDLP can still tie up a server or workstation while it scans it remotely and it will really tie up a server running SQL Server or MySQL.  As such, you really need to plan ahead for scanning so that it is done overnight, after backups, etc.  And do not expect to scan everything all at once unless you have only a few systems to scan.  It can take a week or more for even small organizations.

But what if you have Oracle, DB/2, Sybase or some other database management system?  Unless you are willing to take the OpenDLP source code and modify it for your particular data base management system, I am afraid you are only left with commercial solutions such as Application Security Inc.’s .DbProtect, Identity Finder DLP, ControlCase Data Discovery or Symantec Data Loss Prevention.  Not that these solutions handle every database management system, but they do handle more than one database vendor and some handle most of them.

You should now have some ideas of how to scope your CDE so that you are prepared for your next PCI assessment.

How Many People Does It Take?

There are a lot of jokes that start with the phrase, “How many people does it take …”  But this post is no joke.  I have been taking some heat over my comment that you do not need to know who is attacking you, you only need to focus on what you need to protect.  As such, I felt the need to further explain myself.

The first complaint I get is that it is important for security professionals to know the tactics used by the attacker.

So my first question to all of you is, “How many people does it take to analyze attack vectors?”

We have forensic security organizations such as Verizon, Trustwave and Security Metrics that analyze attacks.  We have security companies such as IBM/ISS, Symantec, Kaspersky and McAfee that analyze attacks.  We have hardware/software vendors such as Checkpoint, Microsoft, Cisco and Palo Alto that analyze attacks.  I would venture to say there are hundreds of reliable sources for the analysis of attacks.  And yet, I am taken to task that you need to have your own analysis of attacks.  These hundreds of other sources just are not enough for you to rely on?  Really?  If you are doing the correct analysis of your vulnerability scanning and penetration testing reports, your attack vector risks should be known and you should have either patched or developed mitigations for those risks.

And while they might be put together in a slightly different sequence, DDoS is still DDoS and a SQL Injection is still a SQL Injection.  The bottom line is that the library of exploits available to an attacker is essentially finite.  This is proven out by the statistics that the forensic firms publish year after year.  As such, you should be able to monitor for all of these attacks fairly easily because they are all known quantities.  Yes, there is the rare Zero-Day that turns up every so often.  But, even those can be picked up if you have things configured and implemented properly.  If you think about it, unless an attacker is someone that can develop their own exploit code (and 99% do not), they are limited to whatever exploits are available in the public domain of exploits and that is a known quantity.  Take an inventory of what is available in Metasploit or Core Impact at any fixed point in time and you will see what I mean.

Then there is the group that argues that if you do not do analysis of the attacker, you cannot understand why you are being attacked.

So my second question is, “How many people does it take to give you an idea of why you are being attacked?”

This is pretty straight forward to figure out without some extensive and intensive analysis.  In 99% of cases, you are being attacked for one or more of the following reasons.

• Your organization has sensitive information such as credit card numbers, bank account numbers, intellectual property or customer information that the attackers want.
• Your organization has produced a product or service that has been perceived to be a safety hazard, overpriced or other detriment to society.
• Your organization or an employee has publicly taken a stance on some issue(s) that has irritated some group(s) of people.
• Your organization has donated money, time, products or services to an organization viewed by some group(s) of people as questionable.

Read the reports published by the forensic firms.  Read the news reports in the media.  If you distill down that information, the reasons for attacks break down into these four basic reasons.  Yet, security professionals continue to worry about the motivations of the attacker.  If you think your attack is unique, you are wasting your time.  The likelihood of your attack not being covered by these four primary reasons is slim to none.

I think these complaints just come down to the fact that doing the actual grunt work of security is just not very sexy work.  There is no doubt about that fact.  Ensuring the security of networks 24x7x365 is very, very monotonous work.  And it is that very monotony that is one of the primary reasons why organizations get breached.  People get bored with the monotony and they start to cut corners on procedures because, in their view, nothing is going on and, therefore, nothing will go on.  Only rotation of people and tasks will address the monotony, but that only works for so long.

This is why security professionals turn to automated tools to minimize reliance on people to flag potential anomalies.  Without tools, people get bored very quickly searching for the “needle in the haystack” through all of the data produced by all of the devices on your network.  However, even with all of the necessary tools, correlation of information still requires people to bring all of the anomalies recognized by the tools together and determine if all of these anomalies warrant further investigation.

Even with the necessary tools, you are not out of the woods.  One of the more common problems that we encounter is that organizations have not completely implemented those tools.  How many of you invested in the cool intrusion prevention system and still run it in notification mode?  Even then, those organizations that do completely implement the tools, do not always keep up on the “care and feeding” of the tools to ensure that the tools recognize the anomalies.  The tools are current and up to date, but anomalies are not recognized because the tools are not properly configured and tuned to the organization’s current network configuration.  Networks are not the static environments that a lot of people think they are.  As a result, either the number of false positives is so high that personnel ignore the voluminous number of alerts generated or anomalies are just never identified by the tools.

It is not until someone finally recognizes an anomaly for a breach that it finally gets interesting.  Then things become very interesting in a hurry.  Unfortunately, the statistics from the forensic firms point to the fact that, if an anomaly does get recognized, it is often many months to years down the road from the original compromise.

And that is where security professionals need to get better.  If you look at how long it took TJX to recognize their breach (years) versus how long it took Global Payments (months, but still counting), we are headed in the right direction.  But when it takes attackers only minutes, hours or even days to get your information, months still does not cut it.  We need to get to days or, better yet, minutes.  That is the challenge security professionals face and that is where we need to focus our efforts.

The PCI DSS is a good foundation, but the requirements of the PCI DSS are not going to get us to our goal.  We must go beyond the PCI DSS to get to our goal and that is a message that the PCI SSC and the card brands have consistently delivered.  The PCI DSS is only a security baseline, the ante into the game.  If you really want to be the best, you need to take your security game beyond the PCI DSS.

So let us start using the PCI DSS properly.  If your organization can execute the requirements of the PCI DSS 24x7x365 at almost 100% compliance, then you are ready to take things to the next level.  If you cannot achieve almost 100% compliance, then you need to work with your organization to get to that level.  Breaches and data loss are never going to go away, but if all organizations followed this approach, the number of breaches and amount of data lost would significantly drop.

Cannot Say It Better

If you read nothing else this week, you need to read this posting by Daniel E. Geer, Jr., Sc.D.

People in the Loop: Are They a Failsafe or a Liability?

PCI SSC Opens SIG Voting

All of you representatives of participating organizations (PO), the PCI SSC has opened elections for the coming year’s SIGs.  Just a friendly reminder for all POs to exercise their right to vote on the SIGs.  I am guessing that the voting page is behind the PO logon to the PCI SSC Web site.  They announce the results of the balloting on November 4, so vote as soon as possible.

This Year’s PCI SSC SIG Proposals

At the Special Interest Group (SIG) session at this year’s PCI Community Meeting, a number of presentations were made regarding the potential PCI SIG topics that will be addressed in the coming year.

The session was structured where the people that created the SIG proposal presented the reason for their proposal and then took questions from the session attendees regarding their proposal.  The PCI SSC received 31 proposals for SIGs this year.  Of those, 13 made a short list and seven were selected as finalists to be voted upon.  The SIG finalist topics for 2011 are:

• Administrative Access to Systems and Devices
• Guidance on Risk Assessments
• Level 3 and 4 e-Commerce Merchant compliance guidance
• Hosting and Managed Service Providers Guidance for Small Business
• Cloud Technology v2.0 – a follow on to last year’s SIG
• Patch Management
• Small Business PCI Compliance Guidelines

Once a similar session is held at the European Community Meeting, the PCI SSC will announce the SIG voting period.  Participating Organizations (PO) will then vote on the SIG proposals and on November 4, 2011 the PCI SSC will announce the SIG winners.  Once the winners are announced, QSAs, ASVs, and POs can apply to be members of the SIG of their choice through December 2011.

With that said, here is my take on this year’s SIG topics.

Administrative Access to Systems and Devices

This SIG is to be created to develop an Information Supplement that explains the options organizations have to comply with PCI DSS requirement 2.3 for securing non-console access to systems and devices.  This is a regular topic of discussion at almost every organization trying to comply with the PCI standards.  Based on the number of questions requirement 2.3 generates, there are a similar number of possible solutions.  This was probably one of the better SIG proposals presented in my opinion.

Guidance on Risk Assessments

This SIG is to be created to develop an Information Supplement to guide merchants and service providers in what should be the result of a proper risk assessment, not create another risk assessment methodology or framework.

While such an Information Supplement is an admirable ideal, anyone that has ever tried to use OCTAVE, NIST 800-30, ISO 27005 or any other risk assessment framework, you understand why this SIG is a losing proposition.

The problem with every risk assessment methodology or framework I have ever seen is that, while they will identify an organization’s risks, they are unwieldy and take too much effort to get to those answers, if the organization even gets to answers.  As a result, most risk assessments are either never completed or are so out of date by the time they are delivered, they are useless.

This is a problem that the various governance focused standards bodies and professional associations really need to address.  In my opinion, until these governance organizations address the shortcomings of the risk assessment process and develop a more manageable process, this SIG should be put on a back burner.

Level 3 and 4 e-Commerce Merchant Compliance Guidance

The purpose of this SIG is to develop a checklist that will guide Level 3 and 4 merchants to understand their options of using e-Commerce solutions.  The people presenting this SIG proposal made a very good argument that most small merchants have no idea of how ISPs/ASPs provide e-Commerce solutions, let alone what they need to ask these third parties in regards to PCI compliance.

I have to say, given the interactions I have had over the years with various third party service providers, such a checklist would not only serve Level 3 and 4 merchants, but would also provide the third parities with an idea of what their responsibilities are when it comes to PCI compliance.

Hosting and Managed Service Providers Guidance for Small Business

This SIG would develop a checklist for small business on what to look for regarding hosting and managed service providers.  This SIG is not as focused on a particular level of merchant, but is meant to provide guidance to all merchants.  It is also focused on all types of third party services, not just e-Commerce solutions providers.  In my opinion, this SIG should be combined with the previous SIG.

Cloud Technology v2.0

This SIG is to be a follow on to last year’s original Cloud SIG.  It would develop another Information Supplement regarding hybrid Clouds.

Cloud computing is such a problem these days because even IT personnel do not understand “The Cloud,” let alone non-IT personnel.  And it certainly does not help when there are all of the Cloud solution vendors that further obfuscate the definition issue by having their own take on what “The Cloud” is and is not.  As a result, almost any third party solution can get classified as a Cloud solution.

The problem I had with this SIG presentation is that they really did not define what was meant by a “hybrid Cloud.”  Not that you should blame them as I do not think the industry could define this term.  As a result, I am skeptical as to the value of this SIG.

Patch Management

This SIG would create an Information Supplement on patch management.  For QSAs, we have already been given guidance on this topic.  As a result, this SIG should be handled very quickly as all they need to do is write the Information Supplement and disband.  Why the PCI SSC could not create this Information Supplement is beyond me.

Small Business PCI Compliance Guidelines

This SIG presentation seemed to cover a lot of the ground covered by the Level 3/4 merchant e-Commerce SIG.  The twist here was to develop an Information Supplement or guide for small businesses to guide them through the PCI compliance process.

In my opinion, what might be a better way to address this issue would be to produce one or more videos that small business owners could watch over the Internet to educate them on PCI compliance.  The program could be modularized based on the type of merchant, so they would only have to view those topics relevant to their business.

Those are the SIG proposals for this year.  It was a tough session to cover as there was a lot of information to cover in the 15 minutes that the presenters were allowed.  So I apologize ahead of time if I misunderstood anyone’s proposal.  Hopefully in the next couple of weeks the presentations will get posted to the PCI SSC Web site so that they can be downloaded.

More Requirements That Cannot Be Marked ‘Not Applicable’

In the August 2011 issue of the PCI SSC’s Assessor Update, there is an article titled ‘Checking for SAD’, with SAD meaning sensitive authentication data.  In this article, the PCI SSC is telling QSAs that PCI DSS requirements 3.2.1, 3.2.2 and 3.2.3 cannot be marked as ‘Not Applicable’.  These are in addition to PCI DSS requirements 1.2.3 and 11.1 that I earlier wrote about being unable to mark as ‘Not Applicable’.

To refresh everyone’s memory, the PCI DSS requirements in question are as follows.

3.2.1 For a sample of system components, examine data sources, including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored under any circumstance

3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card-verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance

3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored under any circumstance

The rationale being used by the PCI SSC for not allowing these requirements to be not applicable is as follows.

”These requirements are a fundamental part of the Standards and each review must fully account for all Sensitive Authentication Data (SAD) that may enter the assessed environment or application.”

I have been hearing comments from QSAs questioning the relevance of this clarification in outsourced environments or environments totally operated through bank-owned terminals and networks.  My interpretation of why the PCI SSC is clarifying these requirements is to ensure that QSAs are confirming that outsourced environments truly are out of scope.

The QSAs complaining the most seem to be those that conduct assessments in Asia and Australia.  In these parts of the world, the banks own the terminals and operate the networks that the terminals connect.  As a result, cardholder data never comes into contact with the merchant’s systems.

What I am sure concerns the PCI SSC is the fact that the merchant’s POS system can have a serial or USB connection to the bank-owned terminal.  While the serial/USB connection can provide the bank-owned terminals network access and the POS with cardholder data, in Asia and Australia, this connection is for the transfer of the total of the receipt to the terminal from the POS and the passing of the acceptance or decline of the charge from the terminal to the POS.  What I am sure concerns the PCI SSC is, what, if anything, did the QSA do to confirm that the connection only did just that?

However, I can also understand the position some QSAs’ are taking questioning this clarification.  Particularly in those situations where there is no connection between the POS and bank-owned terminal and the terminal’s network, not an uncommon condition in Asia and Australia.  It is in those situations that I would have to say there is a strong argument to allow for a ‘Not Applicable’ with an explanation that the terminal is bank owned and does not connect to the merchant’s network or POS.

Just another topic for discussion at the Community Meeting.

UPDATE: At the 2011 PCI Community Meeting, this was discussed and clarified by the PCI SSC. What is expected is that the QSA will discuss the steps that the QSA took to determine that this was ‘Not Applicable’ but they do not want these requirements marked ‘Not Applicable’.  Their rationale is that a QSA would have to have conducted some sort of assessment procedures to determine that these requirements are ‘Not Applicable’ and those procedures are what they want documented.

Should the PCI Guru allow for “Guest” Postings?

I am going to try out the WordPress PollDaddy feature to collect your thoughts on this topic.  I have had a number of requests lately asking for time to post to the PCI Guru blog on PCI topics.  These requests have come from individuals as well as security vendors.  I have some reservations, but I wanted to get the readership to respond on this topic.  So, let us try this out.  The poll will be open for one month.