Jeff Schorr

What Is Requirement 9.9 Actually Asking A Merchant To Do? Part 2

Last week, I posted the first in a three part series on the new PCI DSS 3.0, requirement 9.9. This addition to the DSS 3.0 is a best practice until June 30, 2015, after which it becomes enforceable for compliance.

Today's post is all about the second sub-requirement, 9.9.2, which covers device inspection.

In several product demonstrations I’ve done recently, the customers have remarked something similar to:

“Boy, that sounds like a lot of work. Do we actually have to inspect every device?”

The answer to that question is an emphatic yes. The best way to ensure no tampering is happening is by having a human look at each device to confirm:

1) It is in your inventory
2) It is in the location where you expect it to be
3) It is free of any signs of tampering

Here's what the actual requirement states:

9.9.2 = INSPECTION

Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

The word “periodically” here can be read as “regular” and “consistent.” This is because if the devices aren’t being inspected on a set schedule, in the same way each time, inconsistencies across these checks could cause important signs of tampering to be missed.

Now, how to figure out what is the correct period of the inspections?
The SSC has provided a nice resource to help you figure out at exactly what frequency you should be inspecting your devices in the "Skimming Prevention: Best Practices for Merchants" document. Appendix A, starting on page 30, is a questionnaire that will assist in assessing the risk (high/medium/low) of a particular location which then corresponds with a timeframe.

Coalfire's "Complying with PCI-DSS Requirement 9.9" white paper provides a baseline recommendation on what a high/medium/low risk should translate into in terms of frequency. Their recommendations are daily for a high risk location, weekly for a medium risk, and monthly for a low risk.

Your particular location or business type may call for tweaking this reccomendation - for example, some gas merchants might choose to inspect at each shift change (their business type is a well known target for skimming). At the end of the day, you'll have to justify your choice of frequency to your QSA.

Then how do you make each inspection consistent?
There are two ways. The first is by utilizing highly skilled, security-focused employees who know exactly what to look for and how to go about inspecting devices.

The second is to create a template for inspection (an example is provided in Appendix B of the Skimming Prevention document) that walks the inspector through each step and highlights what they need to look for. This allows anyone in your organization to perform the inspections at any time. If data is collected in the right way around each inspection, then everything is available for that highly skilled security employee to review, if necessary.

So what about the actual inspection?
First, you'll want to check the device's unique identifier to confirm what you're looking at is the asset you think it is.

Once this is confirmed, next is checking for any tampering.

There are different places on each device type that are points of attack. For example, on a gas pump you would want to check the card swipe/dip, the receipt door, maintenance door, and PIN pad. Or if using a system like a Clover or Ziosk, which utilize encrypting readers, the only point of attack - thus the only point needing inspection - is the card swipe. On your particular set of assets, it is important to identify and inspect these areas of that are weak against attacks, as well as generally looking at the entire devices for any scratches, holes, peeled stickers or other signs of someone messing with the asset.

Inspecting the environment near the device is important as well.
Reviewing the area around the asset, looking for signs that remote cameras have been installed and/or if there are unexpected charity boxes or merchandising that could be hiding bluetooth skimmers will further ensure the safety and security of your devices.

Recording the data around inspections.
Finally, whether you choose to use a log book, excel spreadsheet, or other tool, you'll want to collect and recording the inspection data and results of each inspection. At a minimum you should be recording:

  • Who inspected the device
  • The location of the inspection
  • The date and time
  • Confirmation of the asset's unique identifier
  • Answers to inspection questions
  • Comments on any inconsistencies or concerns

Ultimately, you want to be able to provide all of this data to your QSA to prove your compliance and be able to track down the source of an incident, if one ever occurs.

Next week, I'm going to cover the final piece of the requirement, 9.9.3 which covers policy and training around the inventory and inspections.

Header image by nolifebeforecoffee, used under CC 2.0

What Is Requirement 9.9 Actually Asking A Merchant To Do? Part 1

