(PCIDSS) Payment Card Industry Data Security Standard - Fact Sheets

pcilogo While on the “A Perfect Fit: Understanding the PCI Security Standards“ Webcast this morning.

There were a few things that I took note of that are worth repeating:

  1. PCI Compliance (Fines, Dates, etc) is enforced by Card Associations/Brands and their Acquirers not the PCI Council.

  2. There was a neat chart that depicted the relationship between the different standards:


  • I learned of three new “Fact Sheets” published by PCICo From: https://www.pcisecuritystandards.org/education/fact_sheets.shtml

    Payment Card Industry Security Standards Overview
    PCI security standards are technical and operational requirements set by the Payment Card Industry Security Standards Council to protect cardholder payment data.

    Getting Started with PCI Data Security Standard
    PCI security for merchants and payment card processors is the vital byproduct of applying information security best practices in the Payment Card Industry Data Security Standard (PCI DSS).

    Ten Common Myths of PCI DSS
    The Payment Card Industry Data Security Standard (PCI DSS) secures cardholder payment data that is stored, processed or transmitted by merchants and processors.

    The Ten Commons Myths of PCI DSS is quite good (I especially like the first 4 of these),

    Myth 1 – One vendor and product will make us compliant

    Many vendors offer an array of software and services for PCI compliance. No single vendor or product, however, fully addresses all 12 requirements of PCI DSS. When marketing focuses on one product’s capabilities and excludes positioning these with other requirements of PCI DSS, the resulting perception of a “silver bullet” might lead some to believe that the point product provides “compliance,” when it’s really implementing just one or a few pieces of the standard.

    -- Take a second and read through the audit procedures, especially section 12, how is a product going to to this ? find all of the other sections that a product cannot address., in my experience products can address a fraction of the requirements, they are met by processes around systems and their logical controls. Products can you you address Encryption, Log Management, Firewalling, IDS/IPS, File Integrity Monitoring, Anti-Virus/Malware, Vulnerability Assessment, among others – but each of these still will require operational processes and monitoring controls.

    Myth 2 – Outsourcing card processing makes us compliant

    Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder payment data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.

    -- There are other business processes in place that deal with payment cards that are not necessary apparent, and while you can use out-sourcing to reduce scope, you will still have work to do. There are no real shortcuts here.

    Myth 3 – PCI compliance is an IT project

    The IT staff implements technical and operational aspects of PCI-related systems, but compliance to the payment brand’s programs is much more than a “project” with a beginning and end – it’s an ongoing process of assessment, remediation and reporting. PCI compliance is a business issue that is best addressed by a multi-disciplinary team. The risks of compromise are financial and reputational, so they affect the whole organization. Be sure your business addresses policies and procedures as they apply to the entire card payment acceptance and
    processing workflow.

    -- Too many times have I seem IT Audits or IT Reviews dropped on a IT Manager because it has “IT” in it, There is much more business and process and operational and organization controls then logical controls in the PCI Standard. IT supports business processes and is an enabler, you need business and department heads involved with PCI Compliance, especially to explain and understand the flow of cardholder data that IT may not know about.

    Myth 4 – PCI will make us secure

    Successful completion of a system scan or audit for PCI is but a snapshot in time. Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.

    -- Compliance != Security && Security != Risk Management (Compliance does not equal Security and Security does not equal Risk Management) – The PCI Standard is a baseline that is a best-practice approach to payment card security, it is not a risk based approach that is tied to your your organizational Risk Assessments and will not address non-payment assets or information. Compliance is a snapshot in time, you need to make sure that the processes are operating effectively after the review/audit has been performed. The process should also include continuous assessment of risk and implementation of controls to reduce the risk of new threats.

I signed up for the CPISM exam


I just signed up for the Certified Payment-Card Industry Security Manager or CPISM. So I’ll be in Dallas, TX from November 5th - November 7th – If you are in the area or are also taking the exam, please feel free to drop me a note.

Here is the link to sign up:

CPISM Training and Exam on Wed 5-Nov-08 8:30 AM

The CPISM measures aptitude in eight knowledge domains that were were generated and validated by industry experts. These domains constitute the knowledge that a security manager in the payment card industry needs to protect data. The domains follow:

