Back from a one-day trip to Amsterdam where I attended the “Secure Amsterdam Workshop 2009” meeting organized by ISC2. This year topic was forensics IT investigations.
The first speaker was Matthijs van der Wel from Verizon Business who reviewed the 2009 Data Breach Investigations Report. It was interesting to have “real” examples given by Maathijs to correlate the (huge) amount of numbers presented in the report. What to learn? The main problem with forensics is to not disturb the business. In case of incident, a company may decide to continue the day to day operations instead of taking the time to investigate deeper (example: a server in an international organization which cannot be stopped). There is also an important gap between compliance and the real world. All major companies assume to be compliant but, practically, security measures are badly or even not deployed. An interesting statistic: like on classical market places, the prices of “goods” decreases when the are plenty available in stock. It’s exactly the same for stolen data. Example: the market value of a stolen credit card number decreased from ~$15 to ~$0.5 (principle of supply and demand).
But the value could be increased if the credit card number is provided with an expiration date and, even more, with the owner’s name! Today, bad guys try to build database of market places not far from the owner’s address of stolen cards. Why? To use them not too far to avoid behavioral monitoring put in place by banks (Using a CC from Belgium to buy a 40″ flat screen in Italy will look suspicious!)
The second presentation made by Maathijs was about IT forensics. Matthijs insisted on the value of logs (events). Logs must be collected, analyzed and stored for potential investigations in the future. The data collection is the critical step in the process. If corrupted, the data won’t be exploitable. On the other side, their analyze can be repeated as long as required. Note that the log analyze process may become a nightmare in certain cases where hackers change the internal date/time of servers to try to hide their activities in the flow of entries.
To efficiency collect data and protect them do not rely on a single person. Example: ask a sysadmin to collect logs from his own servers is irrelevant. Temptation can be big to alter them to hide some mistakes. Apply here the principle of separation of duties. Incident response was also covered: Incident response must be performed like a real project:
- Define clear objectives
- Define the scope
- Containment, collection of evidences
- Analyze
- Report
During the collection of evidences, be sure to respect the chain of custody and write down all steps and remarks into a logbook. Incident responses can take months to be completed. The logbook will help you to not forget critical information.
The second speaker, Thijs Bosschert – a colleague of Matthijs – make a more technical presentation about the forensics tools available (btw, his blog is very interesting!). There are plenty of tools available to perform investigations on digital data but he focused on tools/hardware to take images of storage devices (today, data are stored everywhere: hard disks, memory cards, USB devices, mobile phones, game console, camera, …). Some hardware solutions were briefly presented (like logicube.com, voomtech.com) and software solutions (my favourite was ddfldd which, like the standard “dd” command, can take images of devices with a MD5 hashing on the fly!). Thijs made a demo with a small USB stick and was able to recover a lot of information.
Just after the lunch, Pieter Claassens from Sourcefire presented some slides about “Modern Risk Quantification Practices”. Interesting but nothing new for CISSP’s (I’m pretty sure 90% of the audience got this certification!).
Finally, Matthijs came back to present the last (but the most important) step in incident response: the report! It’s absolutely mandatory to provide an excellent report. The goal is to explain to non-techies what happened, what analyzes were performed and how to prevent the issue. A good report must be understandable even by your Mom! Always write the report based on a time line (based on the incident or based on analyze actions) and always stay neutral.
Excellent meeting, I learned a lot…