Archive for July, 2009

26
Jul
09

SAS 70 and PCI

One of the most misunderstood standards is the American Institute of Certified Public Accountants (AICPA) Statement on Auditing Standards number 70 (SAS 70).  I intend to explain this standard and show how it can be applied to the PCI compliance process.

It is important to understand that the SAS 70 is a financial accounting standard and is considered an attest service in the audit community.  As an attest service that means that the auditor issues an opinion regarding the control environment.  This attestation is not a certification such as those an organization gets for ISO.  The SAS 70 standard was developed so that financial auditors did not have to go out and conduct an audit of every outsourcer that a client might use.  This saves the outsourcer of having multiple audits conducted mostly in the last quarter of the year.  However, being a financial audit standard, it does not have to cover everything that you will need to complete your PCI compliance process.  Even with the SAS 70 report, you will likely have to go back to the outsourcer with additional questions.

A key point about SAS 70 is that there must be a material financial impact to your company in order to justify a SAS 70 report from an outsourcer.  This is why outsourcers such as those that process your organization’s payroll or serve up your financial software will have a SAS 70, but your telecommunications provider or the company that monitors the security of your facilities likely does not have a SAS 70.  As a result, not every outsourcer will have to provide your organization a SAS 70 report.

A SAS 70 can come in two varieties, Type I and Type II.  A SAS 70 Type I report only attests to the description of the outsourcer’s control environment.  The auditor conducts no independent testing of the control environment and therefore does not express an opinion on whether or not the control environment is functioning properly.  For PCI compliance a Type I report is worthless, as you need the testing to have any chance of using the report.  A Type II report will have a section devoted to the tests that were conducted to confirm that the control environment is functioning properly and the outcome of those tests.  However, since the testing in a Type II report will be focused on key financial controls that do not necessarily involve PCI, a Type II report may also be worthless to your PCI compliance efforts.

Just like its financial audit report brethren, there is a correct way to read a SAS 70.  The first thing you should read is the cover letter to the report, otherwise known in auditing circles as the opinion letter.  The opinion letter will tell you the locations reviewed, the time span of the report, whether the report is a Type I or a Type II and whether or not there were material issues found during the audit.

The locations reviewed are very important.  If your organization is hosted out of the outsourcer’s data center Q and it was not reviewed in the SAS 70 report, then you need to get the SAS 70 report that covers data center Q.  Unlike the PCI ROC, which covers an organization’s compliance at a given point in time, a SAS 70 report is for a period of time known as the opinion period.  The opinion period can be as little as three months and typically as much as 12 months.  Most SAS 70 reports are for opinion periods of six to 12 months.  For financial auditors, they can only accept SAS 70 reports that cover all or part of their audit client’s financial audit period.  For PCI compliance, it is up to you to determine if you are willing to accept the SAS 70 report.  If you have a QSA conducting your assessment, it is up to the QSA to accept the report.

The opinion letter will not expressly use the terminology of Type I or Type II.  To determine the type of SAS 70 report, you will need to read the letter and look for where it says, “We did not perform procedures to determine the operating effectiveness of controls for any period” or similar wording.  That will indicate that the report is a Type I and is not usable for you PCI compliance.

There are three opinions that an auditor can provide; unqualified, qualified and adverse.  An adverse opinion is the worst and means that the control environment is not operating as designed and the controls cannot be relied upon.  I have never seen an adverse opinion ever publicly issued, but you need to be aware that it does exist.  A qualified opinion means that some controls are not operating as designed.  The opinion letter will document those controls that failed and why they failed.  The best opinion, unqualified, means that the control environment is functioning as designed and that none of the controls failed testing.  Remember, just because an outsourcer gets an unqualified opinion, does not mean that the controls operate that way all of the time.  It just means that the auditor through their testing techniques was not able to observe any conditions that would indicate that the controls were not functioning.  The phrase ‘reasonable but not absolute assurance’ is how auditors refer to the ability of their testing to detect any flaws in the control environment.  What this means is that they construct their tests such that there is a high likelihood that any flaws in the controls can be detected, but that these testing procedures are not perfect.

