January, 2009

PCI DSS Compliance | What is the “Cardholder Environment”?

Regarding PCI DSS compliance, i’m often asked as a PCI QSA what is the cardholder environment? In essence, people are wanting to know what is in scope and how do you determine scope. To be honest, it is not at all a clear black and white answer; so many variables come into play, the biggest being the growth of outsourced third party providers, such as managed service providers, data centers/co-location entities, among others.

As for the entities and organizations that are in scope, it is essentially any organization that is directly involved in the processing, storage, or transmission of transaction data or cardholder data.

Regarding the actual cardholder data itself, think of any systems that support the transaction or storage of carholder data. Any “system components” that cardholder data travels across or any “system component” where cardholder data resides is in scope.

One can quickly see how other third party providers can very easily be brought into the scope of the audit. Talk to your Qualified Security Assessor (QSA) as he or she should have the knowledge to know what is in scope regarding the organizations involved in the process and what the actual “system components” are for the cardholder environment.

SAS 70 Type II Audits | A Discussion on Pricing | Auditor’s Expert Opinion

SAS 70 pricing is much like that of a roller coaster ride. I’ve personally seen the wild swings in the market within the last 3 to 5 years. How volatile has pricing been? Quite a bit and it’s based on a number of issues currently facing the market. Thus, the more informed you are, the more information you will have to make an informed decision on who to use and why.

As recently as three years ago, the number of providers were relatively small, thus fees were at a level where not much compromise was given by CPA firms in regards to pricing. Well, the SAS 70 fanfare is alive and now well, with dozens and dozens of firms providing these audits. And truthfully, its justifiable to see prices come down as more competition results in lower fees. Hey, it is capitalism, right?

Please be aware though that there are a number of CPA firms practicing in states without licenses. Additionally, many of these CPA firms never actually do the work; rather they use outsourced personnel. In short, if you receive a low fee, be cautious because they may not of gone through the licensing requirements for a respective state and may simply be outsourcing the work to I.T. contractors at greatly reduced rates. These conditions, and more, affect the quality of the report and the validity of the report, so buyer beware. This is just an introduction to the pricing issue. Stay in touch, as I will have much, much more to say on this issue regarding SAS 70 audits.

California Security Breach Information Act (SB-1386) | What You Need to Know.

In short, the California Security Breach Information Act (SB-1386) is a California state law requiring organizations that maintain personal information about individuals to inform those individuals if the security of their information has been breached or compromised. thus, the Act stipulates that if there’s a security breach of a database containing personal data, the responsible entity must notify each and every individual for whom it maintained the information for. The Act, which went into effect July 1, 2003, was created to help stem the alarming growth of identity theft, which has many consumers on the edge and frightened concerning the protection of their personal data.

Here’s what’s important to grasp for a regulatory compliance aspect. The California SB-1386 is a trend that is sweeping the nation and will only continue to grow as concerns for the security of confidential information become more paramount. Gov. Tim Pawlenty signed the MN Plastic Card Security Act, essentially codifying parts of the Payment Card Industry Data Security Standards (PCI DSSS) into law.

Auditors need to be aware of these rules and regulations and their overall impact they can have on an audit, be a SAS 70 audit, HIPAA or GLBA audit or even a PCI DSS Assessment.

SAS 70 Audits and PCI DSS Compliance | A Two for One Audit? Not Quite

As an accountant and a PCI Qualified Security Assessor (QSA), i’m seeing more and more auditors essentially provide audit and fieldwork services for both a SAS 70 and a PCI DSS assessment at the same time, then issue a PCI DSS Report on Compliance (ROC) and a SAS 70 Type II Service Auditor’s Report. While I am all for audit efficiencies, there does need to be some degree of engagement independence, both in an administrative manner (different engagement letters, etc.) and in terms of audit expertise (both CPA’s and QSA’s need to be involved in their respective assignments and committed to the work at hand).

Furthermore, SAS 70 audits will also examine areas not covered by PCI DSS assessments, and the same is true for PCI DSS assessments covering technical areas traditionally not under the scope of a SAS 70 audit. As professionals, we need to be careful in not blurring the lines and distinctions between CPA’s and QSA’s and still try to maintain professional indepedence in regards to the work that each does and what they are qualified to do.

To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide.
To learn more about PCI DSS assessments, visit pciassessment.org

PCI DSS Requirement 1.1.2 | Network Diagrams | Easier Said Than Done

PCI DSS Requirement 1.1.2 is an often overlooked area within the PCI framework for assessment. That’s also a shame because it’s such a critical component for helping lay the groundwork for true clarity and transparency for the assessment itself. The problem with most organizations that have network diagrams and topology documents in place is that they are old, outdated, too high-level, void of the necessary detail you need to clearly help understand the cardholder environment for purposes of PCI DSS compliance. A good rule of thumb is to include as much information in the network diagrams and topology documents for helping assess scope and all “system components” that are directly or indirectly related to the storage, transmission, or processing of cardholder data.

Take a look at this comprehensive list I recently put together for a client regarding his network diagram and topology documents. I asked the organization to clearly identify and illustrate these system components in their drawings:

• List of ll IP Addresses in use
• Firewalls
• Demilitarized Zone (DMZ)
• Routers and Switches
• Intrusion Detection Systems (IDS)/Intrusion Prevention Systems (IPS)
• Any enterprise wide applications (CRM systems, etc.)
• Remote Access
• Data transmission methods used for data traversing back and forth on the network
• Wireless Networking or Networks
• Web Servers
• Proxy Servers
• Email Servers
• DNS Servers
• Operating Systems
• Databases
• Applications
• Anti-virus

