Overview (By Georg Beham – see the Bloggers)
Detecting security incidents is often a difficult task for cloud users. Conventional IT environments, with on-premises data-processing, can rely on an internal security incident management process which uses monitoring, log file analyses, intrusion detection systems as well as data loss prevention (DLP) to detect hacker attacks and data loss.
When outsourcing to the cloud, not only the cloud service itself but also significant aspects of security incident management are outsourced. Security incident management should therefore be included in the contract with the cloud provider.
Cloud users should inform themselves about the provider’s detection capabilities before migrating to the cloud. The existence of a security operation centre (SOC) and suitable security incident management is an important selection criterion for a cloud service. Cloud users and providers should have the same idea about what qualifies as a security incident. In fact, the definition of a security incident is mandatory in international cloud computing as cloud users and providers may be located in different jurisdictions and e.g. the loss of personal data could have different implications. The loss of certain personal data may be immaterial to a US provider, but it could be consequential to a European cloud user. The process for communicating security incidents and their escalation should also be set down.
A look at the tools for detecting and clearing security incidents can also provide clues as to the maturity of the provider’s security incident management.
Security incident reaction – Computer forensics
Computer forensics pertains to the identification, collection, analysis and presentation of digital data in order to establish the facts of the case. In the identification stage, possible evidence is identified together with the client, depending on the actual case. Data collection entails establishing the ‘scene of the crime’ and area of investigation, carefully preserving any evidence and safeguarding and verifying the integrity of the collected data. During analysis, the evidence is carefully analysed and the results objectively evaluated; the resultant conclusions are then reviewed. The findings are finalised and conclusively documented in the presentation (source: ‘Computer Forensics: Recognising, detecting and resolving system intrusions’; Alexander Geschonneck) .
Nothing short of the ‘data collection’ stage constitutes a major cloud challenge for forensic experts. While conventional computer forensics often starts with the storage medium in order to construct bit-by-bit copies if they are lucky, that is nearly impossible to do in the cloud. For cloud users – not to mention forensics experts – there is usually no way to tell which storage media were used to store the data and where those storage media are physically located. Forensic data collection in the cloud calls for alternative – as well as qualitative – procedures. The forensic expert must collect the data via logical interfaces (e.g. virtual directories, databases). Today already, some cloud providers save hashes (digital fingerprints) along with each data record which are ready for use in the event of a forensic analysis. Here, however, it is important for cloud users and providers to set down such procedures in advance in a Service Level Agreement (SLA). In addition, they also require related technical documentation to ensure the credibility of the data.
A key success factor for computer forensic investigations is the existence of sufficient log data. Similar records should also be available for networks, systems and applications. The availability of log data to forensic experts and the retention period should also be set down in accordance with statute and internal agreements. Here, the synchronisation of system times for all systems is key. The log data from different systems are often merged for analysis purposes. Only with synchronised records can operations be reconstructed and the sequence of events be understood.
Cloud providers could even add extra services to their existing cloud services as proactive support for forensic investigations. These service packets could offer data versioning, alternative storage of forensic data (e.g. copies of emails), automatic hashes, relevant data interfaces as well as analysis tools.
Clouds can span many countries. Forensic investigations can therefore fall under different legal systems. This should also be considered, along with which measures to take in such cases. Rules for house searches (disclosure management) should be set down to ensure an orderly and controlled procedure.
An organisational structure encompassing cloud users, cloud providers and other interested parties should be created as well. Such a cloud forensics organisation should contain people with forensic, cloud, organisational and legal expertise.9
After all, forensic analyses have legal implications. Requirements ensuing from the Data Protection Act, Telecommunications Act or labour law must be taken into account. Enterprises that avail themselves of cloud services should ask these questions before an investigation proves necessary. Arrangements should be made with lawyers and staff councils on how these investigations should proceed. A procedure should then be set down with the cloud provider that can be initiated in the event of an investigation.
Thus far we have seen the cloud in relation to computer forensics as the ‘scene of the crime’ from which data are collected and analysed. Yet the cloud may actually prove to be more of a solution for computer forensics, i.e. Forensics as a Service. After all, the analysis of mass data requires loads of storage space and machine time. Because the cloud is so scalable and flexible, it could amply satisfy those requirements in a relatively short span of time. In addition, it can be quite costly to acquire the necessary software and train staff. Enterprises could purchase these services from the cloud for the duration of the project.