Live CD for Remote Incident Handling
This paper was written by Bert Hayes. Bert Hayes is a security professional at the University of Texas. When Bert originally wrote this paper, he submitted it to me for the SANS Gold process, and I helped push the paper in the right direction, however, while it was an excellent paper and well written, it didn't really meet the criteria we were looking for.
However, I thought "Wow, what a great idea, what a great paper. I am sure a lot of organizations will benefit from this."
Of course Bert nor the Internet Storm Center can be held liable for any damage you to do a computer while using this, (just to get that disclaimer out of the way), and it's recommended that if you are going to use the contents of the computer you are doing the investigation on for a prosecution, don't use this. (Changing the state of the data on the drive during a forensic investigation is generally frowned upon.)
But, as I said, this is a great paper and you should definitely download it and give it a read.
Enjoy
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
Comments
When I'm investigating an event, it usually involves touching the system that generated the event to get more information, so that I can determine that an incident actually took place. Acquiring memory is almost always one of the things I will do, and that involves touching the machine (at least with the technology that I'm using.)
I'm curious how many incidents handlers are actually maintaining a 100% hands-off approach, and if so, how they achieve that (especially in lean IT/security departments?)
In the case of an actual incident, I do know what actions I have taken on the machine, and record those actions as well.
Another issue, is that it's very rare, at least in my experience, that incidents being investigated actually go to court. That's probably partly due to the fact I'm only doing incident handling for my employer and not a "hired-gun" that would get called in in the case of some huge fraud.
Shawn
Jun 25th 2010
1 decade ago
On the other hand, there are plenty of reasons why these systems aren't adequate, ranging from the trivial (hardware breakpoints on Intel processors are in registers that can be read and modified by the CPU) to the intentional (you can turn off the power supply to the debugging infrastructure from code in secure boot ROMs on some ARM devices, preventing the debuggers from working) to the esoteric (if your malware is running inside the embedded processor of your system's I/O controller, you might not see it if you just look at main RAM).
One embedded platform I've used boasts a parallel port designed expressly for letting a host computer have fast read/write access to its memory. Intended applications range from shared memory data processing to firmware upload, but you can also use it to scrape the target's RAM without going through the target's CPU.
It would seem to me that there's enough of a market for things like e-commerce web servers and bank transaction processing machines--the kinds of that hardware that people want to launch prosecutions over--that the hardware vendors might be well positioned to provide purpose-built hardware support for forensic examination (suitably secured somehow). Such a technology would be a double-edged sword, since anyone with access to the forensic download port could grab all the data in the machine, and if the download port could be turned off from software then the malware might start doing that.
Zygo
Jun 28th 2010
1 decade ago