Quite a list, but then again, it tremendously aids in the overall PCI DSS assessment, not to mention sufficing for PCI DSS Requirement 1.1.2.

PCI DSS Compliance | Understanding Cardholder Data and What Information to Store

Payment Card Industry Data Security Standards (PCI DSS) compliance is everywhere these days, or so it seems. As a result, there seems to be some confusing information on what CAN and CANNOT be stored regarding cardholder data. Folks, there really should not be any gray area on this, as the rules and regulations are quite straightforward and black and white. Okay, so here we go. Regarding cardholder data, this is what you CAN store, but it also MUST be protected: The Primary Account Number (PAN), the cardholder name, the service code, along with the expiration date.

So, what CAN’T you store (however, there are exceptions)? Here they are: Full Magnetic Stripe/Track Data, CVC2, CVV2, CID, CAV2 (what are these you ask, the numbers that merchant will often ask to help complete and authorize the transaction, you know, those secret numbers on your card :), and finally you cannot store PIN/PIN block information.

So there you have it. If you want to learn more about the Payment Card Industry Data Security Standards, then visit pciassessment.org

Payment Card Compliance | PCI DSS | Tips on Passing your PCI DSS Assessment

Regarding PCI DSS, as a PCI QSA i’m often asked what’s the most difficult hurdle that organizations need to overcome for ensuring PCI DSS compliance. Well, we could talk at length about some of the technical, I.T. challenges, such as two-factor authentication, encryption (though not required.lol!). But in all seriousness, organizations are very deficient on having documented policies and procedures in place for their critical infrastructure. From change management to tape/media backup and recovery procedures, many organizations fail to have these very policies and procedures documented in an organizational wide corporate security document, or something of a similar nature, such as online WIKI.

So, why is this such a repetitive and persistent problem for companies? For the most part, it has to do with the lack of expertise in writing these documented policies and procedures along with finding the time to do them. They can be painstakingly slow and arduous to complete. The solution; hire a firm that have experience and expertise in developing and writing policies and procedures for PCI DSS and for any other regulatory compliance mandate your company may encounter, such as SAS 70 audits.

PCI DSS Compliance for Merchants and Service Providers | Compliance is MANDATORY

That’s right. Compliance for the Payment Card Industry Data Security Standards, simply known as PCI DSS, is mandatory for all merchants and many service providers. How mandatory? Enough for MN Governor Tim Pawlenty to sign into law and codify various provisions of the PCI DSS mantra. Mandatory in that even small merchants processing only a handful of payment transactions (credit, debit, gift cards) have to conduct their own self-assessment for PCI DSS, or obtain help from an external PCI QSA or other qualified payment card specialist. The just of it is this-PCI DSS compliance is not going away, rather, it will only become more paramount in the years ahead. The key to comply with PCI DSS is to know what level you fall under regarding compliance and what needs to be done for that respective level of compliance. Turn to pciassessment.org to learn all you need to know about the Payment Card Industry Data Security Standards compliance.

Payment Card Industry Data Security Standards | PCI DSS | It’s the LAW in Minnesota

The Minnesota Plastic Card Security Act, signed by MN Governor Tim Pawlenty, essentially has codified various parts of the Payment Card Industry Data Security Standards (PCI DSS) into law. What’s interesting to not is not so much the specifics of what the law actually has to say, but rather it is a sign of a growing trend that is sweeping the nation in many states. Texas and California also have PCI DSS on their minds, as witnessed by recent legislative attempts in these two states to take action on the PCI standards. This essentially, is a sign of the times, as individuals and businesses alike are demanding more security into today’s heightened technology world we live in. The dollar amount being processed by payment cards (debit, credit and gift cards) is absolutely staggering and will only continue to rise in the coming years. The PCI DSS standards, which evolved out of the former VISA CISP data security standards is here to stay and will only grow over time. As a PCI-QSA, my advice to merchants and service providers who have to become PCI DSS compliant. Learn all you can about the PCI DSS standards and how they ultimately affect your organization. Remember, knowledge is power.

SAS 70 Audits & Data Centers | Tips on Preparing for the Audit

Today’s data centers and managed services providers are complex businesses, providing customers with a wide array of services. As such, SAS 70 audits have become the standard compliance audit for assessing internal controls for data centers and managed services. But buyer beware, not all SAS 70 audits are the same when being conducted on data centers and managed service providers. So, what’s the scope, you say? Well, generally speaking a good quality SAS 70 audit process and its subsequent report should include the following areas for considerations of controls:

1. Executive Management/Strategic Management Drivers
2. Human Resources
3. Quality Assurance Activities
3. Client Contract Processes
4. Technical Client Provisioning Processes and Activities
5. Change Management
6. Incident Management
7. Logical Security
8. Network Security
9. Shipping and Receiving Management
10. Physical Security
11. Environmental Security

Any SAS 70 conducted on data centers, managed services providers and co-locations entities that encompass the following above referenced areas can be considered a quality audit and report, at least in terms of scope. It’s then up to the CPA firm conducting the audit to actually perform testing for these above referenced areas, but that’s a whole other topic of discussion for a later date.

To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide.
To learn more about PCI DSS assessments, visit the Payment Card Industry (PCI) Resource Guide.