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.]]>
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.]]>
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?]]>
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.]]>
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.]]>
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]]>
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.]]>
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.]]>
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.]]>
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.]]>