Once you have read the opinion letter, you need to read the testing section to see if the controls that you need for your PCI compliance were tested and if the tests are ones that are relevant to your PCI compliance.  The most common tests that everyone needs are related to physical security and environmental controls at the data center. All of these are necessary for all outsourcers.  Additional control testing will be required if your outsourcer provides services beyond just housing your technology, so you will be interested in controls surrounding those additional services.  Many organizations are now adding PCI, Gramm Leach Bliley Act (GLBA) and Sarbanes Oxley (SOX) tests to their SAS 70 reports to help their customers meet the majority of their compliance requirements.  This is a relatively new practice and the adding or changing tests can radically affect the price of an organization’s SAS 70 report, so it is still rare to find many of the controls tested for these other compliance areas.

When reviewing the control tests, the auditor will usually mark the test as “No Relevant Exception Noted” if the test was passed.  In cases where an issue was noted, the issue will be documented.  If the issue is determined to not be systemic, it will typically be noted in the testing notes and will not result in a qualification.  If a single issue is deemed by the auditor to be systemic or a group of issues lead the auditor to believe there is a failure of controls, then a qualification will be generated.  A qualification is not an indication of a bad organization; a qualification just indicates an area that requires improvement.  However, depending on the controls qualified, you may feel that your outsourcer has issues in meeting their PCI compliance obligations.

The final area that should be reviewed is a section labeled ‘User and User Auditor Considerations’.  Not all SAS 70 reports have such sections but those that do are typically invaluable to the user organization.  This section describes the controls that your organization needs to have in place and functioning in order for the outsourcer’s control environment to function as described in the SAS 70 report.  This is similar to the purpose of the Implementation Guide required in the PA-DSS.  Without this section, your organization would not know its responsibilities for creating complimentary controls so that the controls in place at the outsourcer remain functional and effective.

Entire books have been written on the SAS 70 process.  I hope that I have given you an eye into the process and how you can use it to reduce the amount of work to meet your PCI compliance.

UPDATE: It was announced in February 2010 that the SAS 70 standard will be superseded by SSAE 16 in the United States and by ISAE 3402 internationally.  From a user and user auditor standpoint, these new auditing standards do not change much from the SAS 70, so what is stated here still is valid.  See my new post entitled SAS 70 Is Dead for more information on SSAE 16 and ISAE 3402.

20
Jul
09

Is My Call Center In Scope?

Here is a question that keeps coming up.  The PCI SSC issued article number 5362 in their FAQ site about two years ago.  I am not going to quote it all here, but I am going to discuss the key points of this clarification.  Hopefully this post will clear this up once and for all.

The most important part of the clarification is that it only applies to call centers that record operator conversations with customers.

The second biggest point of clarification is that ALL call center audio recordings are in scope.  As such, those audio recordings must be protected to the same level as any digital data.  This includes security measures such as encryption, access based on business need and other PCI recommended security measures for protecting cardholder data (CHD).

The final largest point the clarification makes is that this clarification only applies to retention of CVV2, CVC2, CAV2 or CID data in the call center’s audio recordings even though requirement 3.2.2 states that CVV2, CVC2, CAV2 or CID data must not be retained under any circumstances.  However, there are some strings attached in allowing CVV2, CVC2, CAV2 or CID data to be retained in the audio recordings.

  • The information contained in the audio recordings must be protected according to all applicable PCI DSS requirements.  This includes meeting requirement 3.4 (encryption, hashing, etc.), as well as minimizing access to the recordings, logging of access to each recording and other related PCI DSS requirements in sections 1, 2 and 3 of the PCI DSS.  Compensating controls for achieving these requirements is allowed for call center audio recordings if the PCI DSS requirements cannot be achieved.
  • If a commercially available solution exists to purge the cardholder data from the audio recordings, the cardholder data MUST be purged.  If the CHD is purged, then only those requirements in 1.1 need to be applied to the audio files.  This means that if your call center application has the ability to purge CHD, you must be running that purge capability at least daily.  Even if that purge capability is an extra add-on to your call center application, you must purchase it and you must use it.
  • The audio files can not be programmatically searched or queried for the cardholder data.  There are applications that can search certain types of digital audio recordings that need to not be present anywhere on the organization’s systems.  In addition, there are applications that convert audio files to text transcripts.  Sometimes these applications are provided as part of the call center application suite.  Either way, text transcription of audio recordings is not allowed.
  • If audio recordings are backed up to other electronic media, the audio recordings must be encrypted on the backup media.

I hope you now understand this important clarification.

UPDATE: On January 22, 2010, the PCI SSC issued a new clarification regarding call recordings containing CVV/CVC/CID.




July 2009
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

Months