I had the pleasure of speaking with Jake Williams, an incident responder extraordinaire, who teaches SANS' FOR610: Reverse-Engineering Malware course. In this interview, Jake discussed his perspectives on getting into digital forensics, crafting a strong malware analysis reports and making use of the analyst's findings.
Could you describe your professional background a bit? How did you get into reverse-engineering?
Well, I started out my professional career in the US Army, I've worked as a DoD civilian, and as a contractor/consultant. Over my career I've done a lot of programming. I've also done a fair amount of penetration testing of some pretty hardened networks (those are always more fun than the easy ones). I've found that I really enjoy incident response and digital forensics work as well. As a byproduct of performing incident response, I found that I needed to learn to reverse engineer malware. I was one of those kids that took everything in the house apart just to "see how it works" so it felt like a natural progression.
When I started in incident response, you found a piece of malware or evidence of an intrusion and that was it. The client reloaded the machines involved, most often without really understanding what happened. I like to call this the 'Bronze Age' of incident response. We didn't have HIPAA, GLB, or PCI/DSS requiring the level of investigation/accountability we have now. As threats became more advanced and standards started progressing, clients wanted to know what the malware I just found was capable of. At first, it was hard to even find someone to outsource this kind of work to, the field was so new. Then I realized that I didn't want to outsource it even if I could. I realized that by already having the context of the IR investigation, I could often jumpstart my analysis.
I guess I got into malware RE primarily as a means of providing the client with a more complete picture of the incident. But it really spoke to that part of me that likes to take things apart, so I've found that I enjoy a good piece of malware like many people enjoy a crossword puzzle.
But really, the benefit of augmenting IR knowledge with RE knowledge allows you to write a much more complete report to the client. It allows you to more effectively close the book on an incident, rather than recommending follow analysis of discovered malware.
Does an organization need to reach a certain maturity level in its security practices to benefit from a comprehensive report like that? How often do you think your reports might have been accepted, but simply shelved away?
Yes, an organization definitely needs to reach some technical maturity level to make complete use of a detailed report. The more detailed the report, the more technical maturity they need to make full use of it. I'm not picking on organizations, but consider this analogy. I get a detailed prospectus in the mail for every mutual fund in my IRA. I hate to admit it, but if I look at them at all, it's only the high level information. My investment technical maturity level isn't high enough to make use of much of the information in the prospectus. I think most of us can relate to that analogy, so I like to keep it in mind when writing my own reports.
I've found that the real key is to target your audience. That doesn't mean to dumb down the report, just to structure it in such a way that the information gets progressively more technical as the report progresses. You'll note that many of your prospectus's read that way (at least the good ones do). I understand the temptation to report on various portions of the incident and the malware completely and then move on to the next aspect in the report. Unfortunately, that makes the report harder to read for those with less technical expertise. I think there is a inverse correlation between the technical accessibility of a report and the odds of it being immediately shelved.
Any tips on how a malware analyst might create a report to increase the likelihood that the report will actually be useful?
Sure. I usually break my reports into three sections. The first section is the executive summary. Executive summaries are mentioned in every reporting seminar, but I almost never see them written correctly. The executive summary is NOT a place to show off how smart and technically savvy you are. Remember, you are writing here for executives. Even if you think the report will only be read by technical staff, the executive summary should still be written using as little techno-jargon as possible. Also, big words don't work here either. Note that most newspapers write at the 8-9th grade level. If you are exceeding this in your executive summary, you are losing a portion of your potential audience.
The second section in my report is where I include actionable intelligence from the incident. I get a little more technical here, but if an item isn't directly actionable or is deeply technical, it doesn't belong here. I write section this to what I call this "401/504 grade level." This means that I don't use any terms or reference technology in this section that a graduate of SEC401 (GSEC) or SEC504 (GCIH) wouldn't be expected to know. By concentrating only on actionable items, you ensure that your IR staff and systems administrators can comprehend your findings. This section is primarily intended for the IR staff anyway, so this works out well.
The third section in the report is where I go hog wild. If I spent time performing the analysis and found deeply technical information, it goes in this section of the report. I don't try to intentionally confuse anyone in this section. I do however consider it an "enter at your own risk" area. The analysis is deeper and more technical. It is still useful, but only if you've reached a certain technical maturity. Think of it as a report written by a malware reverse engineer for a malware reverse engineer. I figure that most people could comprehend a report like this after completing FOR610.
So my advice is to make the report digestible to three different audiences: non-technical personnel (or those with no security experience), IR personnel, and fellow reverse engineers. By writing to your audience (all of them) you minimize the chances that your report will just find its way to file 13.
Thanks for sharing your thoughts on these topics, Jake! Folks, for a continuation of this conversation with Jake, be sure to read parts 2 and 3 of the interview.
Jake Williams and Lenny Zeltser will be co-teaching the FOR610: Reverse-Engineering Malware course on-line live March 28-April 29, 2013. Get a choice of a MacBook Air, Toshiba Portege Ultrabook or $850 discount when you register for this class before March 13, 2013.
