March, 2009

PCI DSS Transaction Levels | VISA Requirements for Merchants

PCI DSS transaction levels for merchants are used to identify what “Level” an organization would fall into for PCI DSS compliance.

Level 1: Any merchant-regardless of acceptance channel-processing over 6,000,000 Visa transactions per year OR Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.

Level 2: Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 Visa transactions per year.

Level 3: Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.

Level 4: Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year.

Regarding PCI DSS compliance for VISA, most merchants will fall into Levels 2, 3, and 4, which allows a merchant to conduct a payment card industry Data Security Standards (PCI DSS) self assessment. However, a self-assessment is easier said than done, as it is best to still utilize a Qualified Security Assessor (PCI QSA) to assist in self-assessment matters.

Level 1 compliance for merchants requires an actual on-site PCI DSS assessment by a PCI-QSA.

Compliance with PCI DSS | Expert Advice from a PCI QSA

Compliance with PCI DSS can be daunting and a challenge indeed. However, simply breaking down the PCI DSS requirements and looking at it in a thought manner will help alleviate your concerns. As a Payment Card Industry Qualified Security Assessor (PCI QSA), i’m often asked the who, what, when, where, and why of compliance with PCI DSS.

So, with that said, here is some important advice in truly understanding compliance.

1. You need to find out if you are identified as a merchant or a service providers in the eyes of PCI compliance. Contact a PCI QSA for advice on this issue if you are not sure of your answer.

2. Once you have accomplished this, you need to identify what “Level” of compliance is mandated for your organization. This can be done by calculating the total number of transactions your organization undertook or will undertake in a full year’s time. Take note, that for merchants, most organizations will fall into Levels 2,3, and 4, which can allow you to conduct a PCI DSS self-assessment (with oversight and guidance from a PCI-QSA is what i highly recommend). Level 1 merchants will have to undergo an actual on-site PCI DSS assessment by a QSA. As for service providers, most of you will also have to undergo an on-site PCI DSS assessment. Again, find your level based on your transaction volume.

3. If you can self-assess, then visit pcisecuritystandards.org and obtain the self assessment questionnaires. There are five (5) of them, so read carefully as to which one is for you. If you have to have an actual on-site PCI DSS assessment done, then contact a firm who can conduct this for you.

PCI DSS | Payment Card Industry Compliance | Tips on Preparing for a PCI DSS Assessment

Are you a merchant or service provider having to comply with the Payment Card Industry Data Security Standards v1.2, commonly known as PCI DSS? If so, take a page out of a QSA’s play book for helping you prepare for a PCI DSS assessment. While we as QSA’s often talk about and spend much time on I.T. security and network issues, such as firewalls, routers, switches, and other hardware/devices/and technology utilities, let me bring your attention to an often overlooked area. Policies and procedures. That’s right-at the heart of any successful PCI DSS assessment are the development of policies and procedures that are detailed, current, relevant, and represent an actual “representation” of your organization’s control environment. How important are they? Important enough that there is an entire section of the PCI DSS requirements, known as “Maintain an Information Security Policy” is dedicated to policies and procedures. What’s more, sprinkled throughout various other sections of the PCI DSS requirements are more calls for policies and procedures. Thus, its paramount that you tackle this arduous and time consuming task as soon as possible. Don’t have a good PP writer on board-then contract it out to a PCI QSA firm that has experience in developing policies and procedures for your organization.

Credit Card Security Compliance | Learn about PCI DSS

Credit card security compliance is more technically known as the Payment Card Industry Data Security Standards, simply known as PCI DSS. PCI DSS is a framework established and agreed upon by the major payment brands (Visa, MasterCard, American Express, Discover Card, and JCB). The oversight, training and assessment guidelines for PCI DSS is conducted by the Payment Card Industry Security Standards Council, known as the PCI SSC.

Payment card industry compliance is a very general and broad term, thus you need to fully understand what your compliance needs are and how to go about undertaking the requirements for meeting these very needs. Most organizations requiring PCI DSS compliance are either merchants or service providers, and they have to comply based on what level they fall into for PCI DSS.

