Pursuing Compliance in the Public Cloud - …...Pursuing Compliance in the Public Cloud Identifying...

Pursuing Compliance in the Public Cloud Identifying the right compliance strategy for your business in the cloud February 2014 Version 0.1 Jason Cumberland

Dimension Data White Paper: Compliance in the Public Cloud

of 16

Introduction:

Organisations considering moving IT assets or applications from an on-premise installation to the cloud face a bewildering array of compliance options and certifications. Organisations commonly ask themselves these questions when developing their own compliance roadmap and strategy:

• Which certifications do I need to achieve directly? • For which certifications can I leverage my data centre provider? • Do I need to bring in an outside auditor or can I conduct a self-audit? • What are my competitors doing in terms of compliance? Should my strategy be the same? • What will my clients expect of me in the sales process?

The key to successfully navigating the compliance waters is to determine which of the many available certifications are relevant to your business and which add more cost and complexity to your business than they’re worth. Given that each of the common compliance standards is accompanied by significant costs, correctly identifying the requirements from your internal stakeholders and clients is a critical initial step when developing your compliance strategy. In this paper, we’ll discuss several of the most common compliance standards to help determine the applicability of each to your business. These include:

• AICPA Statement on Standards for Attestation Engagements No. 16 (SSAE 16) • Payment Card Industry Data Security Standard (PCI DSS) • The Health Insurance Portability and Accountability Act of 1996 (HIPAA) • US–EU Safe Harbor Framework • International Standards Organization (ISO) 17799 / 27002 • International Standards Organization (ISO) 27001 • Food and Drug Administration (FDA) Title 21, Code of Federal Regulations (CFR) Part 11 • Federal Information Processing Standards (FIPS) / Federal Information Security Management

Act (FISMA) / The Federal Risk and Authorization Management Program (FedRAMP) • Sarbanes–Oxley Act (SOX) • Gramm–Leach–Bliley Act (GLBA)


of 16

Commonly used terminology

To aid in the detailed evaluation of each of the above certifications, it’s important to establish the terminology that we’ll use throughout this paper. Control objectives versus control procedures and activities Control objectives provide high-level goals that organisations try to achieve using policies, procedures, and systems. Control procedures and activities are the actual policies and procedures that are put in place to achieve the objectives. Best practice versus prescriptive standards ‘Best practice’ standards define control objectives, goals or methods that work across many organisations but allow organisations to choose which ones to use and how to implement them. ‘Prescriptive’ standards provide detailed control requirements that need to be met exactly as outlined in order to meet the standard. Attestation versus certification Attestation is the result of an audit conducted to measure compliance with control objectives set by an organisation. The auditor measures whether the control objectives are met by the control procedures in place. The auditor attests to the organisation’s ability to meet its own standards but does not determine whether the standards are valid. In this case, because there are no prescriptive standards, there’s no easy way to compare organisations simply by establishing whether an attestation standard has been completed. Certification is the result of an audit conducted to measure compliance with prescriptive standards. The auditor can explicitly certify whether those standards have been met. From a buyer’s perspective, these standards can be used to directly compare service providers given that the standards for each organisation are the same.


of 16

Detailed review of compliance and common security standards

SSAE 16 (Formerly SAS70) The Statement on Standards for Attestation Engagements (SSAE) 16 is an attestation standard used by auditors to evaluate the internal systems of a service provider. ‘Systems’ are generally defined as the services provided, along with the supporting processes, policies, procedures, personnel and operational activities that constitute the service organisation's core activities that are relevant to user entities. SSAE 16 is not a prescriptive standard. Instead, it reviews whether an organisation’s control procedures are followed and whether those procedures achieve the organisation’s control objectives. The audit does not make a judgment as to whether the control objectives are ‘good’ or will meet security or other objectives. However, companies are now required to submit a management assertion as part of the SSAE process attesting (among other items) that the control objectives were suitably designed, and that the description of the system is accurate.

SSAE 16 control objective example: An organisation could define an SSAE 16 control objective that stipulates only individuals with a green identity badge are allowed access to the data centre, and a control activity that the posted security guard will allow anyone into the data centre as long as their identity badge meets this criterion. In this case, as part of the SSAE 16 review, outside auditors will evaluate whether the control activity (the security guard’s ability to enforce the control objective) is sufficient to meet the control objective, and ask for proof (documentation) that the control activity was consistently followed. So long as this documentation exists, this control objective will be achieved.

