Endpoint
1/29/2014
01:20 PM
Doug Landoll
Doug Landoll
Commentary
Connect Directly
RSS
E-Mail
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 dlandoll@lantego.com

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
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0607
Published: 2014-07-24
Unrestricted file upload vulnerability in Attachmate Verastream Process Designer (VPD) before R6 SP1 Hotfix 1 allows remote attackers to execute arbitrary code by uploading and launching an executable file.

CVE-2014-1419
Published: 2014-07-24
Race condition in the power policy functions in policy-funcs in acpi-support before 0.142 allows local users to gain privileges via unspecified vectors.

CVE-2014-2360
Published: 2014-07-24
OleumTech WIO DH2 Wireless Gateway and Sensor Wireless I/O Modules allow remote attackers to execute arbitrary code via packets that report a high battery voltage.

CVE-2014-2361
Published: 2014-07-24
OleumTech WIO DH2 Wireless Gateway and Sensor Wireless I/O Modules, when BreeZ is used, do not require authentication for reading the site security key, which allows physically proximate attackers to spoof communication by obtaining this key after use of direct hardware access or manual-setup mode.

CVE-2014-2362
Published: 2014-07-24
OleumTech WIO DH2 Wireless Gateway and Sensor Wireless I/O Modules rely exclusively on a time value for entropy in key generation, which makes it easier for remote attackers to defeat cryptographic protection mechanisms by predicting the time of project creation.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Sara Peters hosts a conversation on Botnets and those who fight them.