Cloud Forensics

IaaS Environments

In infrastructure-as-a-service (IaaS) scenarios, increasing virtualization of physical machines also offer some benefits: Snapshot technologies make it possible to create complete images of the virtual machines, which is an enormous advantage for digital forensics. But one question remains unanswered – whether or not the image was created in a valid way. There is no simple way for a user to verify this. Documenting the technical process of the scope of a snapshot process will definitely be a big help; many CSPs work with a modified version of the hypervisor, and you should not rely on the manufacturer’s process documentation for this reason.

Additionally, IaaS service customers are unable to access network components, making it impossible to access log files on routers, switches, firewalls, and the like in the course of the investigation. Thus, no evidence at all is available from the network layer, and only the CSP would be able to change that.

An interface that allows the customer to tap into the source of evidence would be a useful step in the right direction. Network components then could create individual log files tailored for virtual instances in IaaS scenarios. This would mean that only excerpts of the network traffic to and from the virtual instance would be recorded and provided to the customer, possibly even as a commercial value-added service. Also, the CSP would probably want to restrict the period of time in which log files are available to the customer to avoid wasting storage space. Of course, customers could only access evidence for their own virtual instance and not for any neighboring instances. Such an approach would offer a decisive benefit to the customer: In the case of a compromise, the customer could correlate evidence from the client with the network layer and the server (IaaS instance), assuming that the IaaS instance had written its files to an external logfile server at regular intervals. Otherwise, an attacker would be able to delete or modify the log files after successfully breaking into the IaaS instance.

To prevent attacks of this kind, the CSP could offer a virtual introspection service. The customer would need to sign an agreement allowing the CSP to run automated tools against the hypervisor at regular intervals to verify the system state of the virtual instance and create corresponding log entries. Attackers would not be able to manipulate these entries unless they completely compromised the hypervisor [9].

SaaS Environments

In SaaS environments, customers can only communicate with the service through a prebuilt API. In many cases, this process is handled directly by a web interface. Advantages and disadvantages to this approach exist, but the decisive thing is that customers need not concern themselves with the security of the application – that is in the hands of the CSP. The disadvantage is that the customer is restricted in terms of the flexibility of the application – that is, the customer cannot just add functionality that the CSP doesn’t implement. One example of this is the feasibility of forensic investigations in SaaS scenarios, as the previous example showed.

However, options exist for changing this situation: The CSP could offer an additional forensics interface, which users could then leverage to trace specific access to records in the SaaS application. These records could comprise, for example, emails, customer data, and financial data. The cloud service customer would thus need to verify how and when users could access the data.

Such an interface could be part of a larger provenance framework that would log all read and write access to the records and serve up the results to the customer. In case of a suspicious incident, a user could query the API for corresponding access and thus more easily identify unauthorized access. At the same time, an automated evaluator could make sure that no unauthorized third-party access occurs.

For the CSP, implementing this type of interface would be easier than with other service models because the context of the data to be protected is clearly visible.

For example, if the ABI function storing a file is called in the scope of a PaaS service, the function call could be logged to record the fact that a file with a specific name was stored at a specific location. The further context of the file is unclear to the CSP. This is different for a SaaS service: The context of the data is clearly visible to the CSP, because it has implemented the functionality (e.g., email is sent, processed, and so on.)

The data format of this interface could leverage existing data formats, thus ensuring interoperability between various tools and frameworks. One popular format is DFXML by Simson Garfinkel [10], which is an XML format for describing forensic information.

Using an open data format would also offer the advantage that the existing forensics projects could be connected to this interface. In an ideal world, customers would thus be able to add a cloud service to their own in-house forensics framework.

To guarantee the requirements such as integrity, authenticity and confidentiality, existing XML frameworks could be used with DFXML for signing and encryption. This means that the log information would be output to the customer in the form of XML via an API and additionally signed by the CSP, or even encrypted if needed. However, there is no way of knowing precisely what information the customer might need for an investigation – this depends to a great extent on the scenario in question or on the SaaS platform and the critical assets.Finally, it is important to determine how long the CSP should retain data for each customer. Again, this value could be defined individually in the SLA. At the same time, the customer would have the option of extracting the data directly from the interface and integrating the data with its own logging server. On the server, the logs could be matched with the customer’s own policy and evaluated correspondingly.