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.

Perimeter

10/20/2010
11:00 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

An SMB Guide To Credit Card Regulations, Part I: PCI DSS Q&A

This article is the first in a short series designed to help small businesses understand the regulations around securing credit card transactions, specifically the PCI DSS (Payment Card Industry's Data Security Standard) requirements.

This article is the first in a short series designed to help small businesses understand the regulations around securing credit card transactions, specifically the PCI DSS (Payment Card Industry's Data Security Standard) requirements.In an effort to provide the most tangible information, I've consulted with a Qualified Security Assessor (QSA). Portions of content and resources in this series have been contributed by trusted security colleague Martin McKeay, QSA and host of the Network Security Podcast.

Let's jump right in and start looking at some of the most intriguing questions surrounding the PCI DSS requirements as they apply to smaller businesses.

Q1: What exactly does PCI DSS cover and does it apply to me? There are many parts to the PCI DSS requirements. Simply put, you're required to meet certain standards to protect cardholder data. Most notably, the PCI DSS puts requirements on ANY merchant who is storing, processing or transmitting cardholder data. Storing covers not only digital, but also physical storage, an often overlooked situation. The PCI DSS also covers what parts of the cardholder data you can and cannot store, how it can be stored and what type of protection to apply to specific combinations of data. If you're processing, transmitting or storing (on paper or digitally) credit card, debit card or bank account numbers, then PCI DSS applies to you. This includes, but isn't limited to, any organizations that have recurring billing data on computers, credit card machines or readers and/or filed documents with credit card or bank numbers.

Q2: We don't process many credit cards--do we still have to meet PCI DSS requirements? Yes! Even if you don't process many credit cards (in number of transactions or in dollar amounts) you still fall under the PCI DSS requirements. Generally speaking, there are four tiers of merchants and the tiers are based on the number of transactions, not the sum of the money. If you're processing less than 20,000 transactions a year (that's an average of 55 a day), then you're a Level 4 Merchant. If you process more than 20,000 but less than a million a year, you're a Level 3 Merchant. There are also Levels 1 and 2 for larger transaction volumes. Your merchant level only dictates the type of accounting and reporting you're responsible for and doesn't make you less responsible for compliance.

Q3: How do I know if my business is compliant? You probably won't know for sure, but there are a variety of self-assessments available to get you thinking about the appropriate security. PCI DSS provides four Self-Assessment Questionnaires (SAQs) for use by lower level merchants. The SAQ you use will depend on your business model. Larger merchants are audited and reviewed by QSAs, like Martin. Smaller merchants are mostly on an honor system--now. The complication with self-assessments is that even though the questions included are less exhaustive than a QSA review, the smaller merchants are still responsible for meeting ALL the requirements. You can view more on the PCI DSS SAQs here.

Q4: What happens if we're not compliant? Several things could happen. Lever 3 and Level 4 merchants have different relationships with PCI DSS than their larger counterparts, but one component is the same. Your agreement is not directly with the credit card company, but instead is with the acquiring bank--the bank that processes transactions for you and manages your merchant account. To simplify the relationships, you and your acquiring bank have an agreement, and your acquiring bank has a responsibility to the credit card companies for PCI DSS. If you're not compliant but it hasn't resulted in a breach (yet) then one of several things may happen. How they handle the gap depends on your contract, the situation and your relationship with the bank. They might choose to absorb the fees from the credit card companies, they could pass the fees on to you, or they can even impose their own additional fines for noncompliance. Most often, being noncompliant will result in higher per-transaction fees for you, large monthly fees and possibly fines passed from the credit card company via the acquiring bank. On the other hand, if your noncompliance has resulted in a breach and cardholder data is lost or stolen, then you're going to have a mess on your hands. The breach laws and fine structures are enough to put most small companies out of business.

We'll be talking more about PCI DSS's specific requirements like wireless networks in subsequent parts of this series. PCI DSS is still a fairly new concept, relative to other regulations and data security laws. Because of its novelty, the bugs and logistics are still being ironed out but QSA professionals predict more interaction and responsibilities for Level 3 and 4 merchants down the road. The honor system will fade into a framework with more validation and QSA consulting. This series will serve as a springboard to help SMBs prepare for current and future PCI DSS regulations.

Jennifer Jabbusch is a CISO and infrastructure security specialist at Carolina Advanced Digital. By day she architects enterprise security solutions and by night, well, she does the same thing. For Dark Reading, she melds her enterprise experience and intimate knowledge of small business operations to deliver relevant security guidance for SMBs everywhere. Jennifer Minella is VP of Engineering and consulting CISO at Carolina Advanced Digital, and an author, speaker and consultant for infrastructure security for government, education and Fortune 100 and 500 corporations. View Full Bio

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15564
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be map...
CVE-2020-15565
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs....
CVE-2020-15566
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, o...
CVE-2020-15567
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes...
CVE-2020-15563
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM g...