Stuff

Speaking
I've got a couple of speaking engagements coming up that I thought I'd share...

7-9 Nov - PFIC 2011 - I'll be giving two presentations, one on the benefits of using a forensic scanner, and the other, an Introduction to Windows Forensics.  I attended the conference last year, and had a great time, and I'm looking forward to meeting up with folks again.

30 Nov - CT HTCIA - I'm not 100% sure what I'm going to be presenting on at this point...  ;-)  I'm thinking about a quick (both presentations are less than an hour) presentation on using RegRipper, as well as one on malware characteristics and malware detection within acquired images.  I think that both are topical, and both are covered in my books.

Jan 2012 - DoD Cybercrime Conference (DC3) - I'll be presenting on timeline analysis.  I gave a presentation on Registry analysis (go figure, right??) here a long time ago, and really enjoyed the portions of the conference that I was able to attend.  I know that Rob Lee recently gave an excellent webinar on Super Timeline Analysis, but rest assured, this isn't the same material.  While I have provided code to assist with log2timeline, I tend to take a slightly different approach when presenting on timeline analysis.  Overall, I'm looking forward to having a great time with this conference and presentation.  Also, timeline analysis has it's own chapter in the upcoming Windows Forensic Analysis 3/e.

Reading
I've had an opportunity to travel recently, and when I do, I like to read.  Being "old skul" (re: I don't own a tablet...yet), I tend to go with hard copy reading materials, such as magazines and small books.  I happened to pick up a copy of Entrepreneur recently, for a couple of reasons.  First, it's easy to maneuver the reading material in to my seat and stow my carry-on bag.  Second, I think it's a great idea to see how other folks in other business areas solve problems and address issues that they encounter, and to spur ideas for how to recognize and address issues in my own area of interest.  For example, the October issue of the magazine has an article on how to start or expand a business during a recession, addressing customer needs.  In the technical community, this is extremely important.

In that same issue, Jonathan Blum's article titled Hack Job (not the same title in the linked article, but the same content) was interesting...while talking about application security, the author made the recommendation to "choose an application security consultant".  I completely agree with this, because it falls right in line with my thoughts on DFIR work...rather than calling an IR consultant or firm in an emergency, find a "trusted adviser" ahead of time who can help you address your DFIR needs.  What are those needs?  Well, in any organization, regardless of size, just look around.  Do you have issues or concerns with violation of acceptable use policies, or any other HR issues?  Theft of intellectual property? 

If you call a consulting firm when you have an emergency, it's going to cost you.  The incident has already happened, and then you have to work through contracting issues, getting a consultant (or a busload of consultants) on-site, and having to help the responders understand your infrastructure, and then start collecting data.  You maybe paying for more consultants than you need initially, because after all, it is an emergency, and your infrastructure is unknown.  Or, you may be paying for more consultants later, as more information about the incident is discovered.  Also, keep in mind emergency/weekend/holiday rates, the cost of last minute travel, lodging, etc.  And we haven't even started talking about anything the consultants would need to purchase (drives for imaging), or fines you may encounter from regulatory bodies.

Your other option is to work with an trusted adviser ahead of time, someone who's seen a number of incidents, and can help you get ready.  You'll even want to do this before increasing your visibility into your infrastructure...because if you don't have a response capability set up prior to getting a deep view into what's really happening on your infrastructure, you can very easily be overwhelmed once you start shining a light into dark corners.  Work with this trusted adviser to understand the threats you're facing, what issues need to be addressed within your infrastructure and business culture, and establish an organic response capability.  Doing this ahead of time is less expensive, and with the right model, can be set up as a budgeted, predictable business expense, rather than a massive, unbudgeted expenditure.  Learning how an incident responder would address your issue and doing it yourself (to some extent) is much faster (quicker response time because you're right there) and less expensive (if you need analysis done, FedEx is much less expensive than last minute plane flights, lodging, rental cars, parking, etc., for multiple consultants).  Working with a trusted adviser ahead of time will help you understand how to do all of this in a sound manner, with confidence (and documentation!).

MBR Infectors
I've posted on MBR infectors before, and even wrote a Perl script to help me detect one of the characteristics of this type of malware (i.e., modifying the MBR, and then copying the original MBR to another sector, etc.).

