Today I'll provide an overview of what is often the elephant in the room. The Payment Card Industry Data Security Standard (PCI DSS). Unlike ISO 27001 where shades of grey are acceptable, in PCI DSS things are very much black and white, with some wiggle room although limited and realistically only if you can convince the QSA that what you are doing is ok. It boils down to you either comply with a requirement, or you don't. There is no "kind of". Background
The main standard most people will need to comply with is PCI DSS. The other standards have a specific scope.
Depending on the number of transaction you may be considered a level 1, 2, 3, or for some payment brands even a level 4 merchant or service provider. In a nutshell if you are a level 1 merchant or service provider, you will need to have an on-site assessment annually and Quarterly Authorised Scanning Vendor (ASV) scans. Lower levels may only require you to validate using a self assessment questionnaire (SAQ) and have quarterly ASV scans. The main thing to remember though is that the number of transactions you do only determines the validation requirements, not the compliance requirements. You will always have to comply with all requirements outlined in the standard, unless they are really not applicable to your situation.
If you are slightly freaked out by those broad rules and you are thinking OMG that means my entire worldwide network is potentially in scope, then you are starting to get it. PCI DSS is the elephant in the room or bigger than Ben Hur is quite appropriate as well. Which is where scope reduction comes into play.
The how and why is a bit beyond this intro to the standard. Either way if doing scope reduction exercises keep your QSA briefed and they can provide advice as to what you are doing will help your situation or not.
This requirement outlines the processes that need to be in place with regards to the management of firewalls and routers used in the Cardholder Data Environment. Most organisations have this reasonably under control. There are however documentation requirements that are not often met and there are those pesky ANY rules (you can have them, but it typically increases the scope).
Systems are often compromised through the use of default passwords and other default configuration items. This section addresses requirements such as default passwords, but also security/hardening configuration of devices used, such as server configuration standards for servers and network devices. This varies from organisation to organisation. Basic build documents are usually available, but they do not often address the requirements of the standard. Default passwords are usually changed, but the simple ones are not (public, private ring a bell?).
This requirement addresses the storage requirements for cardholder information and what can be stored and what cannot be stored. It also addresses encryption requirements and outlines the related documentation requirements. This is probably the most difficult requirement for most organisations. Encrypting and managing the keys can be a big challenge.
This requirement addresses the interaction between the organisation and third parties as well as donors/customers. Usually easily met by most organisations as they often already have VPNs or SSL based applications.
This requirement addresses the malware management of the environment and helps ensure that malicious software does not adversely affect the environment. If you don't have this sorted, PCI will be the least of your problems. Most organisations do OK with this, just read the requirement for regular scanning carefully.
This requirement addresses patching and change control as well as the development and testing of applications used to accept and process cardholder information. The main issues we find relate to the lack of security training or awareness for developers as well as a deficiency in security related testing of internal and external facing applications. On the patching side, if it has a CVSS score of 4 or higher, you must patch.
Requirement 7 relates to access and privilege management and the processes involved for providing access the cardholder data. This includes the authorisation process and documentation, typically role based. Most of the time the deficiencies relate to documentation.
Users have individual accounts on the various systems and password controls are applied, but not documented. Userid and password management is often fine, however privileged accounts management and the use of root in some organisations can be challenge.
In order to protect the cardholder information physical security must be considered. Usually OK, the most problems we come across relate to dealing with visitors.
As part of management of cardholder data it is important to have visibility in the environment and have the ability to track activities. The daily review of logs and file integrity monitoring is where most people struggle
Under PCI DSS it is expected that the security of systems and applications be tested regularly to ensure that cardholder information is safe. The quarterly wireless checks for rogue devices is usually the main stumbling block as all sites have to be done. Likewise the difference between a penetration test and a vulnerability scan is sometimes confused and causes issues.
Policies are the cornerstone of compliance as they outline the requirements to be followed within the organisation. Usually policies are OK, however monitoring of the PCI status of your service providers is often not well developed.
Be aware of the self assessment trap that people tend to fall into. Remember all those quizzes in magazines. Can you run 100m in 12 seconds?, sure. Can you bench press your own weight at least ten times? no problem. We tend to over estimate our abilities. So when doing the gap analysis, for each requirement you look at, add the following "how can I prove it?" That should bring answers back into reality. For example requirement 1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations "how can I prove it?". What the QSA will be looking for is a document that states "must be approved, must be tested, etc" then typically they'll ask to see the approval for a particular change to a network device. Who approved it, who executed it, etc. If that is not possible, then you are not compliant.
|
Mark 391 Posts ISC Handler Oct 12th 2012 |
Thread locked Subscribe |
Oct 12th 2012 8 years ago |
Mark-
Great diary. I ran the PCI compliance program for a mid-sized retailer, you hit on all the major points. This is a great overview, and gives a good impression of just how big a PCI audit can get. I encourage anyone with a stake in their org's PCI compliance to attend the PCI ISA training, whether they are intending to be an ISA or not. It's insightful and worth the coin. I can't tell you how many times I had to walk a dev, sysadmin, or exec back from the idea of "It's encrypted, so it's safe." Encryption is just one of the many requirements, and frankly, one of the easier ones to meet. Encrypted card data is still card data. It's not a token. It still needs protecting, so one can't hide behind encryption. I'd like to ask the audience how they feel about req. 8.5.8 - Group, Shared, or Generic passwords. In theory, this is one of my favorite PCI reqs, because it forces an organization to address priviledged access control. In practice, it's damn near the most difficult requirement on the Standard. How do other orgs handle 'service accounts' or 'application accounts?' I had to jump through some pretty creative compensating control hoops, I'm curious to hear of other's stories too. |
Eli 9 Posts |
Quote |
Oct 12th 2012 8 years ago |
Correction...that'd be "Group, Shared, or Generic Accounts" - not passwords.
|
Eli 9 Posts |
Quote |
Oct 12th 2012 8 years ago |
Requirement 0 - Finding Cardholder Data
“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.†So you should check for Ccardholder data "leakage", ie card info outside of your environment. If there is, eliminate it ASAP or your scope now dramatically increases... |
dayglo 5 Posts |
Quote |
Oct 12th 2012 8 years ago |
Enjoy the information. I have no experience with this. I would assume smaller merchants hire a company to handle this and do not have this burden? If you use one of those square devices on your iPad, then square has to prove compliance and holds all liability?
|
dayglo 2 Posts |
Quote |
Oct 12th 2012 8 years ago |
You said "PCI DSS applies to any organisation that accepts, process, store or transmit credit card information". That is incorrect, PCI is not just for credit cards. It is for payment cards which also includes debit cards, prepaid cards, etc carrying the log of any of the PCI SSC's payment brands.
Source: PCI SSC FAQ website. Go to https://www.pcisecuritystandards.org/index.php, and click on FAQs. "Does PCI DSS apply to debit cards, debit payments, and debit systems? Any payment card (credit, debit, prepaid, stored value, gift or chip) bearing the logo of one of the PCI Security Standards Council’s five founding payment brands is required to be protected as prescribed by the PCI DSS." |
dayglo 2 Posts |
Quote |
Oct 12th 2012 8 years ago |
@ davidj2 - The smaller merchants who use verifone type equipment on POTS lines (the small boxes that are not connected directly to the register and generally provide their own receipt) only need to conform to the SAQ-B requirements as long as they meet the few other stipulations in the attestation. It is not difficult to meet SAQ-B requirements. Those companies who transmit credit card data over the internet likely have to meet SAQ-D (Or maybe SAQ-C) which starts to get a little more hairy in the number and type of requirements one has to meet.
|
dayglo 4 Posts |
Quote |
Oct 12th 2012 8 years ago |
@davidj2
Not sure what you mean by square devices, but yes whomever takes the payment typically has the responsibility for PCI DSS |
Mark 391 Posts ISC Handler |
Quote |
Oct 14th 2012 8 years ago |
@ElyP, Yes you are correct that any payment branded card is typically in scope. I was trying to keep it simple, but probably should have included that.
M |
Mark 391 Posts ISC Handler |
Quote |
Oct 14th 2012 8 years ago |
Banks and companies that accept the transactions from merchants, known as the "acquirer", are part of the problem. They've turned PCI into a cash cow. One very well-known small merchant acquirer "fines" a merchant about $30 a month if they are not PCI compliant. Have you ever heard of getting PCI compliant for less than $360 a year? It's cheaper to get fined by far. Another very large acquirer recently started fining their large customers. By "large" think Level II. I've seen letters saying the fine is $5,000 a year for operations processing millions of transactions. Have you ever head of any Level II getting PCI compliant for $5,000 a year?
I'm sure those small fines add up to big income dollars to the acquirer when spread across their customer base and all it took was sending a letter. Now that is a security Return On Investment! The fines are also small enough that no merchant is going to switch acquirers because of them. Paradoxically, the fines are proof that the acquirers willfully allowed their merchants to stay non-compliant and that may incur risk for the acquirers in the event of a merchant breach. But I'm sure the accumulated fines will offset much if not all of that pain even if the merchant declares bankruptcy because of a breach. No, I do not work for any entity that helps merchants become PCI compliant. Or any kind of compliant for that matter. |
Anonymous |
Quote |
Oct 14th 2012 8 years ago |
Once often over-looked compensating control that can be acceptable for a LOT of the individual requirements is the installation of a good Data Loss Prevention system. But it has to be comprehensive. If you have a large, flat network DLP can be a lifesaver in terms of speed. Cost, not so much.
|
Anonymous |
Quote |
Oct 14th 2012 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!