In order to assist merchants that have to meet this requirement, several independent organizations have already published white papers, most of which are available on our resources page. However, over the last week or two, the conversations I’ve had with customers and others have indicated that a little more clarification would be helpful.

So, today's post starts a series that dives deeper into 9.9, its sub-requirements, and the nuances of the mandate. Our founder, Vasu, will be jumping in as well to help make this as clear as possible. 

Here we go:

9.9 = PHYSICAL SECURITY OF DEVICES

Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

So what does “direct physical interaction” mean? In the payments world, that would be all the devices used for “card present” transactions. These devices definitely include the standard payment terminals (customer facing or not), kiosks, self-checkout lanes, etc.

Now, how do we go about protecting these devices? According to the requirement, it's by creating an inventory of the devices (9.9.1), physically inspecting them (9.9.2), and empowering staff with training (9.9.3). 

But I’ll get to that in a second. I want to pause here to mention that within this requirement is the mandate for completely new organizational policy, procedure, and process. It’s worth stating again - since this was never required before, the creation and implementation of new policies, trainings, and in-store process is necessary. Thus the extra six months.

9.9.1 = INVENTORY

Maintain an up-to-date list of devices. The list should include the following:
  • Make, model of device. 
  • Location of device (for example, the address of the site or facility where the device is located).
  • Device serial number or other method of unique identification.

There are several tracking mechanisms that can be used including many of the device management tools to maintain this inventory.

Keep in mind though; inventory needs to aid inspection. As an example, if we had a tool that was taking only a logical inventory of all the devices and it wasn’t verifiable physically, it would be pretty pointless when it comes to this requirement.

So it doesn’t matter what tool you choose, make sure that your inventory is physically verifiable. 

This makes sense as you think about it. The logical component is ensuring protection of card data by tying something about the payment device to something in your environment (like a serial number, a digital signature of the payment terminal, etc.). A human, during the inspection process, needs to be able to walk around and ensure that what the computer “thinks” it’s tracking is the same thing that is actually, physically there. 

In Part II and Part III we will talk about how to tie this logical inventory to a physically verifiable activity and the considerations that go with it. Stay tuned.

Be sure not to miss a post by subscribing to get the blog delivered directly to your inbox.

Start Here - A Primer on PCI DSS 9.9

While the hot news around the PCI DSS recently has been the declaration that SSL is dead and speculation on what DSS 3.1 will look like, another major change in the standard is swiftly approaching. As of July 1, 2015, the PCI DSS requirement 9.9, which covers the physical security of "Point of Interaction" (POI) devices, moves from a best practice to an enforceable requirement.

If you haven't started planning for it yet, there is no time like the present. And to help you get a better understanding of the requirement, we bring you another expert resource, compliments of HALOCK Security Labs.

This white paper, called Complying with PCI-DSS Requirement 9.9 - A QSA's Perspective, is a look at the why, what, and how of this portion of the DSS.

While a smaller subset of the overall standard, this new addition can translate into a large effort.

As noted in the opening of the white paper, "Organizations are now expected to train personnel to look for suspicious activity with all physical devices. This is a major change, as previous versions of the DSS did not require any point of interaction inspections whatsoever." Organizational policy and behavioral change is always difficult, but with the right tools, it can be manageable.

Get your planning started by downloading the white paper and talk to your QSA (HALOCK can be reached here) about what compliance with 9.9 means for your organization today.

INFOGRAPHIC - Skimming Update

Here at Termtegrity, we are passionate about skimming. Borderline obessed even. So when we looked at the data we had gathered over the past 13 months on skimming incidents, both here in the US and abroad, we thought it made for some pretty interesting statistics.

We compiled this data from all the publicly available news reports we've tracked over the last year and created the infographic below.

What it shows reinforces the statment that the PCI Security Standards Council made by adding requirement 9.9 to the Data Security Standard version 3.0, that skimming is a relevant fraud tactic that merchants should be protecting themselves against.

If you have any questions about the infographic or want to learn more about how our SpotSkim tool is helping merchants protect themselves and comply with requirement 9.9 contact us here or connect with us on Twitter at @Termtegrity.

