Difference between pages "Volatility Framework" and "Incident Response"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
 
(Kill Chain)
 
Line 1: Line 1:
{{Infobox_Software |
+
{{Expand}}
  name = Volatility |
+
  maintainer = [[AAron Walters]] |
+
  os = {{Cross-platform}} |
+
  genre = [[Memory analysis]] |
+
  license = {{GPL}} |
+
  website = [https://www.volatilesystems.com/default/volatility https://www.volatilesystems.com/] |
+
}}
+
  
The '''Volatility Framework''' is a completely open collection of tools, implemented in Python under the GNU General Public License, for the extraction of digital artifacts from volatile memory (RAM) samples. The extraction techniques are performed completely independent of the system being investigated but offer unprecedented visibility into the runtime state of the system. The framework is intended to introduce people to the techniques and complexities associated with extracting digital artifacts from volatile memory samples and provide a platform for further work into this exciting area of research.  
+
Incident Response is a set of procedures for an investigator to examine a computer security incident. This process involves figuring out what was happened and preserving information related to those events. Because of the fluid nature of computer investigations, incident response is more of an art than a science.  
  
The project was originally developed by and is now headed up by [[AAron Walters]] of [[Volatile Systems]].
+
== Tools ==
  
== Plugins ==
+
Incident response tools can be grouped into three categories. The first category is '''Individual Tools'''. These are programs designed to probe parts of the operating system and gather useful and/or volatile data. The tools are self-contained, useful, discrete, and do not create a large footprint on the victim system.
See: [[List of Volatility Plugins]]
+
  
== Memory acquisition drivers ==
+
Standalone tools have been combined to create '''Script Based Tools'''. These tools combine a number of standalone tools that are run via a script or batch file. They require minimal interaction from the user and gather a fixed set of data. These tools are good in that they automate the incident response process and provide the examiner with a standard process to defend in court. They also do not require the first responder to necessarily be an expert with the individual tools. Their weakness, however, is that they can be inflexible. Once the order of the tools is set, it can be difficult to change. Some script based tools allow the user to pick and choose which standalone tools will be used in a given examination.
  
In 2012 [[Michael Cohen]] contributed both a Linux and a Windows Open Source memory (acquisition) driver to the volatility project.
+
The final category of tools are '''Agent Based Tools'''. These tools require the examiner to install a program on the victim which can then report back to a central server. The upshot is that one examiner can install the program on multiple computers, gather data from all of them, and then view the results in the aggregate. Finding the victim or victims can be easier if they stand out from the crowd.
  
These drivers are currently available in the volatility scudette branch and soon to be released as a separate download. To obtain this branch run:
+
== See Also ==
<pre>
+
* Obsolete: [[List of Script Based Incident Response Tools]]
svn checkout http://volatility.googlecode.com/svn/branches/scudette/ volatility
+
</pre>
+
  
In the scudette branch the drivers can be found under:
+
== External Links ==
<pre>
+
* [http://dfrws.org/2002/papers/Papers/Jesse_Kornblum.pdf Preservation of Fragile Digital Evidence by First Responders], by [[Jesse Kornblum]], DFRWS 2002
volatility/tools/linux and volatility/tools/
+
* [http://blog.handlerdiaries.com/?p=325 Keeping Focus During an Incident], by jackcr, January 17, 2014
</pre>
+
  
=== Linux ===
+
=== Kill Chain ===
 +
* [http://www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-Defense.pdf Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains], by Eric M. Hutchins, Michael J. Clopperty, Rohan M. Amin, March 2011
 +
* [http://www.emc.com/collateral/hardware/solution-overview/h11154-stalking-the-kill-chain-so.pdf Stalking the kill chain], by RSA
  
To build the kernel module for the current kernel version, make sure you have a working build environment and the kernel headers installed. Change into this directory and run make:
+
=== Incident Lifecycle ===
<pre>
+
* [http://www.itsmsolutions.com/newsletters/DITYvol5iss7.htm Expanding the Expanded Incident Lifecycle], by Janet Kuhn, February 18, 2009
cd volatility/tools/linux/
+
* [https://www.enisa.europa.eu/activities/cert/support/incident-management/browsable/workflows/incident-lifecycle Incident lifecycle], by [[ENISA]]
make
+
</pre>
+
  
The acquisition driver is named pmem.ko.
+
== Tools ==
 +
=== Individual Tools ===
 +
* [http://technet.microsoft.com/en-us/sysinternals/0e18b180-9b7a-4c49-8120-c47c5a693683.aspx Sysinternals Suite]
  
To load the driver:
+
=== Script Based Tools ===
<pre>
+
* [[First Responder's Evidence Disk|First Responder's Evidence Disk (FRED)]]
sudo insmod pmem.ko
+
* [[COFEE|Microsoft COFEE]]
</pre>
+
* [[Windows Forensic Toolchest|Windows Forensic Toolchest (WFT)]]
 +
* [[Regimented Potential Incident Examination Report|RAPIER]]
  
To check if the driver is running:
+
=== Agent Based Tools ===
<pre>
+
* [[GRR]]
sudo lsmod
+
* [[First Response|Mandiant First Response]]
</pre>
+
  
The driver create a device file named:
+
== Books ==
<pre>
+
There are several books available that discuss incident response. For [[Windows]], ''[http://www.windows-ir.com/ Windows Forensics and Incident Recovery]'' by [[Harlan Carvey]] is an excellent introduction to possible scenarios and how to respond to them.
/dev/pmem
+
</pre>
+
  
To unload the driver:
+
[[Category:Incident Response]]
<pre>
+
sudo rmmod pmem
+
</pre>
+
 
+
To read acquire the memory just read from the device file. e.g.
+
<pre>
+
dd if=/dev/pmem of=image.raw
+
</pre>
+
 
+
For more information see:
+
<pre>
+
volatility/tools/linux/README
+
</pre>
+
 
+
=== Windows ===
+
Since recent versions of 64 bit Windows require a signed driver the volatility scudette branch comes with both pre-built (binary) and source versions of the driver. The prebuilt binary is signed.
+
 
+
Both the i386 and amd64 binary version of the driver can be found on the downloads part of the [http://code.google.com/p/volatility/ Volatility code repository] as winpmem or in the scudette branch under:
+
<pre>
+
volatility/tools/winpmem/binaries/
+
</pre>
+
 
+
E.g.
+
<pre>
+
volatility/tools/winpmem/binaries/amd64/winpmem.sys
+
</pre>
+
 
+
A standalone tool for imaging memory that uses an embedded copy of the pmem driver can be found as winpmem.exe in:
+
<pre>
+
volatility/tools/winpmem/executables/Release/
+
</pre>
+
 
+
To load the driver:
+
<pre>
+
winpmem.exe -l
+
</pre>
+
 
+
The device filename is (This can not be changed without recompiling):
+
<pre>
+
\\.\pmem
+
</pre>
+
 
+
To read and acquire the physical memory and write it to image.raw:
+
<pre>
+
winpmem.exe image.raw
+
</pre>
+
 
+
To unload the driver:
+
<pre>
+
winpmem.exe -u
+
</pre>
+
 
+
For more information see:
+
<pre>
+
volatility/tools/windows/README
+
</pre>
+
 
+
== See Also ==
+
* [[List of Volatility Plugins]]
+
 
+
== External Links ==
+
* [https://www.volatilesystems.com/default/volatility Official web site]
+
* [http://code.google.com/p/volatility/ Code repository]
+
* [http://code.google.com/p/volatility/w/list Volatility Documentation]
+

Revision as of 06:19, 29 January 2014

Information icon.png

Please help to improve this article by expanding it.
Further information might be found on the discussion page.

Incident Response is a set of procedures for an investigator to examine a computer security incident. This process involves figuring out what was happened and preserving information related to those events. Because of the fluid nature of computer investigations, incident response is more of an art than a science.

Tools

Incident response tools can be grouped into three categories. The first category is Individual Tools. These are programs designed to probe parts of the operating system and gather useful and/or volatile data. The tools are self-contained, useful, discrete, and do not create a large footprint on the victim system.

Standalone tools have been combined to create Script Based Tools. These tools combine a number of standalone tools that are run via a script or batch file. They require minimal interaction from the user and gather a fixed set of data. These tools are good in that they automate the incident response process and provide the examiner with a standard process to defend in court. They also do not require the first responder to necessarily be an expert with the individual tools. Their weakness, however, is that they can be inflexible. Once the order of the tools is set, it can be difficult to change. Some script based tools allow the user to pick and choose which standalone tools will be used in a given examination.

The final category of tools are Agent Based Tools. These tools require the examiner to install a program on the victim which can then report back to a central server. The upshot is that one examiner can install the program on multiple computers, gather data from all of them, and then view the results in the aggregate. Finding the victim or victims can be easier if they stand out from the crowd.

See Also

External Links

Kill Chain

Incident Lifecycle

Tools

Individual Tools

Script Based Tools

Agent Based Tools

Books

There are several books available that discuss incident response. For Windows, Windows Forensics and Incident Recovery by Harlan Carvey is an excellent introduction to possible scenarios and how to respond to them.