Brett recently posted a very good article on the three fears folks encounter when comes to public speaking in DFIR.
Reading his article, and re-reading it, got me to thinking about my own experiences. My first experience speaking in DFIR was at LISA NT 2000; however, it wasn't my first public speaking experience. I'd taken a required public speaking course in college, and like most folks in college, did what I could through the course, did a brain dump on the exam, and walked away from the material. That was a mistake. I was headed into the Marine Corps, and guess what...they put each and every one of us on the hot seat, over and over again. It began with the "impromptu speech" exercise in Officer Candidate School, where we were each given a few minutes to put together a short speech on a topic that the platoon commander gave us, and we had to give that presentation in front of the rest of the platoon. No props, no PowerPoint, no finger puppets...just put together and present a concise, coherent presentation. This training continued the following summer after commissioning as each of us went through The Basic School; for example, there was an evolution of instruction called "techniques of military instruction", where we each had to give a short presentation after choosing from several topics, such as "field sanitation". Throughout the six months of training, we were constantly giving presentations...patrol orders, and other 5-paragraph orders.
When I returned to The Basic School as an instructor, I had to go through the process called the "murder board"...I had to give the classes I would be presenting in front of the rest of my team, which included other LTs, Capts, and the Major in charge of our group. After that, there was continual process improvement, as I gave the various classes and presentations to student companies (2ndLts and Warrant Officers), and processed their instructor review forms from each class.
So, yeah...I had a good bit of practice. Some of the feedback was constructive. In other instances, the feedback was purposely negative, so that we'd get used to receiving negative feedback. However, when I was standing on the podium for the first time, giving my first presentation in front of a technical audience in the private sector, I was already pretty beat by the time I got there...the anxiety from my imposter syndrome had kept me amped for so long, I was pretty tired by the time I said, "hello" into the microphone the first time.
Another opportunity I had to present at a major conference was in New Orleans; the conference organizers thought it would be a good idea to hold the conference during Mardi Gras. This was both a good and bad idea at the same time, because it gave folks something to do besides the conference. One I was accepted to the conference, I was really looking forward to meeting and engaging with a couple of the folks who would be teaching training courses before the conference...but that ended up being a non-starter, as several of them disappeared into the party crowd the moment their course was complete.
When it came my time to speak, I dutifully got the room a few minutes early to ensure that the AV was suitable, I had the right connectors (VGA, at the time) and everything was set up. When the time came for me to speak, I looked up and all I could see, in the entire room, was the folks recording the video for the talk, and their lights. I quite literally could not see anyone else in the room, and was just about to cancel the talk when I realized that there were actually four people in the room besides me, and the video crew. However, they'd all decided to sit behind the stadium lights the video crew was using, and I couldn't see them. I ended up giving the presentation to what I assumed was all four people...the door in the back of the room may have opened and closed once or twice during my talk, I don't remember.
Some things that I've found over time are good to prepare yourself for...
There's always going to be someone asking what seems to be out-of-the-ballpark questions. When the question gets asked, your mind is going to be racing to understand the question and apply it to the context of the presentation and conference. You'll have just spent weeks, or even months, preparing the materials, and even practicing your presentation. And you'll have just spent 45 minutes or more, with your mind racing while you were speaking...are you hitting all of your points, are you saying what you wanted to say, oh, god I'm not really reading directly from the slides, am I? Sound exhausting? It is. And you'll get that way-out-beyond-left-field question.
My recommendation...rather than trying to do a pretty massive context switch on the fly, just say that you'll take it off-line. Don't get into a back-and-forth right there, because it'll just chew up time and others won't be able to ask their questions. Or, in the case of presentations just before a break, or lunch, or the end of the day, get to whatever's next. Besides, it's better to be able to focus your attention on those types of questions when you're not on the podium.
Similar to this is the "...what happens if you..." or "...did you do this..." question. I remember years ago I was presenting at a conference on NTFS alternate data streams, and I ran through the litany of examples, only to get, "...did you try this?" If you're confident in the material and the Demo Gods are kind to you that day, there's nothing wrong with opening a command prompt and giving it a shot. After all, I strive to learn something new from the perspective of others, when I have the opportunity, and this is a good way to go about it. However, in this case, the question was a "...what happens if you...?" question, and I turned it around...I knew the person asking the question had a Windows laptop open in front of them, so I asked, "...why don't you try it and let us all know what you find." Now, this wasn't intended to put that person on the spot, nor to single them out. The purpose of my responding what way was to demonstrate that when the conference was over and we weren't all in the room together, it's possible to get the answer to our questions by simply trying these things ourselves.
Another aspect of this is the smartest person in the room. You know who they are, because you've seen them at conferences, just like I have. These are the folks who have a question, stand up, and the first word out of their mouth is "I", and they don't actually ask a question. Whether they intend it or not, their delivery is going to come across as, "look how much I know" or "look at how smart I am". Now, I'm not suggesting that this is the intention, I'm simply saying that this is how it comes across, and the best way to handle these situations is to thank them, and maybe follow up with them later in the conference.
Then there's the long-winded talker who takes the opportunity, once they have the mic and everyone's attention, to abscond with it. Yes, its exactly how it sounds...there will be someone who "runs away" with your presentation once they have the microphone. This is another one of those, "...let's take this offline..." moments.
There are going to be people who ask the question you just answered. Literally. I've been to conferences (attended, as well as been a speaker...) where speakers have to submit their presentations prior to the conference date. The presentations are provided on a CD/DVD, or at the conference web site. In more recent years, this has all been part of smartphone apps for some conferences; everything, including the schedule and presentation materials are available via the app. When it comes time for you to speak, the person from the conference who introduces you will usually make a statement about where the presentation materials can be found, and some speakers may also have a URL in their presentation (maybe at the beginning, usually at the end) as to where the slide deck or materials can be found.
And yet, there will still be someone who asks if the materials will be available, and if so, where/when. It happens.
What I've seen more recently is that even though presentation materials are available, attendees will use their smartphones to take pictures of slides. I'm not at all sure why people do this if the materials are available, but from my perspective as a speaker, it simply tells me that they aren't interested in what I have to say.
Final Words
I don't for the life of me believe that anything I've shared here today is isolated to the DFIR community. Not at all. I am sure that these same sorts of things happen in other communities and at conferences of all types. However, I'm sharing what I've seen over the years in hopes that it will help others as they prepare to venture forth and engage in speaking at conferences. If it's a good experience for the speaker, they're more likely to continue. Good luck.
Lessons From Time In The Industry
I recently had the opportunity to give a presentation to the class taught by a good friend of mine. She'd asked me well in advance, and over the weeks leading up to the presentation, I went back and forth on the subject matter...what would I talk about to a group of folks just coming into the industry? I ultimately gave a presentation on Registry analysis, but I had compiled some notes on various other topics, including one of which I'd titled, "Lessons Learned In The Industry". By the time we got to the presentation, I had more than a few pages of notes, with edit marks, sticky notes, and I'd even written up a couple of Word documents that were now sitting on my desktop.
Instead of crumbling the notes up and deleting the Word docs, I thought it might be a good idea to get the notes written out into some semblance of a presentation, and blog post was as good a place to start as any. Also, this gives me the opportunity to put something down in writing and edit it, hopefully making it into something that makes a bit of sense before publishing it.
A little bit about myself to provide some context; I started in "information security" about 30 years ago. If I had to tie my time in the field back to a single point in time, my first real introduction to 'security' came in my initial military training. This training didn't involve computers, but had to do with information security overall. A lot of the training involved terrorism awareness (i.e., unusually heavy or dense packages, misspelled names or addresses, stains on packages, etc.), cryptographic equipment, communications security, authentication, etc. All of this maps directly to the 'cyber' realm today, except for perhaps the issue of misspellings. As a community, we've gotten to a point where misspellings and issues with grammar are accepted as the norm.
Getting Started
We all start someplace. I started down the road of computer-based information security while I was in graduate school. As I've mentioned before, I was in grad school at a very interesting time for the computer industry. Not only was I attending school on the outskirts of Silicon Valley, but new versions of operating systems were coming out (Windows 95, Windows NT, OS/2 Warp, etc.), and some network security tools (SATAN) were just being developed and released. After finishing my degree program, I took a class in Java programming out of SJSU, in which the professor spent a lot of time talking about "shippable places". This is all to say that there was a lot going on in the industry at the time, and a lot of different paths one could follow.
All in all, these were very interesting times, and I was in an very interesting place. Things were no more or less interesting than they are now, just different. I was transitioning from military to civilian life, and needed to find "my place", and like many who are just coming into the industry, there was a LOT out there! So much so, it could be very overwhelming. All of this is to simply say, I get it. Been there. My recommendation to you, if you're new to the field, is to not overwhelm yourself. Being overwhelmed is self-inflicted; don't do that to yourself. Yes, there is a lot to learn, but you don't have to know all of it now. And you're never going to know all of it. No one does.
Pick an area of interest, and learn about it. At the very least, you may decide, "meh, this isn't for me." And you know what? That's great. That's okay. That's freakin' awesome! Don't do something you don't enjoy. That's the great thing about this industry - there are so many things out there, like hard, technical skills, soft skills, etc., that there's something for everyone. You can be the best technical writer, the best policy analyst, or the best malware reverse engineer you can be. You can be a great pen tester, or you can opt for the 'blue' side, in DFIR. Within each of those broad areas, you can further specialize. But the point is, don't try to boil the ocean.
Be a good generalist, but also specialize in something. Become good at something. Then become good at something else. But also understand, you don't have to be great at everything. Understand that, deep in your bones. Know it. Because you're going to run into "gatekeepers" in this field (just as you will in any other field) who are going to tell you that in order to be a success, you have to model yourself after them. Not true. In fact, some of those folks who demand that you be great at everything have some pretty major holes in their own armor.
One of the things I've done is look to an area that doesn’t already have a great deal of attention. For example, when I was a kid, I played soccer. At the time, everyone wanted to be a forward...forwards scored goals and got all the glory. No one wanted to be a defender, a fullback, the last line of defense before the goal keeper. But instead of competing for a forward slot, I ended up getting pretty good at being a defender. Jump forward 20-odd years, and I was working in a shop with half a dozen folks who all swore that Linux was the only true operating system in existence, and no one was taking a good hard look at Windows from the perspective of performing vulnerability assessments. And yet, all of our customers had infrastructures that consisted of mostly Windows systems. So, I started digging into Windows systems, with the goal of understanding how to not only determine the point-in-time state of the system, but also how to look across all systems and determine the state of processes and procedures for that environment. Along the way, I ran across this fascinating thing called the "Registry", and the more I dug into it, the more I learned that I didn't know. Further, the more I dug into the Registry, the more I learned that few, if any, other analysts were really interested in the Registry. In those early days, when I would take a break from learning about the Registry and talk to others, I'd learn that most acknowledged that it existed, and some even knew something about it.
Just because I've written two books on the Windows Registry doesn't make me an "expert". Nor has it led to me being sought out, nor recruited, as an expert. But you know what? I enjoy digging into the Registry, seeing what's there, and then looking to see how user and adversary behaviors are reflected in the Registry.
A great way to see how far you've come in a learning something is to put together a presentation, and teach what you know to others. This can be as simply as a "lunch-and-learn" brown bag training session for your team, even done remotely. This can really help you put your thoughts in order, and as you're developing the presentation, maybe even see gaps in your knowledge and understanding. Start with what academics call a "literature search"...see what else is already out there. If you don't have something ground-breaking or earth-shattering, don't worry about it...we all don't know everything, and it's more than likely that most of what you're going to present is going to be beneficial to others, anyway.
Speaking of presenting, Brett Shavers recently published a really good article covering the three most common fears folks encounter when speaking in DFIR. Not only does my own experience show that Brett's right, but by putting a name to the fears, we call them out of the shadows and into the light where we can address and overcome them.
The Most Important Thing
The most important thing in the industry is you. Self-care is critically important in this industry. There will be a good deal of stress placed on you; some, or most of it may be self-inflicted. You need to ensure that your physical, emotional/mental, and spiritual needs are met.
As an incident responder and consultant, there were times when I was flying out to some remote location. I didn't always have control of when that would occur; many times, a customer would call for immediate response on the West Coast after I'd already put in a full day's work. This meant that I would get rest as I needed it, stay hydrated, eat healthy (something you can't always do on the road), and be sure to take vitamin supplements, as needed. To this day, I like to keep Airborne on hand, and will be more focused on taking it when I know I'm traveling.
From an emotional perspective, put the time in to learn about and understand yourself. Understand what works for you and what doesn't.
I've taken the Myers-Briggs Type Indicator test a lot over the years. It started when I was on active duty, and the whole time I've been a very strong ISTJ, and I haven't really deviated from that over the years. What does that mean? Well, as an "introvert", I recognize how engaging with crowds or large groups of people affect me. I can go to a conference, engage and participate, but at some point, I'm going to need some "me time". This can be as simple as getting away for a few minutes, taking a nap, or getting some exercise. I know that when I do this, I can return refreshed and ready to engage again, rather than be exhausted, sullen, and moody. People recognize when everything about your body languages says, "I just want to get out of here". When I've been to multi-day user conferences, try to plan for down time, so I can recharge.
A great book to read, for anyone, is Chapman's The Five Love Languages. Reading this book and thoughtfully applying the content to ourselves is a great way to begin, or continue, developing self-awareness. This book applies to relationships, and not just relationships with a spouse or better half, but any relationship. You can apply what you learn from this book to your kids, family members, friends, and it will even apply when you're doing incident response. For example, different customers will respond in different ways; some will get a sense of your credibility because they see you doing things, but others may react better to direct, concise verbal reports, or to you just spending the time to listen to them.
Further develop self-awareness by studying emotional intelligence. Understand your "triggers", learn to recognize those internal forces that cause you to react or feel a certain way, and do this before responding. Develop an understanding of why you react the way you do, before you respond. If someone says something to you, verbally, via email or Twitter, etc., what is it that causes you to react the way you do? Is your reaction negative or positive? Remember, not everyone has the same perspective you do, and someone who's responding to you, especially online, is going to be in a place that you can't see and may not understand. So, look at your reactions before responding.
Develop A Network
No one of us knows everything. I know, I know...that's not easy to hear. It's easy for us to sit back and assume that someone else knows everything, and then use that as an excuse to not engage with them. This means that we miss an opportunity to develop our network. The reason for this is that there is no one person that knows everything or has seen everything in this industry, and sometimes, just seeing a different perspective, even seeing the same thing but from a different point of view, can be very enlightening.
Developing a network goes far beyond clicking "Like", or "RT". Or even beyond clicking both "Like" and "RT". It goes well beyond just sending someone a connection request, and then doing absolutely nothing beyond that. Developing a meaningful network requires effort, not only in reaching out to others, but also responding when others reach out.
Stories abound of people not getting jobs through the traditional application submission process, but finding a great job via their network. This happens because those people put in the effort to build their network. They reached out to others, and responded when others reached out.
When you are engaged in developing a meaningful network, whether online or in-person/IRL, there are some of things you can do to make things work for you.
First, Be Present. Nothing says you're simply not interested in the other person more than being distracted and somewhere else mentally. If you're going to attend a social function, a conference presentation or a meeting, and if you absolutely cannot be away from your phone and your email, don't go. Reschedule. Send someone else.
What does not being present look like? Someone goes to a conference, one for which all of the speakers had to send in their slide decks for inclusion on the conference DVD or at the conference web site. I've been to conferences where the schedule and all of the presentations were available on a smartphone app, so any attendee could access them at any time, and didn't have to be sure to download them prior to the conference. Then at the beginning of the presentation, the speaker states, "...these slides are available on the conference ...". However, by the end of the presentation, someone still asks if and where the slides will be available.
USMC Gen. John Allen has been in the news recently, and I associated with him back when he was a Major, and we were both stationed at The Basic School (he commanded the Infantry Officers Course). One of the things he'd have his instructors do is ask leading questions before a class, and if the student officers were not "present", they would reschedule the class for a less convenient time.
Being Present leads to Ask Good Questions. If you're read a blog post, an article, or just attended a conference presentation or webinar, be sure to ask questions relevant to the topic. If someone puts forth the effort to develop a conference presentation or article about something they did, maybe it's best to leave the "...did you also do these other things..." questions for another time, or medium. Don't subvert or abscond with the context, using it as an opportunity for your own agenda. If you have a question about something ancillary to the topic, be sure to ask, but do so in a manner and at a time when doing so doesn't derail the conversation.
Learn to Communicate, in both written and verbal form. None of us are born with the innate ability to clearly and concisely communicate, it's something we learn over time, through experience and with feedback. I have had experience writing, in various forms (reports, performance reviews, etc.), throughout my career, and I still had to work through understanding my boss's preferred writing style...what they preferred to see with respect to format and content in reports...at various jobs. Very few of us are just inherently good communicators, and most of us need to work at it. A little bit of effort in this area will go a long way.
Think about it. Say you're a DFIR analyst or technical threat hunter. Now, you have to clearly and concisely communicate your findings and their impact to a customer, someone who's not as technical as you are, and someone who has a different perspective and an entirely different set of concerns than you. This is also someone who's looking to you, as the 'expert', to communicate with them in a means that they can understand. This means that you can't communicate to them as you would your peers.
Seek Feedback. I found this to be highly effective when working high-stress IR engagements (I know what you're thinking, "...aren't they all??"). By finding the appropriate time to ask my point of contact, "how're we doing?" or "how're things going at this point?", I'd get valuable information about their expectations and perspective. From that feedback, I could then compartmentalize those things that I needed to address immediately, and those things I needed push up to my manager immediately.
This isn't limited to customers. As an analyst, seek feedback from your peers and your manager, and if you're a manager, seek feedback from your subordinates. Create a culture where it's easy to do this, without fear that it will be "used against" someone, but will instead be used to make everyone better analysts, better teammates, and stronger peers.
When it comes to your network, and making it stronger, Stop Assuming. What is one of the assumptions I hear from people? "I assumed you were too busy to answer my email." Nothing is further from the truth. I know that some people where "busy" like a badge of honor, so I get it. But that's not me. Yes, I have reached out to people, via what I thought was their preferred medium (i.e., email, Twitter, etc.) and not received so much as an acknowledgement. But so what? I have no idea what's going on in their life. The simple fact is that I've always tried to respond in a timely manner, even if it's just a "hey, I got your email and I'll take the time here soon to give it the attention it deserves". Don't let the assumption that "...they're too busy..." be your self-inflicted excuse for not asking someone a question.
There are other assumptions I hear, but the point is, you can assume something and limit yourself through a self-imposed obstacle, or you can just ask.
Finally
The last thing is to keep the "3 Foot World" principle in mind. You can only directly affect those things within three feet of you, within arm's reach. I got this principle from reading a first-person account by a member of SEAL Team 6, as he was recounting going through specialized training in rock climbing. The thing is, it applies to life equally well. We have to understand that the only thing that we can control is ourselves...how we respond to things...and the only things that we can directly impact are those things within our 3 Foot World.
What does this mean? Well, when I was doing incident response on a regular basis, I realized early on that these events are stressful for everyone involved. However, I cannot control when an adversary is going to suddenly become visible to a customer, and I cannot control how the customer is going to respond. However, what I could control was my own "3 Foot World", and I did that by developing a process to be prepared for those calls for immediate response that invariably came in at 10:45pm on a Friday.
Before GPS was readily available, I'd get the address of where I was going in relation to the closest airport, and print out 3 different levels or "views", to have with me. That way, I knew how to get where I was going once I was on the ground. Once GPS devices got to a point where they were affordable, one of those went into my carry-on bag. Copies of all imaging documentation, along with any other important templates, went into both my carry-on bag and my checked Pelican case. I had a hard copy of all important phone numbers (my boss, the customer, etc.), in case all I was left with was a credit card, or just a quarter, to make a phone call (i.e., "my cell phone died" was no excuse).
Everything that went into my carry-on bag went into the same place. The same was true for my Pelican case...everything went into the same place, and got repacked in the same place when the engagement was complete. Tableau imagers, laptops, cables, documentation...everything went into the same place. Also, when there was time, priority was placed on ensuring that software was updated between engagements. Did I have the latest copies of commercial tools, were my processes up-to-date?
The purpose of all of this was to provide the best service I could to a customer, given that I'm going to be engaging with them during a really stressful time, very likely when they were exhausted, as well as when emotions were running high. Showing up on-time and prepared may seem like a little thing, but when you're meeting with someone for the first time and they've been pulling 20+ hr days for 10 consecutive days, and the first thing out of your mouth is, "Sorry I'm late..." or "...I forgot this very important item that I need to do my job..."...needless to say, that does not make for a good first impression.
Recognize the "3 Foot World" principle, and apply it.
Instead of crumbling the notes up and deleting the Word docs, I thought it might be a good idea to get the notes written out into some semblance of a presentation, and blog post was as good a place to start as any. Also, this gives me the opportunity to put something down in writing and edit it, hopefully making it into something that makes a bit of sense before publishing it.
A little bit about myself to provide some context; I started in "information security" about 30 years ago. If I had to tie my time in the field back to a single point in time, my first real introduction to 'security' came in my initial military training. This training didn't involve computers, but had to do with information security overall. A lot of the training involved terrorism awareness (i.e., unusually heavy or dense packages, misspelled names or addresses, stains on packages, etc.), cryptographic equipment, communications security, authentication, etc. All of this maps directly to the 'cyber' realm today, except for perhaps the issue of misspellings. As a community, we've gotten to a point where misspellings and issues with grammar are accepted as the norm.
Getting Started
We all start someplace. I started down the road of computer-based information security while I was in graduate school. As I've mentioned before, I was in grad school at a very interesting time for the computer industry. Not only was I attending school on the outskirts of Silicon Valley, but new versions of operating systems were coming out (Windows 95, Windows NT, OS/2 Warp, etc.), and some network security tools (SATAN) were just being developed and released. After finishing my degree program, I took a class in Java programming out of SJSU, in which the professor spent a lot of time talking about "shippable places". This is all to say that there was a lot going on in the industry at the time, and a lot of different paths one could follow.
All in all, these were very interesting times, and I was in an very interesting place. Things were no more or less interesting than they are now, just different. I was transitioning from military to civilian life, and needed to find "my place", and like many who are just coming into the industry, there was a LOT out there! So much so, it could be very overwhelming. All of this is to simply say, I get it. Been there. My recommendation to you, if you're new to the field, is to not overwhelm yourself. Being overwhelmed is self-inflicted; don't do that to yourself. Yes, there is a lot to learn, but you don't have to know all of it now. And you're never going to know all of it. No one does.
Pick an area of interest, and learn about it. At the very least, you may decide, "meh, this isn't for me." And you know what? That's great. That's okay. That's freakin' awesome! Don't do something you don't enjoy. That's the great thing about this industry - there are so many things out there, like hard, technical skills, soft skills, etc., that there's something for everyone. You can be the best technical writer, the best policy analyst, or the best malware reverse engineer you can be. You can be a great pen tester, or you can opt for the 'blue' side, in DFIR. Within each of those broad areas, you can further specialize. But the point is, don't try to boil the ocean.
Be a good generalist, but also specialize in something. Become good at something. Then become good at something else. But also understand, you don't have to be great at everything. Understand that, deep in your bones. Know it. Because you're going to run into "gatekeepers" in this field (just as you will in any other field) who are going to tell you that in order to be a success, you have to model yourself after them. Not true. In fact, some of those folks who demand that you be great at everything have some pretty major holes in their own armor.
One of the things I've done is look to an area that doesn’t already have a great deal of attention. For example, when I was a kid, I played soccer. At the time, everyone wanted to be a forward...forwards scored goals and got all the glory. No one wanted to be a defender, a fullback, the last line of defense before the goal keeper. But instead of competing for a forward slot, I ended up getting pretty good at being a defender. Jump forward 20-odd years, and I was working in a shop with half a dozen folks who all swore that Linux was the only true operating system in existence, and no one was taking a good hard look at Windows from the perspective of performing vulnerability assessments. And yet, all of our customers had infrastructures that consisted of mostly Windows systems. So, I started digging into Windows systems, with the goal of understanding how to not only determine the point-in-time state of the system, but also how to look across all systems and determine the state of processes and procedures for that environment. Along the way, I ran across this fascinating thing called the "Registry", and the more I dug into it, the more I learned that I didn't know. Further, the more I dug into the Registry, the more I learned that few, if any, other analysts were really interested in the Registry. In those early days, when I would take a break from learning about the Registry and talk to others, I'd learn that most acknowledged that it existed, and some even knew something about it.
Just because I've written two books on the Windows Registry doesn't make me an "expert". Nor has it led to me being sought out, nor recruited, as an expert. But you know what? I enjoy digging into the Registry, seeing what's there, and then looking to see how user and adversary behaviors are reflected in the Registry.
A great way to see how far you've come in a learning something is to put together a presentation, and teach what you know to others. This can be as simply as a "lunch-and-learn" brown bag training session for your team, even done remotely. This can really help you put your thoughts in order, and as you're developing the presentation, maybe even see gaps in your knowledge and understanding. Start with what academics call a "literature search"...see what else is already out there. If you don't have something ground-breaking or earth-shattering, don't worry about it...we all don't know everything, and it's more than likely that most of what you're going to present is going to be beneficial to others, anyway.
Speaking of presenting, Brett Shavers recently published a really good article covering the three most common fears folks encounter when speaking in DFIR. Not only does my own experience show that Brett's right, but by putting a name to the fears, we call them out of the shadows and into the light where we can address and overcome them.
The Most Important Thing
The most important thing in the industry is you. Self-care is critically important in this industry. There will be a good deal of stress placed on you; some, or most of it may be self-inflicted. You need to ensure that your physical, emotional/mental, and spiritual needs are met.
As an incident responder and consultant, there were times when I was flying out to some remote location. I didn't always have control of when that would occur; many times, a customer would call for immediate response on the West Coast after I'd already put in a full day's work. This meant that I would get rest as I needed it, stay hydrated, eat healthy (something you can't always do on the road), and be sure to take vitamin supplements, as needed. To this day, I like to keep Airborne on hand, and will be more focused on taking it when I know I'm traveling.
From an emotional perspective, put the time in to learn about and understand yourself. Understand what works for you and what doesn't.
I've taken the Myers-Briggs Type Indicator test a lot over the years. It started when I was on active duty, and the whole time I've been a very strong ISTJ, and I haven't really deviated from that over the years. What does that mean? Well, as an "introvert", I recognize how engaging with crowds or large groups of people affect me. I can go to a conference, engage and participate, but at some point, I'm going to need some "me time". This can be as simple as getting away for a few minutes, taking a nap, or getting some exercise. I know that when I do this, I can return refreshed and ready to engage again, rather than be exhausted, sullen, and moody. People recognize when everything about your body languages says, "I just want to get out of here". When I've been to multi-day user conferences, try to plan for down time, so I can recharge.
A great book to read, for anyone, is Chapman's The Five Love Languages. Reading this book and thoughtfully applying the content to ourselves is a great way to begin, or continue, developing self-awareness. This book applies to relationships, and not just relationships with a spouse or better half, but any relationship. You can apply what you learn from this book to your kids, family members, friends, and it will even apply when you're doing incident response. For example, different customers will respond in different ways; some will get a sense of your credibility because they see you doing things, but others may react better to direct, concise verbal reports, or to you just spending the time to listen to them.
Further develop self-awareness by studying emotional intelligence. Understand your "triggers", learn to recognize those internal forces that cause you to react or feel a certain way, and do this before responding. Develop an understanding of why you react the way you do, before you respond. If someone says something to you, verbally, via email or Twitter, etc., what is it that causes you to react the way you do? Is your reaction negative or positive? Remember, not everyone has the same perspective you do, and someone who's responding to you, especially online, is going to be in a place that you can't see and may not understand. So, look at your reactions before responding.
Develop A Network
No one of us knows everything. I know, I know...that's not easy to hear. It's easy for us to sit back and assume that someone else knows everything, and then use that as an excuse to not engage with them. This means that we miss an opportunity to develop our network. The reason for this is that there is no one person that knows everything or has seen everything in this industry, and sometimes, just seeing a different perspective, even seeing the same thing but from a different point of view, can be very enlightening.
Developing a network goes far beyond clicking "Like", or "RT". Or even beyond clicking both "Like" and "RT". It goes well beyond just sending someone a connection request, and then doing absolutely nothing beyond that. Developing a meaningful network requires effort, not only in reaching out to others, but also responding when others reach out.
Stories abound of people not getting jobs through the traditional application submission process, but finding a great job via their network. This happens because those people put in the effort to build their network. They reached out to others, and responded when others reached out.
When you are engaged in developing a meaningful network, whether online or in-person/IRL, there are some of things you can do to make things work for you.
First, Be Present. Nothing says you're simply not interested in the other person more than being distracted and somewhere else mentally. If you're going to attend a social function, a conference presentation or a meeting, and if you absolutely cannot be away from your phone and your email, don't go. Reschedule. Send someone else.
What does not being present look like? Someone goes to a conference, one for which all of the speakers had to send in their slide decks for inclusion on the conference DVD or at the conference web site. I've been to conferences where the schedule and all of the presentations were available on a smartphone app, so any attendee could access them at any time, and didn't have to be sure to download them prior to the conference. Then at the beginning of the presentation, the speaker states, "...these slides are available on the conference ...". However, by the end of the presentation, someone still asks if and where the slides will be available.
USMC Gen. John Allen has been in the news recently, and I associated with him back when he was a Major, and we were both stationed at The Basic School (he commanded the Infantry Officers Course). One of the things he'd have his instructors do is ask leading questions before a class, and if the student officers were not "present", they would reschedule the class for a less convenient time.
Being Present leads to Ask Good Questions. If you're read a blog post, an article, or just attended a conference presentation or webinar, be sure to ask questions relevant to the topic. If someone puts forth the effort to develop a conference presentation or article about something they did, maybe it's best to leave the "...did you also do these other things..." questions for another time, or medium. Don't subvert or abscond with the context, using it as an opportunity for your own agenda. If you have a question about something ancillary to the topic, be sure to ask, but do so in a manner and at a time when doing so doesn't derail the conversation.
Learn to Communicate, in both written and verbal form. None of us are born with the innate ability to clearly and concisely communicate, it's something we learn over time, through experience and with feedback. I have had experience writing, in various forms (reports, performance reviews, etc.), throughout my career, and I still had to work through understanding my boss's preferred writing style...what they preferred to see with respect to format and content in reports...at various jobs. Very few of us are just inherently good communicators, and most of us need to work at it. A little bit of effort in this area will go a long way.
Think about it. Say you're a DFIR analyst or technical threat hunter. Now, you have to clearly and concisely communicate your findings and their impact to a customer, someone who's not as technical as you are, and someone who has a different perspective and an entirely different set of concerns than you. This is also someone who's looking to you, as the 'expert', to communicate with them in a means that they can understand. This means that you can't communicate to them as you would your peers.
Seek Feedback. I found this to be highly effective when working high-stress IR engagements (I know what you're thinking, "...aren't they all??"). By finding the appropriate time to ask my point of contact, "how're we doing?" or "how're things going at this point?", I'd get valuable information about their expectations and perspective. From that feedback, I could then compartmentalize those things that I needed to address immediately, and those things I needed push up to my manager immediately.
This isn't limited to customers. As an analyst, seek feedback from your peers and your manager, and if you're a manager, seek feedback from your subordinates. Create a culture where it's easy to do this, without fear that it will be "used against" someone, but will instead be used to make everyone better analysts, better teammates, and stronger peers.
When it comes to your network, and making it stronger, Stop Assuming. What is one of the assumptions I hear from people? "I assumed you were too busy to answer my email." Nothing is further from the truth. I know that some people where "busy" like a badge of honor, so I get it. But that's not me. Yes, I have reached out to people, via what I thought was their preferred medium (i.e., email, Twitter, etc.) and not received so much as an acknowledgement. But so what? I have no idea what's going on in their life. The simple fact is that I've always tried to respond in a timely manner, even if it's just a "hey, I got your email and I'll take the time here soon to give it the attention it deserves". Don't let the assumption that "...they're too busy..." be your self-inflicted excuse for not asking someone a question.
There are other assumptions I hear, but the point is, you can assume something and limit yourself through a self-imposed obstacle, or you can just ask.
Finally
The last thing is to keep the "3 Foot World" principle in mind. You can only directly affect those things within three feet of you, within arm's reach. I got this principle from reading a first-person account by a member of SEAL Team 6, as he was recounting going through specialized training in rock climbing. The thing is, it applies to life equally well. We have to understand that the only thing that we can control is ourselves...how we respond to things...and the only things that we can directly impact are those things within our 3 Foot World.
What does this mean? Well, when I was doing incident response on a regular basis, I realized early on that these events are stressful for everyone involved. However, I cannot control when an adversary is going to suddenly become visible to a customer, and I cannot control how the customer is going to respond. However, what I could control was my own "3 Foot World", and I did that by developing a process to be prepared for those calls for immediate response that invariably came in at 10:45pm on a Friday.
Before GPS was readily available, I'd get the address of where I was going in relation to the closest airport, and print out 3 different levels or "views", to have with me. That way, I knew how to get where I was going once I was on the ground. Once GPS devices got to a point where they were affordable, one of those went into my carry-on bag. Copies of all imaging documentation, along with any other important templates, went into both my carry-on bag and my checked Pelican case. I had a hard copy of all important phone numbers (my boss, the customer, etc.), in case all I was left with was a credit card, or just a quarter, to make a phone call (i.e., "my cell phone died" was no excuse).
Everything that went into my carry-on bag went into the same place. The same was true for my Pelican case...everything went into the same place, and got repacked in the same place when the engagement was complete. Tableau imagers, laptops, cables, documentation...everything went into the same place. Also, when there was time, priority was placed on ensuring that software was updated between engagements. Did I have the latest copies of commercial tools, were my processes up-to-date?
The purpose of all of this was to provide the best service I could to a customer, given that I'm going to be engaging with them during a really stressful time, very likely when they were exhausted, as well as when emotions were running high. Showing up on-time and prepared may seem like a little thing, but when you're meeting with someone for the first time and they've been pulling 20+ hr days for 10 consecutive days, and the first thing out of your mouth is, "Sorry I'm late..." or "...I forgot this very important item that I need to do my job..."...needless to say, that does not make for a good first impression.
Recognize the "3 Foot World" principle, and apply it.
EvtxECmd
Eric Zimmerman recently released EvtxECmd, a nifty Windows Event Log file parser that bypasses the Windows API. There are a lot of advantages to a tool such as this; specifically, by bypassing the API, it doesn't succumb to the 'hiccups' that may occur as a result of files that weren't closed properly, or for some other reason, isn't formatted in a manner the API agrees with. This is something I've seen with LogParser, as it uses the Windows API, and will fail to parse a file if there's something 'amiss'.
Using data from the Lone Wolf Scenario, I extracted some (not all) of the Windows Event Log files from the image, and used the following command line to run EvtxECmd against this subset of data:
evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv
Not only was the output file generated, but a lot of data flew by in the command prompt while the command was processing. I thought that this might be useful information, so I deleted the output file and re-ran the command:
evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv > F:\lonewolf\data\evtx\evtxecmd_trace.txt
Once the command prompt returned, I had the output file, as well as the 'trace' file that contained all of the information provided via the prompt. A good deal of it was very useful, such as metrics based on the event IDs (albeit without the event sources, or some other unique identifier) and the count of said event IDs found in that log file. This can be very useful information, and as such, I'd recommend collecting it as part of your investigative process, and keeping it alongside your case notes.
As to the output of the command, the output file contained 31,956 entries; by comparison, Logparser (run via wevtx.bat) threw an error about not being able to open a file (it didn't specify which one), and produced output with 24,770 entries. Clearly, incorporating EvtxECmd into your investigative process will provide a more complete view of the available data, from a total number of events perspective.
However, let's look at some differences in the actual output. I've always been fascinated by the use of BITS for downloading (and uploading) files. As there are a number of BITS Client events available, let's look at a simple event, such as event ID 3.
The output from wevtx.bat, using Logparser, looks like this (i.e., TLN format):
1522194038|EVTX|DESKTOP-PM6C56D||Microsoft-Windows-Bits-Client/3;C:\Users\jcloudy\AppData\Local\Temp\{33340A58-DC7C-4FBB-82A9-24EFA8F8C38D}-gsync64.msi,{50A0E739-31CE-4B89-8972-DE76CC505D31},DESKTOP-PM6C56D\jcloudy,C:\Program Files (x86)\Google\Update\GoogleUpdate.exe,9004
The output directly from EvtxECmd for a similar event record looks like this:
279,279,2018-03-30 21:09:16.6870673,3,4,Microsoft-Windows-Bits-Client,Microsoft-Windows-Bits-Client/Operational,3636,11240,DESKTOP-PM6C56D,S-1-5-18,,,,,,,,,,,F:\lonewolf\data\evtx\Microsoft-Windows-Bits-Client%4Operational.evtx
In the case of the EvtxECmd output, there seems to be some important information missing. Talking to Eric about this, he said that in order to get the additional details (i.e., strings, event description) in the CSV output, you need to have a map file for the event.
So, there you go. Once the appropriate map files are in place and the event description available as part of the output, given the header of the output file, it will be relatively easy to write a script that will translate the output of the tool into something easily incorporated directly into a timeline, for direct inclusion into an analysis process.
For your analysis process, Eric includes map files (read Eric's info for more detail...)...when I ran the tool, there were 52 map files available. Eric provides a description of how to create your own map files.
A note on using Eric's CLI tools: whenever I install a system, one of my first configuration steps is to modify the command prompt to a white background with black letters. This makes things much easier for screen captures, particularly for books and presentations. When running Eric's CLI tools for the first time, I'll get a lot of blank lines in the output, and highlighting or selecting the contents of the screen does not reveal the underlying text. I reached to Eric and he said that I needed to get the nlog.config file from his site, and include it in the directory with each of the command line tools. I simply created a folder for Eric's tools, and put one copy of the file alongside all of the other tools.
Resources
Link to EvtxECmd Maps
Using data from the Lone Wolf Scenario, I extracted some (not all) of the Windows Event Log files from the image, and used the following command line to run EvtxECmd against this subset of data:
evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv
Not only was the output file generated, but a lot of data flew by in the command prompt while the command was processing. I thought that this might be useful information, so I deleted the output file and re-ran the command:
evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv > F:\lonewolf\data\evtx\evtxecmd_trace.txt
Once the command prompt returned, I had the output file, as well as the 'trace' file that contained all of the information provided via the prompt. A good deal of it was very useful, such as metrics based on the event IDs (albeit without the event sources, or some other unique identifier) and the count of said event IDs found in that log file. This can be very useful information, and as such, I'd recommend collecting it as part of your investigative process, and keeping it alongside your case notes.
As to the output of the command, the output file contained 31,956 entries; by comparison, Logparser (run via wevtx.bat) threw an error about not being able to open a file (it didn't specify which one), and produced output with 24,770 entries. Clearly, incorporating EvtxECmd into your investigative process will provide a more complete view of the available data, from a total number of events perspective.
However, let's look at some differences in the actual output. I've always been fascinated by the use of BITS for downloading (and uploading) files. As there are a number of BITS Client events available, let's look at a simple event, such as event ID 3.
The output from wevtx.bat, using Logparser, looks like this (i.e., TLN format):
1522194038|EVTX|DESKTOP-PM6C56D||Microsoft-Windows-Bits-Client/3;C:\Users\jcloudy\AppData\Local\Temp\{33340A58-DC7C-4FBB-82A9-24EFA8F8C38D}-gsync64.msi,{50A0E739-31CE-4B89-8972-DE76CC505D31},DESKTOP-PM6C56D\jcloudy,C:\Program Files (x86)\Google\Update\GoogleUpdate.exe,9004
The output directly from EvtxECmd for a similar event record looks like this:
279,279,2018-03-30 21:09:16.6870673,3,4,Microsoft-Windows-Bits-Client,Microsoft-Windows-Bits-Client/Operational,3636,11240,DESKTOP-PM6C56D,S-1-5-18,,,,,,,,,,,F:\lonewolf\data\evtx\Microsoft-Windows-Bits-Client%4Operational.evtx
In the case of the EvtxECmd output, there seems to be some important information missing. Talking to Eric about this, he said that in order to get the additional details (i.e., strings, event description) in the CSV output, you need to have a map file for the event.
So, there you go. Once the appropriate map files are in place and the event description available as part of the output, given the header of the output file, it will be relatively easy to write a script that will translate the output of the tool into something easily incorporated directly into a timeline, for direct inclusion into an analysis process.
For your analysis process, Eric includes map files (read Eric's info for more detail...)...when I ran the tool, there were 52 map files available. Eric provides a description of how to create your own map files.
A note on using Eric's CLI tools: whenever I install a system, one of my first configuration steps is to modify the command prompt to a white background with black letters. This makes things much easier for screen captures, particularly for books and presentations. When running Eric's CLI tools for the first time, I'll get a lot of blank lines in the output, and highlighting or selecting the contents of the screen does not reveal the underlying text. I reached to Eric and he said that I needed to get the nlog.config file from his site, and include it in the directory with each of the command line tools. I simply created a folder for Eric's tools, and put one copy of the file alongside all of the other tools.
Resources
Link to EvtxECmd Maps
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- …
- 398
- Next Page »