Skimming Infographic

New resource: Sysnet's view of what 9.9 means for merchants

As we draw closer to July 1, 2015 - the date PCI DSS requirement 9.9 moves from a best practice to an enforceable requirement - industry experts continue to weigh in with their perspective on what the new portion of the standard will mean for merchants.

One of our first partners, Sysnet Global Solutions, who specialize in PCI DSS compliance validation and merchant intelligence solutions, have been leaders in thinking and talking about what 9.9 means.

Their new white paper "PCI DSS v3.0: A closer look at Requirement 9.9 - Payment Terminal Protection" author Jason McWhirr, CISSP takes a look at just what the requirement is asking and what you'll need to do to comply.

The main focus of the piece is to spell out exactly what is needed to comply, which he breaks into the following catagories:

1) Inventory – Know what you have, and who is responsible
2) Risk – Know how exposed your payment devices are
3) Train – Know what to look for and who to report to
4) Inspect – Checking the terminals
5) Evidence – Maintain a record of inspections, findings, and incidents

At the end of the paper, he presents a useful list of companies and tools that could help a merchant with compliance (of which our SpotSkim is one). You can download the paper here.

If you haven't started planning for the requirement yet, now is the time. Contact us today to see how SpotSkim makes it as easy as possible to comply with PCI DSS requirement 9.9.

Hot off the digital presses! New PCI DSS 9.9 Resource

The Doomsday Clock recently ticked closer to midnight. While not nearly as perilous, heading into February also marks the swift approach of another countdown – the compliance date for PCI DSS 3, requirement 9.9. Currently a best practice, after June 30 this year, merchants will be expected to comply with the requirement.

To this point, many of the merchants that we talk to here at Termtegrity have yet to really delve into what compliance with 9.9 will mean for them. It’s another item on the list. But it is an item that becomes more complex as the size of your organization grows and will likely require organizational operational change.

Luckily, this is top of mind for industry thought leaders, who have begun talking about what the implications of this requirement are for merchants and how to start thinking to prepare for July 1.

One of the leading experts in the industry, Dr. Branden Williams (who literally wrote the book on PCI compliance) has just published a white paper called “Preventing Terminal Tampering – An Examination of the Business Impacts of Requirement 9.9” which takes a step back from the nitty-gritty of the requirement and looks at business level consequences and what you can do to manage the new requirement.

In it, he gives advice on various methods of compliance and discusses the challenges that merchants of all sizes will face. It’s both comprehensive and practical, and definitely worth taking the time to read.

You can obtain a copy of the whitepaper on our site (after a short registration) and while you’re at it, take a second to follow @BrandenWilliams on twitter to get Branden’s unfiltered view on PCI, life, and everything in-between.

The feature image above was created by Mike Mozart of JeepersMedia and is licensed under a Creative Commons Attribution 4.0 International License.

I’m Dreaming of a White(paper) Christmas

Christmas came a little bit early this year. Last Friday, our friends over at Coalfire published an excellent whitepaper titled “Complying with PCI-DSS Requirement 9.9 - A Qualified Security Assessor’s Perspective” that is a thought provoking and practical look at the implications the requirement will have on merchants.

If you're not aware of it yet, requirement 9 covers physical security of the point-of-sale (POS) terminals in a merchant environment. Requirement 9.9 is brand new and deals explicitly with the prevention of POS device tampering or substitution.

Collectively called “skimming,” these attacks are on the rise and can be easy to miss until it’s too late. But not if you have a good process and procedures in place for regularly, consistently inspecting your devices.

So between sips of eggnog and the “It’s a Wonderful Life” reruns (or my personal favorite – “A Christmas Story”) take a few minutes to read this short paper. – you can get it here.

When the deadline for complying with PCI DSS version 3.0 and all its changes hits on July 1, 2015, you’ll be glad you started thinking about it now.

And from all of us here at Termtegrity, have a safe and joyful holiday season!