February, 2009

SAS 70 Internal Controls | Important Facts and Tips to Know

SAS 70 audits test a wide array of internal controls within your organization for helping ensure SAS 70 Type I or Type II compliance. What’s interesting to note about these “internal controls” is that you need to truly understand what they are and how they relate to the “control objectives” being tested for during the SAS 70 audit.

Technically speaking, internal controls are: A process, affected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in various categories.

In more simpler terms, internal controls for SAS 70 audits can be best viewed as the processes, procedures, and related activities that YOUR organization has in place for ensuring that a structured, safe, sound, and secure “control environment’ is in place. In short, is your organization dotting your I’s and crossing your T’s when it comes to daily operations within your organization.

Now, there are a “best of breed” agreed up control objectives and related internal controls that should be used for SAS 70 audits, which you obtain from a quality CPA firm specializing in SAS 70 audits.

However, not all CPA firms use the same control objectives and technically, its really up to the organization undergoing the SAS 70 to actually construct, develop, and agree upon what there internal controls and control objectives would be. In reality, good quality CPA firms can help you with this. It’s really a colloborative process, to say the least, regarding SAS 70 internal controls.

PCI Policy and Procedures Documents | You Need them for PCI DSS

PCI policy and procedures documents are extremely critical in achieving Payment Card Industry (PCI) compliance. How critical? Enough that an entire requirement for PCI is dedicated to developing an information security program. In fact, requirement 12: Maintain a policy that addresses information security for employees and contractors, requires just that, developing these policies and procedures.

But hold on, it is much more than just PCI DSS Requirement 12; there are a number of other areas sprinkled throughout the PCI DSS requirement that “require” documented policies and procedures on a wide array of items. News to you? Maybe, maybe not. Either way, writing these PCI policy and procedures documents take time, alot of time.

Add to the fact that because every organization is different, you can not simply stamp on a one size fits all approach; it does not work that way. You need to spend time customizing the policy and procedures document so they fit your organization’s needs.

Sure, you can start with some broad based themes and templates, but you will really have to roll your sleeves up to grind out the details in achieving the true “spirit” of these documents.

What is SAS 70 | A Question I’m Often Asked by Service Organizations

What is SAS 70? For us in the regulatory compliance and Information Technology world, this would be an absurd question. Well, put yourself in the shoes of businesses who work hard everyday, struggling to make ends meet, and then suddenly, they’ve been told they need a SAS 70. A SAS what? I field these calls everyday from the curious minded individuals who have now come to find themselves locked into the regulatory compliance game that many service organizations have come accustomed to.

So, then. What is SAS 70? Well, its an auditing standard put forth the American Institute of Certified Public Accountants (AICPA) in 1992, which is used to report on controls placed in operation and (if need be), tests of operating effectiveness. English please, right? Okay, in more simpler terms, its an audit that is used to test a number of controls (i.e., “checks and balances” you should have in place) throughout your organization.

To add to this, there are TWO types of SAS 70 audits; a Type I and a Type II. Most organizations having to comply with and go through a SAS 70 audit ultimately prepare for a SAS 70 Type II audit.

Okay, these are the basics, to learn more, visit the official SAS 70 Resource Guide, where you can learn all you need to know about SAS 70 audits to help answer that ever important question-What is SAS 70?

PCI Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data | What You Need to Know

For Payment Card Industry (PCI) compliance, there are twelve (12) core, functional requirements mandated under PCI DSS v1.2. What’s important to note is that many times you truly need to “read between the lines” to interpret, comprehend, and understand what the PCI DSS standards are actually stating, and asking you to validate.

Take PCI Requirement #1: Install and maintain a firewall configuration to protect cardholder data. If you read all the requirements and the tests that accompany each requirement, it seems to sound quite straight forward. Well it is and it isn’t. The “isn’t” part lies in the ability to interpret some testing that really has not been spelled out for you. For example, throughout requirement #1 it tells you to “examine” and “verify” a whole host of configuration settings for network devices, particularly firewalls and routers. So how should you interpret “examine” and “verify”. As a Qualified Security Assessor (QSA) for PCI, I can tell you that just simply asking for the rulesets and configuration documents is simply not enough. You have to actually examine, interpret, read, and dissect the rules and configurations settings, match them against the test criteria, along with using the network topology documents (that should be developed) as further evidence. In short, simply printing out rulesets, throwing them in a folder as audit evidence and moving on to the next phase of the PCI is not going to cut it. If you want to brush on truly understanding rulesets and the configuration of network devices (routers, firewalls, load balancers, etc.), CISCO and JUNIPER and other network device providers have a host of free information on the internet.

To learn more about PCI DSS compliance and Requirement 1 and other areas of the PCI DSS v.1.2 standard, then visit PCIassessment.org.

PCI DSS and SAS 70 Audits | Audit Efficiencies? Maybe…just Maybe

As a SAS 70 auditor and a PCI QSA, i’m often asked about the efficiencies of scale that can be achieved with SAS 70 audits and PCI DSS assessments. I have blogged about this a few times before, so let me be more clear and transparent in what i believe can actually be obtained in regards to audit efficiencies when conducting a SAS 70 and a PCI DSS assessment on an entity.

First and foremost, as an auditor, there should still be independence within the SAS 70 audit and the PCI DSS assessment. Independence how? Simple, do not treat them as one audit, because they are simply not that. Technically speaking, a PCI assessment is just that, an assessment, not an audit, which requires “attestation”. Moreover, there are significant differences between the audit and the assessment, which can be discussed at length (and will be) in a whole different blog.

I stress in the title of this blog that “maybe” there can be audit efficiencies, however, it many times is dependent on the quality of the auditors, their expertise in both conducting a PCI and a SAS 70 audit, and how much they are willing to rely on evidence from the PCI DSS assessment for the SAS 70 audit, and vice versa. Good auditors will find ways to create these efficiencies; other auditors might want to conduct a PCI DSS assessment and rubber stamp a SAS 70-this is a BIG NO NO.

Want to learn more about where these efficiencies of scale can be maximized? To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide and to learn more about PCI DSS Assessments, visit the PCI Resource Guide.

Payment Card Industry (PCI) Compliance | Much More than just I.T.

That’s right. Payment Card Industry (PCI) compliance is much more than just I.T. and all the surrounding hardware and software components that make up the “system components” within the cardholder environment. I’ve just recently finished up a PCI Readiness Assessment for a client on the West Coast and guess what happens to be there most significant and time consuming remediation activity? The writing of documented policies and procedures for numerous requirements as set forth and promulgated by the PCI DSS v.1.2 standards. That’s right, they can be painstaking, arduous, and time consuming. Even worse, most I.T. security professionals really do not like to consume themselves with this daunting task.

So remember, when you are are all caught up in the PCI game and you are so focused on routers, switches, load balancers, and other network and system devices, make sure you focus on the much needed policies and procedures that are sprinkled throughout the PCI DSS requirements. My advice, hire a seasoned Qualified Security Assessor (QSA) to write them for you, you’ll be glad you did.

And if you don’t believe me, take a look at Requirement 12: Maintain a Policy that Addresses Information Security.

To learn more about Payment Card Industry (PCI) compliance, visit pciassessment.org

PCI DSS Requirement 10: Regularly Monitor and Test Networks

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.

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

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.

PCI Security Standards | Learn How to Become PCI Compliant

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.

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

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.