I had an interesting chat recently with a fellow Marine vet recently which generated some thoughts regarding non-technical skills that veterans bring to bear, in any environment. This is something I've thought about before, and following the exchange, I thought it was time to put together a blog post.

Before I start, however, I want to state emphatically and be very clear that this is not an "us vs them" blog post.  I'm fully aware that a lot of non-vets may have many of the same skills and experiences discussed in the post, and I'm not suggesting that they don't.  More than anything, the goal of this blog post is to help vets themselves overcome at least a modicum of the "imposter syndrome" they may be feeling as they begin their transition from the military to the civilian community.

The military includes some quality technical skills training, and a great thing about the military is that they'll teach you a skill, and then make you to use it.  This includes the entire spectrum of jobs...machine gunner, truck driver, welder, etc.  While the technical skills imparted by the military, for the most part, may not seem up to par with respect to the private sector, there are a lot of soft skills that are part of military training that are not as prevalent out in the private sector.

Vets also develop some pretty significant technical skill sets, either as part of or ancillary to their roles in the military.  When I was on active duty and went to graduate school, I did things outside of work like upgrade my desktop by adding a new hard drive which, back in '94, was not the most straightforward process if you've never done it before.  I knew an infantry officer who showed up and had not only installed Linux on his 386 desktop computer, but had already developed a familiarity with the OS...again, not something to shake a stick at back in the mid-'90s.  I developed more than a passing familiarity with OS/2 Warp.  Prior to that, I had some pretty inventive enlisted Marines working for me; one developed a field expedient antenna that he called a "cobra-head", and he carried around in an old calculator pouch.  Another Marine discovered a discrepancy in the "Math for Marines" MCI correspondence course exam; he wrote it up, I edited it and had him sign it, and he got the award.  After all, he found it.  My point is that I've spoken with a number of vets who've been reticent to take that big step out into the private sector, instead opting for a "soft" transition by working for a contractor or in LE first.  I think that some of this has been due to the misconception of, "I won't measure up", but honestly, nothing could be further from the truth.

For vets, the skills you have may be more sought after than you realize.  For example, if you spent some time in the military, you have some pretty significant life experiences that non-vets may not have, like living and working with a diverse team.  Spent six years in the Navy, with a good bit of that on ship or on a submarine?  If you spent any time in the military, you very likely spent time living in a barracks environment, and it's also very likely that you spent time having to be responsible for yourself.  As such, when you're transitioning to the private sector, you've already learned a lot of the lessons that others may not yet have experienced.

One notable example that I've heard mentioned by others is being part of a team.  What does this mean?  One fellow vet said that he has, "...a strong sense of not being the guy that screws over my teammates."  He further shared that he'll do whatever it takes to ensure that he doesn't make someone else's job tougher or needlessly burdensome.

There are also a number of little things...how often have you been on a conference call when someone spends a minute responding, but they're still on mute?  Or they have some serious racket going on in the background, and they won't go on mute?

Other examples include planning and communications.  Like many, I took a class on public speaking while I was in college (it was a requirement), but my real experience with direct communications to others came while I was in the military, beginning in Officer Candidate School (OCS, which is an evaluation process, not a training one).  During OCS, we had an evolution called "impromptu speech", where the platoon commander gave us 15 min to prepare a 5 min speech, and we were evaluated (in front of everyone) on both the content and conduct (i.e., did we finish on time, etc.) of the "speech".  Each of us got direct feedback as to such things as, did we follow instructions and stay on point, did we stay within the time limit, were we engaging, etc.  We then had multiple evolutions (military speak for "periods of training") throughout the rest of OCS where we had to use those skills; briefing three other candidates on fire team movement, briefing 12 other candidates on squad movement, the Leadership Reaction Course, etc.  For each evolution, we were evaluated on our ability to come up with a plan, take input and feedback, and then clearly and concisely communicate our plan to others.  And when I say we were "evaluated", I mean exactly that.  I still remember the feedback I received from the Captain manning the station of the Leadership Reaction Course where I was the team leader.  This sort of evolution (along with performance evaluation) continued on into initial officer training (for Marines, The Basic School, or "TBS"); however, there was no intro or basic "impromptu speech" evolution, it just picked up where OCS left off.  Not only were we evaluated and critiqued by senior officers, but we also received feedback from our fellow student officers.

My point is that there were experiences that developed basic skills that many of us don't really think about, but they have a pretty significant impact on your value once you transition out of the military.  For enlisted folks, did you ever have to guide a new person through the wickets of "how we do things here"?  Were you ever in the field somewhere and told by your squad leader that you had to give a training class to fill a block of time, and then evaluated on how you did?  Were you ever in a role where you had to give or elicit feedback? You may think that these were small, meaningless experiences, but to be quite honest, they add up and put you head and shoulders above someone with the same technical skills, but hasn't experienced those same sorts of events during their career to that point.

