Principal Security Consultant
Jeff Hall is a principal consultant in Optiv’s advisory services practice on the Payment Card Industry (PCI) compliance team. Jeff’s role is to provide post-sales support and consulting to Optiv’s clients as well as providing support and mentoring to other Optiv team members. He has more than 30 years of experience in project management, information security, information security strategic planning, software evaluation, selection and implementation, voice and data networking, systems analysis and design, information system audit, systems programming, and data center operations.
What You Should Take Away From The PCI DSS 3.0 – Part 1
There are a lot of people and organizations pointing to “business as usual” or BAU as the huge take away from the latest version of the PCI DSS. Yet according to the PCI SSC in their recent statements regarding BAU at the 2013 Community Meetings, BAU is only a suggestion, not a requirement of the new version of the PCI DSS.
Based on my look at the new PCI DSS, here is where I would be focusing my time preparing for the next iteration of the PCI DSS.
SAD vs. CHD
Go through and read v3 and you will see references everywhere to “sensitive authentication data,” or SAD, instead of the usual cardholder data or CHD. In the PCI Glossary for the PCI DSS v2, SAD is defined as:
“Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data, PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.”
Whereas in the same Glossary cardholder data (CHD) is defined as:
“At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code”
The reason for this change in nomenclature, based on discussions at the 2013 Community Meetings, is because of the increasing threat of memory scraper attacks that are looking for SAD in terminals, POS devices and anywhere else that SAD exists in the processing of card transactions regardless of however brief.
As a result, the Council is now focusing everyone on protecting any and all information related to the processing of card transactions, not just CHD after a transaction is processed. For those organizations doing the bare minimum of complying with the existing PCI DSS, this will likely create a larger issue as you go to v3.
Related to the SAD change is requirement 9.9 which for the moment is a best practice until 2015. This new requirement states:
“Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
Note: These requirements apply to cardreading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.”
This requirement is the result of numerous breaches that were the result of tampered card terminals and other devices that come into contact with the card. Over the years, card terminals and card readers have been found with USB drives soldered inside to collect track/chip data and PINs. More sophisticated techniques have involved the modification of software that runs these terminals and collects the track/chip data and PINs before the point-to-point encryption (P2PE) solution can encrypt the data. Devices are used to intercept the communication between the POS keyboard where the card is swiped and the PC where the data is encrypted to send on for processing the transaction.
Solutions to address this requirement will include:
- Mounting terminals in a locked cradle with keys only provided to the manager on duty. Almost all terminal swaps occur after a retail facility is closed so ensuring that the terminals are locked down minimizes the possibility that people swap the terminals after hours.
- Placing serialized security tape over the seams of the card terminal so that if they are opened the serialized security tape is obviously broken. The reason serialized tape is used is so that the serial number on the tape can be checked and matched to the retail outlet’s records. Basic security tape is easy to obtain, but with a serial number, the tape is much harder to replace or fake.
- Placing serialized security tape over the wires or connectors inside of card readers in gas pumps and similar devices or over the cables that connect terminal devices to PCs.
- Reviewing and logging, at least daily, the serialized security tape for tampering and taking questionable equipment out of service until it can be proven to be secure. A lot of my clients that follow this process do the review of all of the serialized security tapes at each manager shift change.
- Video monitoring of all terminals for tampering including hours when the retail operation is closed. Again, almost all of the terminal swaps occur during overnights when shelves are being restocked or the facility is being cleaned by outsiders and management cannot be as diligent in watching what everyone is doing.
- Only replacing card equipment with the approval of management outside of the retail facility. In a number of cases, the bad guys shipped doctored terminals to the retail outlet with instructions to swap it with a good terminal under the guise that the good terminal was producing errors. Had someone called a help desk or someone outside of the store, the issue probably would have been identified before a breach occurred.
I have had a number of clients that have been caught in various terminal schemes and all ended up implementing a variety of the above to minimize the risk. These changes did not occur overnight and typically took at least a year to get up and running smoothly. So depending on the size and sophistication of your operation, implementing any or all of these will likely take time to get engrained in your daily procedures. As a result, most organizations will need to start planning the rollout of these sorts of procedures now in order to make the June 30, 2015 deadline.
Data Flow Diagrams
The first requirement that I guarantee organizations will struggle with is not new and must be dealt with immediately if you want a v3 Report On Compliance (ROC). For v3, the Council has decided to integrate the network and data flow diagrams and they make that integration mandatory for requirement 1.1.3.
Any QSA worth their salt can tell you why this is being done. It is driven by the fact of scoping being such an issue. No one ever seems to know just exactly how SAD flows across a network anymore. Today’s data flow diagrams can be obtuse pictures that have more of a relationship to modern art than they do to a network. As a result, it is anyone’s guess as to how a transaction gets from a website, card terminal or POS to an acquirer and then how it gets to its storage location.
Talk to developers, and they typically cannot tell you all or sometimes even any of the ports/services their applications use let alone how the data gets from their application to wherever and back. To them it can seem like magic.
Talk to the networking folks, and they tell you they are just a utility to provide the transport mechanisms between endpoints.
Talk to the security folks, and they just open ports/services on firewalls and ACLs based on getting requests for applications to work properly.
As a result, is it surprising that organizations have such a problem with identifying their category 2 connected systems when trying to define scope?
To address this mess, the Council has stepped in and decided to fix this situation by requiring the data flow and networking diagrams to be integrated so that everyone understands how the SAD navigates the network.
I can tell you from my years as a QSA that this is going to create a huge issue for a lot of organizations because, at a minimum, their application developers, networking and security folks are going to have to figure this all out. This effort will likely result in a rather rude awaking for some and take a while to get a useable deliverable.
The good news is that, for probably the first time, these organizations will have an actual understanding of how some of their data flows through their network. And once they have that understanding they will finally be able to come up with a realistic inventory of those category 2 systems.
If anything, requirement 1.1.3 will likely drive the sales and development of automated network diagramming and data flow analysis solutions due to the complexity of most organizations’ networks. This diagram will be needed for you to comply with some other requirements that I will discuss later. So if you do not get this diagram done, you will be unable to comply with other requirements.
Another requirement that will create problems is 7.1.1. Requirement 7.1.1 states:
“Define access needs for each role, including:
- System components and data resources that each role needs to access for their job function
- Level of privilege required (for example, user, administrator, etc.) for accessing resources.”
This goes beyond just providing your QSA a listing of users. The PCI SSC is expecting organizations to document each class of user, the devices they have access, the data they have access, the level of privilege required for access and business purpose for that access. I envision a spreadsheet matrix to explain all of this information.
However, for organizations that are not as clearly organized, it is probably going to take a while to develop such a document or may be nearly impossible to develop such a document. As a result, this is another requirement that should be developed as soon as possible so that it is available before June 30, 2015.