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

Remember that old adage about "teaching a person to fish?" That's pretty much what the third and final subsection of the new PCI DSS requirement 9.9 covers.

The 9.9.3 requirement states:

Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:

• Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices. granting them access to modify or troubleshoot devices.
• Do not install replace or return devices without verification.
• Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
• Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

There are a few things here to consider.

• In order to provide training to employees, a formal policy is needed
• The formal policy isn't just written down, but is also disseminated to all the relevant employees; in this case, the front line employees
• Perhaps bundling this in your store's Standard Operating Procedure is a great way to start

When thinking about creating policy and training, they will need to cover scenarios such as:

• Will you ask front line employees to check the ID of the human who shows up to work on a device or ask them to call a manager?
• How does the manager know whether or not the person is supposed to be there?
• What does "suspicious behavior" mean?
• What is the mechanism for employees to report this suspicious behavior?
• What are the review and actions based on these reported incidents?
• Who is responsible, and accountable for them?

For this requirement, just ensuring your security staff is aware is not enough. In order for it to be effective, each person that works in a location where customers can swipe their credit cards needs to have read and acknowledged this policy and be trained on how to implement it. For this, there are several alternatives:

• If you already have a training program in place around PCI compliance and a procedure for updating the content, creating and adding a section on requirement 9.9 should suffice.
• There are organizations like our partner LiquidNexxus that are PCI certified trainers who also can create custom training for your organization.
• In SpotSkim, we've added both policy and training into the app. This allows for easy dissemination of information and tracking as the employee reviews and acknowledges both the policy and training.

Once you have created and rolled out the policy and training, the testing procedure for your QSA is to review the training and ensure it includes everything stated in the requirement. Once they validate the training, the QSA will select a sample of employees to interview to ensure they understand the policy and procedures found in the training.

Tracking and being able to report on when employees were presented with the policy and training will make this process much easier.

If you'd like to hear more about the requirement or have questions, Coalfire is hosting a webinar on April 28, 2015 at 2pm Eastern to review requirement 9.9 and answer attendee inquires. You can register for the session here.

Header image photo credit to Colynn used under CC 2.0.

PCI DSS 3.1, Requirement 9.9 Changes

PCI DSS just released 3.1. As an organization that is focused on 9.9 specifically, we thought we'd provide you, our customers and prospects, some guidance around changes and what we believe to be the rationale.

You can grab the summary of changes on the PCI Website, and a copy of the standard v3.1 here.

Please keep in mind, we are only covering the 9.9 section changes here, and not anything else. As always, your assessor may have a different opinion than what is presented here. Here is our perspective.

So what exactly are the changes?

The changes specifically state the following:

Updated testing procedure to clarify both devices and device locations need to be observed.

What does this mean?

In general any testing procedures apply during assessment phase. So imagine your assessor is sitting in front of you, they would be asking you the following question:

"You have 1000 stores. Can we take a sample of this, this, and this other store. I'd like to see a list of devices currently in these stores, and how, when, and by whom have they been Inspected in the past year."

What is the rationale?

Your assessor is looking for the following information, which makes sense (in our minds anyway):

1. Sample of Devices to make sure that the Device Information is correct:

   • Do we know the current status of this particular device?
   • What do we know about the history of the device?
   • Do we know where it is and where it has been?

2. Sample of Locations to make sure that Location Information is correct:

   • What do we think the number of devices are in this location?
   • Does our thinking match reality?
   • How did we come up with an Inspection Period for this location in the first place?

The point of this exercise to reconcile the two facts together to get to the following conclusion (in the assessor's mind):

"If we think that this location x has 10 devices and can positively verify that the number is exactly 10; no-more, no-less...

and

If we think that each device that is in this location is supposed-to-be Inspected on a daily basis and can validate that...

then

We are reasonably certain that all locations are following almost exactly the same process."

If you are a math geek like me you might even call this Proof by Induction.

Customers that are using SpotSkim are covered. This clarification doesn't add anything new to what the solution provided already. As always we continue to make improvements to make your process more consistent, faster, and cheaper. If you are a customer and are worried about what these changes mean to you - please feel free to reach out to us using the Support section of the portal.

If you are not a customer and are interested in learning more about SpotSkim, you can contact us here.

Header image by Nana B Agyei, used under CC 2.0

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.

Subscribe to our blog

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.

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!