Chad Tilbury recently posted an MBR malware infographic that is extremely informative!  The infographic does a great job of illustrating the threat posed by this type of malware, not just in what it does and how it works, but being a graphic, you can see the sheer number of variants that are out there, as well as how they seem to be increasing. 

This stuff can be particularly insidious, particularly if you've never heard of it.  I've given a number of presentations where I've discussed NTFS alternate data streams (ADSs), and the subject matter freaks Windows admins out...because they'd never heard of ADSs!  So, imagine something getting on a system in such a way as to bypass security protections on the system during the boot sequence.  More importantly, as a DFIR analyst, do you have checks for MBR infectors as part of your malware detection process?

Blogs
Melissa's posted a couple of great blog posts on a number of topics, including (but not limited to) using Volatility and John the Ripper to crack passwords (includes a video), and examining partition tables.  She's becoming more prolific, which is great because she's been posting some very interesting stuff and I hope to see more of it in the future.

Tools
I've seen some tweets over the past week or so that have mentioned updates to the Registry Decoder tool...sounds like development is really ripping along (no pun intended...).  If you do any analysis of Windows systems and you haven't looked at this tool as a resource...what's wrong with you?  Really?  ;-)

Evidence Collection
A long time ago, while I was on the IBM ISS ERS team, we moved away from using the term "evidence" to describe what we collected.  We did so, because the term "evidence" has the connotation of having do with courts, and there was an air of risk avoidance in much of the IR work that we did...I'm not entirely sure where that came from, but that's how it was.  And if a customer (or someone higher up the food chain) says, "don't call it 'evidence' because it sounds like we're taking it to court...", then, well...to me, it doesn't matter what you call it.  Now, this doesn't mean that we changed what we did or how we did it...it simply means that we didn't call the digital data that we collected "evidence". 

This recent SANS ISC post caught my eye.  The reason it caught my eye was that it started out talking about having a standard for evidence handling, listed that requirements, and then...stopped.  Most often when talking with on-site IT staff during an incident, there's an agreement with respect to the need for collecting data, but when you start talking about what type of evidence is admissible in court, that's when most folks stop dead in their tracks and paralysis sets in, as often the "how" is never addressed...at least, not in a way that the on-site IT staff remembers or has implemented.

Here are a couple of thoughts...first, make data collection part of your incident response process.  The IR process should specify the need to collect data, and there should be procedures for doing so.  Each of these procedures can be short enough to easily understand and implement.

One of the things that I learned while preparing for the CISSP exam way back in 1999 was that business records...those records and that data collected as part of normal business processes...could be used as evidence.  I am not a lawyer, but I would think that this has, in part, to do with whether or not the person collecting the data is acting as an agent for law enforcement.  But if collecting that data is already part of your IR process and procedures, then it's documented as being part of your normal business processes.

And right there is the key to collecting "evidence"...documentation.  In some ways, I have always got the impression that this is the big roadblock to data collection...not that we don't know how to do it (there is a LOT of available information regarding how to collect all sorts of data from computer systems), but that we (technical folks) just seem to naturally balk at documenting anything.  And to be honest, I really don't know why that is...I mean, if a procedure states to follow these steps, and you do so, what's the problem?  Is it the fear of having done something wrong?  Why?  If you followed the steps in the procedure, what's the issue?

This really goes back to what I said earlier in this post about finding and working with a trusted adviser, someone with experience in IR who is there to help you help them to help you (that was completely intentional, by the way...).  For example, let's say you have a discussion and do some hands-on work with your trusted adviser regarding how to collect and preserve "evidence" from the most-often encountered systems in your infrastructure...laptops, desktops, and servers in the server room.  Then, let's say you have an incident and have to collect evidence from a virtual system, or a boot-from-SAN device?  Who better to assist you with this than someone who's probably already encountered these systems?  Or better yet, someone who's already worked with you to identify the one-off systems in your infrastructure and how to address them?

So, working with an adviser would help you address the questions in the SANS ISC blog post, and ensure that if your goal (or one of your goals) is to preserve evidence for use by law enforcement, then you've got the proper process, procedures, and tools in place to do so.