\* Payment card industry structure  
\* Payment card structure and data  
\* Payment card transaction processing  
\* Compromise fraud statistics and trends  
\* Merchant risk analysis  
\* Laws and the regulatory environment  
\* Payment card security programs  
\* Third party relationships

See more info here: http://www.paymentsecuritypros.com/CPISM/

Since I’m in payment processing, and a former QSA this just really makes sense for me and will help us serve and support our clients better.

PCI DSS 1.2 - Anti-virus for *all* platforms


As I wrote yesterday on the summary of changes to PCI DSS 1.2 coming October 1st to a city near you.

Requirement 5: Clarified that requirement for use of anti-virus software applies to all operating system types.

I was a little surprised because the prevailing wisdom that only Anti-virus protection applies to Microsoft windows platform really applied for PCI.

While still on the “marathon morning” webinar this morning: Graham Cluley (his blog is here) of Sophos had an excellent and informative presentation “Viruses and Spam in 2008 - A look a the current security landscape and future trends”

Two Items of note related to PCI DSS and Anti-virus:


See: http://www.sophos.com/pressoffice/news/articles/2008/06/machovdyA.html


See: [http://www.sophos.com/pressoffice/news/articles/2008/02/rstbtool.html](http://www.sophos.com/pressoffice/news/articles/2008/02/rstbtool.html


I would say that the risk is low to OSX and Linux, but we are seeing attacks in 2008 on these platforms which does make the PCI DSS 1.2 Anti-Virus requirement clarification more reasonable. Expect to see AV for Linux, Mac and other platforms products being marketed towards the end of this year and 2009 and on.

PCI 3.3.2 - This ________ shouldn't be here !?!


I received a bill that had an option to pay with a credit card on the back, my favorite part of it is the line that asks for:

SECURITY CODE FROM BACK OF CARD__________________________________________

PCI 3.3.2 - clearly states:

“Do not store the card validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions”

Perhaps I’ll write “Call if Security code is required” um… no – I think I’ll make an e-check – I’m now wondering what they do with these slips after they receive them per PCI 9.6

Don’t forget about receipts, remittences, or other paper items for PCI reviews. How many people would just go ahead and fill this out if they wanted to pay by credit card ?

PCI SSC to release PCI DSS version 1.2 in October 2008


Council to evolve PCI DSS with enhanced clarity on technical requirements, improved
flexibility and greater management of evolving risks and threats

Using feedback provided by this community, including more than 2,000 questions submitted to the Council since its formation in 2006, version 1.2 of PCI DSS:
• Incorporates existing and new best practices
• Provides further scoping and reporting clarification
• Eliminates overlapping sub-requirements and consolidates documentation
• Enhances the frequently asked questions and glossary to facilitate understanding of the
security process.

It will be interesting to see what the “new best practices” are and what new requirements will be based on “evolving risks and threats”

Stay tuned…

Forcing Software for PCI Compliance

Jaime from The Merchant Account Blog writes:

Lately I’ve been hearing reports of processors that are starting to charge their customers $15 per month for not being PCI compliant. To fix this problem, these processors are requiring their customers to install some PC based scanning software that is supposed to magically make the business PCI compliant, thereby allowing them to avoid the monthly charge. Let me start out by saying: This is a bunch of crap! There is nothing that you can just put on your PC that will make your business PCI compliant. This is so far off course that it hardly can be related to PCI. PCI compliance is in reference to networks, computers, hardware and software that play a part in the processing, storage, or transfer of a credit card transaction.

Check out the rest of the post here: Forcing Software for PCI Compliance Unbelievable. I don’t think I could of put it any better myself and really hits on the theme that a product (even if it is PABP or PA-DSS certified), or PCI Scan, or any other service, CANNOT make you PCI compliant – I have a blog post brewing on this very theme.

PCI PA-DSS - Changes to Store and Forward processing

If you read the PCI standards carefully and hang out with PCI geeks here or here you will notice that PCI applies to post-auth data and not necessarily pre-authorization data. – I think the official language is “subsequent to the authorization” On May 1st, a payment processor modified their message formats as a part of their PCI compliance to not send Field 35 in SAF Advice transactions and would just send the PAN in field 2 and Expiration Date in field 14, instead of DE 35. Also, from a forum post from “andrewj

Another update on this (if you are from Australia) - there is a change being made to AS2805.2 to change the track 2 field from mandatory to optional in 04x0 messages. This should be released sometime this month.

This is a good trend in the industry, hopefully others will take this example and continue to trend.

Payment Systems Blog announces PCI Certification- (April Fools)

(April Fools) Payment Systems Blog is now PCI compliant by using “The Fastest, Least Intrusive, and Cost Effective PCI Certification Available” offered by Scanless PCI. –It really makes me sleep better at night; knowing that I’m now secure. – DB

PCI Certified by Scanless PCI

Boston Globe: 'Malware' stole Hannaford data


According to this article Boston Globe Article: Advanced tactic targeted grocer.

A massive data breach at Hannaford Brothers Cos. was caused by a “new and sophisticated” method in which software was secretly installed on servers at every one of its grocery stores, the company told Massachusetts regulators this week.

The software was installed on computer servers at each of the roughly 300 stores operated by Hannaford and its partners. Hannaford did not say how the software might have been placed on so many servers, and company spokeswoman Carol Eleazer said the company continues to investigate how the software was installed and other specifics of the breach.

To me this raises a few questions. Where was File Integrity Monitoring (PCI 10.5.5) of the Store Servers ? Why didn’t this pick up any changes to the Store Servers ? Was it not monitored ? Was it not configured properly. Was the malware installed in a directory that wasn’t monitored by the File Integrity Monitoring software? How does software get installed on every one of its stores without detection. (Yes, that I understand that maybe no files where written to disk, and everything theoretical could done in memory - but the malware would have to run at higher privileges to sniff the network (exploit of an unpatched systems?) and there would need to be some type of outgoing network traffic (probably encrypted payloads to badguys sites.))

The data were taken “in transit for authorization from the point of sale,” the letter states, meaning as it was transmitted from the cash register to one of the institutions that Hannaford uses to process transactions. Eleazer said these include major card networks and First Data Corp. of Denver, a major processor.

When possible in OLS.Switch we don’t sent unencrypted card numbers in the message format from the POS to the switch , -- from the switch to the endpoints (FDR, VISA DEX, MC Banknet) is a different story (as far as I know nothing other then a TCP/IP sockets when send data to the clear across a private network is supported. I would love to see channel encrypted tunnels here in the future. )

Free tools to Find Cardholder Data for PCI or PABP

Corbiscreditcards460 Just a quick post to list some help tools for detecting cardholder data on your systems, or tools to setup for ongoing controls to monitor for cardholder data. 1) ccsrch ccsrch is a tool that searches for and identifies unencrypted and contiguous credit card numbers (PAN) and track data on windows and UNIX operating systems. It will also identify the location of the PAN data in the files and record MAC times 2) Senf: The Sensitive Number Finder Senf is a fast, portable tool (written in Java, runnable just about everywhere) for finding sensitive numbers. Use this tool to identify files on your system that may have Social Security Numbers (SSNs) or Credit Card Numbers (CCNs). 3) Spider (Windows) (Linux) Spider’s purpose is to identify files that may contain confidential data. It scans a collection of files, searching for patterns of numbers or letters that resemble Social Security numbers or credit card numbers (additional search patterns can be created using Unix regular expressions). 4) Tenable’s Ron Gula’s blog using Nessus to find Senstive Data: Detecting Credit Cards, SSNs and other Sensitive Data at rest with Nessus 5) Snort - using the Bleeding EdgeEmerging Threat Snort rules, (see BLEEDING-EDGE Credit Card Number Detected ET POLICY Credit Card Number Detected in Clear) You might be using snort as and IDS - or using a product or appliance that uses it as its engine. This tool is also very handy to check for email that contains CC data as well. (EDIT: Bob writes to say the that Emerging Threats have replaced the Bleeding Edge project as it died. Thanks !) 6) Strings http://unixhelp.ed.ac.uk/CGI/man-cgi?strings or http://www.microsoft.com/technet/sysinternals/miscellaneous/strings.mspx using the parameter Strings -n min-len Let me know of others that are useful.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now