jump to navigation

Conclusions / Legal juni 24, 2006

Posted by Rolf in Forensic process, Forensic tool, Generic Info, Information, Legal aspects, Objective, Proposal, Uncategorized.
7 comments

Being able to gather data that is reliable enough to be admissable in court by simply pushing a button has a lot of legal consequences. The most obvious way to have admissable evidence is by using "qualified electronic signatures" for all the actions that take place in detecting, gathering and processing data and evidence. The reason it is so obvious is that such a signature is already so called " legal evidence", it is then up to the defendant to proof he did not do it in stead of we having to proof he did it. Alas this would require a very complicated and expensive public key infrastructure. Therefore we have to look also at cases that do not have the benefit of legal evidence. In order not to have to go through all the legislation worldwide we have to make a number of assumptions. The assumption we made are:

  1. The whole system is in private hands and is not owned by the government and or police. Therefor we do not have the special investigation rights as adressed in criminal law. We have to stay within the boundaries of private law.
  2. The whole system must operate within the boundaries set by privacy laws.

ad.1: The fact that we are not a law enforcement agency brings a lot of restrictions on the gathering of data and/or evidence. Law enforcement agencies have, if a reasonable level of suspicion exist, the right to seize goods, arrest people, search houses and persons. In a way we can say that they can steel, kidnap, intrude, stalk and rape. With other word they have the permission to break laws. Luckily these special right are only granted under very special and highly controlled circumstances. Because of these controlled circumstaves we as private persons or organisations can not just investigate everything that we think is suspicious. We have to stay within the boundaries as set by private laws.

ad. 2: Like mentioned above in case of an incident it is required to investigate the circumstances in order to get data and/or evidence. In order to get data that can act as evidence we first have to gather it. As we do not have the same right as the law enforcement agencies we need to stay within the boundaries of privacy laws. In Dutch law privacy related data may only be processed if a number of conditions is met:

•Data must be processed in an orderly matter.
•Data may only be collected for a specific goal
•Collection of data may only take place if one of the following criteria is met:
 o Explicit aproval
 o Necessary for executing a contract
 o Necessary for executing legal requirements
 o Necessary for protecting vital interest of the person it concern
 o Necessary for executing a public duty
 o Necessary voor a justifyable cause
•Data may be processes for the original goal that they were collected for.
•Measures must be taken to avoid that data are colected and/or processed unnecessary or for the wrong objectives
•The processing must be reported to the CBP (College Bescherming Persoonsgegevens), unless de reporting of processing is excluded in the vrijstellingsbesluit;
•Data must always be available for the person concerned and he or she must be enabled to correct, delete or protect data.

For what the privacy laws mean for our IT envoronment please see the comments. 

Identity and Pseudonyms juni 24, 2006

Posted by Wilbert in Forensic tool, Legal aspects.
add a comment

There has been quite some discussion about linking an identity to user IDs etc. I can imagine this could be one of the corner stones to allow a forensic information system to exist.

The document ‘Digitale identiteit en pseudonieme digitale certificaten’ gives interesting and relevant perspectives towards IDs and privacy laws and the linkage of an ID to a human person.

If the ID to access a computer system is chosen in such a way it cannot be easily linked back to the owner of that ID (thus chosen in naming but also in protecting the link between the user and his IDs), I think it can be considered a Pseudonym.

See link tab comment 14 for the document

Conclusion / Solution juni 22, 2006

Posted by Wilbert in Forensic process, Forensic tool, Generic Info, Information, Legal aspects, Objective, Proposal, Uncategorized.
8 comments

Taking into account all the discussions and information, there is a need to come to some sort of conclusion/solution.

The objective was to define a system that when an electronic incident had happened, by a push on the button the system would produce forensic information that would be admissible in court.

This lead to a common (mis)understanding that after the ‘push’ evidence would be produced and no further forensic investigation would be necessary.

First of course is that no evidence is produced but information that could become evidence. To become evidence the information needs at least be produced in a way that no reasonable doubt exists about the origin and content of the information and underlying data.

Second, there always is a need to do (some) further forensic investigation. If only to show the minimum necessary is done to obtain the obvious information and no relevant information is forgotten (pro or con a suspect).

In addition, from a business point of view it needs to be acceptable as well.

So the system does not need to be the ‘holy grail’ for the forensic world. A one fits, does all miracle tool. It is an interesting starting point, but in the end we have to bring in some common sense and realism as well.

Some automation in forensic investigations does already exist today (like Encase, WTF) so sugggest the new system should go beyond or preferably differentiate from what the existing tools do today.

