When you look at papers outlining how to build an enterprise-scale incident response process it shows the text book picture about what it should look like. It's not until you start building out the incident response (IR) process and/or responding to security events/incidents when you can truly see what the critical pieces are in the process. In most of the "text book style" IR documentation I've read (for my Masters, enjoyment, and research) they tend to gloss over the triage. Triage is only mentioned as necessary to confirm an indicator and determine if a security event is an incident. Whether if you are building out an IR process or doing internal IR work, triage is not an activity that should be glossed over. In my opinion, it is one of the most important steps. Not only does it need confirm an indicator and determine if a security event is an incident but it also needs to provide guidance to staff for security events that are not incidents. In addition, a good percentage of one's work will be triaging indicators/events to determine what needs to be done - if anything. Seeing how important triage is I dedicated a lot of time to improving and refining techniques to triage security indicators and events. In this post I'm explaining a single technique, which is how the Recentfilecache.bcf file can be used to quickly identify an infected system
read more........http://journeyintoir.blogspot.com/2014/04/triaging-with-recentfilecachebcf-file.html
read more........http://journeyintoir.blogspot.com/2014/04/triaging-with-recentfilecachebcf-file.html