During my time in the industry, I've authored 9 books under three imprints, and co-authored a tenth.

There, I said it. The first step in addressing a problem is admitting you have one. ;-)

Seriously, though, this is simply to say that I have some experience, nothing more. During the latter part of my book writing experience, I saw others who wanted to do the same thing, but ran into a variety of roadblocks, roadblocks I'd long since navigated. As a result, I tried to work with the publisher to create a non-paid liaison role that would help new authors overcome many of those issues, so that a greater portfolio of quality books became available to the industry. By the time I convinced one editor of the viability and benefit of such a program, they had decided to leave their profession, and I had to start all over again, quite literally from the very beginning.

Authoring a book has an interesting effect, in that it tends to create a myth around the author, one that they're not aware of at first. It starts with someone saying, "...you wrote a book, so you must X..". Let "X" be just about anything. 

"Of course you're good at spelling, you wrote a book." Myth.

"You must be rolling in money, you wrote a book." Myth.

All of these things are assumptions, myths built up only to serve as obstacles. The simple fact is that if you feel like you want to write a book, you can. There's nothing stopping you, except...well...you. To that end, I thought I'd write a series of posts that dispel the myths and provide background and a foundation for those considering the possibility of writing a book.

There are a number of different routes to writing books. Richard Bejtlich has authored or co-authored a number of books, the most recent of which have been reprints of his Tao Security blog posts. Emma Bostian tweeted about her success with "side projects", the majority of which consisted of authoring and marketing her ebooks.

The Why
So, why write books at all? In an email that Gen Jim Mattis (ret) authored that later went viral, he stated:

By reading, you learn through others’ experiences, generally a better way to do business, especially in our line of work where the consequences of incompetence are so final for young men.

Yes, Gen Mattis was referring to warfighting, but the principle equally well for DFIR work. In his book, "Call Sign Chaos", Mattis further stated:

...your personal experiences alone aren't broad enough to sustain you.

This is equally true in DFIR work; after all, what is "analysis" but the analyst applying the sum total of their knowledge and experience to the amassed data? As such, the reason to write books is that no one of us knows everything, and we all have vastly different experiences. Even working with another analyst on the same incident response engagement, I've found that we've had different experiences due in large part to our different perspectives.

The simple fact is that these different perspectives and experiences can be profoundly valuable, but only if they're shared. A while back, I engaged in an analysis exercise where I downloaded an image and memory sample provided online, and conducted analysis based on a set of goals I'd defined. During this exercise, I extracted significantly different information from the memory sample using two different tools; I used Volatility to extract information about netstat-style network connections, and I also used bulk_extractor to retrieve a PCAP file, built from the remnants of actual packets extracted from memory. I shared what I'd done and found with one other analyst, and to be honest, I don't know if they ever had the chance to try it, or remembered to do so the next time the opportunity arose. Since then, I have encountered more than a few analysts to whom this approach never occurred, and while they haven't always seen significant value from the effort, it remains a part of their toolkit. I also included the approach in "Investigating Windows Systems", where it is available, and I assume more than one analyst has read it and taken note.

Speaking for myself, I began writing books because I couldn't find what I wanted on the shelves of the bookstore. It's as simple as that. I'd see a title with the words "Windows" and "forensics" in the title, and I'd open it, only to find that the dive did not go deep enough for me. At the time, many of the books related to Windows forensics were written by those who'd "grown up" using Linux, and this was clearly borne out in the approach taken, as well as the coverage, in the books.

The First Step
The first step to successfully writing a book is to read. That's right...read. By reading, we get to experience a greater range of authorship, see and decide what we enjoy reading (and what we pass on), and then perhaps use that in our own writing.

My first book was "Windows Forensics and Incident Recovery", published in 2004. The format and structure of chapter 6 of that book is based on a book I read while I was on active duty in the military titled "The Defense of Duffer's Drift". I liked the way that the author presented the material so much that I thought it would be a useful model for sharing my own story. As it turned out, that was the one chapter that my soon-to-be wife actually read completely, as it is the only chapter that isn't completely "technical".

With that, thoughts, comments and questions are, as always, welcome. Keep an eye open for more to come!

There's been a lot of discussion on social media around how to "break into" the cybersecurity field, not only for folks just starting out but also for those looking for a career change. This is not unusual, given what we've seen in the public news media around cyber attacks and ransomware; the idea is that cybersecurity is an exploding career field that is completely "green fields", with an incredible amount of opportunity.

Jax Scott recently shared a YouTube video (be sure to comment and subscribe!) where she provides five steps to level up any career, based on her "must read for anyone seeking a career in cybersecurity" blog post. Jax makes a lot of great points, and rather than running through each one and giving my perspective, I thought I'd elaborate a bit on one in particular.

Jax's first tip is to network. This is profound...really profound...for a number of reasons.

First, what I see a LOT of is folks on social media asking for advice on getting into the cybersecurity field, without realizing that the "cybersecurity field" is a huge, expansive...there are a lot of different things you can do in the field. Networking lets you see what you may not see, and it affords you the opportunity to see different aspects of the field. For example, there are more technical (pen testing, digital forensics) aspects of "cybersecurity", as well as less technical (incident management, compliance, policies, etc.) aspects. Not everyone is suited to everything in this field...I once worked with/mentored an incident response consultant who got so anxious when it was their turn to go on-site that they once had to check themselves into the hospital, and another analyst had to take the engagement.

