Regulatory Compliance, Governance and Security


February 11, 2009  10:27 PM

PCI DSS Requirement 10: Regularly Monitor and Test Networks

Charles Denyer Charles Denyer Profile: Charles Denyer

Payment Card Industry (PCI) Data Security Standards (DSS) compliance is often not a black and white assessment. Sure the PCI council gives you the complete assessment document, which fully explains each of the twelve (12) requirements and what is needed for validating each of these respective areas. However, it’s one thing to read them, its a another to truly understand what they mean.

Take PCI Requirement 10: Regularly Monitor and Test Networks. The question often asked to me as a Qualified Security Assessor (QSA) is: What do you want to see logging and audit trails for, that is what systems….and if we’re not logging and producing audit trails, then EXACTLY what system components do we need to start doing this for”? And in all honesty, this is a great question. It’s the who, what, when, where and why for requirement 10.

My initial answer is the following: You need to truly “identify” all system components in the cardholder environment, thus you need to be able to configure and establish logging and audit trail mechanisms for these “system components”. Remember, “system components” are just that, any “system (hardware, software, etc” used in the cardholder environment. So, at a minimum logging and audit trails NEED to be established for the following:

1. Network Devices (firewalls, routers, etc.)
2. Operating Systems (UNIX/LINUX, Windows)
3. Applications on these Operating Systems that support the “cardholder environment”
4. Databases that support the cardholder environment where data is written and saved to.

Remember, this is just a starting point and the above four (4) items are MANDATORY in my view, with many other “system components” that could truly be in scope.

February 9, 2009  2:04 AM

PCI Compliance Strategic Plan | How to Become Compliant | PCI DSS

Charles Denyer Charles Denyer Profile: Charles Denyer

Need to be Payment Card Industry (PCI) compliant in 2009? Are you a Merchant, Service Provider, Third Party Processor or some other Third Party outsourcing entity involved in the process, storing, or transmitting of payment and creditcard data? If so, listen up, because you need to develop a PCI compliance strategic plan that fits your organization. How so? By following these simple steps.

1. First and foremost, you need to find out exactly what level you fall under for purposes of PCI compliance. Take a quick look at these charts for finding out your transaction volume. When you’ve identified your level, then find out what is required of you.

2. If you need an actual onsite PCI DSS assessment by a Qualified Security Assessor (QSA), then its time to roll up your sleeves and find one. If you can self-assess with a Self-Assessment Questionnaire, known as the “SAQ”, then you may still need some guidance from a QSA; it all depends on your comfort level and how much you can accomplish on your own.

3. Good luck. Remember, if you get into a jam, a QSA can always help with your PCI Compliance strategic plan.


February 8, 2009  3:11 PM

PCI Security Standards | Learn How to Become PCI Compliant

Charles Denyer Charles Denyer Profile: Charles Denyer

Payment Card Industry (PCI) compliance is becoming a force to reckon with, to say the least. It seems as if every possible and conceivable industry in the country is being affected by PCI compliance, either directly or indirectly. What’s important to note about PCI compliance is that it primarily affects merchants, service providers, third party processors, and other third party outsourcing entities that are involved in the storage, transmission, or processing of cardholder and payment data.

Before you jump off a bridge because of the costs and time involved with PCI compliance, take a deep breath and look at it in a practical manner. The PCI security standards, official known as the Payment Card Industry Data Security Standards (PCI DSS v1.2) illustrates exactly what needs to be accomplished and validated for PCI compliance, if you have to have an onsite PCI assessment. If you don’t and you can essentially “self assess”, then you can simply obtain the “self assessment” questionnaires.

So how do you know if you need an onsite PCI assessment done by a QSA or a “self assessment questionnaire”? Well, find your transaction volume for processing credit cards, and that will give you the answer.

Once you’ve don that, you will be on your way to clearly understanding what needs to be done for purposes of PCI compliance.

To learn more about PCI compliance, the onsite PCI assessments and the different PCI “self assessment questionnaires” contact me directly and i will assist you in any way i can.


February 8, 2009  2:59 PM

SAS 70 Audit Guide | Learn the Secrets to SAS 70 Audits

Charles Denyer Charles Denyer Profile: Charles Denyer

Need to learn about SAS 70 audits? Not too sure about what the audit actually entails in regards to scope, time, effort and financial considerations? Well, if your organization is seeking to become SAS 70 Type I or Type II compliant for 2009 and beyond, then its a good idea to start educating yourself on the particulars of SAS 70 audits. The more informed and educated you are, the greater your success in going through a SAS 70 audit for your organization in a timely, efficient, and cost-effective manner.

Helpful suggestions on learning about SAS 70 audits include the following:

Know the difference between a Type I and Type II audit
Learn about pricing for SAS 70 audits
Understand and comprehend the meaning of audit “scope”
Learn about a SAS 70 Readiness Assessment and how it can help augment the overall audit process for Type I and Type II reports.

Keep in mind that all organizations are different, as such, your SAS 70 requirements and what you essentially need to “get out” of your report could be significantly different from another company. For example, are you just looking to “check the box” for a compliance report or are you actually seeking value out of your SAS 70 audit.

Visit the official SAS 70 Resource Guide to learn more about SAS 70 Type I and Type II audits.


February 7, 2009  12:04 AM

Payment Card Industry Compliance (PCI) | What’s in store for 2009?

Charles Denyer Charles Denyer Profile: Charles Denyer

Payment Card Industry (PCI) Data Security Standards (DSS) compliance will no doubt continue to grow in 2009 and beyond. The number of merchants, service providers, and other third party processors/third party providers needing the PCI stamp of approval will continue to grow, based on varying industry and business circumstances.

What all entities need to be aware of are the following:

Understanding what level of PCI DSS compliance is needed. This is based primarily on the “transaction volume” your business does on a yearly basis.

If you do have to go through an official on-site assessment by a Qualified Security Assessor (QSA), then you need to be able to find the right QSAC firm who can truly help you understand what compliance entails, what the roadblocks could be and what are some of the hidden costs that most organizations are simply not aware of.

If you want to learn more about Payment Card Industry Compliance, then visit pciassessment.org


January 30, 2009  9:33 PM

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

Charles Denyer Charles Denyer Profile: Charles Denyer

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.


January 30, 2009  12:15 AM

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

Charles Denyer Charles Denyer Profile: Charles Denyer

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.


January 29, 2009  1:09 PM

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

Charles Denyer Charles Denyer Profile: Charles Denyer

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.


January 28, 2009  1:03 PM

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

Charles Denyer Charles Denyer Profile: Charles Denyer

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


January 28, 2009  12:47 PM

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

Charles Denyer Charles Denyer Profile: Charles Denyer

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.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: