Using ArcSight logs as evidence to support legal action?

Document created by pbrettle on Aug 17, 2011
Version 1Show Document
  • View in full screen mode

A bit of background first – I work for ArcSight EMEA and I am based in the UK. I have previously (around ’99 to ’04) I worked for a independent information security consultancy company. I did a lot for them during that time, but one thing that I did do was to get involved with two separate projects to assist organisations pull together evidence and information to use in court. One was for a UK government department and one was for a government linked (but independent) organisation. Unfortunately, both cases were before ArcSight had any foot print here in the UK. But I still think there is some validity in mentioning what I did.

 

The first case was pretty straightforward with a couple of individuals who were accessing unacceptable websites and pictures (you know what I mean) via the internet. Unfortunately they were administrators and were fairly well clued up on what to delete and hide. So there was quite a bit of manual tracking down of data to pull it all together. Also, they were smart enough to push the “the logs can be easily faked” message early on. Therefore we knew there was no point in just pulling together just a few simple logs. What we needed was solid proof on a large scale, so that it could not be discredited. We were able to pull a considerable amount of data together and we got proxy, workstation and Windows server logs together for a submission. We really thought that it wouldn’t go to court as the accused parties would just take it, but it seemed they wanted to go for something called “unfair dismissal” which would have enabled them to get compensation. Therefore it had to go to court. I am not sure how much difference there is with the Canadian court system, but the UK one has a mechanism of sharing of information prior to the hearing. So each party needs to declare what evidence they have in advance for full disclosure. Anyway, the initial filing went in for the accused, who were taking the UK government department to court for “unfair dismissal”. We had to produce the evidence to support the original dismissal and as part of the initial filing, we submitted a brief overview of our findings. The lawyers for the accused then asked for full disclosure on the evidence which we supplied. A simple attempt was made to discredit this, but they quickly realised that it was not the individual elements that were damning, it was the whole body of evidence that was. This wasn’t a few logs that showed guilt, which can easily be discredited or doubt shown. But there was a large volume (in fact 20 pages of logs in summary alone), that meant that we really couldn’t have faked them! And then there were logs from different systems, technologies and devices that showed supporting information for themselves.

 

The second case was much simpler as I was drafted into assist an organisation to pull together evidence for a criminal case against an employee of a transport company. The background is that this transport company (part local government owned) was working with development groups and the government in redeveloping parts of a city. Therefore the information that they had was of a sensitive commercial nature – for example, knowing where the next rapid transport links were to be setup and who owned what land that needed to be bought for it! Oddly, the first sign that there was something wrong was that the same employee was involved with land that was due to be purchased, twice – unusual to say the least! Again, this was an administrator who used some fairly sophisticated techniques to hide accesses to various folders and files, but had access to create and delete users to hide the audit trail. Again, we were able to pull together sufficient information to be certain of what they had done and again the issue of authenticity of the logs was brought into question. Single logs on their own were not going to be sufficient because they “could be easily faked”. So again, we were able to pull together a large number of logs from different sources such as firewalls, network equipment and operating systems to prove what had been done at what time (though the time of the incidents helped here, as it was all done at midnight or around there, so it was easy to find the relevant logs!). As with the previous example, we were able to provide a summary of the accesses and incident but the real evidence was with the huge weight of logs that we had that supported this. There was no way that the defence could claim that 100’s of pages of logs were faked or somehow wrong! In this case, the defendant pleaded guilty quickly and was subsequently imprisoned.

 

I am not sure what the legal situation is elsewhere, but certainly in the UK the mere act of unauthorised access to a computer system carries the threat of a prison sentence (not that this alone stops anyone). In the UK the computer misuse act is actually fairly strong and all we need is sufficient “strength” in the evidence that can stand in court. There is no minimum legal precedence or standard that the evidence must reach, so one log entry could be sufficient, but there are plenty of legal avenues that can be used to discredit this. What does work is when there is a large amount of logs from difference sources that support what you are saying. Attempting to argue against them is seen as futile and a judge could rule that its time wasting (which I know has happened previously), so its often the best case for the defence to accept the log data and move on to a different tactic.

 

A common issue that seems to come up a few times is that there seems to be an expectation that the log data needs to be submitted in its raw or original format. Yes, clearly this makes sense, but its also pretty useless. For what I have previously done, we did “format” the data anyway. There was always going to be a process of taking the logs and highlighting them, documenting them and putting them in a format that allowed them to be printed out – so you could say that this is “normalisation” anyway, so by default we will be doing some processing. Therefore there should be no issues with any ArcSight logs as if anything, they are in better format to submit anyway.

 

Actually the benefit here is not in the raw log, but in the weight of logs that can be brought together with ease using ArcSight. For example, using IdentityView, it becomes a fairly trivial activity to run what we call the “user investigation” report. This runs through all activity for the user and dumps it into a report. I have provided this report to a few people in HR departments and they have all said its sufficient to take action against an employee, so I am confident a small amount of customisation and it would be fine for legal submission. Again, its not the single log that is relevant here, but the proof of all activity up to and including the alleged incident. For example, someone could claim their physical access card had been stolen and used to enter the secure part of a building. But the same card had been used to purchase coffee a mere 10 minutes later, on the same floor as the person in question! A quick check on what they ordered (the usual) indicates that its the same person! This was an actual incident that I have heard of and the person in question had to admit that it was them! Its not the individual logs but the linked and joined ones together that paint the picture that help.

 

Finally, I would say that we do have two customers in Europe (cant mention the names), but they have been long term customers for us and both have used and submitted evidence collected from ArcSight solutions in court. All have been successful and I have no doubt in what we can provide.

 

So, back to the use case point above - Using ArcSight logs as evidence to support a legal case? Yep, its actually quite easy and its a good idea to keep focused on the objective and not the individual parts. There are lots of arguments on individual parts of this - the fact that normalisation occurs at all means that the log has changed, but when confronted with days, weeks or months of activity logs, it becomes virtually impossible to discredit. Strength in numbers works, though not to bamboozle, but to paint a picture - a very clever picture, but a picture nontheless.

 

As for practical parts of the use case?

 

  • Active Channel view / Field sets defined for exporting data in a specific format - raw log, crypto signature, name etc. Although its great to have lots of logs for supporting your evidence, do you need ALL of the event fields? Maybe strip this down to what is needed with a field set and then have an active channel to display these. Export on the field set to keep the total sizes down.
  • Reports - you dont "need" IdentityView for this, but build the use case to make sure you can report on what you need. Of course, building a trace of user activity with IdentityView is great, its not for everyone. So why not do some simple mapping to enrich the data for username / person name as needed. This could be done at connector (connector mapping is documented) or maybe have your own Active List with user information in it? Either way, a mechanism is there to do simple and fast reporting on user name / machine name is what is needed. Beyond that its simple.

 

Finally, work with your legal team on what is actually needed though. Sometimes its less than you think and its not as complicated as it might seem.

Attachments

    Outcomes