Where existing tools in general focus on low-level technology investigations, I propose the new system focuses on the Identity and Access Management (IAM) aspect, thus the access and behaviour on systems/applications, basically the login and instructions given to the system (commands issued (GUI or CLI), programs started, database manipulation, …) and the direct and indirect resulting events of those actions.

The information as input to the system should come from the standard available access control and audit functions of operating systems and applications. There is no indication that there are any legal concerns in relation to the use of these standard functions already commonly used throughout organisations today.

The system will take the IAM and audit information and correlate and organise the different data sources into a readable sequence of actions and events performed/caused by a person. Although the aim should be that the output of the system is of a quality that it can be used in court (and clearly shows what a user has done), it does not exclude the usefulness of low level technological forensic investigations to support that information.

When such a system would exist, it could or even should be extended to be used beyond forensic investigations for (near mis) incident reporting by analysing of user behaviour before an incident happened. The fact that the analysis is done in a forensic sound way is just a bonus (in the end this only says something about how the investigation is done, not what has been investigated or for what reason).

Reality Check juni 22, 2006

Posted by Wilbert in Forensic tool, Generic Info.
5 comments

Would DEC have been useful in the following case?

http://www.informationweek.com/management/showArticle.jhtml?articleID=189600435

Focus on identity and access management juni 17, 2006

Posted by Wilbert in Forensic tool.
add a comment

An internal threat study of Carnegy Mellon, CERT, Nation Threat Assessment Center and US Secret Service (for document see in link tab) on 23 insider incidents in the banking and finance sector revealed that
– 20 cases were performed using legitimate user commands.
– 18 cases were performed by authorized users with active computer accounts at the time of the incident.
– 10 cases were performed by users using their own username and password to carry out the incident

Although the report leaves still some questions, it basically say the majority of attacks were performed following a normal access control process (like username/password).

Assuming that the insider threat is still the biggest threat and that the study can be considered valid for other sectors as well, suggest to focus on the identity and access management system and logs produced by that.

Assumption 5 focus of DEC is the identity and access management system.

Memory information is excluded from the DEC juni 17, 2006

Posted by Wilbert in Forensic tool.
4 comments

In forensic investigations, memory content can give valuable information. A reason not to reboot or shutdown a target system before taking a memory image. Also malicious code can be created that runs completely out of memory. So in a post-incident investigation memory contents can give valuable information.

Memory content is very volatile. To capture information from this, to be subject to investigations later, would practically be impossible. The impact on a running system while taking a memory dump is significant, if not enormous, unacceptable,… So imagine this is done regularly.

Unless dedicated hardware is developed, I propose

Assumption 4, memory information is excluded from the DEC.

The systems supporting the DEC can be protected adequately juni 12, 2006

Posted by Wilbert in Forensic tool.
2 comments

The systems supporting the DEC, thus the collectors, storage, processing, reporting systems can be protected adequately with standard COTS products. Think about network segregation (separate VLAN, Firewalls, nIDS, etc.) as well as the system/application/database level (access control, hIDS, AV, etc.) and the transaction level (session encryption).

Assumption 3, the DEC can be protected adequately.

Where to store the data juni 11, 2006

Posted by Wilbert in Forensic tool.
9 comments

Off-loading the data from the different systems that generated it to a (central or not) dedicated system for analysis purposes seems more logic then keeping it for analysis on the system where the potential incident happened.

Assuming that potential attackers would have full access, this off-loading should be done near real-time. Any failure of this should trigger an alarm (which should result in action preventing the incident from happening). Of course this needs to be done in a propor manner (consider hash, time-stamp, signed etc.).

This will have an additional overhead on the network due to the transfers, as well as additional overhead on the processor for hsashing signing etc. (but avoids potential disk space problems due to extensive logging).

Having the data in a central place allows an easier management of the data. Think about archving on SANs, ROMs.

Assumption 2, data will be stored centrally.

Which data should be considered? juni 11, 2006

Posted by Wilbert in Forensic tool.
add a comment

Standard system logs should not be a problem to be included. I have not found any information considering the privacy laws in relation to setting certain audit functions on syscalls or events for unix systems (or windows and others). Not in preventing it nor the need to declare it.

Assumption 1, All standard system logging options can be turned on (if required).

The Digital Evidence Collector (DEC) juni 9, 2006

Posted by Wilbert in Forensic tool, Proposal.
7 comments

Some tools exist already that might support a solution.

Think about Encase Enterprise (see links tab)

