Forensicator Readiness
Sunday, January 23, 2011
I attended a lot of trainings as a communications technician in the Marines. There were formal trainings by outside parties, organized trainings by my unit, and formal education on my own to hone my troubleshooting skills. The goal of all of those trainings was to prepare me to perform my job regardless of the situation I might face. Even though I left the Marines, I carried over the same mentality to my career in information security especially for digital forensics. Using a mixture of formal education, paid training, and a lot of self training to ensure I'm capable of performing my job regardless of the situation I might encounter. However, outside of forensic challenges or forensic datasets I never had an organized way to approach self training until I wanted to learn about incident response investigations. This post will explain the approach I've been using but haven't documented until now.
Forensicator readiness is the method I've been using to help prepare myself to be able to investigate any situation regardless of the circumstances. If someone said "I need you to help figure out what caused this incident” I wanted to be able to hit the ground running. This is better than having to reply with "I'd like to help out but first I have to attend a training which by the way costs a few thousand dollars". I'm sharing my approach because I think it might be useful to others. Experienced analysts/examiners can use it to learn how to investigate new types of cases or students can use it to help prepare them for the common cases they might face. Forensicator readiness consists of the following six steps:
* Pick a Scenario
* Establish the Scenario’s Scope
* Collect Digital Information
* Examine Digital Information
* Scenario Simulation
* Identify Areas for Improvement
Ever since I read the Alexiou Principle (as described by Chris Pogue here and here) I've been using it in my cases. The principle has been helpful in planning out the investigation and keeping the investigation on track. I thought if it works for actual cases then it should work for simulations. Well, the principle does work in simulations so I use it in the forensicator readiness steps.
Pick a Scenario
There is always something to learn in digital forensics whether it’s a student studying the field in school or a forensicator who has been in the field for a number of years. It could be trying to understand how to investigate different types of cases, how to examine new data, or how to extract data from certain devices. The first step is to pick a scenario containing the item or situation of what is to be learned. The scenario could be based on the common types of cases processed in your organization or on a potential situation someone might need to investigate. A few scenario examples are: data leakage through USB device, sexual harassment involving company email, or a malware infected server.
Next a determination needs to be made to see if it’s possible to set up test systems to simulate the scenario. Research is completed in the collection, examination, and simulation steps and systems will be needed to run a few tests on. For example, I’d like to learn how to investigate a hacked database server. Unfortunately, I can’t use this scenario since I can’t simulate a SQL injection attack against a test database server. As a result, my focus is on the scenarios I can simulate in a test environment such as a malware infected system.
Having a scenario by itself isn’t enough because an end goal hasn’t been established; what is trying to be accomplished. This is where the first question of the Alexiou principle comes into play which is “what question are you trying to answer”. Identify a few potential questions to help guide the goal of the investigation. For example, the two potential questions of a suspected malware infected system I've been using are: is the system infected and how did the system become infected. The two questions identify what I’m trying to accomplish and helped guide my research in investigating a malware infected system.
Establish the Scenario’s Scope
The selected scenario has an end goal and can be replicated in a test environment. The next step is to determine the scope of the testing environment. Is the test environment going to be one computer or multiple computers? What operating systems are going to be on the computers? Are there going to be any networking devices such as routers, switches, or firewalls? Another consideration when determining the scope of the testing environment is what resources are available. Is there the necessary hardware and software to build the test environment? I'd like to be able to simulate a test environment of over 20 machines for my malware scenario but I can’t pull it off due to the lack of resources. I had to settle on just a few test systems and I’m still able to simulate my scenario. The above questions are only some of the things that have to be considered when scoping the test environment.
Setting up of the test environment during the next few steps may take some time. Despite the time required, one of the benefits of setting up your own environment is learning about the technology as you install and configure it. For example, if your scenario requires a web server running IIS (Windows Internet Information Service) then setting up IIS will provide a better understanding of what the default settings are and how it can be configured.
Collect Digital Information
At this point, the scenario has been identified, goals have been established, and the testing environment has been identified. The next step is to collect the digital information. The second question in the Alexiou principle states “what data do you need to answer that question”. The data sources in the test environment need to be evaluated to determine which ones can help you answer your question(s). The data sources could include hard drives, memory, logs, or captured network traffic.
Once the data sources of interest are identified then it’s time to research how these sources should be collected and what tools can be used. The amount of research required for this step will depend on the experience of the person conducting this exercise. In some instances, a person will already have a procedure in place for collecting the data sources and will have knowledge of the tools to use so additional research may not be necessary. On the other hand, the person may be facing a new data source(s) so there won’t be a procedure for the collection and the person won’t have knowledge about the tools to use. For example, in one of my scenarios I wanted to collect a hard drive and volatile data. I had experience with hard drives but collecting volatile data was new. I conducted research with the intention of modifying my collection procedures to include volatile data. The research involved reviewing RFC 3227, forensic books, blogs, and forums to determine what procedural steps were required to collect volatile data and what tools could be used to acquire volatile data from a system.
The new procedural steps and tools will need to be evaluated to determine if they work as intended. This evaluation will require a small test environment. Continuing with my volatile data example, I tested the procedural steps I researched and my list of tools to see which one best met my needs. I ran a few tests against Windows XP virtual machines by acquiring the volatile data from them. This not only allowed me to see if the steps were correct and what tool worked best but it also showed me what changes I had to make to the collection steps.
Examine Digital Information
At this point it's time to identify and extract the data required to answer the scenario questions. Continuing on with the Alexiou principle's second question “what data do you need to answer that question”; this question can further identify the data needed to answer the questions. The data sources have already been identified so the next part is to identify what information in those data sources can answer the questions. For example, in my scenario one of my data sources was volatile data so I had to figure out what information I needed from it. Some of the information was the running processes, established network connections, and loaded drivers. Once the exact information in the data sources is identified, the third Alexiou principle comes into play which is "how do you extract the data". Using the volatile data example, this would be determining how to extract the established network connections, loaded drivers, and running processes from the data.
As might be expected, research has to be conducted to decide what information in the data sources is needed to answer the questions and how that information can be extracted. The same types of references used in the collection step can be used such as blogs, forums, and forensic books.
Similar to the collection step, the new examination steps and tools need to be evaluated to see if they work as intended. The evaluation can use available forensic datasets or a small test environment. Forensic datasets can be used for testing different types of data sources and this is a faster option then setting up a test environment. The datasets available for testing the examination steps and tools for the volatile data example include: NIST CFReDS Project, Forensic Educational Datasets, Honeynet Challenges, or the memory images on the Forensic Incident Response blog. If there isn't an available dataset then a small test environment has to be set up. The fourth question of the Alexiou principle is "what does the data tell you". This question should be kept in mind during the evaluation because the purpose of the examination steps and tools are to extract information needed to answer the scenario questions. If the information doesn't help answer the question then additional research may have to be performed so the examination steps and tools can be adjusted.
Scenario Simulation
This step is where all of the hard work of researching and evaluating pays off. The scenario simulation is when the test environment is created and the scenario is simulated in that environment. The first scenario I've been working with is a computer infected with malware, and one of the ways I simulated this scenario was by visiting known malicious websites with a computer running vulnerable software. After the scenario is simulated then the next step is to treat the test environment like a real investigation. The data sources of interest get collected, and information is extracted from those sources to answer the scenario's questions.
Identify Areas for Improvement
Now that the dust has settled from investigating the scenario in a test environment; it's time to reflect back on what was done. The purpose of this step is to see if there is anything to improve upon. A few things for consideration are: did the tools perform as expected, were the procedures correct, what didn't work, and what can be done better. Something else to keep in mind during this reflection is to decide if any additional research has to be performed on any artifacts in order to get a better understanding about them. During my simulation, I didn't have a good understanding about the attack vector artifacts such as those left by exploits. I spent some time researching a few of these artifacts so I'd have a better understanding the next time I come across a similar artifact.
Summary
There isn’t a set time table to complete the forensicator readiness steps. It could take days, weeks, or months to complete. The time all depends on the scenario and how much of an understanding someone wants. People prepare for things differently and forensicator readiness is no different. If the steps can accomplish the end goal of preparing someone to investigate an incident regardless of the circumstances - like it did for me- then the process has served its purpose.
So when someone said to me "I need your help to figure out what caused this infection"; I was ready to rock and roll. I’ve been successful numerous times locating malware on systems and identifying the attack vector that put the malware on the systems. A few of the vectors were: a malicious email attachment, a drive-by download using a malicious PDF, and third party content pointing to a website hosting Windows help center and Java exploits. I don't think my success is a string of luck. It's due to my preparation for a situation I thought I would face sooner or later. It just so happened to be sooner than I was expecting.
Forensicator readiness is the method I've been using to help prepare myself to be able to investigate any situation regardless of the circumstances. If someone said "I need you to help figure out what caused this incident” I wanted to be able to hit the ground running. This is better than having to reply with "I'd like to help out but first I have to attend a training which by the way costs a few thousand dollars". I'm sharing my approach because I think it might be useful to others. Experienced analysts/examiners can use it to learn how to investigate new types of cases or students can use it to help prepare them for the common cases they might face. Forensicator readiness consists of the following six steps:
* Pick a Scenario
* Establish the Scenario’s Scope
* Collect Digital Information
* Examine Digital Information
* Scenario Simulation
* Identify Areas for Improvement
Ever since I read the Alexiou Principle (as described by Chris Pogue here and here) I've been using it in my cases. The principle has been helpful in planning out the investigation and keeping the investigation on track. I thought if it works for actual cases then it should work for simulations. Well, the principle does work in simulations so I use it in the forensicator readiness steps.
Pick a Scenario
There is always something to learn in digital forensics whether it’s a student studying the field in school or a forensicator who has been in the field for a number of years. It could be trying to understand how to investigate different types of cases, how to examine new data, or how to extract data from certain devices. The first step is to pick a scenario containing the item or situation of what is to be learned. The scenario could be based on the common types of cases processed in your organization or on a potential situation someone might need to investigate. A few scenario examples are: data leakage through USB device, sexual harassment involving company email, or a malware infected server.
Next a determination needs to be made to see if it’s possible to set up test systems to simulate the scenario. Research is completed in the collection, examination, and simulation steps and systems will be needed to run a few tests on. For example, I’d like to learn how to investigate a hacked database server. Unfortunately, I can’t use this scenario since I can’t simulate a SQL injection attack against a test database server. As a result, my focus is on the scenarios I can simulate in a test environment such as a malware infected system.
Having a scenario by itself isn’t enough because an end goal hasn’t been established; what is trying to be accomplished. This is where the first question of the Alexiou principle comes into play which is “what question are you trying to answer”. Identify a few potential questions to help guide the goal of the investigation. For example, the two potential questions of a suspected malware infected system I've been using are: is the system infected and how did the system become infected. The two questions identify what I’m trying to accomplish and helped guide my research in investigating a malware infected system.
Establish the Scenario’s Scope
The selected scenario has an end goal and can be replicated in a test environment. The next step is to determine the scope of the testing environment. Is the test environment going to be one computer or multiple computers? What operating systems are going to be on the computers? Are there going to be any networking devices such as routers, switches, or firewalls? Another consideration when determining the scope of the testing environment is what resources are available. Is there the necessary hardware and software to build the test environment? I'd like to be able to simulate a test environment of over 20 machines for my malware scenario but I can’t pull it off due to the lack of resources. I had to settle on just a few test systems and I’m still able to simulate my scenario. The above questions are only some of the things that have to be considered when scoping the test environment.
Setting up of the test environment during the next few steps may take some time. Despite the time required, one of the benefits of setting up your own environment is learning about the technology as you install and configure it. For example, if your scenario requires a web server running IIS (Windows Internet Information Service) then setting up IIS will provide a better understanding of what the default settings are and how it can be configured.
Collect Digital Information
At this point, the scenario has been identified, goals have been established, and the testing environment has been identified. The next step is to collect the digital information. The second question in the Alexiou principle states “what data do you need to answer that question”. The data sources in the test environment need to be evaluated to determine which ones can help you answer your question(s). The data sources could include hard drives, memory, logs, or captured network traffic.
Once the data sources of interest are identified then it’s time to research how these sources should be collected and what tools can be used. The amount of research required for this step will depend on the experience of the person conducting this exercise. In some instances, a person will already have a procedure in place for collecting the data sources and will have knowledge of the tools to use so additional research may not be necessary. On the other hand, the person may be facing a new data source(s) so there won’t be a procedure for the collection and the person won’t have knowledge about the tools to use. For example, in one of my scenarios I wanted to collect a hard drive and volatile data. I had experience with hard drives but collecting volatile data was new. I conducted research with the intention of modifying my collection procedures to include volatile data. The research involved reviewing RFC 3227, forensic books, blogs, and forums to determine what procedural steps were required to collect volatile data and what tools could be used to acquire volatile data from a system.
The new procedural steps and tools will need to be evaluated to determine if they work as intended. This evaluation will require a small test environment. Continuing with my volatile data example, I tested the procedural steps I researched and my list of tools to see which one best met my needs. I ran a few tests against Windows XP virtual machines by acquiring the volatile data from them. This not only allowed me to see if the steps were correct and what tool worked best but it also showed me what changes I had to make to the collection steps.
Examine Digital Information
At this point it's time to identify and extract the data required to answer the scenario questions. Continuing on with the Alexiou principle's second question “what data do you need to answer that question”; this question can further identify the data needed to answer the questions. The data sources have already been identified so the next part is to identify what information in those data sources can answer the questions. For example, in my scenario one of my data sources was volatile data so I had to figure out what information I needed from it. Some of the information was the running processes, established network connections, and loaded drivers. Once the exact information in the data sources is identified, the third Alexiou principle comes into play which is "how do you extract the data". Using the volatile data example, this would be determining how to extract the established network connections, loaded drivers, and running processes from the data.
As might be expected, research has to be conducted to decide what information in the data sources is needed to answer the questions and how that information can be extracted. The same types of references used in the collection step can be used such as blogs, forums, and forensic books.
Similar to the collection step, the new examination steps and tools need to be evaluated to see if they work as intended. The evaluation can use available forensic datasets or a small test environment. Forensic datasets can be used for testing different types of data sources and this is a faster option then setting up a test environment. The datasets available for testing the examination steps and tools for the volatile data example include: NIST CFReDS Project, Forensic Educational Datasets, Honeynet Challenges, or the memory images on the Forensic Incident Response blog. If there isn't an available dataset then a small test environment has to be set up. The fourth question of the Alexiou principle is "what does the data tell you". This question should be kept in mind during the evaluation because the purpose of the examination steps and tools are to extract information needed to answer the scenario questions. If the information doesn't help answer the question then additional research may have to be performed so the examination steps and tools can be adjusted.
Scenario Simulation
This step is where all of the hard work of researching and evaluating pays off. The scenario simulation is when the test environment is created and the scenario is simulated in that environment. The first scenario I've been working with is a computer infected with malware, and one of the ways I simulated this scenario was by visiting known malicious websites with a computer running vulnerable software. After the scenario is simulated then the next step is to treat the test environment like a real investigation. The data sources of interest get collected, and information is extracted from those sources to answer the scenario's questions.
Identify Areas for Improvement
Now that the dust has settled from investigating the scenario in a test environment; it's time to reflect back on what was done. The purpose of this step is to see if there is anything to improve upon. A few things for consideration are: did the tools perform as expected, were the procedures correct, what didn't work, and what can be done better. Something else to keep in mind during this reflection is to decide if any additional research has to be performed on any artifacts in order to get a better understanding about them. During my simulation, I didn't have a good understanding about the attack vector artifacts such as those left by exploits. I spent some time researching a few of these artifacts so I'd have a better understanding the next time I come across a similar artifact.
Summary
There isn’t a set time table to complete the forensicator readiness steps. It could take days, weeks, or months to complete. The time all depends on the scenario and how much of an understanding someone wants. People prepare for things differently and forensicator readiness is no different. If the steps can accomplish the end goal of preparing someone to investigate an incident regardless of the circumstances - like it did for me- then the process has served its purpose.
So when someone said to me "I need your help to figure out what caused this infection"; I was ready to rock and roll. I’ve been successful numerous times locating malware on systems and identifying the attack vector that put the malware on the systems. A few of the vectors were: a malicious email attachment, a drive-by download using a malicious PDF, and third party content pointing to a website hosting Windows help center and Java exploits. I don't think my success is a string of luck. It's due to my preparation for a situation I thought I would face sooner or later. It just so happened to be sooner than I was expecting.
Labels:
readiness
Posts
