AICPA SAS 70
•American Institute of Certified Public Accountants Statement on Auditing Standards No. 70 audit, often referred to as SAS 70 audit, was first introduced in 1992.
•The SAS 70 audit is meant to measure internal controls over financial reporting.
•The SAS 70 audit has been one of the primary means used by data center operators to measure their technical processes around security and assure businesses of its data security practices.
AICPA SAS 70
•The SAS 70 audit, according to the AICPA, was never intended to be used by data centers to verify security.
•The SAS 70 audit report was never intended to be a “certification”, rather a measure of whether a data center operator adheres to the controls it has established for itself.
•The SAS 70 audit requires that the operators develop their own control framework, and then audit their security controls to report back to the customers.
•In 2011, AICPA introduced the Statements on Standards for Attestation Engagements No. 16 (SSAE 16) for reporting on controls at services organizations including data centers.
•SSAE 16 is the next generation of AICPA auditing standards, that goes beyond SAS 70 by requiring the auditor to obtain a written report regarding the design and operating effectiveness of the controls being reviewed.
•An audit that is conducted under the SSAE 16 will result in a Service Organization Control (SOC) report.
SOC 1 Report
•A Service Organization Control (SOC) 1 report is produced upon the completion of an SSAE 16 audit.
•SOC 1 reports are focused on internal controls over financial reporting.
•SOC 1 reports are restricted use reports intended only for existing customers, not prospective customers or the general public.
•SOC 1 report is available as Type 1 or Type 2 report:
Type 1 reports is auditors’ opinion on the accuracy and completeness of management’s description of the system or service as of a specific date.
Type 2 report audits the operating effectiveness of the controls throughout a declared time period, generally between six months and one year.
SOC 2 Report
•A SOC 2 report is intended to provide assurance about controls related to:
3) processing integrity,
4) confidentiality and
5) privacy of a system and its information.
•A SOC 2 report is based on pre-defined controls criteria contained in the AICPA Trust Services Principles and Criteria. Thereby it offers a standard benchmark by which two data center audits can be compared against the same set of criteria.
•SOC 2 audit requires a minimum reporting period of six months, thereby requiring at least six months of data showing the company has met its control objectives.
•SOC 2 reports are seldom released publicly, typically distributed under an NDA to customers and prospects alike.
SOC 3 Report
•A SOC 3 report is intended for general release and includes a summary opinion regarding the effectiveness of the controls in place at the data center or service organization.
•A SOC 3 report provides the same level of assurance about controls over security, availability, processing integrity, confidentiality and/or privacy as a SOC 2 report, however it does not contain the detailed description of the testing performed by the auditor.
•A SOC 3 seal is designed to be published on the service provider’s website, or in some similar fashion. It assures users that the data center meets the stringent certification demands laid out by the trust services criteria.
•Payment Card Industry (PCI) Security Standards Council was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.
•Payment Card Industry (PCI) Data Security Standard (DSS) are a set of guidelines, intended to alleviate vulnerabilities and protect cardholder data, for all entities that store, process or transmit cardholder data.
•The latest PCI Security Standards, v2.0, were published in October 2010.
•PCI Security Standards Council administers PCI DSS and related security standards.
•PCI DSS follows common sense steps that mirror best security practices. There are three ongoing steps for adhering to the PCI DSS1:
Assess — identifying cardholder data, taking an inventory of your IT assets and business processes for payment card processing, and analyzing them for vulnerabilities that could expose cardholder data.
Remediate — fixing vulnerabilities and not storing cardholder data unless you need it.
Report — compiling and submitting required remediation validation records (if applicable), and submitting compliance reports to the acquiring bank and card brands you do business with.
1 - PCI DSS Quick Reference Guide.
PCI DSS Requirements
PCI DSS Requirements
Build and Maintain a Secure Network
Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Protect stored cardholder data
Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Use and regularly update anti-virus software or programs
Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Restrict access to cardholder data by business need to know
Assign a unique ID to each person with computer access
Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Maintain an Information Security Policy
Maintain a policy that addresses information security for all personnel
PCI Data Security Standard (DSS)
•The PCI DSS applies to all entities that store, process, and/or transmit cardholder data.
•PCI DSS covers technical and operational system components included in or connected to cardholder data.
•The security controls and processes required by PCI DSS are vital for protecting cardholder account data, including the PAN – the primary account number printed on the front of a payment card.
•Merchants and any other service providers involved with payment card processing must never store sensitive authentication data after authorization. This includes sensitive data that is printed on a card, or stored on a card’s magnetic stripe or chip – and personal identification numbers entered by the cardholder.
Payment Application Data Security Standard (PA-DSS)
•The PA-DSS is for software developers and integrators of payment applications that store, process or transmit cardholder data as part of authorization or settlement.
•Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC. PCI lists validated applications on its website.
PCI DSS Compliance Report1
Template information contained in PCI DSS Report on compliance:
1. Executive Summary (description of entity’s payment card business; high level network diagram)
2. Description of Scope of Work and Approach Taken (description of how the assessment was made, environment, network segmentation used, details for each sample set selected and tested, wholly owned or international entities requiring compliance with PCI DSS, wireless networks or applications that could impact security of cardholder data, version of PCI DSS used to conduct the assessment)
3. Details about Reviewed Environment (diagram of each network, description of cardholder data environment, list of all hardware and software in the CDE, service providers used, third party payment applications, individuals interviewed, documentation reviewed, details for reviews of managed service providers)
4. Contact Information and Report Date
5. Quarterly Scan Results (summary of four most recent ASV scan results)
6. Findings and Observations (detailed findings on each requirement and sub- requirement, including explanations of all N/A responses and validation of all compensating controls)
1 - PCI DSS Quick Reference Guide.