In-Depth

Auditing Data Security in the Cloud

How to audit security when you using a cloud provider.

• 04/05/2011

Data Security

For all of the steps in this section (except step 8), your first option should be to determine whether an evaluation of the area is available via a third-party assessment (such as SAS 70). If it is not, you’ll need to work with your operations, procurement, and legal departments to determine your rights to audit the vendor in this area. Hopefully, those rights are spelled out in the contract. If they are not, your company will need to attempt to press for that right, possibly using the next contract renewal as negotiating leverage.

If the area is not covered by an assessment such as a SAS 70 and if you have the right to audit it, you will need to interview the vendor and review their documentation regarding their technical controls and processes, testing those controls as you’re able.

You will also want to see your company’s requirements for these controls spelled out in your contract and look for evidence that those specific requirements are being met.

Step 5: Determine how your data is segregated from the data of other customers.

If your company chooses a form of outsourcing in which your data is being stored on the vendors’ systems at their site (such as in cloud computing and dedicated hosting), you no longer have full control over your data. Your data may be comingled with other customers’ data (a likely scenario with cloud computing). This creates a number of risks. For example, if data is not properly segregated, another customer (including one of your competitors) on the same shared infrastructure may be able to access your data. Likewise, if one customer’s system is breached, the confidentiality, integrity, and availability of other customers in the same environment may be at risk. For example, viruses might be transmitted from one customer to another or an attacker might be able to download data from all customers in the environment.

This step is most applicable to cloud computing and dedicated hosting.

How: Review the technical controls and processes for assuring segregation and protection of your systems and data. There’s no single way to do this, and the implementation will differ depending on the technologies being used by your vendor, but the vendor needs to demonstrate how they have segregated and compartmentalized systems, storage, network, and so on. For example, in a dedicated hosting environment, you’ll be looking for network devices (such as firewalls) to segregate the network hosting your systems from the networks hosting other customers. In a SaaS environment, you’ll be looking for segregation of databases containing customer data. Ideally, you would like to perform your own tests to validate that their controls are working as designed. Again, the nature of these tests will depend on the technology and the implementation.

Step 6: Review and evaluate the usage of encryption to protect company data stored at and transmitted to the vendor’s site.

If your data is no longer fully under your control (that is, it is being stored at a third-party site and possibly being comingled with data from other customers), it is critical that the data be encrypted to protect against possible compromise. This reduces the risk of a breach impacting the confidentiality or integrity of your data. If you have unencrypted data in a shared environment (such as cloud computing), you can assume that it is no longer confidential.

This step is most applicable to cloud computing, dedicated hosting, and offsite service outsourcing.

How: Look for encryption of data both in transit (for example, via SSL for browser-enabled transactions) and at rest (that is, in storage), because both are outside of your control if your data is stored at a third-party site. Evaluate the strength of the encryption. Hopefully, you will have contractually-dictated requirements for encryption (such as algorithm and key length) against which you can compare the system.

Determine how key management is performed and how your keys are separated from those of other customers in your environment. Ideally, this function should be performed either by your company or by a separate vendor from your standard outsourcing vendor, providing for segregation of duties.

Step 7: Determine how vendor employees access your systems and how data is controlled and limited.

If your data is being stored or processed by employees outside of your company and you do not maintain ownership regarding who has access to that data, you’re putting its confidentiality, integrity, and availability at risk.

This step is applicable to all forms of outsourcing.

How: Determine who has access to your data and systems and review for appropriateness. Determine how appropriate segregation of duties is maintained. Ensure that the concept of “minimum necessary access” is followed.

Review the approval process for determining who will have access to your systems and data. Ideally, the data owner at your company will be the gatekeeper for approval. Your company should maintain the right (hopefully spelled out in the contract) to deny access to your data from vendor personnel.

Review your vendor’s processes for hiring and screening employees, ensuring that appropriate background checks are performed and rules regarding security and management of your environment are communicated to the employees. These requirements should be dictated in the contract.

Ask for a listing of any third-party relationships that your vendor has and any interfaces those additional parties have to your systems. Each of these represents additional exposure of your data.