Second, when you do network, make sure that it's purposeful and intentional. Clicking "like" or "follow", or just sending someone a blind connection request on LinkedIn, isn't really "networking", because it's too passive. If you're networking to develop an understanding of the field, and to find a (new) job, just following or connecting to someone isn't going to get you there.

Networking with intent affords us something else, as well. In his book, "Call Sign Chaos", retired Marine general Jim Mattis stated that "...your personal experiences alone aren't broad enough to sustain you." This is just as true in the cybersecurity field as it is to the warfighter, and intentional networking allows us to broaden our experiences through purposeful engagement with others.

I see recommendations on LinkedIn all the time with tips for how to develop your "brand", and most include things such as leaving a comment rather than liking a post, referring to/referencing other posts, as well as other activities that are active, rather than passive. All of these amount to the same thing...purposeful, intentional networking.

Be sure to check out and subscribe to Jax's YouTube videos for a lot of great insight and information, as well as follow the "Hackerz and Haecksen" podcast for some insightful interviews and content!

Over the years as a DFIR analyst...first doing digital forensics analysis, and then incorporating that analysis as a component of IR activity...there have been some stunningly simple truths that I've learned, truths that I thought I'd share. Many of these "tips" are truisms that I've seen time and time again, and recognized that they made much more sense and had more value when they were "named".

Tips, Thought, and Stuff to Think About

When performing DF analysis, the goal is to be as comprehensive and thorough as possible. A great way to achieve this is through automation. For example, I developed RegRipper because I found that I was doing the same things over and over again, and I wanted a way to make my job easier. The RegRipper framework allowed me to add checks and queries without having to write (or rewrite) entirely new tools every time, as well as provided a framework for easy sharing between analysts.

TCP networking is a three-stage handshake, UDP is "fire and forget". This one tip helped me a great deal during my early days of DFIR consulting, particularly when having discussions with admins regarding things like firewalls and switches.

Guessing is lazy. Recognize when you're doing it before someone else does. If there is a gap in data or logs, say so. At some point, someone is going to see your notes or report, and see beyond the veil of emphatic statements, and realize that there are gaping holes in analysis that were spackled over with a thin layer of assumption and guesswork. As such, if you don't have a data source...if firewall logs were not available, or Windows Event Logs were disabled, say so.

The corollary to the tip on "guessing" is that nothing works better than a demonstration. Years ago, I was doing an assessment of a law enforcement headquarters office, and I was getting ready to collect password hashes from the domain server using l0phtcrack. The admin said that the systems were locked down and there was no way I was going to get the password hashes. I pressed the Enter key down, and had the hashes almost before the Enter key returned to its original position. The point is, rather than saying that a threat actor could have done something, a demonstration can drive the point home much quicker.

Never guess at the intentions of a threat actor. Someone raised in the American public school system, with or without military or law enforcement experience, is never going to be able determine the mindset of someone who grew up in the cities of Russia, China, etc. That is, not without considerable training and experience, which many of us simply do not have. It's easy to recognize when someone's guessing the threat actor's intention, because they'll start off a statement with, "...if I were the threat actor...".

If no one is watching, there is no need for stealth. The lack of stealth does not bely sophistication. I was in a room with other analysts discussing the breach with the customer when one analyst described what we'd determined through forensic analysis as, "...not terribly sophisticated...", in part because the activity wasn't very well hidden, nor did the attacker cover their tracks. I had to later remind the analyst that we had been called in a full 8 months after the threat actor's most recent activity.

The adversary has their own version of David Bianco's "Pyramid of Pain", and they're much better at using it. David's pyramid provides a framework for understanding what we (the good guys) can do to impact and "bring pain" to the threat actor. It's clear from engaging in hundreds of breaches, either directly or indirectly, that the bad guys have a similar pyramid of their own, and that they're much better at using theirs.

We're not always right, or correct. It's just a simple fact. This is also true of "big names", ones we imagine are backed by significant resources (spell checkers, copy editors, etc.), and as such, we assume are correct and accurate. As such, we shouldn't blindly accept what others say in open reporting, not without checking and critical thinking.

There are a lot of assumptions in this industry. I'm sure it's the same in other industries, but I can't speak to those industries. I've seen more than a few assumptions regarding royalties for published books; new authors stating out big publishers may start out at 8%, or less. And that's just for paper copies (not electronic), and only for English language editions. I had a discussion once with a big name in the DFIR community who assumed that because I worked for a big name company, of course I had access to commercial forensic suites; they'd assumed that my commenting on not having access to such suites was a load of crap. When I asked what made them think that I would have access to these expensive tool sets, they ultimately said that yes, they'd assumed that I would.

If you're new to DFIR, or if you've been around for a while, you've probably found interviewing for a job to be nerve-racking, anxiety-producing affairs. One thing to keep in mind is that most of the folks you're interviewing with aren't terribly good at it, and are probably just as nervous as you. Think about it...how many times have you seen courses offered in how to conduct a job interview, from the perspective of the interviewer?