Collection of Evidence: With virtual servers, the controls and procedures in which evidence is gathered must be modified. This could vary from taking the physical servers offline (and migrating off any nonimpacted instances) to simply hibernating and cloning the affected instances. Performing digital forensics on virtual machines has important implications that have yet to be fully explored. When a virtual machine is powered off, its disk image remains available to the host operating system. This exposes the instance to potential tampering in a manner that does not exist with physical machines. Defining acceptable methods for collecting evidence in a virtualized environment will be essential to performing incident response and forensics.

17.2.5  Compliance

The goal of Compliance controls is to ensure that systems comply with all relevant laws, regulations, and any other constraints imposed on the system. Within this family, gaps were identified in the following controls: Technical Compliance and Audit Tools

Technical Compliance: Compliance issues are paramount when operating within a highly regulated environment. Just as with traditional data centers, auditors will demand that cloud environments remain compliant. The physical location of data will be of particular importance in the cloud, especially in the context of data privacy, business continuity planning, incident response, and forensics.

Audit Tools: Audits must identify rogue instances on the network and other suspicious activity or control failings. New tools are required to verify that all instances are in compliance. These compliance checks must be run automatically against instances immediately after provisioning, after maintenance, and again when decommissioned.

17.3  Security Recommendations

In the previous section, we identified a number of security gaps against the ISO 27002 standard that are unique to virtualized systems and cloud computing. In this section, we provide a list of 20 recommendations (summarized in Table 17.1) that attempt to address many of these gaps. Although some of these recommendations are not unique to cloud environments, they become more critical to address when working in a cloud. This is by no means an exhaustive list of steps necessary to protect a cloud environment. Instead, it is meant to provide the reader with some of the many actions that must be taken to ensure a reliable, secure cloud.

1.Provide globally unique names to every instance in the cloud that allow key instance attributes to be identified. From the name, one should be able to identify the application as well as the owner. All instances created across the cloud should be assigned a name provided by the cloud. This is a globally unique

Table 17.1  Summary of cloud computing security recommendations

Recommendations

 1. Provide globally unique names to every instance in the cloud that easily allows key instance attributes to be identified

 2. Record resource locations, both physical and virtual, throughout an instance’s entire lifecycle to enable traceability

 3. Do not implicitly trust the cloud or any instances in the cloud; every interaction in the cloud demands authorization and authentication

 4. Encrypt instances and data when stored to disk and while migrating between servers

 5. Restrict dynamic utilization of resources to predetermined levels to prevent an “internal” denial-of-service attack

 6. Virtually “shred” retired instances and data when no longer needed

 7. Assign priorities (i.e., SLAs) to every instance in the cloud to ensure appropriate availability and resource utilization

 8. Utilize a single management, logging, and monitoring system capable of supporting the entire cloud

 9. Restrict console access (physical and virtual) to users with a defined business need

10.Create new instances according to defined, tested, and approved specifications

11.Execute applications across multiple physical servers to improve reliability

12.Provide centralized authentication and authorization services

13.Provide a centralized key management system to allow the cloud to communicate sensitive information

14.Digitally sign control messages within the cloud in order to prevent tampering and unauthorized use

15.Restrict data ingress/egress points in the cloud to mitigate the introduction of malicious software and removal of private data

16.Record the current state and lineage records (from creation to destruction) of physical and virtual resources

17.Isolate suspicious instances and replace with alternate instances

18.Scan the cloud for unauthorized instances in order to identify, isolate, and remove them

19.Audit resource utilization records to detect suspicious activity

20.Audit instances at “life” events, such as creation, migration, hibernation, and startup, to ensure compliance

identifier that is used to cross-reference information about the instance. Instance names are kept for the life of the cloud to preserve records and logging integrity. If instance names are to be viewed by unprivileged personal or processes, then the instance name itself should not reveal any useful information about the application or the data being stored within the instance. A user-defined name (i.e., “alias”) may be permitted for convenience, but the globally unique name will be the standard identifier used within the cloud.

2.Record resource locations, both physical and virtual, throughout an instance’s entire lifecycle to enable traceability. Records of physical resources and data that were used or generated by an instance should be maintained from creation to destruction. This is important for successful incident response and digital forensics. See Recommendation 16 for additional details.

3.Do not implicitly trust the cloud or any instances in the cloud; every interaction in the cloud demands authorization and authentication. Neither the cloud nor

any instances should trust each other. When an instance stores any data within the cloud, it should encrypt the data. Similarly, the cloud should not trust any particular instance. This includes limiting the amount of cloud resources that are usable by any particular instance (i.e., to prevent a denial-of-service attack). See Recommendations 4 and 5 for additional details.

