Preparation, in my opinion, is the most important phase of incident response. When possible you should have well test procedures for all major tasks you preform, especially when it comes to how you collect your data. In many situations, you will get only one chance to gather the information and you need make it count. These procedures should be review on a quarterly bases, so setup a reoccurring calendar appointment to get that done today.
Having a IR CDROM with all your collection tools is critical to having a great start to a incident. I’ve previously talked about a couple freely available ones, but now I’m we are going to cover what the basic requirements that need to be met when creating your own. Why create your own CDROM? The simple answer is control. Creating your own script allows you to do what you want to do, when and how you want to do it. Additionally, you want to make sure the trusted binaries are really trusted. Installing and verifying them yourself is the best way to make sure you can trust them.
One of the hardest questions to answer when first trying to get started is, what do you need to collect from a compromised host? It depends on your policy and questions you want to answers from the investigation, but here is a list of some of the most common things to collect and analyze from a live host:
-Processes lists ( process id, user running, parent process, path of executable)
-Network stats (listening process, established connections, PID)
-List of open files
-Modify,Access,Creation times (mac)
-System logs (logs for services running, authentication and authorization)
-Schedule’s tasks and start-up items
You could run these tools manually, but this leads to inconsistent data collection. The most effective way to collect this data is using an automated script. Scripts are a great way to help reduce documentation for collecting the evidence and make data collection consistent.The data should be collected using trusted binaries, which are ran from an external source. It’s best to rename the trusted file to distinguish the difference between versions that may already be running on the system ( e.g. ls to ir_ls). The script and tools should be ran from a write protected USB or CDROM where the result are dumped to another system (smb or cryptcat) or an external drive.
Lessons learned is generally the step most people do not to complete. Many time you may have overlapping incidents with little time to document things that went right and wrong. This step is important to make sure that you improve on your experience, and prevent the same mistake from happening more than once. If you do not have a formal meeting, it’s good to keep a to-do list of things that need to be added to your collection script, new tools and process adjustments. Keep it as an ongoing list and when you start your quarterly review of processes you’ll have an action list.