While this is a ‘bad’ control objective from a security point of a view, as long as an organisation shows that it meets the stated objective, it will be considered to be compliant from an SSAE 16 point of view. There are two types of SSAE 16 audits, usually performed sequentially:

• SSAE 16 Type I – Type 1 is a “point in time” audit that evaluates the control procedures at a single point in time, identifying whether the control procedures will meet the control objectives.

• SSAE 16 Type II – Type II evaluates the effectiveness of control procedures over a period of time, so the auditor looks to make sure the control procedures are being followed.

The result of a completed SSAE 16 audit is a SOC 1 (service organisation control) report. Prevalence and relevance: From a service provider perspective, the SSAE 16 Type II audit is generally considered ‘table stakes’ in the world of service providers of public cloud, managed hosting, and co-location services. It should be a must-have for any commercial application hosting. The standard is most common in North America, with acceptance among many global organisations as well. While the controls and scope of an SSAE audit vary greatly for the reasons explained above, generally, there are three broad areas of scope for an SSAE audit:


of 16

• Software development control objectives • Operational control objectives • Data centre/facility control objectives

In the best case, a service provider can cover only two of these three, given that it has no involvement in a client’s software development process. If a client manages its own environment (software deployment, change control, patching procedures, etc.) – which is typical – then the provider’s operational controls are of limited value to a prospective client in a sales cycle given that the independent software vendor (ISV) will be responsible for managing its own operational controls. In this case, relying on a provider’s SSAE audit covers only one of three areas of scope of the SSAE audit. Service providers offering managed services that extend the management of the client’s application (i.e. Application Operations from Dimension Data) extend coverage to two of the three areas of scope, which can offer prospective clients more assurance than if an ISV’s operational processes are unaudited. Service provider versus ISV/enterprise applicability: While considered a must-have for service providers, the requirement for an independent software vendor or enterprise to complete its own audit is far less definite. In some cases, ISVs can leverage the SSAE certification of the data centre provider in its sales cycles to satisfy their clients’ control requirements. However, sophisticated buyers of IT services or software-as-a-service (SaaS) offerings will often insist on seeing the enterprise/ISV’s SSAE audit results as well. Approximate costs: The costs of any audit discussed in this paper include a combination of hard costs (money paid to an outside firm to complete the audit, hardware and software costs to meet various security requirements, etc.) as well as personnel costs related to the time required to prepare for the audit, implement the required organisational controls, and work with the auditors throughout their review to ensure a successful result. In many cases, the latter category of soft costs is far more expensive than the fees paid to the auditors. These soft costs are also more difficult to generalise, as each organisation’s experience will differ. Our advice is to work with your auditor to assess the time required before beginning any outside audit process. This will ensure that internal expectations are properly established to successfully complete the audit in the established timelines. In general, the hard costs of an SSAE attestation paid to an outside firm range from USD 15,000 -25,000 per site being inspected, with significant variation depending on the scope of audit. As mentioned above, in the case of SSAE the organisational costs of SSAE compliance (including the costs to prepare and gather documentation for the audit, employment of an internal security/control officer, costs of ongoing internal audit activities throughout the year to maintain compliance, etc.) easily outweigh the hard costs. Best practices and recommendations: When selling a service to a commercial or enterprise market (i.e. non-consumer services), SSAE-related questions will commonly come up in pre-sales conversations. If your organisation has the


of 16

