PCI DSS compliance is becoming a requirement for many service providers involved in the processing, storage, transmission, and switching of transaction data and cardholder data.
In short, a service provider, for purposes of Payment Card Industry Data Security Standards (PCI DSS) compliance includes companies that provide services to merchants, to other “service providers” or are other entities that control OR could impact the security of cardholder data.
So, here are some common examples of service providers:
Customer Service Entities, such as Call Centers
Managed Service Providers
Web Hosting Providers
Independent Sales Organizations (ISO’s)
And you may also want to know that the major payment brands (VISA, MasterCard, AMEX, Discover Card, and JCB) have different “terms” for service providers.
AMEX-They are called a “Third Party Processor”
Discover-They are called a “Third Party Processor” and a “Payment Service Provider”
Mastercard-They are called “Third Party Processors” and a “Data Storage Entity”
VISA-They can be called a “VisaNet Processor”, which is considered everybody that connects to VISA.
SAS 70 audits, especially Type II reports and PCI DSS Level 1 Report on Compliance (ROC) assessments are dominating today’s regulatory compliance arena. Painfully, as a SAS 70 auditor and a PCI DSS assessor, I keep hearing people talk about these two compliance initiatives as if they are one in the same…..stop…….they are different.
Don’t get me wrong, efficiencies of scale can be had and I will talk about that in a later post, but generally speaking, this is like comparing apples to oranges. Here’s why.
The SAS 70 auditing standard is a loose and flexible standard, allowing auditors to employ (and they do) various methodologies, benchmarks, standards, and frameworks for SAS 70 audits.
The Payment Card Industry Data Security Standards (PCI DSS) requirements are much more rigid, less open to interpretation, if you will.
Ever read one SAS 70 report from a CPA firm then picked up another report on a similar company that was issued by another CPA firm? If so, you probably noticed they looked and “read” quite differently. Well, no surprise there.
Now, try that with a PCI DSS Level 1 Report on Compliance. Sure, they won’t be identical, but they’ll be much more similar than the two SAS 70 audits.
The SAS 70 auditing standard is sure to become a necessary element of the proposed changes for the Investment Advisers Act of 1940. The SEC released a draft of proposed changes regarding “Custody of Funds or Securities of Clients by Investment Advisers” (File No. S7-09-09). In short, this comprehensive document is proposing the use of “surprise examinations” and a “internal control report” on entities that have custody of client funds or securities or instead serves as a qualified custodian for client funds or securities.
Currently the “surprise examination” is discussed as a “written report from an independent public accountant” while the “internal control report” is being described as that of a SAS 70. At this point, what distinctions will be made, if any, between the auditing framework for the “surprise examination” and “internal control report” are not completely clear. More than likely, the SAS 70 auditing standard will be utilized for both the “surprise examination” and the “internal control report”.
You can obtain a sample SAS 70 Type II Report and list of sample custodial control objectives by visiting the SAS 70 Resource Guide.
Policies and Procedures-it’s such a common theme and phrase in today’s regulatory compliance and governance arena, so much so, i think it should have it’s own Wikipedia page. It can be an arduous undertaking in developing these documents. Furthermore, policies and procedures are becoming increasingly larger and larger in scope for compliance initiatives.
Take a look at Requirement 12 for PCI DSS compliance; Maintain an Information Security Policy. It’s quite detailed, to say the least. Furthermore, there are numerous other P&P requirements sprinkled throughout the other 11 PCI DSS requirements.
As for SAS 70, the audit’s success also depends on policies and procedures for a large range of items. A few examples of common P&P documents that may fall under the scope of a SAS 70 Type I or SAS 70 Type II audit are as follows:
Change Management P&P
An organizational wide security policy handbook with documented P&P
To be blunt, most organization despise authoring these documents for a number of reasons: time, cost, or the simple inability to write effective P&P documents.
Even with that said, organizations need to be aware of the growing requirements for P&P for SAS 70, PCI DSS, and a whole host of other regulatory compliance mandates.
The SEC released a draft of proposed changes regarding “Custody of Funds or Securities of Clients by Investment Advisers” (File No. S7-09-09), calling for more oversight and controls over investment advisers or related persons who have custody of client funds or securities along with performing custodial duties and operations.
In short, the proposed changes will possibly require a “surprise examination” and an “internal control report” on these very entities that have custody of client funds or securities along with performing custodial duties and operations.
The proposed control objectives are as follows:
• Physical securities are safeguarded from loss or misappropriation;
• Cash and security positions are reconciled accurately and on a timely basis between the custodian and depositories, and between the custodian and accounting systems;
• Client-initiated trades are properly authorized and recorded completely and accurately in the client account;
• Securities income and corporate action transactions are processed to client accounts in an accurate and timely manner;
• Net settlement procedures for delivery and receive transactions are performed accurately;
• Documentation for the opening of accounts is received and authenticated, and established completely and accurately on the applicable system; and
• Market values of securities obtained from various outside pricing sources have been recorded accurately in client accounts.
If you want to learn more about these proposed changes and would like to receive a sample SAS 70 Type II report, then visit the official SAS 70 Resource Guide at sas70.us.com.
The SAS 70 auditing standard looks to become a vital component of the proposed changes for the Investment Advisers Act of 1940. In short, the recent scandals and ponzi schemes that resulted in the loss of billions of dollars for investors is receiving a wakeup call from the Securities and Exchange Commission (SEC).
The SEC released a draft of proposed changes regarding “Custody of Funds or Securities of Clients by Investment Advisers” (File No. S7-09-09). This lengthy document is proposing the use of “surprise examinations” and a “internal control report” on entities that have custody of client funds or securities or instead serves as a qualified custodian for client funds or securities.
Currently the “surprise examination” is discussed as a “written report from an independent public accountant” while the “internal control report” is essentially described as a SAS 70. Though still in the proposal stages (and waiting on comments from the industry, which are due by July 2009), two things are almost certain: 1. There will be more regulatory oversight and 2. the SAS 70 auditing standard will likely be utilized for both the “surprise examination” and the “internal control report”.
If you are an investment adviser or related person that has custody of client funds or securities and you perform custodial operations, then it is time to understand the SAS 70 audit process and how it will impact your organization. You can obtain a sample SAS 70 Type II Report and list of sample custodial control objectives by visiting the SAS 70 Resource Guide.
Payment Card Industry Data Security Standards (PCI DSS) Level 1 compliance can be a very arduous, time-consuming and costly undertaking for any organization. However, there are a number of proactive steps that should be put in place for helping ensure an efficient and transparent assessment process is in place.
I stress the word “transparency” because the more information you provide a PCI QSA, the better understanding her/she will have when engaging to conduct the PCI DSS Level 1 assessment on your organization.
Here are some helpful tips:
1. Develop in-depth network topology documents that clearly illustrate the cardholder environment. Do not omit any “system components” from these drawings as PCI QSA’s need a true understanding of network topology.
2. Take a hard look at Requirement 12 of the PCI DSS standards-Policies and procedures play a big and important role in ensuring compliance for PCI DSS. If you do not have these PP in place, you need to start writing them internally, or expect to pay a king’s ransom for external auditors or consultants to write these documents for you.
3. Make a list of all external, third party vendors and outsourcing entities that your organization uses. This is important because data centers and other types of managed services entities often fall into the scope of a PCI DSS assessment.
If you want to learn more about PCI DSS compliance, visit pciassessment.org
PCI DSS Requirement 2 is the second out of 12 requirements of the PCI DSS initiatives. What’s important to note about PCI DSS Requirement 2 is that it deals largely with removing vendor supplied default password before putting these new system components on the network in the cardholder environment.
Specifically, as stated by the PCI DSS, Requirement 2 is stated in the following:
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Under this main requirement, which is essentially just a statement, are a number of “tests” that organizations have to undertake for ensuring they meet the demands of PCI DSS Requirement 2.
Many of the tests that are undertaken for PCI DSS Requirement 2 (and for many of the other requirements also) used the phrase “system components” often and often. You need to really understand what this phrase means, and, according to the official PCI DSS wording, “system components” is Any network component, server, or application included in or connected to the cardholder data environment.
You will see the phrase “system components” in Requirement 2 often, so again, understand what it really means. I will be delving much deeper into each of the 12 requirements, but am first giving readers a high level, common understanding of what each requirement actually means and will then circle back in the coming weeks and months.
If you want to learn more about PCI DSS compliance, visit pciassessment.org
PCI DSS Compliance is growing at an astonishing rate for merchants and service providers throughout the country and the globe.
Let’s take some time to distill each of the twelve (12) core Payment Card Industry Data Security Standards (PCI DSS) Requirements. This will be the first in a 12 part series of giving you a better understanding of each of the requirements and the sub-requirements for each.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
As stated by the Payment Card Industry Data Security Standards Requirements: All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employees’ Internet access through desktop browsers, employees’ e-mail access, dedicated connection such as business to business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide
unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.”
Okay, fair enough and with that said, as a Payment Card Industry Qualified Security Assessor (PCI QSA), here’s what you need to be aware of for Requirement 1:
1. Have in place an excellent network topology diagram.
2. Make sure you develop the documented policies and procedures that are being called for in Requirement 1
3. When deploying and hardening network devices, (routers, firewalls,etc.), please keep in mind that you need to be documenting this process along with utilizing industry accepted configuration guidelines , such as SANS, NIST, CIS.
This is just a start and by no means all the items for Requirement 1, but being aware of these issues will greatly help you meet the guidelines for PCI DSS Requirement 1.
SAS 70 audits are being performed at a record pace these days on data centers, managed service providers and co-location entities. The big question is why? Well, there are many general answers that we all hear, such as “Oh, it’s just today’s compliance environment” or “SOX has really affected our business”.
Sure, these are true statements, somewhat boiler plate, but they are true.
In reality, dig a little deeper and stretch a little further into the insight and analysis and you will find that a large number of entities are operating in a Software as a Service (SaaS) mode and function, which essentially has resulted in the explosive growth for many data centers. These companies who have a SaaS business model are being hit quite hard by the SAS 70 compliance mantra from their clients and as such, the down stream effect is that data centers are now included in the scope of many SaaS entities. Amazing what 2 to 3 years can do to the I.T. industry. I say this because it was not that long ago (2005 or so) that a large number of Data Centers were not SAS 70 compliant…and i argue that a big reason for this change has been that SaaS entities occupy racks and racks of space now days.
So there is your SAS 70 and SaaS connection.
But hey, as a SAS 70 Auditor, it’s just my opinion.