Welcome to the first AFoD blog post for 2011. I’ve decided to start the new year out with an interview with Hal Pomeranz. Hal is very well known in the information security community and is probably best known for this work with the SANS Institute as the driving force behind the Linux/Unix security content for SANS. Hal is also part of the SANS digital forensics team and has recently been spending quite a bit of time writing, researching, and teaching on various digital forensic topics.
Professional Biography of Hal Pomeranz
A dynamic and experienced technology authority, Hal Pomeranz is the Founder and Technical Lead of Deer Run Associates, a consulting company focusing on Computer Forensic Investigations and Information Security. He has spent more than twenty years providing pragmatic Information Technology and Security solutions for some of the world's largest commercial, government, and academic institutions.
Hal is a Faculty Fellow of the SANS Institute, and it's longest-tenured instructor. He is the track author and primary instructor for Sec506: the Linux/Unix Security certification track (GCUX). He is also a GIAC Certified Forensic Analyst (GCFA) and an instructor in the SANS Computer Forensics curriculum. Hal frequently contributes to the SANS Computer Forensics blog, and is a co-author with fellow SANS instructor Ed Skoudis and Tim Medin of the weekly on-line Command Line Kung Fu column.
A leader in the community, Hal has served on the Board of Directors for USENIX, BayLISA, and BackBayLISA. He is a co-founder of the IT Professionals Forum. He is a frequent presenter at national and local technical gatherings, and the author of numerous books and articles on subjects ranging from Computer Forensics to Information Security to System and Network Management to Perl Programming. Hal also served as the Technical Editor for Sys Admin Magazine during its last four years of publication. He is a recipient of the SAGE Outstanding Achievement award for his teaching and leadership in the field of System Administration.
Prior to founding his consulting company, Hal's career included a variety of roles from System and Network Operations, to Network and Security Architecture, and even Software Development. He has worked for an equally diverse set of employers including AT&T Bell Laboratories, NASA, the University of Pennsylvania, TRW Financial Systems, and even an Internet start-up, NetMarket, which was the first company to conduct a secure financial transaction on the World-Wide Web. As a consultant for Deer Run Associates, Hal's client list includes Cisco, Microsoft, eBay, the FBI and several other government agencies.
AFoD Interview with Hal Pomeranz
AFoD: Many of the top level people in our community come from a law enforcement or military background. The paths that these people take into digital forensics are generally defined by traditional law enforcement and military career development processes. You are part of the top level of people who have entered digital forensics from the information technology world. Can you describe your journey into the digital forensics community?
HP: I started my career as a Unix Sys Admin. My first boss, an early mentor of mine, saw my interest in Computer Security and nurtured that. So I ended up as a Unix Admin who was also an InfoSec person.
As an InfoSec professional, you're bound to have at least some
interaction with computer crime events, even if it's just in the course of defending your own networks. As it turns out, my second job was at the University of Pennsylvania, whose dial-up services were at the time being used by non-University folks for a lot of nefarious activity. This led to some interaction with law enforcement, including the local FBI office.
There were a couple of other watershed moments in my career that started me down the digital forensics path. The first was incorporating forensic material into my SANS Linux/Unix security track when it was conceived in the early 2000's. John Green-- who did incident response at NSWC Dahlgren and is now the CISO for the state of Virginia-- wrote and taught the original material in the track, and patiently answered lots of newbie questions from me. When John went off to pursue other opportunities, I took over teaching and updating the material. This forced me to learn a lot. I'm also now one of the instructors in the SANS Computer Forensics curriculum, which has also been a great opportunity to help others, but also expand my own
knowledge.
But I still wasn't doing digital forensics as part of my professional
consulting practice, though I did occasionally help out friends who were in difficulty and I certainly worked on engagements where I was part of the IT/InfoSec cleanup crew in the wake of an incident. A couple of years ago, however, Rob Lee approached me about an opportunity with Mandiant. Essentially they were looking to develop relationships with other skilled consultants who they could reach out to on an as-needed basis for short-term help during unexpectedly busy periods. "Surge Staff" is the name of the program.
As it turns out though, "unexpectedly busy" seems to be more the rule than the exception. I've spent a lot of time in the last year and a half working on cases through Mandiant. It's been a very positive relationship for both of us, and I've certainly seen my skills expand enormously with the benfit of this experience. Long live the Surge!
AFoD: Becoming part of the SANS digital forensic team is a relatively recent development for you. Doesn't your involvement with SANS predate your involvement with the digital forensics community? I think I remember you saying that you were one of the original SANS Fellows. Can you tell us about your SANS career and how that has impacted your professional development?
HP: Of currently active SANS faculty, I think I can lay claim to being the longest-tenured. Randy Marchany, Gene Schultz, and I have a good-natured argument going about who's the "oldest" SANS faculty member, but we've all been presenting at SANS conferences since the beginning of the 1990's (before the organization was called SANS, by the way). I taught my first paid tutorial for SANS in 1994-- a class called "Securing Solaris: Step-by-Step". Over time, that course gradually morphed in what is now SANS' "Sec506: Linux/Unix Security" track, which is the basis for the GIAC GCUX cert. We rolled the first version of the track out in 2001 I believe. John Green and Lee Brotzman originally contributed material to the track, and much of John's forensics material is still visible. But I've been pretty much the only instructor and author for several years now.
As far as professional development goes, mastering material well enough to teach it to others seems to me to be the highest order of technical expertise you can obtain. I learn a huge amount updating and teaching my courses. And not just from my own research: SANS attracts some incredibly bright experts as students, and I learn something from the folks I teach every time I do a class. Teaching a class in front of a high level technical audience and being open to admitting that there's something you don't know may be one of the most difficult tightrope acts I can imagine. "How are you going to learning anything if you know everything already?", is a motto that appears in my SANS "author's statement" and I think it's true. We are all experts and yet also students at different times and in different subject matter areas. There is so much we can learn from each other!
In the IT community that I grew up in, there was a lot of knowledge transfer going on, both formally and informally. I was lucky enough to be mentored by some truly famous people. Their expectation was that when I achieved a decent level of proficiency, I would educate the next generation-- "pay it forward". I've tried to live up to that. Aside from stimulating my own learning, the other obvious benefit to being out there in the community and teaching/writing, is the personal "networking" and reputation enhancement aspects. For example, my current business association with Mandiant wouldn't have happened if I didn't know Rob Lee because of our mutual involvement in SANS. And certainly I've had former students who have become clients.
AFoD: Ovie Carroll is good at articulating the point about learning from others also. I agree with him when he says he can sit down with anyone learn a couple things from them. There is just so much to know in our field that it's impossible to really master all of it. That's why it's important for people to share even if they don't think they are at the level of someone like you or Rob. Now the fact of the matter is that you are in the top tier of digital forensics people. What sort of skills did you develop over the years that helped you reach this level in the field?
HP: On the technical side of things, there's a whole body of low-level knowledge about file systems, networking, system devices, etc that System Admins in my generation were expected to master. For example, one of the first posts I wrote for the SANS Forensics Blog was a trick that uses alternate superblocks to allow you to mount "dirty" EXT3 file systems. How did I know about that trick? Because twenty years ago recovering broken file systems from alternate superblocks wasn't just a cool trick-- it was a necessary survival strategy! In any event, it turns out that a lot of this technical knowledge is directly applicable to understanding forensic artifacts.
The other technical item that Sys Admins were expected to master was the ability to write code to automate repetitive tasks. I'm dealing with a case right now where I need to process three or four dozen system images. If I tried to do this serially using some of the standard commercial tools, I'd never get it done. But because I can quickly write small shells scripts, Perl programs, etc I can be doing lots of automatic processing in the background while I'm working on specific artifacts that pop out as "interesting". Also, I can read other people's code, find bugs and vulnerabilities, understand what malware is doing, etc. The ability to program provides so much leverage for forensic analysts! It's a shame that more time isn't devoted to teaching these skills in typical forensic curricula.
Looking at non-technical skills, there's a problem-solving strategy that successful IT people tend to develop that's very similar to the process you go through when responding to an incident or working a case. You end up asking the same sorts of questions: "What was the tip-off that something has gone wrong?", "What were you expecting to see instead?", "When was the last time the correct behavior occurred?", and so on. Good IT shops spend a lot of time doing "root cause analysis"-- figuring out exactly what went wrong so that it never happens again. But as forensic analysts we also spend a lot of time figuring out "what went wrong", and the skills sets overlap.
As an IT/InfoSec consultant, I'm also used to coming into lots of
different environments and quickly assessing system and network
architecture, getting an handle on the site's policies and procedures, and so on. Sometimes I even have to try and deduce how things were supposed to be configured, and then try and figure out where bit rot and entropy have set in-- I call this "IT archeology". You do the same sorts of things when you're pulling apart a forensic image and trying to figure out what the machine was supposed to be doing and what's been happening on the machine.
From a psychological perspective, succeeding in IT over the long term generally means you've developed a certain level of confidence in working with strange problems without much external support or documentation. Computer systems are deterministic-- if you fully understand the technical underpinnings, you should be able to understand past failures and/or predict future behavior. Certainly you develop strong research skills and good testing methodologies, but confidence is key. In the current forensics space, where so much is undocumented and you're often left to your own devices to figure things out, this confidence that you will be able to find a solution is supremely important.
AFoD: There are plenty of people who are in information technology who are good problem solvers and can do some scripting of repetitive tasks, but we both know that doesn't automatically make them good candidates for a role in digital forensics. What do you think are the fundamental building blocks that someone needs to have to be turned into a good digital forensic examiner?
HP: In a nutshell, you want to look for the ones who do the root cause analysis and don't just reboot the machine when something goes wrong. They're the ones who want to figure out *why* a problem happened, not just make it go away. They're going to learn more and learn faster than their peers, and they've got the kind of staying power that comes in handy during investigations.
It also helps if they can write. Do they produce coherent documentation? Are they writing articles or putting their ideas out in the community via other means? Can they convey information to non-technical people? Communication is key, because what we do is a "team sport" that involves lots of people, both technical and non-technical.
And to echo a theme from earlier interviews, I think you're looking for "passion". Is working with computers a job or a calling for your candidate? Do they spend significant amounts of time (especially their own time) on continuing education? I've often said that if I won the lottery tomorrow and didn't have to work for a living, I'd still keep on doing what I do just because I have so much fun with it. There are plenty of frustrations around what we do, so I think you've got to love it in order to get over the rough spots.
AFoD: So lets say that we have someone who has all of the necessary fundamental skills and passion to get into digital forensics work. Let's talk about how you think they should go about it. What would you tell the high school student who wants a career in digital forensics?
What would you tell someone who already has an established career in information technology, but who wants to break into the field of digital forensics?
HP: One piece of the puzzle is having the necessary skills. The question pre-supposes that our candidate has the necessary technical chops to handle the position. But there's a difference between having a large body of technical knowledge under your belt and being able to apply it to an investigation. Some sort of specific training in computer forensic tools and techniques plus some legal background to understand the laws as they apply to forensic investigations is clearly warranted. Obviously, I think SANS training is pretty darn good, but there are lots of other programs out there as well. Caveat emptor.
Another important piece is getting some actual case experience. This can be the hardest part for somebody trying to break into the field. If you're just starting out, then you'll probably have to pay some dues. You might look into large e-discovery firms and contracting shops that do a lot of forensic work. They're more likely to hire junior analysts. Another avenue is law enforcement. It seems like the FBI is interested in bringing on more qualified civilian employees in the computer forensics realm, and state and local law enforcement would probably like a few as well.
If you're already working in a company as an IT professional and would like to make the move into forensics, then you should start cultivating relationships with the people who do incident response for your company. In some cases, there might not be anybody currently in your firm who has that job. In which case, you might talk to your own management about sending you to training so that you can become that person. There's lots of scare stories in the news these days that can bolster your case for creating an internal resource for forensics and incident response.
In the meantime, there are lots of forensic challenges out there that you can use to practice your skills. If you do well in those challenges, it will be good resume material and will likely bring you to the attention of people who are needing to hire forensic experts.
Which brings us to career development item #3. You need to start linking up with the community and getting your name out there. Networking is always the best way to find a job. There's a really interesting forensics community developing on Twitter-- check out Joe Garcia's "Follow Friday" list for a good starting point to find people in the community. Read what these people are saying and the links that they're posting (to their own research and others) and I guarantee you'll learn a lot.
But networking has to be more about giving than taking. So start
doing your own research and writing your own blog posts, white papers, etc. There are a lot of great Open Source forensics projects that you can contribute to. Log2timeline, regripper, and volatility are all examples of projects where you can easily contribute small modules to expand the power of these tools. Or take on a bigger project-- such as adding support for a new file system type in the Sleuthkit, like EXT4 or XFS (both of which are desperately needed, IMHO).
Try and find local groups in your area-- whether tech groups, ISSA, InfraGard, HTCIA, or what have you-- and find other people with common interests. Get some practice speaking in front of these groups. Submit talks to security conferences, BSides, etc. If you're doing interesting work and can be articulate about it, you'll get a job.
And finally, never ever stop learning. The computer industry in general is all about constant retraining because technology changes so rapidly. The computer forensics field is so new that there's an enormous amount that we don't know and research to be done. That means it's even more important to stay up on the latest knowledge. It's like the sharks that die when they stop swimming-- if you stop learning and updating your skills then your career is going to die. Celeste Stokely taught me, "Learn one big new thing every year." It's good advice and I've tried to stick with it.
AFoD: One of the things we discussed recently on Forensic 4cast was whether someone who is interested in going into digital forensics should pursue an actual degree in digital forensics or something broader like computer science. As I think more about it, it seems if you have a burning desire to get into digital forensics and you want to gain some academic training, it's reasonable to get a degree from one of the handful of good programs that are available. However, this isn't going to be an option for many people.
For example, take a high school student here in the United States who doesn't have a lot of money to spend on college or who wisely don't want to start their professional career with a six figure debt burden. Those students might be limited to situations where they can get in-state tuition at a school in their state of residence and those schools will likely not have a digital forensics program. However, there are many state universities that have excellent programs in areas such computer science and engineering.
What would you recommend for those students? Regardless of their degree option, what topics would you encourage them to study to become better digital forensic examiners?
HP: When I think of specific topics from my educational background that help me in my daily practice it would be things like programming, operating systems, compiler design, algorithms, and so on. I went to a pretty "Ivory Tower" Liberal Arts school, so some of the really practical stuff I had to get on my own by hacking around in the school computer labs (much to the detriment of my GPA). In fact, my major was actually math because my school only offered a minor in computer science and not a full degree program. But I learned a lot from the math curriculum too-- like how to model problems and estimate the computational complexity/processing time requirements, and how to construct proofs and logical arguments.
And I think this latter part-- learning how to think about problems-- is one of the most important things you can get out of college. The specific technologies I studied in school (Pascal programming anybody?) are no longer in vogue. But I "learned how to learn", I learned how to write, and I was exposed to a broad range of topics that end up helping at the oddest times. Heck, the Shakespeare I studied in English Lit once helped me defuse a raging flame-war on an intra-company mailing list!
Undergraduate programs are your chance to get a broad background and explore lots of different subjects. Use this time wisely. If you're able, I would recommend doing your undergrad at a smaller, teaching-focused school where you can get more one-on-one time with the faculty, as opposed to a big research university where you get lost in the crowd. If you get really interested in a field and want to study it in depth, then get into a graduate program-- probably at a well-funded research university, if possible-- and really dive in to your research.
AFoD: Let's talk a bit about the current state of digital forensics. What is your impression of where we are as a community? What do we do well and what do we need to get better at as a community?
HP: We are so young as a discipline! It would be easy to focus on what we don't know, the tools that we wish we had, short-comings in different curricula, and so on. But being a "glass is half-full" kind of person, I have to say that it's pretty amazing what we can
do today as compared to a decade ago-- just take memory analysis as one example of many. And we're getting better every day as the result of sterling work by the community.
What we're trying to do now is engineer solutions to problems on platforms where the vendors give us little or no direct support or documentation. In the late 70's and early 80's, Unix people who were faced with a similar situation vis a vis a lack of Unix support from AT&T. My people dealt with the problem by creating a community to share information that they had gleaned through their own research.
We're starting to see some of that in the forensics community, but we need to do more. I'd like to see an ecology of forensics gatherings at least as rich in number and variety as the conferences for people who are interested in breaking systems. And I'd like to see more forensics gatherings that are not sponsored by a single vendor of forensic tools, and which avoid government entanglements that inhibit the free flow of information. Let me be clear that I'm not looking for people to share IoC's or technical details from actual cases. I'd just like to see us sharing basic "block and tackle" type technology notes that will make everybody's lives easier.
We need better cross-platform tools. The mature tools in the field
run largely on Windows and do a good job analyzing Windows-- Mac and Linux, not so much. The Mac folks have a bunch of tools for analyzing Macs (and other Apple devices) that largely only run on the Mac platform. Linux wizards mutter arcane command-line incantations and make data appear. I shouldn't need three different computers to do my job! And that's not even counting the the mobile device insanity that's already threatening to overwhelm us. I have a feeling that things are going to get worse before they get better here, because everybody's so focused on simply understanding all the details of their chosen platforms, but it really does make life hard for analysts who have to deal with cases involving multiple platforms.
And I think we have some more "bridge building" to do. Within our own community we have people with a background in law enforcement or from a military service academy. And then there are folks like me coming at this out of the "computer geek" community. Both sides are still trying to understand where the other is coming from and what valuable stuff each side is bringing to the party. But then there are also all of the external communities we touch: law enforcement, the Bar, Human Resources and other corporate gatekeepers, and even just normal citizens who have need of our services. There's a lot of education and outreach that needs to be done so that these folks understand what we do and what help we can provide, and increase our understanding of what they need from us.
AFoD: You've been involved in the information security and digital forensics communities for a long time. This has given you a unique position where you have had considerable exposure to people who have come into digital forensics from different paths whether from law enforcement or a more traditional information security background. What have learned about the differences between a law enforcement perspective on digital forensics compared to an information technology perspective? Are there any differences that you can see?
HP: From my perspective at the far end of the "nerd" part of the spectrum, I see a lot of differences. One basic thing I really respect about my law enforcement colleagues is their ability to manage their case loads. As an IT person, I was always proud of my ability to "multi-task" and juggle multiple projects simultaneously. But I realize now that I had nothing on an attorney who is simultaneously managing a couple of dozen cases all headed to trial or plea agreements on different schedules, or my LE friends who are having to work so many different kinds of crimes in parallel.
I've also gotten a terrific education from the LE and legal side of the house on what evidence is useful and relevant, as opposed to stuff that I think may be cool from a technical perspective, but which doesn't help them make the case. This has helped me streamline my investigations, as well as my report writing.
Now the plus side of my being a computer person, and the reason I get called in to help on cases, is that I can often extract evidence that the LE folks lack the skills or processes to get at. Sometimes I have to create new tools to do this, which is something I'm comfortable with because I'm confident around information technology. The dark side of this ability, though, is that sometimes we computer folks get sucked down technological rat-holes, where we spend a huge amount of time producing evidence that doesn't really end up being that useful. Somebody with less computer skills, but with more case experience might just move on to some other, more fruitful portion of the analysis. Letting go of an interesting technical challenge and moving on to another piece of the investigation is a skill I'm only slowly getting hold of.
On the other side of the coin, I see my LE friends spending so much time on manual tasks that could be solved by a little scripting. Like many people who aren't primarily technologists, they don't know what things should be easy to do with technology and what's hard-- or they just don't have the skills to implement solutions. I once helped an agent who was manually cutting and pasting EXIF data from an image viewer into a spreadsheet-- about 30 minutes of my tinkering with awk and shell and the output of exiftool saved countless hours of investigator time. It's a huge compliment to me when the LE guys say, "We like having Hal around, because he gets things done faster."
AFoD: You're bringing up a point that I'm seeing emphasized more and more by people in the top tiers of the profession. Conducting an efficient investigation that answers specific questions that our customers want answered is the core of what we should be doing in digital forensics, isn't it? How do you go about scoping out and planning your investigations so that you get your customers what they want?
HP: I think the type of engagement has some bearing on whether you're targeting specific questions or going for a more wholistic approach. Lately I've been doing a lot of "lead generation" work for law enforcement, and that's definitely about honing in on very specific kinds of information. E-discovery is much the same-- winnowing out particular types of information your client is interested in from huge volumes of data. On the other hand, if I were working up a report on a system that was going to be crucial in a court case, I would want to do a more thorough job just to make sure I got at all the evidence: both inculpatory and exculpatory.
As far as the scoping question goes, I think the key is high levels of communication and short turn times. With my law enforcement clients we'll start with a briefing for me on the particulars of the case, and I'll try and understand from them what sorts of information they're interested in. For example, if they're looking for a pattern of on-line behavior, then I'll probably focus my initial efforts on browser artifacts, on-line chat, email, and so on. If they need attribution data then maybe I'll look more at network data timelines, file meta-data, contact lists, the social networks, and so on.
This is not to say that I won't work up other data from the system, but I want to get into the case as quickly as possible and start extracting data. I then take the data that I've found in my first pass which I think is "interesting" and show it to the client. Maybe they say, "Great! We want more of that", or maybe it's uninteresting. Either answer helps guide my investigation. Also, of course, evidence that I turn up sparks a whole new line of thought which may lead to them asking me for other kinds of information.
At this point I return to the images I'm analyzing for another pass. That will turn up more information that I'll take back to the client, and so on. Early on in the investigation I may talk with the client multiple times per day if they can spare the time. As we go through more cycles, we figure out more clearly the kinds of data we're interested in, and I need to interact with the client less often because I know what they're looking for.
Even if I don't need guidance on what to look for, however, I still
like to give the client quick updates on what kinds of information I'm finding, just to keep them up-to-speed on how the investigation is proceeding. This is just quick status updates, mind you—possibly via short emails rather than live conversations-- I'll typically save full detail for the report.
The other advantage to these status updates is that it makes it pretty clear to everybody when we've reached the "point of diminishing returns" in the investigation. Everybody's cost-conscious, and clients really appreciate it when they feel like you're looking out for their bottom-line. They tend to remember things like that when they're needing to hire somebody to help with the next investigation.
AFoD: I'd like to discuss the topic of criminal defense work in the
digital forensics community. I have observed an increasing resistance to the "pariahization" of digital forensics people who do criminal defense work. When I first entered the field, there wasn't much pushback on the idea that examiners who engaged in criminal defense work had gone over to "the dark side" and that it was essentially acceptable to push these examiners to the margins of our community. Now I'm seeing that attitude becoming much less prevalent. I suspect this is because we are seeing more people in the law enforcement community leave to start second careers in the private sector. I also think one of the things that is causing a change in attitude is that we have more people from the traditional information security world entering the digital forensics field who don't view forensics through the lens of the justice system. This gets back into our previous discussion about the differences of people who enter the digital forensics community from an information technology background as opposed to a law enforcement one. What are your thoughts on digital forensic examiners who engage in criminal defense work?
HP: Maybe it's because I'm coming at this from a non law enforcement background, or maybe I'm just hopelessly naive, but it seems to me that forensic analysis should be first and foremost about science, and not about choosing sides. Prosecution or defense, we as analysts should report on observed facts. Where we're required to draw conclusions based on our observations, we need to be aware of our biases and avoid letting them distort our findings. And because we sometimes have to make judgments based on incomplete evidence, it's incumbent upon us to acknowledge the gaps in our understanding and be scrupulous in our research and experimentation. As scientists we should welcome peer review and encourage transparency.
Also, I was raised to believe in "innocent until proven guilty", and that everybody is entitled to a "robust defense" regardless of their ability to pay. To me that means that the defendant should also have access to the same level of forensic experts that the prosecution enjoys and not just the people who have "lowered themselves" in some way to work defense cases.
OK, that's the "perfect world" view anyway. The history of jurisprudence is littered with examples of witnesses, forensic analysts (both digital and traditional), attorneys, and law enforcement personnel who have-- intentionally or otherwise-- manipulated a case and achieved an outcome that was directly contradicted by the available evidence. And rising legal costs mean that justice can be trumped by deep pockets.
I don't know how to solve these problems in our current justice system. But I do think that reducing the adversarial nature of the current system would be a good first step. Shouldn't a trial be a collective search for the truth rather than a slap fight? Wouldn't cooperation reduce costs for both sides?
As forensic analysts, we can't control how attorneys, judges, and other members of the justice system behave, but we should at least begin by unwinding artificial "us vs. them" divisions in our own field. Let's not ostracize fellow practitioners based on the types of cases they work on. Instead, let's grow the size of our community so that we can expose-- through peer review and science-- those members who act unprofessionally or unethically regardless of which side of the aisle they're currently sitting on.
AFoD: What can we expect to see from you in 2011?
HP: The SANS Forensics curriculum is just exploding in popularity and all of the qualified faculty are scrambling to meet the demand. As an independent, I've got a bit more "flex" in my schedule than some of the other faculty who've got full-time employers, so I expect to be teaching more for SANS in 2011. In particular, I seem to be picking up some of the dates for Lenny Zeltser's excellent Reverse Engineering Malware class--particularly the international training. Also, Chad Tilbury and I are co-teaching For508 via SANS' vLive! distance-learning technology later this year, and I'm really looking forward to that.
I'm also getting out to some non-SANS forensic events in 2011.
For example, I'm giving a couple of talks at the DoD Cyber Crime Conference in January, and a couple more at CEIC in May(apparently I need to find a non-SANS venue for the Fall as well). And while I'm on the road so much, I've been trying to make appearances at various local user groups-- for 2011 I've got confirmed dates to speak at the ISSA meeting in Tacoma, WA, NECERT's Cyber Security Forum in Omaha, and the Linux User Group in Boulder. (you can follow my travels on the Deer Run Associates home page). There are so many folks that I've been corresponding with via email and Twitter that I'm hoping to meet in person in 2011!
I've also got a plan to continue writing articles for the SANS Forensics Blog every 4-6 weeks. I've got a backlog of topic ideas-- it's the research and the writing that can be difficult to find time for! For example, there's at least two more articles planned in the series I started recently on EXT4. And of course there's the weekly Command Line Kung Fu blog that I'm co-writing with Tim Medin.
The big one, however, is that I promised Rob Lee I'd develop a Linux Forensics class for SANS. This is a huge undertaking-- hundreds of hours of work-- that I need to find time for in 2011. I'm cheating a bit in that the research, blog posts, and presentations I'm doing lately are all development work that's going to end up feeding into the final version of the Linux Forensics class. But it's still going to be a massive effort to give birth to this baby.