Add to this is the ability to either conduct a PCI DSS self assessment or to undertake an actual on-site PCI DSS assessment by a qualified security assessor, known as PCI-QSA. Get the facts about compliance and start making inroads sooner rather than later for all your credit card security compliance needs (again, more technically known as PCI DSS

What is Required for PCI Assessment? | PCI DSS Q and A

What is required for PCI assessment compliance? This is a question i’m often asked, especially by organizations that need to comply with Level 1 of the PCI DSS standards, which is an on-site assessment conducted by a Qualified Security Assessor (QSA), such as myself. Well, here is what you need to “comply” with according to the PCI standards:

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 stroed 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

Sure, it is lengthy and an arduous task, to say the least. Remember though, there are four (4) different levels of compliance for PCI DSS, with most organizations falling into levels 2,3, and 4. Level 1 compliance can be very time consuming, but so can Levels 2,3, and 4 if you do not have a good grasp on what is required by the PCI DSS standards. My recommendation, consult with a PCI QSA on what level you fall into and what assistance you may need.

12 PCI DSS Requirements | Lessons Learned from a PCI QSA

The 12 PCI DSS Requirements are lengthy and technical indeed. However, organizations need to truly understand the scope of the PCI assessment for gaining greater insight into the efficiencies that can be had for undertaking a Payment Card Industry Data Security Standards (PCI DSS) Assessment.

So, what are my lessons learned as a Qualified Security Assessor (QSA) who conducts PCI assessments?

First and foremost, the assessment is NOT always about technology. Sure there is a host of requirements surrounding the “system components” of the “cardholder environment”, but look closer and you will find that developing documented policies and procedures is one of the most time-consuming and arduous processes of the entire assessment? Your kidding, you might say? Not at all, it’s amazing how much time and effort is needed for developing these documents for ensuring PCI compliance.

Add to the fact that you need to properly “scope” the assessment for a number of parameters and I would highly advice a PCI Readiness Assessment for any entity going through a Level 1 PCI engagement.

Properly scope the assessment for what is and is not included in the “cardholder environment”, conduct a PCI Readiness Assessment and be mindful of the documented policies and procedures that must be in place for compliance.

To learn more about PCI, visit pciassessment.org

PCI DSS Merchants Levels | Learn Your Requirements for PCI DSS Compliance

Regarding PCI DSS merchant levels, it is paramount that these very merchants properly identify the level they fall under for compliance with PCI DSS. Most merchants will be able to undergo their own payment card industry data security standards (PCI DSS) self assessment questionnaire (SAQ). However, many will also be required to conduct and go through an annual on-site assessment by a Qualified Security Assessor (QSA).

Again, this all depends on the merchant levels and you have to understand that these PCI DSS merchant levels are different for each of the respective payment brands. So, let’s take a closer look at this.

Discover Card: They do not even use merchant level categories, rather, they use a risk based approach for assigning PCI DSS requirments.

VISA: Visa uses Levels 1 to 4 for classifying merchant levels. Learn more about VISA Merchant requirments

American Express, JCB, MasterCard: These major payment brand heavyweights also have identify merchants from Levels 1 to 4, and again, this is based on transaction volume. Learn more about their PCI DSS merchant levels.

Payment Card Industry Compliance | Its much more than just PCI DSS

When people think of payment card industry compliance, they naturally think of PCI DSS compliance. And to be fair, the vast majority of organizations undergoing PCI DSS compliance are merchants and service providers who have to either conduct their own self assessment or go through an on-site assessment with a Qualified Security Assessor (QSA).

But here’s what else you need to know about payment card industry compliance and how it could affect you.

Payment Application Data Security Standard (PA-DSS)
The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS.

Pin Entry Devices (PED)
To gain approval by PCI Security Standards Council, PIN entry devices must comply with the requirements and guidelines specified by a number of documents listed on the PCI SSC website.

In summary, these are two additional compliance initiatives outside of the traditional PCI DSS assessments that many people are not familiar with. I’ll be covering these in a much more in-depth manner in subsequent blogs.

SAS 70 Compliant | Discussion on SAS 70 Auditing Methodologies

Being SAS 70 compliant is quickly becoming a requirement for many service organizations (i.e., companies that provide outsourcing to another entity) in today’s business arena. Many companies, however, voice frustration in not really understanding the audit methodology used and the process/roadmap for becoming SAS 70 compliant.

Let me distill some of these issues for you in better helping understand the auditing standard.

First and foremost, auditors who conduct SAS 70 audits use standards put forth by the AICPA and other approved governing bodies and “best of breed” corporate governance institutions (i.e. ISACA, IAA, etc.)

Additionally, what you need to know is that their is a commonly used “Roadmap” for SAS 70 compliance that consists of these sequential steps:

1. SAS 70 Readiness Assessment: Activities necessary for understanding your organization’s control environment, the scope of the audit and other essential areas.

2. Remediation: These are activities needed for becoming SAS 70 compliant. Generally, they include strengthening one’s control environment by utilizing any number of measures (additional security controls, policies and procedures, etc.)

3. Document Gathering: After steps 1 and 2 are completed, auditors need to gather documentation for the audit. This is a collaborative process that includes the auditor and the service organization undergoing the audit. This can take some time.

5. Fieldwork: Auditors will then arrive on-site to conduct fieldwork activities necessary for testing your internal controls in accordance with SAS 70 auditing standards.

6. Outcome of testing/drafting of report/discussion of findings: These are all activities that occur subsequent to fieldwork.

As one can see, being SAS 70 compliant requires the initiation of a number of steps for the audit process.

To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide.

SAS 70 Compliance | Tips on Scoping a SAS 70 Audit

SAS 70 compliance is commonplace for many of today’s businesses. Unfortunately, one of the missing ingredients in understanding SAS 70 compliance is the scope of the audit. That’s right. The who, what, when, where, and why of the actual SAS 70 audit process. Most service organizations undergoing a SAS 70 audit think that they are all the same, that is, one SAS 70 report should “look and feel” like another report. This is incorrect, as different industries and companies alike have varying requirements on what needs to be covered for SAS 70 compliance.

Here are some things you need to know to help determine SAS 70 scope:

1. What is the test period (if a SAS 70 Type II audit is being conducted)
2. Where are all the locations (physical offices, data centers) that will be included in the testing of the audit.
3. What is the audit actually COVERING? That is, is it a general controls audit or are their certain business processes that are being included in the scope of the audit? (This is essentially one of the biggest scoping issues you need to understand and come to an agreement on).

To learn more about SAS 70 compliance and scoping, visit the official SAS 70 Resource Guide.