Endpoint
1/29/2014
01:20 PM
Doug Landoll
Doug Landoll
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2008-3277
Published: 2014-04-15
Untrusted search path vulnerability in a certain Red Hat build script for the ibmssh executable in ibutils packages before ibutils-1.5.7-2.el6 in Red Hat Enterprise Linux (RHEL) 6 and ibutils-1.2-11.2.el5 in Red Hat Enterprise Linux (RHEL) 5 allows local users to gain privileges via a Trojan Horse p...

CVE-2010-2236
Published: 2014-04-15
The monitoring probe display in spacewalk-java before 2.1.148-1 and Red Hat Network (RHN) Satellite 4.0.0 through 4.2.0 and 5.1.0 through 5.3.0, and Proxy 5.3.0, allows remote authenticated users with permissions to administer monitoring probes to execute arbitrary code via unspecified vectors, rela...

CVE-2011-3628
Published: 2014-04-15
Untrusted search path vulnerability in pam_motd (aka the MOTD module) in libpam-modules before 1.1.3-2ubuntu2.1 on Ubuntu 11.10, before 1.1.2-2ubuntu8.4 on Ubuntu 11.04, before 1.1.1-4ubuntu2.4 on Ubuntu 10.10, before 1.1.1-2ubuntu5.4 on Ubuntu 10.04 LTS, and before 0.99.7.1-5ubuntu6.5 on Ubuntu 8.0...

CVE-2012-0214
Published: 2014-04-15
The pkgAcqMetaClearSig::Failed method in apt-pkg/acquire-item.cc in Advanced Package Tool (APT) 0.8.11 through 0.8.15.10 and 0.8.16 before 0.8.16~exp13, when updating from repositories that use InRelease files, allows man-in-the-middle attackers to install arbitrary packages by preventing a user fro...

CVE-2013-4768
Published: 2014-04-15
The web services APIs in Eucalyptus 2.0 through 3.4.1 allow remote attackers to cause a denial of service via vectors related to the "network connection clean up code" and (1) Cloud Controller (CLC), (2) Walrus, (3) Storage Controller (SC), and (4) VMware Broker (VB).

Best of the Web