4.Encrypt instances and data when stored to disk and while migrating between servers. All instances should be encrypted by the cloud provider when being stored to disk or in transit from one physical server to another across the network. This is to prevent unauthorized access to the information stored within the instance. Additionally, individual instances should take their own precautions and encrypt sensitive information, including virtual memory (RAM), that may persist on disk (e.g., through paging files or if the instance is hibernated to disk).

5.Restrict dynamic utilization of resources to predetermined levels to prevent an “internal” denial-of-service attack. Automatic growth should be capped at a predetermined level. A cloud administrator can manually override this limit after a review. Without this limit, it may be possible for one business application to consume vast amounts of resources on the cloud and effectively cause a denial-of-service for all other applications.

6.Virtually “shred” retired instances and data when no longer needed. When there is no longer a business use for an instance or data, it should be removed from the cloud and disposed of properly. The image on the file system should be virtually shredded (i.e., overwritten with random data).

7.Assign priorities (i.e., SLAs) to every instance in the cloud to ensure appropriate availability and resource utilization. When a new instance comes online within the cloud, it should be allocated a business criticality. This rating is used to determine the order in which resources are allocated across applications within a cloud. Those applications with a higher business criticality will have first rights to cloud resources.

8.Utilize a single management, logging, and monitoring system capable of supporting the entire cloud. The cloud should have a singular management interface to control and check the status of the various aspects of the cloud. The implementation of this management interface could be centralized or distributed, allowing for multiple consoles that provide the same information. However, any one console should be able to display information about the entire cloud. Logs and events across all instances should be consolidated and presented in an aggregated manner.

9.Restrict console access (physical and virtual) to users with a defined business need. Access to device consoles (physical or virtual) within the cloud should be restricted to users with a defined business need. The ability to start and stop an instance on the network should be restricted to the owner of the instance and authorized delegates.

10. Create new instances according to defined, tested, and approved specifications. New instances should be built, ideally through an automated process, to predefined, tested, and approved technical specifications (such as templates). Arbitrary instances should not be allowed onto the cloud without going through an approved process that includes defining a technical specification.

11.Execute applications across multiple physical servers to improve reliability. Distributing a business task in an intelligent manner across a number of physical servers improves the reliability of the task, since it is no longer reliant on any one server.

12. Provide centralized authentication and authorization services. Authentication, the verification of the identity of a process or individual, should be handled by a centralized service within the cloud. By centralizing the authentication of users and processes, it is easier to detect suspicious activity, such as failed logins. This also reduces the number of copies of sensitive data, such as usernames and passwords, across the cloud.

13.Provide a centralized key management system to allow the cloud to communicate sensitive information. Centralized key management provides a mechanism for the cloud to securely communicate sensitive information. Segregation of this key management from the cloud provider, and by roles within the same provider, is a worthwhile consideration because of the separation of access and enhanced level of data privacy that can be provided. At a minimum, each administrative user on the cloud would be assigned a public/private key pair that could be used to facilitate secure communications. This key management infrastructure should be used for distributing initial super user credentials and for managing instances.

14. Digitally sign control messages within the cloud in order to prevent tampering and unauthorized use. The key infrastructure described above should be used to encrypt all messages, such as the control messages to create, destroy, or otherwise modify instances on the cloud. If needed, these control messages would be encrypted in addition to being signed. Time stamping of all control messages should be required to prevent replay attacks.

15. Restrict data ingress/egress points in the cloud to mitigate the introduction of malicious software and removal of private data. Interfaces where data can be copied to and from the cloud should be restricted to administrator use and monitored. This includes network and storage media interfaces. Physical access to media (e.g., tapes, disk drives, USB interfaces) should be restricted to prevent unauthorized data access. Cloud storage clients should use approved network interfaces to upload, download, and access cloud data. Network data ingress and egress should be monitored for malicious software and unauthorized data transfers.

16. Record the current state and lineage records (from creation to destruction) of physical and virtual resources. As instances are brought online and destroyed, it is important to keep a list of all approved instances. This list will be used to audit the cloud, ensuring that there are no rogue instances running. These records should include the physical location of each instance, state (e.g., running, suspended, isolated, destroyed), and owner. Historical records of instances should be maintained after an instance is removed from service.

17. Isolate suspicious instances and replace with alternate instances. If suspicious activity is noticed, the offending instance should be frozen and replaced with an alternate instance. The suspect instance would then be isolated from the rest of