Or WFT (see links tab)

Flow diagram of the Forensic proces juni 6, 2006

Posted by Rolf in Forensic process.
14 comments

In addition to the unstructured criteria and requirements for the forensics tool it is even more important to have the underlaying proces of gathering digital evidence clear. What proces is going to be automated by the forensic tool? What are the individual steps in that proces ? What are the (legal) conditions we have to consider for each step ? It would be very nice to have consensus on the proces and the conditions. Once we know them we can start filling them in by researching both law and technology.

Step 1: Detection

Suspicious event is detected

Condition: Event must be illegal (strafbaar feit) ?
Question: Who decides if something is illegal ?

Step 2: Gathering

Procedure is started by gathering data.

Condition: Data must be gathered legally
Question: What does legally mean in gathering data ?

Step 3: Analyses

Analyses of the data to get information about the event

Condition: data should not be changed during analyses

Step 4: Evidence

Produce qualified, verifiable evidence of the event

Step 5: Correlation

Produce evidence that correlates the proven event to a proven identity

Condition: Correlating the event to an Identity should not break privacy laws

Where to implement the Forensic ‘tool’? juni 5, 2006

Posted by Wilbert in Proposal.
7 comments

A lot of targets can be taken into account for the 'tool'. We can think of all computer systems, network devices, mobile devices, etc. To make it manageable I believe we need to focus on a rather small but effective solution.

Taking into account that more and more network connections use session encryption, and this will not change in the future, I suggest dropping the network aspect completely (understanding that it might be important to understand where an attack originates from).

Could even consider dropping the desktop/laptop as well. To commit a crime that is important enough to prosecute, I would guess that it must in most cases involve servers. Although it might of course be that proof generated by the server is not enough for prosecution (as the input would probably come from a desktop/laptop or even mobile device). Also quite some users have admin access over their system, or could obtain it via the numerous vulnerabilities in it. I would guess that in most organisations it is not a trusted device/end point. So users with bad intend, would probably be able to remove or disrupt the tool (as I assume it would not be a secret, probably needs to be declared or be made aware some way).

Suggest to solely focus on the server farms. Any thoughts?

What are the concequences of an international environment for forensics? juni 5, 2006

Posted by Rolf in Legal aspects.
2 comments

How do i handle evidence different in Europe then in the United States? Will the tool be internationally applicable or just confined to the dutch jurusdiction ?

Forensics issues juni 5, 2006

Posted by Rolf in Legal aspects.
10 comments

When does evidence hold in court and when not? What do i have to do to protect the so called chain of custody or in other words when is it broken?

Privacy Issues in the computer forensics process juni 5, 2006

Posted by Rolf in Legal aspects.
8 comments

What are the issues in computer forensics with regard to privacy legislation?

Criteria for the forensics tool juni 5, 2006

Posted by Rolf in Forensic tool.
23 comments

I have opened this post not to have discussions about the criteria and requirements that we set for the forensics tool. It is the objective to have very short comments, just stating the requirement, criterium or nice to have for the tool.

How important is computer based forensic material juni 3, 2006

Posted by Wilbert in Generic Info.
9 comments

Does anybody have a clue how important computer based forensic material really is?

How many cases (or any other way to quantify that) are decided where the computer based forensic material made the tipping point? Or where the computer based forensic material made the outcome stronger? How many cases did not conclude because there was no computer based forensic material or it was not admissible to court?

Is there something to say about those cases where it was or could have been important?

What is legally allowed in computer forensics? juni 3, 2006

Posted by Wilbert in Legal aspects.
10 comments

Lets assume that it is techniclly possible to collect any data we wish. What data would be allowed to be collected? Take into account that at the time of data collection nothing happened yet, no incidents, thus also no suspects. It means we do not target specific individuals as such. Basically we collect 'raw' data and do not even have the intention to look at it. We just want to safe store it.

The Idea of automaticaly gathering digital evidence juni 2, 2006

Posted by Wilbert in Objective.
2 comments

Wouldn't it be nice if instead of going through a cumbersome process of electronic evidence gathering after an incident had happened, it would be possible to continuously collect electronic information that when an incident happened by a push on the button could be transformed in information that would be admissible in court.

In first instance this might be an obvious way to go. However the more I think about it the more complex and difficult it appears to be. For example what data to collect, from what source, when, where to store, how, how long, accessible by whom. And this all in a legally sound way to ensure the results are admissible in court (thus not just the production of the data, but the total chain as of collection).

The proposal requires to be scoped to manageable proportions taking above into account.