operational discipline to meet the control objectives you define (generally through a culture of strict adherence to process, heavy documentation, and internal audit reinforcement), and you can justify the costs of your own SSAE audit, our recommendation is that you pursue your own audit to remove barriers in the pre-sales process. By selecting a service provider that has completed its own audit, you can often limit the costs and scope of your own audit by ‘carving out’ the portions of the controls already met by your service provider, and limit the scope of your own audit to only those items for which your organisation is directly responsible. Due to the costs of an SSAE audit as well as the maturity of organisational processes and controls required, many smaller or early-stage organisations cannot justify the conducting their own SSAE audit. In this case, organisations commonly utilise their service provider’s SSAE compliance (generally at the facility level). Organisations can leverage more meaningful and extensive SSAE compliance by selecting a vendor with a managed service offering that extends its SSAE compliance through the operational controls related to the specific application being hosted. This allows the ISV/enterprise to confidently respond to pre-sales questions regarding SSAE compliance covering both facilities and operational controls, without incurring the significant costs of an individual SSAE audit. Lastly, regardless of whether you choose to pursue your own SSAE audit, ensure that you carefully review your provider’s SSAE report (generally under a non-disclosure agreement). The details of these tests will vary from one provider to another, and it is critical to your own risk mitigation strategy to understand the scope and detailed results of each provider’s audit. Payment Card Industry Data Security Standard (PCI DSS) PCI DSS is a prescriptive data security standard that applies when storing, processing, or transmitting credit and debit card data. The security standards are agreed to by the major credit issuers (Visa, MasterCard, etc.) to eliminate the establishment of separate standards for each issuer. All credit card companies require adherence to these standards in their terms of service. ‘Acquiring banks’ (banks processing the issuer’s credit card transactions) are responsible for ensuring that their merchants are compliant with the PCI Data Security Standard and that the merchants use PCI-certified service providers. Acquiring banks generally ‘pass through’ this requirement in their agreement with their merchants, meaning that the merchants are financially responsible for any losses if they are not compliant or were using non-compliant service providers. There are currently four different levels of certification and related requirements*:

• Level 1 (> 6 million transactions per year, credit card processors/payment gateway): o Requires an annual on-site audit and quarterly network scan

• Level 2 (> 1million credit/debit transactions per year): o Requires an annual on-site audit and quarterly network scan or self-assessment

questionnaire (requirements vary depending on issuing bank) • Level 3 (< 1million transactions per year):

o Requires an annual self-assessment questionnaire and quarterly network scan • Level 4 (20k – 1million transactions per year):

o Requires an annual self-assessment questionnaire and quarterly network scan


of 16

*Note that each major card issuer has slightly varying requirements for Level 1 through 4. The information above is a generalisation of the different issuers. Prevalence and relevance: PCI is the compliance standard and the definitive standard for any organisation processing credit card data. Service provider vs. ISV/enterprise applicability: Prospective buyers of SaaS or infrastructure-as-a-service (IaaS) often include PCI compliance in their checklist of requirements without a complete understanding of the complexities involved in pursuing a PCI compliance strategy. Similar to SSAE 16, PCI compliance can be achieved with varying audit scopes. For a complete PCI compliance strategy, an organisation must be compliant at the hardware, process, software, and facilities levels. A data centre provider’s PCI compliance cannot legitimately cover all of these areas for a third-party hosting within their facilities (see best practices below for further information). Approximate costs: Costs for a full-scale PCI audit vary significantly. The initial consulting fees to establish the scope of the analysis and any gaps in current procedures commonly ranges from USD 25,000-100,000+ depending on the size of the organisation and established scope. A bare-bones onsite PCI audit could cost as little as USD 20,000-30,000 per year, with in-depth audits for large organisations easily costing more than USD 100,000 annually. Key soft costs to consider: The organisational process changes required to adhere to PCI compliance can be significant. Among other things, organisations must nominate (or hire) an internal security officer who will be responsible for managing compliance internally between audit periods. Best practices and recommendations: The first distinction that we recommend clients make when pursuing PCI-compliant hosting is to decide whether they are pursuing a PCI-compliant provider solely for marketing value (i.e. making the claim that the application is hosted in PCI-compliant facilities), or whether the organisation actually intends to pursue its own PCI audit of the application being hosted. While we do not generally dispute the marketing value of the former strategy, from a security perspective, this is not a model that will carry significant value with an experienced INFOSEC organisation. If your application is processing or storing any credit card data, to be compliant with the card issuer’s terms of service, your organisation must complete its own PCI audit. Similar to SSAE, portions of the PCI requirements can be ‘carved out’ of your own audit based on your service provider having completed a separate audit, but the application itself must undergo its own evaluation. Health Insurance Portability and Accountability Act (HIPAA) The sections of HIPAA relevant to data centre service providers relate to the security of patient data processed or stored by ‘covered entities’. Covered entities include those with a direct patient