Like others, I've also experienced prejudice against members of the armed forces.  I'm not sharing this to diminish or minimize anyone else's experiences; rather, I'm simply sharing one of my own experiences.  Years ago (at the time of this writing, close to 20), I worked for a services company in VA, for which the security division was run out of the office in CA.  Not long after I started, I was told that I needed to fly to the CA office to get trained up on how things were done, and that I would be there for three days.  So, I flew out, and spent the first day and a half chatting with the tech writer in the office, who was also a Marine vet.  That's right...after all the discussion and planning, I showed up and nothing happened.  When things finally got kicked off, the Director of Security Services stated emphatically that, had I applied to the company through his office that I wouldn't have been hired, for no other reason that because I was coming from the military.  Apparently, his feeling was that military folks couldn't think the way civilian security folks thought, that we're too "lock-step".

While he was saying this, he was also giving me a tour of the facilities in the local office. Part of the tour included a room that he described as a "Faraday cage".  While we were in the room, with the door closed, his cell phone rang.  Evidently, it was NOT someone calling him (in the "Faraday cage") to remind him that, per my resume, I had earned an MSEE degree prior to leaving the military.  In fact, I knew what a "Faraday cage" was supposed to be from my undergrad schooling.  So...yeah.

My point is, don't put someone on a pedestal due to some minimized sense of self-worth, or some self-inflicted sense of awe in them.  After all, we all knew that Colonel or 1stSgt who really shouldn't have been in their position.  Realize that there are things you do bring to the table that may not be written into the job description, or even be on the forefront of the hiring manager's mind.   However, those skills that you have based simply on what you've experienced will make you an incredibly valuable asset to someone.

For the vets out there who may be feeling anxious or reticence about their impending transition...don't.  Remember how you hated staying late to clean weapons, but you adjusted your attitude and focused on getting it done...and not just your weapon, but once you were finished, you went and helped someone else?  Remember all those times when the trucks were late picking you and your team up, and how you developed patience because of those experiences?  Remember how you also looked to those experiences, and thought about all the steps you'd take to ensure that they didn't happen on your watch, when you were in charge?  Well, remember those times and those feelings while you're interviewing, and then reach out and extend a helping hand to the next vet trying to do the same thing you did. 

IWS has been out for a short while now, and there have been a couple of reviews posted.  So far, it seems that there is some reticence to the book, based on the form factor (size), as well as the price point.  Thanks to feedback on the book on that subject from Jessica Hyde, the publisher graciously shared the following with me:

I’m happy to pass on a discount code that Jessica and her students, and anyone else you run across, can use on our website (www.elsevier.com) for a 30% discount AND we always offer free shipping. The discount code is: FOREN318.

Hopefully, this discount code will bring more readers and DFIR analysts a step closer to the book.  I think that perhaps the next step is to address the content itself. I'm very thankful to Brett Shavers for agreeing to let me share this quote from an email he sent me regarding the IWS content:

As to content, I did a once-over to get a handle of what the book is about, now on Ch 2, and so far I think this is exactly how I want every DFIR book to be written.

I added the emphasis myself.  This book is something of a radical departure from my previous books, which I modeled after other books I'd seen in the genre, because that's what I thought folks wanted to see.  Mention an artifact, provide a description of what the artifact may mean (depending upon the investigation), maybe a general description of how that artifact may be used, and then provide names of a couple of tools to parse the artifact.  After that, move on to the next artifact, and in the end, pretty much leave it to the reader to string everything together into an "investigation".  In this case, my thought process was to use images that were available online to run through an investigation, providing analysis decisions and pivot points along the way.  This way, a reader could follow along, if they chose to do so.

If you get a copy of the book and have a similar reaction to what Brett shared, please let me know.  If there's something that you like or don't like about the book, again, please let me know.  Do this through an email, a comment here on this blog, or a blog post of your own.  As illustrated by the example involving Jessica, if I know about something, I can take action and work to change it. 

How It Works
When a publisher decides to go forward with a book project, they have the author submit a prospectus describing the book, the market for the book, and any challenges that may be faced in the market; in short, the publisher has the author do the market research.  The prospectus is then reviewed by several folks; for the book projects I've been involved with, its usually been three people in the industry.  If the general responses are positive, the publisher will move forward with the project. 

I'm sharing this with you because, in my experience, there are two things that the publisher looks at when considering a second edition; sales numbers and feedback from the first edition.  As such, if you like the content of the book and your thoughts are similar to Brett's, let me know.  Write a review on Amazon or on the Elsevier site, write your own blog post, or send me an email.  Let me know what you think, so that I can let the publisher know, and so that I can make the changes or updates, particularly if they're consistent across several reviewers. 

