I was BSing with Mr. Rosen over some pizza a couple months back. I described the scheme I'm about to lay out and how it was borne from my (ir)rational paranoia about The Cloud. I told him that I had set up my system this way "because I'm paranoid that someone's going to hack in and mess up my shit." to which he replied something like, "I'd be less afraid of the that, and more afraid that I'm going to do something stupid." Touché. Perhaps the biggest threat to our data isn't the anonymous blob outside our network. Maybe our data is more likely to be corrupted by the ijit sitting at the keyboard.
Whatever the motivation, I believe it's good practice to limit my evidence's exposure to the outside world. However, to make our lives easy, some data flow is required. In true blogger fashion, let me confuse you with a diagram before properly explaining it:
 |
| Network Traffic Flow |
In this diagram, you see that the Acquisition & RAID computer has two shared folders.
The Evidence (RW) is an rw share used for dumping case data, extracted files, logs, and other data created on the Analysis machine. It is a temporary directory - more on that later.
The Disc Images (RO) folder is a read-only share. It contains the disc images created during acquisition that are stored on the RAID.
Over on the Analysis machine, I named two hard drives RW and RO, to follow the nomenclature used on the Acquisition computer. Remember how I said that the Analysis computer itself doesn't do any actual analysis? Here's why. Each drive is fully-available to the Host OS; however, each drive is shared with the VM Clients as either read-only or read-write. Hopefully you're seeing a pattern here.
 | ||
| The LAPTOP-looking icons are Virtual Machines hosted on the Analysis PC |
The pattern is that each Virtual Machine has the exact same setup as the Analysis machine. They all believe they are connecting to a Server with read-only or read-write shares. Of course, in the case of the Virtual Machines, the network is pretend, meaning the usual bottlenecks of LAN traffic don't exist.
Simplified Workflow
This may seem overly complicated, but it's mind-numbingly simple to put together. For me, it makes my casework organization easy. Once it's all set up, you'll have the equivalent of multiple copies of evidence on multiple machines. Of course, it's all imaginary - only one working copy actually exists - but I don't think these Atreyus are going to look into any magic mirrors any time soon, so our secret is probably safe.
Here's what it looks like from SIFT (Linux). Notice that Linux thinks I have write privileges, but when I tried to write a file to the RO directory, the request was denied:
 |
| SIFT Workstation |
 |
| The view from XP |
With this all in place, my usual workflow is as follows:
- Acquire the disc images with the acquisition machine, saving them to the RO directory on the RAID.
- Access the disc image directly over the network from a VM, or copy it to the analysis machine's RO directory if I'm going to do a bunch of work with the image (keyword searches, IEF, etc.).
- Scan, search, attack images from multiple VMs at the same time, directing all output to the RW drive.
- Scan, search, attack output on RW drive from multiple VMs.
- When I'm ready to archive the case, I move everything to the RW drive on the Acquisition machine. Then it's Sneakernet time. I access the Acquisition machine directly, and move the files either to the RO folder, or to another location inaccessible by the network. Because, in reality, I'm just moving files from one directory to another on the same drive, this takes very little time.
