-Credit card payments are accepted for any business which have the standard applies.
-The current version is 1,2, effective October, 2008.
-The standard is broken down into 12 requirements, categorized 6 areas
- PCI Security Standard Council creat and maintaine the standard. This body doesn’t enforce the standard and doesn’t impose any consequences for non-compliance. The card brands perform this function.
- There are 4 levels of compliance criteria. Merchants at levels 1-3 are required to have quarterly vulnerability scans.

These scans are performed by a Authorized Scanning Vendor.
- Most small business will be standard 4 merchants (merchants that process less than 20,000 transactions per year).

Level four merchants are not required by the PCI DSS to have quarterly scans, but scans may be recommended or required by processing providers.

- Using a self-assessment questionnaire determine for the compliance of Level 4 merchants. They have 4 questionnaires.

The questionnaire which applies is determined by the methods that hte merchant uses to process payments. Merchants that store credit card data on their systems are subject to a mass of requirements.
- There are 4 types of questionnaires – A,B,C, and D.

- The Type A and B questionnaires are for merchants that do not store any cardholder data on their systems, use only dial-in processing terminals which are not connected to the internet or any other network, or use only manual imprint machines. Most small businesses will use these self-assessment questionnaires. Even these small merchants are subject to some of the PCI DSS requirements:

– Requirement 3-Protect cardholder data: Store in any form for certain card information. This includes the full magnetic track data, the three or four-digit card validation (also called CVV) codes, and PIN data. The full card number should also not be displayed on receipts or in any place where it can be viewed by anyone who does not have a legitimate business need to view it.
– Requirement 4-Encrypt the transmission of cardholder data though open, public networks:POLICIES, practices, and procedures must be in place to foreclose the sending of unencrypted credit card numbers through EMAIL.
– Business need-to-know requirement 7-Restrict access to cardholder data.
– Requirement 9-Restrict physical access to cardholder data: Controll access to data as strictly , mark cardholder data as confidential, and destroy data when it is no longer needed for business purposes (paper copies must be crosscut shredded, incinerated, or pulped)

– For employees and contractors, requirement 12-Maintain a policy that addresses information security: This means WRITTEN policies, security awareness training, incident reporting procedures, and contractual agreements with service providers

Secure web sites against attacks is requirement #6,6′s aim, by requiring either of the following for all web-facing applications:

Manual code review by experts
Application Layer Firewall
Now this press release effectively says that the intent of code review requirement is met by:

Manual web application security is thought vulnerability
Proper use of automated web application security vulnerability assessment (scanning) tools
The million dollar question is: Can a vulnerability assessment or penetration test really detect the uniform findings that a code review does? Can we think that a code review can be replaced by a vulnerability assessment or a penetration test?

I don’t agree. Code review is a white box exercise, yet vulnerability assessment is a black box exercise. A security expert can look under the hood and see the guts of the application with code review,where as a vulnerability assessment looks at the application from outside and can only see the few security flaws that have actually manifested themselves into full blown exploitable vulnerabilities. Therefore a vulnerability assessment will leave out many other complex, subtle, yet serious flaws that only a code review could have discovered.

So I want to know why the council thinks that it meets the intent of the code review requirement.

Now here’s some background before you read about the next confusion.

The PCI standard clearly states that a compensating control must be in addition to controls required in the PCI DSS compliance. Just sounds involuted, it’s really simple. Interpret with an instance: Let’s take Requirement #3.3 which asks the PAN to be masked when displayed. If this requirement cannot be met then the merchant will have to propose a compensating control.

Issue 1: Where is the credit card data? Can we find data in our databases and fileservers? Scalability and manageability problems was disappointing by early experience with crawlers.

For “data discovery” which is the good old problem. Many vendors will try to sell complicated crawlers and data classification engines that will scour servers, index the data and build classification etc. Most crawlers don’t work well in such environments. Also most crawlers need authentication information to login to each server and managing this across a large data center is difficulte. My recommendation is the following: Start with imperfect lightweight discovery that gets smarter over time. It’s better to get started rather than wait for a perfect heavyweight discovery. I suggest starting with an “active discovery” that watches any access to your servers and builds a data discovery map based on this access. Once you have an idea of a good working set of critical servers to start with; you can always add a crawler-based discovery more selectively to such servers. The combination of “breadth-first” active discovery and “depth-next” crawler discovery is a power combination that reduces overhead, simultaneously keeps the discovery up-to-date.

One good approach for active discovery is provided by data auditing without requiring crawling, without requiring agents, and without requiring logging to be turned on, on the servers. Data Auditing was used by enterprises are usually pleasantly surprised with the ease of use. It can turn an endless discovery project into a project lasting few days. Active discovery can be turned on and off. It can also be linked to policies.

Recommendation: Lightweight discovery is the best. Progress in steps – active discovery combined with selective deep crawling will give you the momentum to solve the messy data problem in stages.

At start,it was peace to notice that majority the audience agreed that PCI was helpful for their organizations in cases where they wanted to jumpstart their security program, but were not sure how.  Most people also agreed that PCI helped them get executive attention and much-needed budget to implement the security controls they knew they needed to have. No surprises here.

However, at some point in the discussion I started to realize that the desire of some organizations to do “compliance first” and to treat PCI as a “blind” checklist as well as their desire to just focus on achieving compliance and not at all on security was due to the fact that the pressure on them “to be secure” was much weaker compared to the pressure “to be PCI compliant.”

In original works,those organizations who deal with a journey to “we just need to get the auditor/assessor off our backs” fear their auditors more than they fear the hackers (uhu, Russian, Chinese and Romanian combined ); at least, their decision-makers seem to. Those same decision makes also likely think that it is much simpler to measure when they are PCI compliant (=when the QSA leaves with a ‘PCI OK’ report) compared to when they are “secure enough” (=when nothing bad happens for a long time DURING WHICH they are not asleep at the wheel…); thus, in their minds,  compliance seems like a “cheap substitute” for security.

When this discussion started, many of the audience members pointed out that PCI compliance projects were initiated by the finance departments or even directly by the CFO.  At the same time, most of the security projects at their organizations were initiated by the IT departments (or their IT security sub-departments).  It goes without saying that CFO has much more of a CEOs ear, compared to some unnamed security manager down in the trenches.