of 16

relationship, such as hospitals, doctors, pharmacies and insurance companies. These entities must be HIPAA compliant under the provisions of the law. This definition of ‘covered entities’ makes it technically impossible for any data centre service provider to be HIPAA compliant because they are not covered entities under the law’s provisions. For this reason, we advise that organisations seeking data centre providers proceed with caution when dealing with a service provider claiming HIPAA compliance. While service providers cannot be HIPAA compliant, they may qualify as a ‘business associate’ of a HIPAA-covered entity if involved in a function or activity involving the use or disclosure of protected health information. Generally this means that if any patient data is stored in the application running in a service provider’s infrastructure, a service provider is obligated as a business associate under HIPAA. Prevalence and relevance: HIPAA is a common compliance standard (though often misunderstood) and the definitive standard for any organisation processing patient healthcare data. Service provider vs. ISV/enterprise applicability: HIPAA-covered medical organisations are required to contractually obligate business associates to utilise security mechanisms and privacy procedures that include (but are not limited to):

• Security mechanisms that ensure all transmissions of data are authorised and employ the standards necessary to protect the integrity and confidentiality of the data that is transmitted.

• Privacy procedures that require any unauthorised use or disclosure of protected health information to be reported to the medical organisation.

• Security mechanisms that protect records and other data from improper access. • Privacy policies that bind the service provider’s agents and subcontractors to the same

restrictions on the use and disclosure of protected health information as those imposed upon the service provider.

In addition, the covered entity’s business associate agreement (BAA) with the service provider must include specific procedures for the storage and transfer of patient data in the event that the contract is terminated, the service provider goes out of business, and/or is acquired by or merged into an organisation that is unsatisfactory to the entity. Approximate costs: While there are several organisations available to help you develop your HIPAA compliance strategy, there is no third-party data centre audit requirement under HIPAA, so there’s no formal attestation or certification that service providers can achieve. As a result, costs here are less definitive but may include items such as backup software, data archiving tools, write-once storage media, etc. A service provider experienced with HIPAA hosting will be able to provide for many of these requirements within its standard offering. Best practices and recommendations: Given the structure outlined above, the key distinction when seeking out service providers to host HIPAA-related data is that they are willing to accept liability for breach of the confidentiality of the data


of 16

they’re hosting. This is key to fulfilling an organisation’s responsibilities under HIPAA and ensures that the risk for data confidentiality flows through to all organisations involved in the processing or storage of the related data. While there are general requirements for HIPAA hosting, there is not one standard set of contract or security terms related to HIPAA, so expect some discussion with your provider regarding your specific BAA and the best way to meet the requirements under its specific business associate agreement. US–EU Safe Harbor European Union (EU) law prohibits the transfer of an individual’s personal data to non-EU nations that do not meet the European adequacy standard for privacy protection. To provide a streamlined means for US organisations to comply with the law, the United States Commerce Department developed the Safe Harbor framework of prescriptive security standards. Safe Harbor certification will assure EU that your company provides ‘adequate’ privacy protection. Safe Harbor requires you put in place a privacy policy and procedure that covers the gathering and use of personal information. At a high level, the policy needs to cover several areas:

• Notice – you must provide notification about the purpose for which you collect and use information about individuals, and explain disclosures to third parties. You also have to provide individuals with a way to contact the company with inquiries or complaints.

• Choice – you must give individuals the ability to opt out of having their personal information disclosed to a third party.

• Third parties – any third parties to which you disclose information must follow the same policies.

• Access – you must give individuals the ability to correct, amend, or delete collected information if it is inaccurate.

• Security – you must take reasonable precautions to protect the data. • Data integrity – you must have a relevant purpose for maintaining and using any personal

data collected. • Enforcement – you must implement systems to enforce these policies and fix any problems

identified. Service provider versus ISV/enterprise applicability: This standard generally applies to enterprises, ISVs, and data centre providers. It’s uncommon for organisations to rely completely on their data centre provider for this certification. Approximate costs: Safe Harbor is a self-audit certification. Certification consists primarily of developing a qualifying privacy policy (for which you may wish to engage outside expertise) and identifying a company officer who will certify that the organisation will follow the policy and Safe Harbor requirements. You must also identify all data you are collecting about EU citizens. This information must be submitted to the Commerce Department for review, after which the US Government will certify you under Safe Harbor. There are no audit or application costs for achieving this certification.