Step 8: Review and evaluate processes for controlling non-employee logical access to your internal network and internal systems.

If you’re using service outsourcing and/or supplemental (contract) labor, you are likely allowing a third-party vendor’s personnel to have a degree of logical access to your network and systems. Because these personnel are not employees of your company, they are less likely to have a personal investment in the company’s success or an awareness of its policies and culture. If their access to company information assets is not governed and if expectations regarding their usage of that access are not communicated, it is more likely that company information assets will be unnecessarily exposed or misused.

This step is most applicable to onsite and offsite service outsourcing plus supplemental labor.

How: Ensure that policies require approval and sponsorship from an employee prior to a non-employee obtaining logical access to company systems. If feasible, obtain a sample of non-employee accounts and validate that they have appropriate approval and sponsorship.

Review and evaluate processes for communicating company policies (including IT security policies) to non-employees prior to granting them system access. Look for evidence that this communication has occurred. For example, if all non-employees are required to sign a statement that they have read and agree to the policies, pull a sample of non-employees and obtain copies of these agreements.

Review and evaluate processes for removing logical access from non-employees when they have ceased to work with your company or otherwise no longer need access. Consider obtaining a sample of current non-employee accounts and validating that those non-employees are still working with your company and still have a need for their current level of access.

Ensure that nondisclosure agreements (NDAs) are signed by non-employees to legally protect your company from inappropriate use of company data. Pull a sample of non-employee accounts and obtain a copy of the NDA for those accounts.

Ensure that consideration has been given to identifying data that should not be accessed by non-employees and activities that should not be performed by non-employees. For example, your company may decide that access to certain levels of financial data should never be granted to non-employees. Or it may decide that non-employees should never be granted system administration duties. The answer will depend on your company’s industry and philosophies; however, an evaluation process should take place and the results of that evaluation should be documented in company policy and enforced.

Step 9: Ensure that data stored at vendor locations is being protected in accordance with your internal policies.

No matter where you store your data, it is still subject to your internal policies. Outsourcing storage to a third party does not absolve your company of responsibility to comply with policies and ensure proper security of the data.

This step is most applicable to cloud computing and dedicated hosting.

How: Ensure that data stored at third-party sites has been classified in accordance with your company’s data classification policy and is being protected in accordance with that policy. Data with certain levels of classification might be inappropriate to store outside the company (such as employee and customer personal information). Review your company’s policies on data security and ensure that off-site data is being protected in accordance with those policies. Encrypting data that is stored with the vendor will greatly benefit you in this area.

Step 10: Review and evaluate controls to prevent, detect, and react to attacks.

Without appropriate intrusion detection and prevention techniques, your systems and data are at an increased risk of compromise. This risk is increased in an outsourced model, specifically when outsourcing systems and infrastructure, because of the shared infrastructure,—an attack and compromise on one customer could result in compromise of your systems.

This step is most applicable to cloud computing and dedicated hosting. Also, consider whether this risk is applicable if you’re using offsite service outsourcing, as the service provider may store your data on their systems and/or have connectivity to your internal systems.

How: This step might be divided into separate substeps. For infrastructure and systems located at third-party sites, determine the effectiveness of processes such as those listed next.

• Intrusion Detection: Look for the usage and monitoring of Intrusion Detection Systems (IDSs) to detect potential attacks on your systems and integrity checking tools to detect potential unauthorized changes to system baselines.

• Intrusion Prevention: Look for the usage and monitoring of Intrusion Prevention Systems (IPSs) to proactively detect and cut off potential attacks on your systems.

• Incident Response: Look for clearly defined processes for responding to potential security incidents, including notification and escalation procedures.

• Discovering and Remediating Vulnerabilities: Look for the usage and monitoring of vulnerability scanning tools to detect and mitigate potential vulnerabilities that might allow an intruder to access and/or disrupt your systems.

• Logging: Look for the logging of significant activities (successes and failures) on your systems, for the monitoring of these logs, and for the storage of these logs in a secure location for an adequate period of time.

• Patching: Look for procedures to receive and apply the latest security patches so that known security holes are closed.