If you teach DFIR, and find value in the book content, but would like to see something more, or something different, let me know.  As with Jessica's example, there's nothing anyone can to do take action if they don't know what you're thinking.

Book Discount
While I was attending OSDFCon, I had a chance to (finally!) meet and speak with Jessica Hyde, a very smart and knowledgeable person, former Marine, and an all-around very nice lady.  As part of the conversation, she shared with me some of her thoughts regarding IWS, which is something I sincerely hope she shares with the community.  One of her comments regarding the book was that the price point put it out of reach for many of her students; I shared that with the publisher, and received the following as a response:

I’m happy to pass on a discount code that Jessica and her students, and anyone else you run across, can use on our website (www.elsevier.com) for a 30% discount AND we always offer free shipping. The discount code is: FOREN318.

What this demonstrates is that if you have a question, thought, or comment, share it. If action needs to or can be taken, someone will do so. In this case, my concern is the value of the book content to the community, and Jessica graciously shared her thoughts with me, and as a result, I did what I could to try and bring the book closer to where others might have an easier time purchasing it.

So how can you share your thoughts?  Write a blog post or an email.  Write a review of the book, and specify what you'd like to see.  What did you find good, useful or valuable about the book content, and what didn't you like?  Write a review and post it to the Amazon page for the book, or to the Elsevier page; both pages provide a facility for posting a review.

Artifacts of Program Execution
Adam recently posted a very comprehensive list of artifacts indicative of program execution, in a manner similar to many other blogs and even books, including my own.  A couple of take-aways from this list include:

- Things keep changing with Windows systems.  Even as far back as Windows XP, there were differences in artifacts, depending upon the Service Pack.  In the case of the Shim Cache data, there were differences in data available on 32-bit and 64-bit systems.  More recently, artifacts have changed between updates to Windows 10.

- While Adam did a great job of listing the artifacts, something analysts need to consider is the context available from viewing multiple artifacts together, as a cluster, as you would in a timeline.  For example, let's say there's an issue where when and how Defrag was executed is critical; creating a timeline using the user's UserAssist entries, the timestamps available in the Application Prefetch file, and the contents of the Task Scheduler Event Log can provide a great deal of context to the analyst.  Do not view the artifacts in isolation; seek to use an analysis methodology that allows you to see the artifacts in clusters, for context.  This also helps in spotting attempts by an adversary to impede analysis.

So, take-aways...know the version of Windows you're working with because it is important, particularly when you ask questions, or seek assistance.  Also, seek assistance.  And don't view artifacts in isolation. 

Artifacts and Evidence
A while back (6 1/2 yrs ago), I wrote about indirect and secondary artifacts, and included a discussion of the subject in WFA 3/e.

Chris Sanders recently posted some thoughts regarding evidence intention, which seemed to me to be along the same thought process.  Chris differentiates intentional evidence (i.e., evidence generated to attest to an event) from unintentional evidence (i.e., evidence created as a byproduct of some non-attestation function).

Towards the end of the blog post, Chris lists six characteristics of unintentional evidence, all of which are true.  To his point, not only may some unintentional evidence have multiple names, it may be called different things by the uninitiated, or those who (for whatever reason) choose to not follow convention or common practice.  Consider NTFS alternate data streams, as an example.  In my early days of researching this topic, I found that MS themselves referred to this artifact as both "alternate" and "multiple" data streams.

Some other things to consider, as well...yes, unintentional evidence artifacts often are quirky and have exceptions, which means they are very often misunderstood and misinterpreted.  Consider the example of Shim Cache entry from Chris's blog post; in my experience, this is perhaps the most commonly misinterpreted artifact to date, for the simple fact that the time stamps are commonly referred to as the "date of execution".  Another aspect of this artifact is that it's taken as standalone, and should not be...there may be evidence of time stomping occurring prior to the file being included as a Shim Cache record.

Finally, Chris is absolutely correct that many of these artifacts have poor documentation, if they have any at all.  I see this as a short-coming of the community, not of the vendor.  The simple fact is that, as a community, we're so busy pushing ahead that we aren't stopping to consider the value to the community as a whole that we're leaving behind.  Yes, the vendor may poorly document an artifact, or the documentation may simply be part of the source code that we cannot see, but what we're not doing as a community is documenting and sharing our findings.  There've been too many instances during my years doing DFIR work that I would share something with someone who would respond with, "oh, yeah...we've seen that before" only to have no documentation, not even a Notepad document or something scribbled on a napkin to which they can refer me.  This is a loss for everyone.