AccessData has announced that version 3 of their FTK computer forensic software will be released in the near future. AccessData claim that several key improvements will be delivered in the new release, including a parallel processing capability and live network-based acquisition of computers. But two questions arise. Will FTK v3 be plagued by bugs and crashes in the same way FTK v2 was? And what practical improvement in processing speed will be achieved using the parallel processing capability?
Elementary uses FTK v2. We have been licensed for FTK v2 for two years, but the first time we used it the software crashed one of our servers (the dreaded Windows "blue screen of death"). Since FTK v2.2 was released the product has been much more stable, and is now frequently used here in certain types of pornography investigations. (FTK is much more effective than EnCase at recovering pictures). We also find its text indexing facility very useful, albeit rather slow.
The question is - has AccessData learnt from the painful experience of FTK v2? That product was clearly released before it was stable. You would think that vendors of computer forensic software would recognise the need for their products to be reliable and stable, since they form the basis of expert evidence given in Court. How then can a vendor justify releasing an unstable and immature product?
One wonders is that happened as a result of financial or competitive drivers at AccessData? A similar thing happened at Guidance Software when EnCase version 4 was released before it was stable. The first dozen or so versions of that release were extremely buggy. It is interesting to note that the current CEO and COO of Access Data (Tim Leehealey and Brian Karney, respectively) worked for Guidance Software during the EnCase Version 4 debacle.
So it will be interesting to see what happens with FTK v3. If the software delivers on its promises, and based upon experience with FTK v2 that could be a big "if" - at least in the early days, it will be a very worthwhile package.
We are receiving conflicting information from our sources at AccessData. One manager tells us that he would be surprised if they will have the parallel processing capability working reliably before the end of 2009. Another source told us yesterday that FTK v3 will be released at the end of the month. Perhaps both are correct?
How much difference will the parallel processing (AccessData call it the "distributed worker") capability make? Its hard to say. FTK v2 is rather slow, on one of our fast analysis systems (Intel Core i7, eight 3.06GHz cores, 12Gb DDR3 RAM, 2Tb of fast RAID10 local disk) we can process about 120Gb in a 24 hour period. FTK v2 is unique among the commercial forensic tools we use in that it uses all processing cores on the computer. (EnCase uses just one). However we are left with the impression that there would be some room for a performance improvement through a more efficient implementation.
Parallel processing will improve FTK's processing speed, but by how much depends on how its computing workload compares with its I/O workload (i.e. reading evidence). There is a limit to how much additional processing capacity will improve performance. Eventually this will be limited by I/O bottlenecks, and there is no sign of AccessData tacking that problem. Ironically, the more inefficient their software is the more there will be to gain from parallel processing.
The idea of using multiple computers to share the workload of computer forensic processing is not new. Golden Richard III et al at the University of New Orleans published a paper in 2004 entitled "Breaking the Performance Wall: The Case for Distributed Digital Forensics". They proposed using clusters of commodity computers (Beowulf clusters) to speed up computer forensic analysis - although their prototype system was only capable of holding evidence data in RAM. My recent paper "A Second Generation Computer Forensic Analysis System" extends this idea in a variety of ways, including through the use of parallel (or clustered) file systems to eliminate the I/O bottleneck, thus making it possible to realise the full benefits of parallel processing. (Some of the methods described in my paper are the subject of NZ Patent Application 579120).
