Case Study

Corporations can outsource the email service to a SaaS provider, which offers various benefits. For example, you don’t need to purchase and manage your own email server, which saves both procurement and personnel costs. From now on, the CSP is responsible for the security of the application – not your own administrator, who simply has to manage the user interface. Staff can then configure their email clients to use SSL/​TLS to retrieve email directly from the CSP and to use the CSP’s email server in the cloud to send email. Users also can access the CSP’s web front end as a web mailer.

Unfortunately, users desktops are continuously hit by malware despite the use of anti-malware solutions. Malicious programs can sniff the password for access to the email servers in the SaaS cloud and send it to an attacker. Incidents of this kind are nothing special; in fact, they are part of the daily grind. The employee typically doesn’t notice a thing and isn’t even suspicious, because the email client just keeps on working as before. Even if the attacker uses the stolen credentials to log in to the victim’s email account via the web front end, the victim typically will not notice because logging mechanisms giving the user the ability to identify such incidents are not usually configured.

Some CSPs show you the last IP addresses used to access the email account; however, this assumes that the user logs into the web front end and that the address that is recorded is not the address assigned to the user. In the case of an insider attack on the same network, or if the user simply can’t interpret the information, detecting the attack becomes very difficult.

The attacker needs to leave noticeable traces in the victim’s email account before the victim starts to become suspicious. This might be the case if the attacker were to delete a message from the inbox or to manipulate a message in some noticeable way. The victim would be surprised in this case, but it might be the CSP’s fault if some kind of technical glitches occurred. The user has no chance to confirm or refute this theory. In other words, a method of guaranteeing accountability in cloud services is also missing [8].

If users do suspect somebody of manipulating their email, they still don’t have an option for performing forensics investigations themselves. Their only option is to contact the CSP’s hotline and request that the incident be investigated. Depending on the CSP’s approach, the user might finally find out that their account has been compromised.

But what would the results of this be? The user has no way of finding out which data the attacker has viewed because they have no access to logging data. In the worst case, the attacker might have copied the whole account and simply published it on the web. Another possibility is that the attacker might sell the data to a competitor – all of this is pure speculation to the user.

Outgoing email is another issue: It is very difficult to track the correspondence that went out to potential business partners, because an attentive attacker would probably delete outgoing and incoming messages. In other words, an intruder could attack systems belonging to business partners and colleagues in the name of the victim. They could also send false offers to business prospects or even manipulate account data.

Of course, all of these attacks would be possible with a legacy email service that you ran yourself. But, in that case, a retrospective investigation would be much easier because systems and processes could be established to support or facilitate forensics investigations. In a cloud environment, the user is primarily dependent on the CSP’s cooperation. This situation could cause substantial legal problems or delays in the case of globally active CSPs.

New Approaches to Cloud Forensics

Basically, three different components must be considered for investigations in cloud environments: the user’s client system, which is connected to the cloud service; the network layer through which the data was exchanged between the user and the cloud; and the virtualized cloud instance – independent of the service model. The sources of evidence from all three components must be correlated and organized in a common context to make it possible to discover the details of the incident. Unfortunately, this is very difficult to do in real-life scenarios, because the investigator typically doesn’t have the necessary evidence.

As this example shows, traditional methods of digital forensics are no longer useful, or only partly useful, in cloud environments. Whereas a one-to-one copy of the data medium previously was created in the case of an incident, investigators cannot resort to that method in today’s virtualized environments. The main issue here is that the forensic investigator typically doesn’t exactly know where the data affected by the incident is located. This applies to the SaaS scenario as well: The precise storage location of the email is invisible to the user and attempting to identify it would cause both security problems and data protection problems.

Additionally, the CSP will never grant the user physical access to the data medium because it could also contain data belonging to other users not designed for disclosure to a third party. To avoid cases like this, it is a good idea to add a clause to your Service Level Agreement (SLA). However, we are unaware of a CSP that offers this kind of provision in their SLA.