I blogged about getting started in the industry back in April (as well as here and here), and after having recently addressed the question on an online forum again, I thought I'd take things a step further. Everyone has their own opinion as to the best way to 'get started' in the industry, and if you look wide enough and far enough, you'll start to see how those who post well thought out articles have some elements in common.
In the beginning...
We all start learning through imitation and repetition, because that's how we are taught. Here's the process, follow the process. This is true in civilian life, and it's even more true in the military. You're given some information as to the "why", and then you're given the "how". You do the "how", and you keep doing the "how" until you're getting the "how" right. Once you've gotten along for a bit with the "how", you start going back to the "why", and sometimes you find out that based on the "why", the "how" that you were taught is pretty darned good. Based on a detailed understanding of the "why", the "how" was painstakingly developed over time, and it's just about the best means for addressing the "why".
In other cases, some will start to explore doing the "how" better, or different, questioning the "why". What are the base assumptions of the "why", and have they changed? How has the "why" changed since it was first developed, and does that affect the "how"?
This is where critical thinking comes into play. Why am I using this tool or following this process? What are my base assumptions? What are my goals, and how does the tool or process help me achieve those goals? The worst thing you could ever do is justify following a process with the phrase, "...because this is how we've always done it." That statement clearly shows that neither the "why" nor the "how" is understood, and you're just going through the motions.
Years ago, when I had the honor and the pleasure of working with Don Weber, he would regularly ask me "why"...why were we doing something and why were we doing it this way? This got me to consider a lot about the decisions I was making and the actions I was taking as a team leader or lead responder, and I often found that my decisions were based not just on the technical aspects of what we were doing, but also the business aspects and the impact to the client. I did not take offense at Don's questions, and actually appreciated them.
Learn to program
Lots of folks say it's important to learn a programming language, and some even go so far as to specify the particular language. Thirty-five years ago, I started learning BASIC, programming on an Apple IIe. Later, it was PASCAL, then MatLab and Java, and then Perl. Now it seems that Python is the "de facto standard" for DFIR work...or is it? Not long before NotPetya rocked the world, the folks at RawSec posted an article regarding carving EVTX records, and released a tool written in Go. If you're working on Windows systems or in a Windows environment, PowerShell might be your programming language of choice...it all depends on what you want to do.
There is a great deal of diversity on this topic, and I'd suggest that the programming language you choose should be based on your needs. The main point is that learning to program helps you see big problems as a series of smaller problems, some of which must performed in a serial fashion. What we learn from programming is how to break bigger problems into smaller, logical steps.
Engage in the community
Within the DFIR "community", there's too much "liking" and retweeting, and not enough doing and asking of questions, nor actively engaging with others. Not long ago, James Habben posted an excellent article on his blog on "being present", and he made a lot of important points that we can all learn from. Further, he put a name to something that I've been aware of for some time; when presenting at a conference, there's often that one person how completely forgets that they're in a room full of other people, and kidnaps and dominates the presenter's time. There are also those who attend the presentation (or training session) who spend the majority of their time engaged in something else entirely.
Rafal Los recently posted a fascinating article on the SecurityWeek web site. I found his article well-considered and insightful, and extremely relevant. It's also something I can relate to...like others, I get connection requests on LinkedIn from folks who've done nothing more than clicked a button. I also find that after having accepted most connection requests, I never hear from the requester again. I find that if I write a blog post (like this one) and share the link on Twitter and LinkedIn, I'll get "likes" and retweets, but not much in the way of comments. If I ask someone what they "like" about the article...and I have done this...more often than not the response is that they didn't actually read it; they wanted to share it with their community. Given that, there is no difference between having worked on writing and publishing the article, and not having done so.
Engaging in the community is not only a great way to learn, but also a great way to extend the community itself. A friend recently asked me which sandbox I use for malware analysis, and why. For me to develop a response beyond just, "I don't", I really had to think about the reasons why I don't use a sandbox. I learned a little something from the engagement, just as I hope my friend did, as well.
An extension of engaging in the community is to write your own stuff. Share your thoughts. Instead of clicking "like" on a link to a blog post, add a comment to the post, or ask a question in the comments. Instead of just clicking "like" or retweeting, share your reasons for doing so. If it takes more than 140 characters to do so, write a blog post or comment, and share *that*.
I guess the overall point is this...if you're going to ask the question, "how do I get started in the DFIR industry?", the question itself presupposes some sort of action. If you're just going to follow others, "like" and retweet all the things, and not actually read, engage, and think critically, then you're not really going to 'get started'.
For me, the best part which I totally agree with you is about "Questioning". Maybe because I learned myself by questioning most of the things if not everything, and maybe because I truly believe it's the difference between someone whom knows what he/she is doing, and between someone whom just knows how to do it. I always tell my students not to blindly take what they learn even though they believe the person in front of them is an expert or whatever. Maybe at that specific time I lost concentration and said something let's say not 100% wrong, but something that was not totally true (partially wrong), maybe there is a better way too. Why stick to the way you learned from me only, go find your own way, use it and discover yourself whether it works or not.
Tools, tools, tools, lots believe it's the tool that makes you good or even great, and I like you don't believe in that. What good is a Ferrari, if I'm no good driver? What good is the fanciest toolbox, if I don't know how to use it? The same for computers, and especially DFIR. What good is using a tool if I don't know why it does it retrieves shows me the data that way? Why should I believe it; just because it was developed by company XYZ, and XYZ has a huge reputation in the industry, doesn't mean I must blindly use it and not question it. Tools are tools, we use them to speed up the process and make things much quicker and faster, but it is the Human Intelligence part that is important too. Most of the time during my teaching especially Infosec related courses at the start I get negative feedback from attendees, they want to see using this tool and that, but I try before that to stay focused on the "WHY" and idea behind the technology or part of process I'm explaining is much more important. I totally believe if we manage to understand the path and idea, then the tool could be easily and accurately selected. "Hope I managed to express my ideas here... :)"
The part were I don't agree with you, is your questioning of people that do "Likes and Re-Tweets" without engaging. Not engaging with the article/post does not mean they didn't read it, but maybe have no addition, didn't have time or maybe didn't like to engage :)
Or the another issue, is maybe they are shy of sharing their thoughts and afraid that what they share is wrong! I've seen lots under this category, and I always say that we all do mistakes and maybe have understood an idea wrong, so it is okay. Anyway, not engaging does not mean that I didn't read your posts, especially yours!
Thanks again for your time writing this post.
Thanks for the comment.
I see tools posted all the time, and others sharing links to the tools, but almost nothing about how folks have used the tools.
> Not engaging with the article/post does not mean they didn't read it...
Well, when the post tells folks to not just Like and Retweet, but to share *why* they're doing so, but all they do is Like or RT...that kind of tells me that they didn't read it. ;-)
My thought is that if something is worth sharing with others, it's worth telling folks why. It's not so much about having an addition, something to add, it's more about what was said or discussed that led you to think, "yeah, I've gotta share this with others", or "this is worth sharing with others".
> ...maybe they are shy of sharing their thoughts ...
Hhhmmm. I guess what I don't understand is this...why are folks who do DFIR work not afraid to write reports that they share with their manager, and more importantly, with their clients? How is it that someone can be fine with sharing their expert opinion and interpretation of their findings, but not be comfortable sharing their thoughts and opinions?
My guess in not engaging in the community is the fear of being wrong, fear of having words taken out of context, fear of being criticized, and the fear of having public statements used adversely against you in cases. Personally, I believe that sharing publicly does the opposite of these fears. Being peer-reviewed in public increases credibility, corrects errors, and moves forward the ideas that are discussed.
Credibility and knowledge is in direct relation to the level of engagement in the sharing of ideas.
I also believe everyone has something to share at some level in the community. It doesn't have to be a groundbreaking discovery that requires a formal peer review in order to be worthy of sharing with the community, but an idea or a spark that ignites a discussion that can eventually solve a previously unsolved problem.
> ...sharing publicly does the opposite...
I have to say, I agree with you.
Several years ago, I was in the audience for a presentation, and the presenter stated that he'd informed his client of their window of compromise based on the (incorrect) interpretation of a single data point. While nothing could be done about what the client was told, at least discussing this privately with the presenter corrected their interpretation of the data.
For those who don't share out of fear that their words will be used against them, sharing and solidifying your thoughts and understanding lead to that credibility you mentioned.
> I also believe everyone has something to share ...
As do I. I believe that there is as much value in letting others know that activity continues as there is in identifying new activity.
What I don't get about the "fears" you mentioned is that DFIR analysts have to write reports and share their findings with someone...a client, the prosecutor, HR, etc. How is it easy to do so without fear, but those same people are afraid to share an opinion, or something that they've seen?
For those who choose not to engage in the community, but willingly provide reports and testimony in the public purview, my guess is that if they were not required to provide reports and testimony, they would not. By required, I mean "paid".
Great post. Everyone needs to stretch professionally to grow. There are a variety of reasons why someone may not be as public facing with contributions. However, I agree that encouraging public contributions is great for the community. It leads to peer review, as Brett mentioned, and new discovery. That said, I see nothing wrong with retweeting things you find value in as it increases the signal on important findings and news. For example, the work Dan P and David C. Each shared on shellbags this week. I retweeted it because it was important that everyone know the additional scenarios that create a shellbag entry. I didn't discover it, but saw it and wanted to bring it to the attention of others. I am okay with people who retweet things they find of value because it pumps up the signal. Of couse I retweeted this post as well.
First off, thanks for the mention.
I've found that many internal IR groups don't actually document much or anything. The reports I have reviewed for customers have gone from a small narrative paragraph to 200+ pages of copy/paste emails. I think there is also an idea that your report is only going to be read by a small set of people, if it even gets read at all. Posting a blog can be intimidating because you are hanging it all out for your very critical peers to see. Take an example of the extreme sides that the members of our industry took in response to MalwareTech being arrested and not having any evidence to logically go either direction.
Also, for me, the twitter 'like' still functions as the old 'favorite' button which is more like tagging an email for followup. I think we could all improve more on the comments and explaining the value you see as the reason for further sharing.
Thanks, all, for your comments...
From my experience, there is not a great deal of review (peer or otherwise) with respect to reports, etc. As such, I completely agree with Brett, in that having *some* form of review leads to growth. And I do think that the medium leads misinterpretations
> I retweeted it because it was important that everyone know...
I agree that this is important for data interpretation (God knows we still see AppCompatCache entries misinterpreted or misrepresented pretty regularly), but to my point, when you RT'd, did you share your thoughts/reasons for *why* you thought this was important?
I've worked with people who've shared things internally within the organization, sending a link with nothing more than an "FYSA". When this first arrives, it's noise, and there's nothing about "FYSA" followed by a URL that distinguishes it from noise. As such, I don't agree that RT'ing something inherently "pumps up the signal" as much as it adds to the noise. If you're going to RT or share something because you found value in it, pump up the signal by also sharing what you found to be significant.
> I've found that many internal IR groups don't actually document much or anything.
> ... if it even gets read at all.
Oh, agreed. I tend to think that, based on what I've seen produced over the years, that some folks put all their eggs in that basket, hoping that the client will read the executive summary, make their own assumptions off of that, and run with it.
> ...example of the extreme sides...
I get that, and you have to be ready for it. You have to assume that in any large group, particularly with the presumption of some modicum of anonymity, that some people are just going to be d*cks. We should also agree that due to the medium, some folks with the very best of intentions are going to viewed as d*cks. One such example I've experienced in responding to questions is when I ask, "which version of Windows are you working with?" No matter how many times this factor is described as being important, that question often elicits the response of, "oh, look at this jerk! Who does he think he is???"
I'm not suggesting that we comment on *everything*. What I'm saying is that we have a lot of smart folks in this industry, and we're really missing out on some great stuff by doing nothing more than clicking "Like", "RT", or "Favorite".
Statements I've heard over the years as reasons for not contributing, even just with internal teams:
"Everyone's already seen this..."
Not true, and so what? The fact is, I'll be the first to admit that I haven't seen everything. I'll also be the first to say that seeing a bit of malware or a technique that others have seen is as valuable as seeing something for the first time. Even if everything is the same with the malware...IIV, delivery mechanism, persistence mechanism, etc...the fact that it's still being used is important. Look at other aspects...what was the vertical attacked? If it was a phishing attack, *who* was targeted? Years ago, I was involved in a targeted breach where a retired 3-star general was targeted, and I thought that was pure genius, particularly from a cultural perspective. I mean, who else can you pretty much guarantee will click on something, regardless of training.
Stepping forward to more modern times, take a look at Allison Wikoff's research into the "Mia Ash" persona, particularly the individuals that were targeted.
"I can't contribute the way you do."
No one's asking you to. This is one of those responses where someone goes to a ridiculous extreme in order to justify their actions (or lack thereof), and if anything, indicates that you're in for a long, hard battle to get them to contribute.
When I say, "...if you 'like' something, then there's a reason you 'like' it, so share that along with the 'like' or retweet...", and the response is "...but I can't contribute the way you do...", it's clear that walls are being thrown up.
*NOT* sharing a thought or considered opinion is a loss for us all. But remember, these interactions go beyond just the act of contributing...it's important to, as @James said, 'be present' while doing so.
Where's the like/retweet button ;)
Great article love the comments on learning to program if nothing more then to learn to think about the bigger picture and how to process things.
Agreed. I typically include a "SoWhat" factor in a quote retweet. I use the Mute feature to reduce the noise on Twitter. As for reports, in any organization where I worked where peer review did not exist, I instituted it sometimes from the bottom up. Peer review is essential. What I would personally like to see is more of the bloggers in our world submitting more citable scholarly articles. DJI would be even better with more submissions. Time is of course a factor. But that is a peer reviewed journal in our field. But I recognize several hurdles including, but not limited to, time and those whose employers probibit or have high barriers for publication.
Agreed, peer review is essential. It's how we get better at what we do.
I've reviewed articles for scholar journals, and to be honest, I've been disappointed. I think that the best way to describe it goes back to some of the OSDFCons I've attended that have had academic and practitioner tracks...the practitioners have had a very difficult time with the academic side. Yes, it's great that there's a paper with all this math that someone put a great deal of work into, but how do we *use* it?
I've flat out turned down some of the recent journal articles I've reviewed because they were just poorly written.
Yes, it is difficult to write for such journals for all of the reasons you stated. Sometimes it's better to plant the seed that puts others on the road to discovery than to try to plant the tree.
Oh, and I should also add that other articles I've turned down have started off with a statement describing a problem that apparently did not exist.
The last academic paper that I can remember being *really* valuable was Jolanta Thomassen's paper on deleted keys and values in the Windows Registry. Her research was well considered and valuable, the paper was well written and easy to understand, and she released a tool along with it. I think that the reason I found so much value in her work is that she'd engaged in the industry to determine what was relevant.
I'm not a fan of academic papers. As Harlan mentioned, solving non-existent problems using extensive mathematical analysis and algorithms, written at a PhD level, is only fit as a homework project for a theoretical problem that no one has ever seen or expected to see.
I do enjoy any writing (blog post, article, a simple PDF, or even a PPT) that gets right to the point of (1) the problem and (2) the solution.
However, I may be alone in what I prefer to read to get the job done...
Post a Comment