of 16

Best practices and recommendations: It’s our recommendation that clients dealing with European organisations pursue their own Safe Harbor certification in addition to ensuring that their data centres are compliant. International Standards Organization 17799 / 27002 ISO 17799 was renamed to ISO 27002 but references to both are still regularly found. ISO 17799 provides best practice recommendations for information security management, covering all information (files, paper, faxes, phone calls, email, etc.) within an organisation. These recommendations may not all apply and do not all need to be used. Organisations are expected to review and decide what is relevant for their specific use case. The standard includes 134 specific controls, categorised into approximately 36 control objectives covering areas such as: 1. Risk assessments and treatment 2. System policy 3. Organising information security 4. Asset management 5. Human resources security 6. Physical and environmental security 7. Communications and operations management 8. Access control 9. Information systems acquisition, development and maintenance 10. Information security incident management 11. Business continuity management 12. Compliance Information security is defined within the standard in the context of three areas

– Confidentiality: ensuring that information is accessible only to those authorised to have access.

– Integrity: safeguarding the accuracy and completeness of information and processing methods.

– Availability: ensuring that authorised users have access to information when required. Prevalence and relevance: Like the other ISO standards, this is most commonly pursued by global organisations. Best practices and recommendations: Due to the self-audit nature of this standard, organisations serving a global market but without the budget or desire to pursue ISO 27001 certification may prefer to adhere to this standard, or portions of this standard, as an interim step. International Standards Organization: ISO 27001 ISO 27001 provides a prescriptive specification for an organisation’s information security management system (ISMS), which includes all of the policies, procedures, roles, responsibilities,


of 16

resources, and structures that are used to protect an organisation's information, as well as the management and control of the security risks associated with the information. ISO 27001 is based on ISO 17799 / ISO 270002. However, unlike ISO 27002, ISO 27001 is a standard an organisation can be certified against. The audit is normally conducted in two stages:

• A review of the existence and completeness of key documentation such as the organisation's security policy, statement of applicability (SoA) and risk treatment plan (RTP).

• An actual audit to test the existence and effectiveness of the ISMS controls stated in the SoA and RTP, as well as their supporting documentation.

Prevalence and relevance: The various ISO certifications are generally preferred by organisations with operations outside North America (in contrast to SSAE, which is more commonly accepted or preferred by organisations within North America). Service provider versus ISV/enterprise applicability: Similar to SSAE 16, this is an audit that can be valid for both service providers and enterprises. Due to the costs of this audit, however, it is not commonly pursued by small or mid-market organisations, particularly those organisations without global operations. Approximate costs: Estimated hard costs: These vary widely based on the size of the organisation and auditing firm, but generally run between USD 50,000-100,000 with certifications valid for up to three years. Years two and three each require a smaller scale, follow-up audit that generally costs an additional USD 5,000-10,000. Key soft costs to consider: Due to the prescriptive and detailed nature of this certification, the soft costs of implementation can be significant. These costs come chiefly from establishing policy documents, changing existing operational process to comply with ISO standards, and the internal controls that must be implemented to ensure compliance with the standards between the formal external audit periods. Best practices and recommendations: For organisations dealing primarily with North American customers, an ISO certification may not be as cost-effective or important as completing a well-scoped, in-depth SSAE audit. Due to the non-prescriptive nature of SSAE, that audit can actually be developed to meet many or all of the same standards as ISO. While this strategy will not allow you to claim official ISO compliance, it will allow you to provide prospective clients with an SSAE attestation and report showing the specific areas that were audited, which will suffice in many situations. For organisations dealing primarily with clients outside of North America, ISO certification is a requirement you will want to seriously consider. Other less commonly cited certifications in the managed hosting / cloud service provider industry include ISO 9001 (covering product quality management systems), ISO 14001 (also covering product quality management systems, but those directly related to how a product is produced), ISO 50001


of 16

