The SANS Security Heroes project is to help introduce you to people that have made a difference in information security and the digital forensic community. We believe there are a lot of people contributing to make computer forensics work, and we want to introduce you to them.
Interview with Michael Cloppert by Rob Lee
1. Tell us how you became interested in IR or Forensics.
In 2001, while in college, someone hacked my Linux server by exploiting a relatively recent (at the time) WU-FTPD vulnerability. By the time I discovered the compromise, my server was full of warez. I knew very little of computer security at the time, but in the ensuing investigation to figure out what happened, I learned a lot and found that I enjoyed the process greatly. I was also pretty ticked at the guy who did it and my subsequent loss of internet innocence, so I locked my system down so far that even I could barely use it. Here again, I learned more. Throughout the experience I developed a strong belief that, even with individuals like my perpetrator out there, secure and networked computing do not have to be contradictory goals. My career hence has been a silent act of vigilantism stemming from this event.
2. What gives you the most satisfaction while working on a case?
The mere act of discovering a compromise or intrusion gives me a feeling of pride. This is especially true when using new or innovative techniques. Sure, I can stare at an IDS console until a specific, high-fidelity alert triggers and work an intrusion from there, or be handed a system that is known to be compromise and find the point of entry, but in most cases for me that feels like going through the motions. On the other hand, if I can mine terabytes of data to discover a previously-unknown C2 channel, or discover a new way to link ostensibly distinct intrusion campaigns suggesting a single actor, I feel I've contributed to the field and from this derive a great deal of satisfaction. I enjoy IR and forensics work the most when I can positively contribute to the tools and techniques available to others.
3. What forensic techniques do you find the most useful?
This is a tough question. At a low level, I frequently find myself validating tool output. If foremost tells me that I'm looking at a PE, I'll hexdump and look for the PE header starting from "MZ." If argus tells me that a particular flow has a certain number of packets and bytes, I'll use tcpdump to give the pcap a second look. Naturally, I don't do this for every bit of output, but certainly when I come across something new or different, and often at the beginning of an investigation. The things one does at the beginning of an investigation often act like a scientific axiom — an assumption, upon which the rest of your investigation rests. The earlier a mistake is made, the more dire the consequences to your conclusions. Thus, I perform far more validation of my own work, conclusions, and tool output earlier in investigations so as to not waste time or, God help me, foment false conclusions. By the end of an investigation, this is only useful to me when I find something unexpected.
4. What is your forensic tool of choice and why?
Without question, Perl. Go ahead, call me old-school (at least I didn't say LISP). Whether I'm trying to analyze a drive or dig through log files, Perl's flexibility, ubiquity, and ease of use as a high-level language make it the perfect all-purpose tool. Netcat as the hacker's swiss army knife? Like hell...
5. Tell us how a commercial tool helped solve a problem. What happened and how did it help?
I don't like endorsing specific vendors, but since you asked... I've found that one of the most difficult problems to solve in this industry is tool selection for enterprise security, forensics, and incident response. At a tactical level, many very powerful tools exist to investigate a small network, or a single computer. At a strategic, enterprise level, many watered-down tools exist which purport to solve the same problems. In large environments where real analysts work, typically neither is sufficient. Marty Roesch has successfully taken a powerful tactical tool (snort), and built an enterprise product offering that provides scalability. Their other products further enhance snort's capabilities. SIM, forensics, and vulnerability scan vendors would do well to learn from Sourcefire's model. I realize this is probably not the intent of the question, but this is the biggest and most consistent pain point I see in our field - one that interferes with our success as analysts in a very real and measurable way.
6. What area of forensics or incident response needs to be understood by every new investigator?
Forensics and incident response are sciences. Your results MUST be repeatable, otherwise you cannot defend your conclusions and they are worthless. Remember, the goal of your work is not for YOU, but for EVERYONE with a need-to-know. And besides, if your work is not repeatable, you will consistently make the same mistakes and will not improve your technique. This simple concept is predicated upon many things, including keeping a log book, following consistent processes, understanding how the tools you use produce the output they give you, and knowledge of computers, software, and networking at the most fundamental levels. If you aren't willing to embrace these aspects of forensics and incident response, you will not be successful.
7. What area of digital forensics or incident response is the most exciting development over the past few years?
The work folks are doing on memory analysis is fascinating. I wish I'd have gotten in on this sooner, but I'm very glad some seriously talented folks have started maturing this area of our field. I've seen memory analysis make cases by revealing passwords, commands issued by adversaries, and memory-only malware is more than just theoretical (although I've yet to see it in even the most sophisticated of intrusion cases). As our threat space matures, we need to be ready and waiting with tools to counter their techniques. For once, with memory analysis, I feel we're finally ahead of the curve.
8. What do you do in your free time when not working on computer forensics?
I am an occasionally-paid but mostly-amateur jazz trombonist.
