Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

1/29/2014
01:20 PM
Doug Landoll
Doug Landoll
Commentary
50%
50%

For SMBs: How To Implement PCI DSS 3

How PCI DSS v3.0 requirements affect the management of service providers for SMBs

Second installment in a series

2013 was not only a year of multiple major breaches exposing cardholder data (CHD), but also a year in which the Payment Card Industry Security Standards Council (PCI SSC) released the next major revision to the Payment Card Industry Data Security Standard: Version 3.0.

PCI DSS v3.0 changes are largely aimed at misinterpretations and misapplications of requirements meant to reduce the risk of such attacks. There are some "evolving requirements" (read: new requirements) in this new version, but mostly version 3.0 addresses a general lack of awareness and appropriate implementation of existing requirements.

Small and midsize businesses (SMBs) implementing PCI DSS typically do not require a Qualified Security Assessor (QSA), and may either implement these requirements on their own or with the help of a security consultant. This series of blogs is aimed at those planning their 2014 PCI DSS strategy with three distinct and important themes found in PCI DSS 3.0.

PCI DSS 3.0 For SMBs Theme 2: Third Party Management: PCI merchants, especially SMBs, rely on external organizations to supply services as part of their e-commerce and information technologies. Managing third parties, or service providers, begins with identification.

Identifying Service Providers: Let’s start with the definition of service providers: "Business entity (other than payment brand) directly involved in the processing, storage, or transmission of cardholder data." This includes hosted or managed firewalls and intrusion detection systems (IDS), hosted websites, data center providers, payment gateways, outsourced customer service functions, independent sales organizations, and transaction processors. This list may be longer than many merchants had expected -- and that’s the point. Service providers are not limited to organizations with whom CHD is shared, but also any service provider that could affect the security of CHD (e.g., vendor providing physical security of data center).

Organizations must start with a complete understanding of the CHD flow, from initial processing, to customer service, to storage, to the transmission and physical locations of all of the systems involved. Depending on the complexity of your operation, this can be a somewhat complex task. Start with a network diagram (see previous blog post) and expand to include physical locations and security services. Requirement 12.8.1 requires that this list be maintained.

Identifying Service Provider Roles: Once merchants have defined the service providers involved in their Cardholder Data Environment (CDE), they must next identify the specific roles and responsibilities of the service provider. It is a poor assumption to assume the role and responsibility of the service provider. For example, do not assume that your hosted data center updates your network diagram (Requirements 1.1.2, 1.1.3), sets appropriate firewall rules to restrict access (Requirement 1.2), or ensures that only one primary function is implemented per server (Requirement 2.2.1). PCI DSS 3.0 specifically calls for the development and maintenance of a responsibilities matrix for each service provider. Many service providers have these matrices available to describe their standard service to PCI merchants. To obtain one, ask for the “PCI Responsibilities Matrix”; if yours does not know what you are talking about, it may be time to look for a new service provider.

SMBs need to ensure such a matrix is in place for each service provider and that these matrices have been signed as part of the contractual agreement. Requirement 12.8.2 specifies that a written agreement must be in place that acknowledges the responsibilities of the service providers.

Managing Service Provider Roles: Once an understanding of the various PCI roles and responsibilities have been established and documented, the organization must ensure that this information remains accurate. This means determining the service provider’s ability to implement their responsibilities (i.e., due diligence) and (at least) annually reviewing the compliance status and contracts with each service provider.

Conclusion: You cannot simply outsource responsibility for PCI compliance. If you have a merchant ID, then you must comply with PCI. PCI DSS 3.0 has strengthened the requirements around the understanding of separating roles and responsibilities between the merchant and the service provider, and SMBs especially need to take note of their current approach to managing their service providers.

Doug Landoll CEO of Lantego Security, a security consulting firm specializing in information security compliance, policy development, and security risk assessment. He can be reached at [email protected]

Doug Landoll is an expert in information security for the SMB market with over 20 years experience securing businesses and government agencies. He has written several information security books and dozens of articles for national publications. He has founded and ran four ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Deliver a Deadly Counterpunch to Ransomware Attacks: 4 Steps
Mathew Newfield, Chief Information Security Officer at Unisys,  12/10/2019
Intel's CPU Flaws Continue to Create Problems for the Tech Community
Irfan Ahmed, Assistant Professor in the Department of Computer Science at Virginia Commonwealth University,  12/10/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16246
PUBLISHED: 2019-12-12
Intesync Solismed 3.3sp1 allows Local File Inclusion (LFI), a different vulnerability than CVE-2019-15931. This leads to unauthenticated code execution.
CVE-2019-17358
PUBLISHED: 2019-12-12
Cacti through 1.2.7 is affected by multiple instances of lib/functions.php unsafe deserialization of user-controlled data to populate arrays. An authenticated attacker could use this to influence object data values and control actions taken by Cacti or potentially cause memory corruption in the PHP ...
CVE-2019-17428
PUBLISHED: 2019-12-12
An issue was discovered in Intesync Solismed 3.3sp1. An flaw in the encryption implementation exists, allowing for all encrypted data stored within the database to be decrypted.
CVE-2019-18345
PUBLISHED: 2019-12-12
A reflected XSS issue was discovered in DAViCal through 1.1.8. It echoes the action parameter without encoding. If a user visits an attacker-supplied link, the attacker can view all data the attacked user can view, as well as perform all actions in the name of the user. If the user is an administrat...
CVE-2019-19198
PUBLISHED: 2019-12-12
The Scoutnet Kalender plugin 1.1.0 for WordPress allows XSS.