(covering energy management systems), and OHSAS 18001 (standards for occupational health and safety management systems). FDA Title 21, CFR Part 11 This FDA regulation applies to all entities regulated by the FDA except food manufacturers. Common examples are drug manufacturers, medical device manufacturers and biotechnology companies. This regulation requires such companies to implement various controls, audits, validation systems and documentation for software and systems related to electronic records and signatures maintained by the organisations under FDA regulation. These tend to be records or signatures that are being submitted to the FDA or stored as part of an approval process for a new product At a high level, the requirements include:

• Systems validation – all computer systems have to be ‘validated’. Essentially, the company must identify and document what the system will be used for and who will use it, and ensure that the hardware and software are adequate for the task (all verified through production testing).

• Record retention – will vary depending on the FDA regulation to which the records are related.

• Records security – securing data so only authorised users have access. • Audit trails – maintenance of audit trails for the creation, modification, and deletion of

records, including who made the change and when. • Electronic signatures – includes fingerprints, retinal scans, or ID names and passwords that

meet certain requirements. Signatures must include certain data (commonly the name of person, whether the signature is providing an approval or denial, and a date and time). They must also be protected so they cannot be modified once captured.

Service provider vs. ISV/enterprise applicability: It is uncommon and improbable that service providers will need to meet this requirement directly. Usually, the organisations outlined above are responsible for meeting these standards. A data centre provider’s responsibility typically involves providing supporting hardware and tools such as write once, read many (WORM) storage infrastructure. Best practices and recommendations: Given that this is an enterprise-only requirement, the service provider can provide only limited assistance in helping you maintain compliance with this regulation. As such, we recommend that you ensure your cloud provider has dealt with these requirements before and can recommend technologies to meet your specific FDA requirements. FIPS, FISMA, and FedRAMP FIPS are Federal Information Processing Standards, many of which are incorporated into FISMA, the Federal Information Security Management Act (2002). The act requires all federal agencies and their contractors to safeguard their electronic systems (regardless of whether these agencies or systems involve cloud providers).


of 16

FedRAMP is the Federal Risk and Authorization Management Program (2012). It requires that all federal organisations that use or plan to use a cloud environment implement the security controls of this program. FedRAMP contains additional controls, not present in a FISMA assessment, specific to cloud environments. FedRAMP was created to establish a risk management programme that could be applied to the entire federal government. At a high level, it covers four steps before establishing a cloud-based service:

• Initiating: agencies or cloud service providers (CSPs) initiate the FedRAMP programme by pursuing a security authorisation.

• Assessing: based on the NIST SP 800-53 Rev. 3 requirements, CSPs must hire a third-party

assessment organisation to perform an independent assessment.

• Authorising: upon completion, the security assessment package will then be forwarded to the FedRAMP Joint Authorization Board (otherwise known as JAB) for review.

• Leveraging: the CSP will then continue to work with the executive departments and agencies

for authority to operate (ATO) permissions. Service provider vs. ISV/enterprise applicability: Because of the scope of these federal compliance standards, in general ISVs or enterprises must obtain their own compliance as well as operate in a data centre that meets these standards. Approximate costs: Like other audits, FedRAMP costs vary, but range from USD 40,000-100,000. The soft costs are far more significant, with the average assessment process requiring six months or more. Best practices and recommendations: Companies whose government clients make up a large portion of their revenue will likely have no choice but to pursue the FedRAMP certification process. As FedRAMP is still an emerging standard as of the date of this paper, expect changes in the coming year as the government formalises the programme. Due to the significant costs of compliance and limited relevancy outside government agencies, non-government-centric organisations are not likely to pursue this standard. Sarbanes–Oxley (SOX) Compliance In 2002, the US Congress enacted the Sarbanes–Oxley (SOX) Act. The act was targeted at changing the way public companies report their financial results and carried with it a significant impact to IT organisations due to the heavy logging and documentation requirements included in the act. The act also contains additional controls related to record retention, which must be carefully implemented into any hosting strategy. Section 404 of SOX covers the assessment of internal controls (to be conducted by an outside party). COBIT stands for Control Objectives for Information and Related Technology. These objectives require logging and reporting of key activities such as application level access control changes, events


of 16

