After my post mentioning the PCI DSS I got some questions like “PCI D..what?” and “What is that anyways? I’ve heard of it but never read anything about it”. Well, after reading this, you people should feel a bit enlightened. Hopefully, CISSPs and similar will not find this as new information, but you might enjoy the refresher. So, read on folks, this is gonna be a (…another) long one.
PCI DSS stands for “Payment Card Industry Data Security Standard” and it was created by the larger players in the credit card business to ensure that those little 1’s and 0’s, that usually reside on your physical magnetic-strip card, does not end up in the hands of a criminal.The first version of the standard was developed and agreed upon in late 2004 and was (still is) intended to provide guidance for organizations that transfer, store or process credit card information in computer security related issues. The first standard was revised in 2006 to make it more up-to-date and more relevant to the current situation.The use of the word “Guidance” is used a bit freely in the description according to me, as if a requirement in the standard is not met by the merchant he might lose his right to handle the kind of data described in the standard, effectively shutting down their business (this is not a bad thing, btw).Before the PCI DSS was widely agreed upon, many of the CC companies had their own standards and recommendations regarding data security, such as: CISP/AIS (Visa), SDP (MasterCard), DSOP (AmEx), I&C (Discover) and DSP (JSB). The above mentioned was also the primary participants in the discussion that later led to the standard. Most of these financial actors still have their own security programs but they have aligned them so that they all have the same objective, help merchants become PCI DSS standard compliant.
The PCI Data Security Standard consists of 12 topics in 6 different categories. These are called “control objectives” and are:
- Build and maintain a Secure Network
- Requirement 1: Install and maintain a firewall configuration to protect cardholder data
- Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect Cardholder Data
- Requirement 3: Protect stored cardholder data
- Requirement 4: Encrypt transmission of cardholder data across open, public networks
- Maintain a Vulnerability Management Program
- Requirement 5: Use and regularly update anti-virus software
- Requirement 6: Develop and maintain secure systems and applications
- Implement Strong Access Control Measures
- Requirement 7: Restrict access to cardholder data by business need-to-know
- Requirement 8: Assign a unique ID to each person with computer access
- Requirement 9: Restrict physical access to cardholder data
- Regularly Monitor and Test Networks
- Requirement 10: Track and monitor all access to network resources and cardholder data
- Requirement 11: Regularly test security systems and processes
- Maintain an Information Security Policy
- Requirement 12: Maintain a policy that addresses information security
In order to verify whether or not the merchants/service providers are really compliant they have to undergo self-assessments, quarterly PCI Security Scans and possibly PCI Security Audits (Depending on the size and amount of sensitive information handled).
The PCI Security Scans are to be performed by a ASV (or, Approved Scanning Vendor) and is non-intrusive in their nature. This means that the scans should not interrupt day-to-day business or cause any damage to the systems evaluated. After one of these scans the ASV compiles a report detailing the different issues found, the associated risk (you will need a CISSP for this 
) and also provide some guidance on how to remedy the issues. Every weakness found should also be categorised in a scale from one to five, five being worst case scenario. The PCI DSS considers level 3 to 5 as a failure to comply and a direct danger to cardholder data. This type of scans was the topic of discussion in the webinar that I based my previous related post on.
If you are a large merchant or service provider you might also be the subject of a PCI Security Audit which consists of a review of internal policies & documentation, internal penetration-testing & security evaluation and also interviews of selected personnel. This is done to actually verify that all guidelines in the PCI DSS has been implemented as they should.
One very interesting document regarding both types of audits was written in late 2006 by consultants from the German security company SRC. In that document (which contains a lot of good info) they listed the top 10 types of vulnerabilities found for both methods (internal/external). What’s very serious about the ones they listed are that they are very old. For example, I used one of them to compromise a network in 2002! This kind of vulnerability should not be present in any company that seriously tries to be secure. No matter the size. They are easily scanned for and can be exploited in under one minute. You can find the whole document here.
Other references on this subject:
PCI Security Standards
PCI Answers - This post was very interesting.
PCI Answers PCI Forum
PCI DSS News and Information
IT Governance PCI DSS information
Google…
That’s it for me now. If I’m mistaken about something or if someone has any questions please drop me a comment or an e-mail!
Cheers,
