What do you do, when your computer forensic tool of choice, Autopsy, EnCase, FTK, etc., helps you to find, say, 40 million data records containing credit card numbers, date of birth, SSN, checking account numbers or similar non-public personal information (NPI)? What if those data are in flat files created by an employee who pulled them from some data source belonging to your organization? What next?
Simulation of “discovered” flat files patterned after an actual case
Query from table 1
Query from second table
(Data is entirely fictitious. Any resemblance to real data, living or dead, is purely coincidental)
The legal team wants specifics. How many unique credit card numbers linked to a name and address were on the laptop? What are all the fields of data you have found? Initially, these questions may be asked to validate action against the employee. But ultimately, the company must report these losses to consumers to whom the information belongs. [1]
Lawyers Want More
They always want more! They want to know if you can provide a list of names and addresses for mailing the information and exactly what data might have been compromised for each individual. In one case, a company felt obligated to provide such granularity for every person compromised as these individuals all worked for that company. An 800 number and help desk may even be set up for employees to call to get more information.
Unfortunately, computer forensic tools were not designed to link flat files and determine what data belongs to whom. This is where I have found the answer in a database application. I use Microsoft Access, though any robust database will do the trick, so long as you are familiar with it and can import and format flat files with it.
Very Tedious!
All of the data will likely be scattered throughout numerous files and file fragments. One file may contain SSN with a Credit Card Number and date of birth. A second file may have a name and a credit card number. These two files must be imported and linked together based on the appropriate key, then you can report how many names can be linked with SSN, credit card number and/or date of birth.
For Example…
In the above data that the “perpetrator” delimited with double quote marks, the key in the first table would be the credit card. The second table also provides a credit card as a key. So, where we can link the credit card numbers together, we may have more NPI data tied to actual persons’ names. In this case, name plus SSN, CC and DOB. Any unique identifier can be a key to tie data together from multiple files or tables.
To further complicate things, file fragments can be located in unallocated space on the hard drive. The examiner must determine the format of each fragment to make sure it matches the format of the other fragments like it. Are there any additional fields? How are the fields delimited; comma, space, tab, quotes, special characters or some combination thereof? If you have concatenated data fragments, are you sure that the fields have not gone out of phase due to incorrect ordering of the file fragments on the disk? Sometimes the pieces of files have pieces! You have to do the best you can to clean them up and fit them together logically without distorting or jumbling the original data of record.
Next post…
I will go over some of the techniques and caveats pertaining to importing flat files into Access.
1 Interactive map and article indicating states with data breach disclosure laws: http://www.csoonline.com/article/221322/CSO_Disclosure_Series_Data_Breach_Notification_Laws_State_By_State/1
2 Article about a national data breach disclosure law: http://www.internetnews.com/bus-news/article.php/3502781
J. Michael Butler, GCFA Gold #00056, is a Information Security Consultant employed by a fortune 500 application service provider who processes over half of the approximately $5 trillion of residential mortgage debt in the US. He is a certified computer forensics specialist. In addition, he authored the enterprise wide information security policies for his corporation.