triggering access changes, transaction types, user IDs, and date and timestamps for all such activities. All unauthorised attempts to access the application must also be logged and reported with a time and IP address. Service provider vs. ISV/enterprise applicability: Due to the financial reporting focus of the SOX Act, data centre service providers cannot provide SOX compliance for their clients. However, the internal controls of the service provider can make an outside SOX audit far easier to complete successfully. In many cases, the controls from other, more directly relevant IT standards such as SSAE 16 or ISO 27001 can also be used to help verify SOX compliance. In addition, public cloud providers with user-based permissions, individual account logins, and in-depth logging built into the application can make SOX compliance far easier. Apart from the infrastructure controls in place, an ISV or enterprise must implement additional controls at the server or application level to meet the requirements of SOX. Gramm–Leach–Bliley Act (GLBA) The GLBA was originally passed in 1999 and its implications were largely for financial institutions. In the Act, financial institutions are defined as all businesses, regardless of size, that are ‘significantly engaged’ in providing financial products or services. This includes, for example, cheque-cashing businesses, payday lenders, mortgage brokers, non-bank lenders, personal property or real estate appraisers, professional tax preparers, and courier services. Service provider vs. ISV/enterprise applicability: Two specific rules in the act are most directly relevant to conducting business in the cloud. The Financial Privacy Rule, which governs the collection and disclosure of customers’ personal financial information by financial institutions. It also applies to companies, regardless of whether they are financial institutions, that receive such information – companies like cloud providers. The Safeguards Rule requires all financial institutions to design, implement and maintain a ‘comprehensive information security programme’ to protect non-public customer information. It requires period testing of the programme as well. Lastly, prior to allowing a service provider to access customers’ personal information, the financial institution must:

• Take reasonable steps to select and retain service providers that are capable of maintaining appropriate safeguards for the customer information.

• Require the service providers, under contract, to implement and maintain such safeguards. Cloud providers are included in the scope of the Financial Privacy Rule above. Prior to disclosing any information to a cloud provider, cloud customers must enter into a contract with the provider which prohibits the provider from disclosing or using the affected data in any manner other than to carry out the purposes for which the information was disclosed. In practice, this is a common legal provision in most cloud contracts.


of 16

The GLBA also requires that all financial institutions provide their clients with the right to opt out of sharing their personal financial information with non-affiliated third parties. In this case, the enterprise must carefully develop provisions to remove specific client data from external storage systems as soon as such a request is received. Best practices and recommendations: For financial institutions considering storing data in a cloud environment: ensure that the internal operational controls and security policies put in place to comply with GLBA can be extended into your cloud environment. Not all cloud providers are equal when it comes to security within the environment. Be sure to review the relevant details carefully to understand whether GLBA can be maintained in the cloud environment of your choice. Clients with GLBA exposure may also want to explore hosted private cloud alternatives where greater degrees of data separation can be achieved. Lastly, ensure that you follow the stipulations above regarding the Privacy Rule and related contractual requirements to maintain compliance with GLBA when working with a third-party cloud provider.


of 16

Dimension Data cloud compliance

Dimension Data operates numerous data centre facilities around the world, and as such, our compliance audits and certifications vary by location. In combination, Dimension Data and/or the facilities in which we operate our data centres meet the following compliance standards:

• SSAE 16 Type II • PCI Level 1 • FISMA Moderate • EU Safe Harbor • ISO 9001(2008) • ISO 27001(2005) • ISO 50001(2011) • OHSAS 18001(2007)

In addition, while Dimension Data or its facilities cannot be directly certified against the following standards (given that data centre providers are not the focus of these standards), we regularly help clients achieve and maintain their own compliance against these standards:

• HIPAA • FDA Title 21, CFR Part 11 • Sarbanes–Oxley (SOX) • Gramm–Leach–Bliley Act (GLBA)

Successfully complying with any of these standards typically involves a joint effort between the Dimension Data team and our client. We have significant experience in operating under all of these compliance standards and would welcome the opportunity to answer any questions you have about maintaining these standards in a cloud environment.

Pursuing Compliance in the Public Cloud - …...Pursuing Compliance in the Public Cloud Identifying...

Documents

Transcript of Pursuing Compliance in the Public Cloud - …...Pursuing Compliance in the Public Cloud Identifying...