Criminal IT: What you can do to help the fight against cybercrime

Start by not tampering with compromised systems...

My day job is a rather unusual one; I'm a computer expert witness, principally in criminal prosecutions and primarily for the police. I help to identify, preserve, analyse and - perhaps most importantly - present computer-derived evidence. My job is to make sure the jury - usually complete computer novices - have the best possible chance of understanding and appreciating the nature of the technology and arguments involved. It's a fascinating, challenging, frustrating and deeply rewarding occupation.

It started with the usual types of cases, ones in which we might all expect to see computer data being important. Internet paedophilia and computer hacking were the bread-and-butter of such cases in the early days but increasingly computer evidence has come to be important in a range of other types of case. I've worked on several extortion, fraud and theft cases; I've been consulted on stalking, harassment and insider dealing; and I've worked on cases where employees have been found to be stealing trade secrets or publishing information on websites.

Even more worrying, I've been involved in cases of abduction, rape and even several gruesome murders. In all of these computers have been involved - as the victim, the agent and as the reliable witness to the event, the motive or the planning.

No police force, no corporate investigators and no aspect of the criminal justice system can afford now to ignore the all-important computer evidence. This might come from the victim's computers or the computers seized from the defendant, from internet service providers, mobile phone companies, digital traffic cameras or CCTV. Every day, every one of us is 'seen' by a large number of computers as we go about our everyday business - and if that business is criminal, then the data those computers contain falls within my remit.

There are, however, a variety of problems that need to be overcome before the computer records - from whatever source - can be presented to a jury. Evidence literally means 'that which is seen' - and as magnetic, electrical or optical coding of binary data, computer records need a lot of processing before they are fit to be seen by a jury. The data needs to be copied, it needs to be interpreted and it needs to be translated so the jury can see the pictures, read the documents or understand the log files.

Perhaps the greatest problem, though, is in the sensitive and transitory nature of binary data - the best example being the timestamps on files. Under NTFS, perhaps the most common file system that we work with today, every file has three timestamps called the MAC values: the date and time at which the relevant file was first created, last modified and last accessed. The creation time is established when a file is first created on the file system; when a picture begins to be downloaded from a website, when a document is first opened, when a file is extracted from an archive - but also when the file is moved from one place on the disk to another. The creation time becomes the first timestamp of interest.

The modified timestamp records the last time at which any data is copied into the clusters which form the file. It records the time at which the picture has been completely copied down from the internet, as the last cluster of the JPEG is finally downloaded; or it represents the last time at which a DOC file is altered by the user. It shows us when the user last did anything substantive with the file so as to change it - or, with a JPEG extracted from an archive, it shows us when the picture was first created, perhaps on some other person's computer, since pictures tend not to be altered. Vital evidence in many cases but not as useful as the third timestamp.

The last accessed timestamp shows the last time at which the file was 'touched' by the computer and is on a 'hair-trigger'. Almost any form of access will reset this timestamp: look at the picture, print out the document or inspect the file's properties; all of these will update the value. It sometimes feels as though even if you were simply to sneeze near a computer it would result in changes to the last accessed timestamp - and certainly if you turn on the computer, shut it down or go looking through the file system you will, inevitably, change these values in ways which you cannot predict.

This is an important consideration in computer forensics. Imagine a computer which has been hacked in the middle of the night. As the hacker explored the system, perhaps looking for interesting files to steal, they will have touched large numbers of files and folders, altering the last access time.

That pattern of changes forms a progression through the system - illustrating whether or not the hacker already knew the system or was exploring blindly. It can tell us whether he knew where his target file was located - showing that he was an insider or had inside knowledge - or whether he had to try and find it. It's almost as though fingerprints at a crime scene came with a time value associated with them, vital in building an understanding of what the intruder knew and who he actually was.

Unfortunately, these timestamps are equally easily affected by system managers who examine the hacked system before reporting the crime to the police - by analogy, they are wiping the crime scene free of fingerprints, obliterating the evidence so as to make it irrecoverable.

In a murder scene we would all know not to do that; in a computer crime scene this is not quite so easy. Several years ago, the Association of Chief Police Officers of England and Wales (ACPO) published a 'best practice' guide for handling computer evidence.

Data should not be changed, or if it is changed should be altered only by competent people who know the extent of that change and are able to give evidence as to why it changed. Data should be copied securely, with the timestamps intact, so it can be reconstructed by the defence - and analysis should proceed on that copy.

The so-called 'first responders' to a computer crime scene - the system managers, business owners and so forth - should all be encouraged not to pollute the scene as they follow their own, natural curiosity. By ensuring that systems believed to have witnessed an offence are preserved reliably, my job in court would become an awful lot easier.

Although the ACPO guide is aimed primarily at law enforcement I cannot recommend it highly enough to all of those involved in computer security or computer operations: it might be the difference between a successful or a failed prosecution when we finally get the suspect to trial, and I'm sure that we would all want to see the best result possible.

Make my job easier; read and follow the ACPO guide for digital evidence.