Pages

Saturday, March 20, 2010

Live Forensics within the Cloud Computing environment

Traditionally analysts performed analysis on static data, either from a core dump, bit to bit imaging etc. Recently we have seen an increased focus directed at the live forensics environment.

I read an article a few weeks ago where cloud proponents stated that an advantage of Cloud Computing is, an ability to conduct live forensics without disrupting mission critical systems.

According to Brian Carrier - “The only difference between a live and a dead analysis is the reliability of the results; a live analysis techniques use software that existed on the system during the time-frame being investigated;dead analysis techniques, use no software that existed on the system during that time-frame.” - Bear in mind though that there are different aspects and levels to these statements.

A few of the experts in this field that I was able to interact with did state that when conducting a live analysis, the system under investigation will be altered in some manner. This in essence can define a live analysis as not a pure forensic form by definition. However the potential for gaining valuable data is looked on as the lesser of two worse case scenarios.

The Cloud Computing environment is susceptible to classical attacks as any regular system. My concern as a security consultant is the potential for exploitation of the system under live analysis. One instance can be with rootkits, and if an attacker can compromise a host's cloud system....well.. but we don't even have to get as deep into that inner circle to manipulate a system covertly.

Rootkits as we know can be divided into database rootkits and BIOS rootkits.The potential for exploiting both and remain undetected is high e.g.by manupulating the ACPI(Advanced Configuration Power Interface)in BIOS via it's ASL programming language to modify hardware features or memory.

Hypothetically speaking one may be able to insert a rootkit which reacts to a forensic probe and then output pre-programmed results to suit an attacker; remember that a snapshot of a running system cannot be reproduced at a later time-frame.

In another scenario the rootkit may be programmed to respond by purging and shutting down the system -- “A "hard" reboot includes a power cycle, which ensures that sensitive information in volatile memory is purged”- Vernon, R.C. Irvine, C.E. Levin, T.E. Naval Postgraduate Sch., Monterey, CA ISBN: 1-4244-0130-5.

Researchers at University of Illinois at Urbana-Champaign demonstrated in a paper that it was possible to construct a working rootkit that did not change the host OS code or data, essentially evading detection with current techniques: - Cloaker: Hardware Supported Rootkit Concealment
Francis M. David, Ellick M. Chan, Jeffrey C. Carlyle, Roy H. Campbell


I am certain thought that security teams and IT auditors for cloud providers are investigating means to mitigate these risks..right?

Any further thoughts on this will be appreciated !

No comments:

Post a Comment