• Protection from Viruses and Other Malware: Look for the usage of antivirus software and the application of new signature files as they are released.

Step 11: Determine how identity management is performed for cloud-based and hosted systems.

Proper identity management practices are critical for controlling access to your systems and data. Distributed computing became popular in the 1990s. When each user was required to track IDs and passwords on multiple systems, it led to problems such as employees sharing accounts, inconsistent password controls (for example, password strength, aging), accounts not being removed when no longer needed, employees with more access than they needed, and other issues. Without some form of central control, no real governance was possible. To resolve these issues, many companies deployed enterprise IDs, giving users one account name for all systems, as well as strong enterprise passwords, which can be used to authenticate to multiple systems.

As your company begins adopting cloud computing, you run the risk of seeing the same issues arise again. Users may end up with accounts with multiple cloud providers, each with a different ID and password. If you’re not careful, you’ll encounter the same issues that companies encountered in the ’90s with distributed computing.

This step is most applicable to cloud computing, particularly SaaS, and dedicated hosting, particularly of purchased applications.

How: Although it’s possible to review the identity management controls over each outsourced system (checking each for appropriate password controls, account management controls, and so on), you should prefer to have a federated identity management capability. This will allow your users to authenticate to your internal systems with their enterprise ID and password and then for your vendor to trust your assertion that each user has been properly authenticated. This offers the benefits of centralized identity management and allows you to avoid storing user credentials with your vendor.

If you implement this form of federated identity management, be sure that your internal credential data (such as IDs and passwords) are not being made directly available to your vendor (that is, they should not be able to make direct calls against your internal identity management systems) and that they are not being transmitted in the clear or stored in the clear at your vendor’s site. These requirements will preferably be dictated in your contract. If you are unable to implement federated identities, you will need to review the identity management controls over your outsourced systems to ensure that they meet the requirements of your policies. An alternative solution is to use an identity management service as a “middle man” between your company and your vendor, but of course that solution introduces another third party that you must audit into your environment.

Step 12: Ensure that data retention and destruction practices for data stored offsite comply with internal policy.

If the lifecycle of data is not defined, data might be retained longer than necessary (resulting in additional storage costs and possible legal liabilities) or may be destroyed prematurely (leading to potential operational, legal, or tax issues).

This step is most applicable to cloud computing, dedicated hosting, and offsite service outsourcing (if the supplier is storing your data).

How: Determine whether lifecycle requirements have been defined for data stored with vendors. For a sample, review the documentation of the data’s lifecycle requirements, including retention, archive, and destruction requirements. Ideally, requirements will be identified for how long the data should be active (online, easily accessible, modifiable if appropriate, and backed up periodically), when and for how long it should be archived (possibly offline, not necessarily easy to access, no longer modifiable, and no longer backed up periodically), and when it should be destroyed.

Ensure that these requirements appropriately reflect the nature of the data (for example, external public content on your website should be treated differently than customer data). The contract should dictate that the vendor manage data per your lifecycle requirements. Review evidence that lifecycle requirements have been implemented, concentrating especially on evidence that your vendor has destroyed data per your requirements. Note that data destruction can often be very difficult to prove in the cloud, increasing the importance of using strong encryption for your data, as described earlier.

Step 13: Review and evaluate the vendor’s physical security.

Physical security impacts logical security, because physical access can override some logical access controls. You can have excellent logical security, but if someone can walk in off the street and walk off with the computer (or perhaps just the disk drive or tape cartridges) containing your systems and data, you will at a minimum experience a disruption of service, and if the data is not adequately encrypted, you may also be looking at a security breach.

This step is most applicable to cloud computing, dedicated hosting, and offsite service outsourcing.

How: Review the vendor’s physical security for controls such as these:

• Badge readers and/or biometric scanners
• Security cameras
• Security guards
• Fences
• Lighting
• Locks and sensors
• Processes for determining who will be granted physical access

Excerpted from IT Auditing: Using Controls to Protect Information Assets; copyright 2011 by The McGraw-Hill Companies.  Used by permission of McGraw-Hill.