Category Archives: Network Security

Writing for Security: Why You Fear It

quillIn the last post in this series, I talked about reasons most information security practitioners give when they are asked why they don’t like writing. In this post, I’m going to tackle the same topic, but I want to dig into a reason that most won’t talk about when asked that question.

Most people don’t write more because they are afraid. For that matter, most people who do write a lot are also afraid. They’ve just developed strategies for dealing with it. You may not realize you’re afraid, and if you are you might not be comfortable talking about it. That’s normal. Any time you put words on paper and put it out there with your name on it, you’re exposing yourself and opening yourself up to criticism. Once you hit that publish button or send that e-mail, you’re writing is no longer yours. It’s everyone’s.

We’ve all heard that the best way to deal with fear is to confront it, so that’s what I’m going to do here. In this post I’m going to talk about some of the reasons why most folks are afraid to write more, and how fear can prevent your writing from living up to its potential.

Why You’re Afraid

Fear manifests in a variety of ways, but in most cases, people don’t use the terms “fear” or “afraid”. Instead, they use words like “worry” or “don’t know.” Uncertainty and doubt are often a result of fear, and it’s very hard to recognize that. For each type of fear I’ve mention in the following sections I’ve listed a few statements someone might say or think where the fear manifests. As you read these, ask yourself if any of those statements are something you’ve said or thought before.

I’m afraid of being too technical

It’s easy to get slowed down because you don’t know what level of technical detail you need to write to. After all, you clearly know what you’re talking about, and you don’t want to take your readers level of expertise for granted. I call this competence paralysis, because it kills a lot of good writing. In one form, competence paralysis results in reports that are far in-depth and taking forever to write. An overwhelming amount of technical detail that isn’t well organized can make these reports unreadable. In another form, blog writers come up with ideas for posts, but as they keep expanding the scope to include more technical details they eventually become overwhelmed and abandon it.

  • “I’m talking about a web server attack, so I should probably write a section about how HTTP works.”
  • “I mentioned phishing, so I should put in four or five images of what a phishing e-mail looks like.”
  • “I’m not sure most people understand SSL, so I’m going to keep this part to the bare minimum.”


I’m afraid of leaving something out

As the complexity of your topic rises, it becomes easy to leave out something important. This is especially true when you’re reviewing a complex processes or anything related to how a piece of code works. Nobody wants to write bad content, not even those guys who write the Nigerian prince scam e-mails. The last thing you want to do is invest a lot of time writing something incredibly detailed only to get e-mails or comments saying you forgot something. The perception is that this makes you look less knowledgeable in the topic area.

  • “I don’t know what use cases are out there, so I’ll include a description of every nmap command.” 
  • “I started writing an article about cryptolocker, but got overwhelmed when I realized how many versions there were, so I ditched it.”


I’m afraid that I’m not a good enough writer

The vast majority of people working in technical fields didn’t come from liberal arts backgrounds. Many never took a writing course, and a lot never even went to college. Because of that, it’s natural to doubt an ability that you haven’t been formally trained in. I’d venture that most people couldn’t tell you what a preposition actually is, yet most of us use them all the time without much thought. Security practitioners do their job by breaking things into their component parts and looking for ways that they or an attacker could manipulate those parts. When you don’t have a full grasp of the parts of speech, you’re less likely to want to approach them as aggressively. Not only that, learning about parts of speech is fairly boring, so we aren’t as incentivized to do it. With all of that at play, it’s reasonable to have some fear of a craft you won’t have perceived to master in a way similar to your primary skill.

  • “I’m good at breaking stuff, but I don’t express it on paper well.”
  • “I can talk through this stuff just fine, but I don’t know how to make it interested in reports.”


I’m afraid of being wrong

Most people enjoy constructive criticism on their writing, but nobody likes being called out, being hung out to dry publicly, or having their intelligence questioned. Unfortunately, there is a large contingent of people who don’t have the ability to provide feedback in a constructive way. All it takes is one brash person to tear down your writing, and you’ll carry that with you forever. I’ve seen a lot of good writers who’ve experienced this first hand, and it completely neutered their ability or desire to write content.

  • “I’m not good enough at programming to write a script that can fix this, so I probably shouldn’t mention it as a mitigation.”
  • “I’m not going to write about that because it would take me years to research it enough to be comfortable to release it.”


I’m afraid that I’m an imposter

All of the aforementioned fears could probably be rolled into this one. Imposter syndrome is a feeling that you are inadequate when compared to your peers, even in spite of evidence to the contrary. This manifests in feelings of self-doubt, a lack of motivation, and fear of being a fraud. If you do what most people in information security do and follow the blogs and Twitter accounts of people you know and respect, you’re inevitably going to become overwhelmed by how much you don’t know. When it becomes time to write about something, you might start comparing yourselves to others in the area.

  • “I want to post this on Reddit, but those guys would tear me apart.”
  • “I’d love to write more about threat intelligence, but guys like Scott and Bill have probably already written about that better somewhere.”
  • “I’m going to keep this one short and to the point because my coworker knows a lot more about this than me.”
  • “I don’t have enough experience to write about this. I’ve only been doing this for 5 years.”
  • “What if nobody reads it?”


Overcoming your Fear

Fear isn’t a bad thing. It’s a regulating force that keeps our other sense in check. You don’t run across the street without cautiously looking both ways, and you don’t write technical reports without checking your facts. If you were completely fearless in all of your writing then you’d probably put out a lot of junk with unchecked facts and reckless claims. You can’t afford these things in security writing because it bears tremendous weight.

The examples in each of the fears above were provided to show the ways that fear can manifest in your writing. Sometimes, fear will cause you to make your writing bloated. A simple paragraph can turn into pages of excess material that isn’t necessary. Other times, fear can cause you to leave out great material because you are afraid you don’t have enough expertise to share those thoughts or you feel the effects of imposter syndrome. In the very worst of scenarios, fear can even prevent from even being willing to share your point of view.

Giving into any of these fears can dramatically limit your career effectiveness, but they can be overcome. Here are a few ways to do that:


Embrace your POV with the Prism Strategy

The beautiful thing about knowledge is that as it gets transferred from person to person, it takes new life. Each person adds their own knowledge to it and shares it through their own lens. That lens can make writing unique. When you look through prism, what you see varies based on the direction you’re looking. The same applies know knowledge acquisition. This is the basis of why different learning methods are effective for different people.

It doesn’t matter if you’re writing about something someone else has already written about. Let that sink in. The thing that makes writing special is that it encapsulates the entirety of your unique experience. Don’t discount how unique your experience is. Someone might know a lot more about TCP/IP than you, but they probably didn’t learn about it the same way you did. They didn’t go through the trials you went through, and they didn’t fight the battles you’ve fought. One of the things that really resounded to me after writing Practical Packet Analysis was the number of people who still come to me citing how many times they’ve tried to learn about Wireshark and packet analysis but have failed, only to eventually find my book and have it click for them. I wasn’t the first to write about that topic, but I provided a unique approach and insight to it that was my own, and a lot of people were able to benefit from it.

Don’t be scared off just because you aren’t the first to write about something. Your unique insight may be what someone is looking for.


Create an Advisory Board

Nearly everything I write gets reviewed by someone I trust prior to publishing. These reviews take a lot of different forms, and I reach out to people I know based on what I’m concerned about with the particular article. If I need a deep dive technical review I’ll contact someone I know with expertise in that area. If I’m concerned about tone, I reach out to people in the industry who I’m friends with that aren’t afraid to tell me if I’m being too harsh or not aggressive enough. If I just need a simple copy edit, I even call in my wife to help, who somehow stumbled across a BS in English before getting her MD.

Whether you’re writing as a function of your job, or as a blogger, you should setup an advisory board as quickly as possible. These individuals should be people who care about you and your material, but they should also be brutally honest. The best way to overcome nearly any fear is for someone else to tell you it’s going to be okay. There have been a lot of posts I’ve published that I was unsure of, but because I had the approval of a trusted advisor I went with it, and those have been some of my best content.


Carefully Choose your Medium

Fears aren’t something you “get over” most of the time. Instead, you learn to manage them. This means that you don’t need to set yourself up for failure in a way that could make a fear grow beyond control. I have a lot of people who come to me asking about writing books and how to get started in that part of this industry. I always point them to my post on that subject first, but I also make sure to try and gauge their fears so I can make a recommendation that will help them. If the person is inexperienced and I sense they have a reasonable amount of fear about the process, I recommend they avoid a book project for now.

As I’ve said before, once you finish your writing and put it out there in the world it isn’t yours any longer. It belongs to the reader. The amount of control you relinquish depends on the medium. If you post on a blog you have some flexibility to make edits, provide follow up posts, and reply to comments. With something like a book, once it’s printed on paper it’s there forever. You can’t go back and edit silly mistakes and you definitely can’t get rid of Amazon reviews. If you have some fear that you need to keep in check, you should build confidence by publishing on more flexible mediums before moving onto something like a book.


Embrace Your Shortcomings

You can spend a lot of time trying to compensate for the areas you’re weak in, but sometimes the best strategy is to embrace those things and put them front and center. You can’t be exposed if you’ve given your reader all you have. If you’re technically weak in an area, don’t try to cover it up. This normally manifests as lazy writing, and makes your reader a lot less likely to want to continue reading or read anything else you write.

A common example I see here is when a report or blog post gets to a point where code is needed. A lot of great infosec people aren’t good coders, so they try to dance around areas where code needs to be in their writing. In most cases, your reader can sense this is happening. Instead of dancing around the elephant in the room, address it. You don’t have to provide the user with 100% of the needed solution. If you just provide them with an overview of what they could or some pseudocode that takes them 20% of the way, that’s 20% farther than they would be otherwise.


More on Writing

I’ve experienced a great deal of fear at multiple points in my career. You can read about one of these here. It took me quite a while to recognize fear was crippling me, and it was only once I realized it that I was able to start moving past it. My goal in writing this post is to help you recognize if it is fear that is preventing you from maximizing your potential in this area. You can’t move past it until you realize it’s there.

If you’re interested in learning more about my personal systems for better technical writing, I’ll be releasing more articles in that area soon, as well as a couple of videos. You can subscribe to the mailing list below to get access to that content first, along with a few exclusives that won’t be on the site.

Sign Up for the Mailing List Here



Writing for Security: Why You Hate It

quillOver the next couple of weeks, I’ll be sharing a multi part series about technical writing for security professionals. If your job requires you to write reports of any kind, or you enjoy blogging, then I think you’ll enjoy it. We’re going to talk about some of the underlying reasons you probably don’t like writing as much as you could, how good writing can help you further your career, and some tactical tips for being a better writer.

I recently conducted an open-ended survey of information security practitioners to ask them what their biggest pain point was. I was fortunate to get a ton of responses and ended up with a list just short of a mile long. The list was very diverse, but there were a few themes that emerged. One that I wasn’t surprised to see was that many expressed their disinterest for the part of their job that involves writing.

Let’s dig into why so many people hate writing.

I’d rather be hunting, pen testing, etc

This was by far the most common thing I’ve heard, and I’m sure you can relate. Most of us get the thrill in our job by catching bad guys or pretending to be them. You probably got into this business because you want to help people be more secure, you love solving puzzles, or you just love breaking things. When you have to write up your findings it really just takes time away from that. This is especially painful when you can’t get ahead of your alert queue or you can’t find enough time to go hunting as it is. For consultants, you also have to contend with the limitation on hours for the gig. If you have to spend 50% of your hourly budget writing a report, that’s time that could be spent actually doing the job.

I’m not good at it

Many practitioners simply aren’t good at putting their actions and findings into words. We all know great investigators and pen testers who can do truly amazing things, but have the communication skills of a rock. To make things worse, many experience imposter syndrome where they perceive their writing is poor when it really isn’t. The only thing worse than being bad at writing is thinking you’re bad at it. After all, who wants to spend time doing something they believe they suck at?

Nobody listens to my findings and recommendations

Perhaps the most bone crushingly painful part of writing occurs when you spend a lot of time validating something and coming up with specific recommendations, only to find out they were ignored. You might have experienced this when you perform a pen test a year after performing another one, only to find the same vulnerabilities still exist. Worse yet, you might respond to a breach only to find the recommendations for preventing similar breaches weren’t followed, resulting in another one.

These are just a few of the reasons you probably hate writing. I don’t blame you. They are all legitimate pains and over time they can crush your soul. It might surprise you, but at one time in my life I hated writing, too. I avoided it like the plague and while I wasn’t horrible at it, I certainly wasn’t very good.

Moving Past the Hate

If you knew me then, you’d have a hard time believing I was capable of writing a few books and hundreds of articles, let alone a PhD dissertation. Luckily, when I was earlier on in my career I quickly figured out that writing was an important part of it. So, how did I turn something I hated and wasn’t great at into one of my biggest strengths? I did what, most hackers do, I broke it down into parts that made sense and developed a system.

I sat down and thought about things I liked to read, and how I could relate those to the things I had to write. I’m a big fan of modern authors like Tom Clancy, John Grisham, and Stephen King. I broke down what I liked about their work and started thinking about what they did successfully and how it could relate to technical writing. Eventually I was able to produce a repeatable system that I owe a lot of my career success to.

I’m not going to go in depth on my system here (I’m going to be sharing that later), but in the next post I’ll share some reasons why hackers hate writing that they may not realize.

More on Writing

The truth is that most of us don’t really enjoy the part of our job that requires writing reports. However, no matter what area of security you work in, a great deal of your success will be determined by your ability to do this thing. Fortunately, writing doesn’t have to be as painful as it is. By spending some time up front, hacking the process a bit, and setting up a repeatable system, you can speed up the writing process and gain back the time you can spend breaking things and hunting the adversary. Not only that, you can also become a much more effective agent of change, helping your network or your clients network become more secure. It can even help you become a better teacher and build your community resume by learning how to share your expertise better through a public blog.

If you’re interested in learning more about my personal systems for better technical writing, I’ll be releasing more articles in that area soon, as well as a couple of videos. You can subscribe to the mailing list below to get access to that content first, along with a few exclusives that won’t be on the site.

Sign Up for the Mailing List Here


Survey: Technical Writing Pain Points

I’m currently working on a multi-part series on technical writing. Specifically, I’m addressing some of the more common things I hear from security pros who hate writing things like penetration test reports and incident reports. I’ll also be addressing informal technical writing, like blog posts.

I’d love to hear from you. What do you dislike about technical writing the most? What is it that makes you dread it or put it off until the lat minute?

Either let me know in the comments, tweet me using the hashtag #ReportingPain, or you can fill out the anonymous survey here:

Research Call for Security Investigators

brainicon_blueI’m currently seeking security investigators for a research study I’m conducting on cognition and reasoning related to the investigative process. I need individuals who are willing to sit down with me over the phone and participate in an interview focused on individual investigations they’ve worked. The interviews will be focused on describing the flow of the investigation, your thought process during it, and challenges you encountered. I’ll ask you to describe what happened and how you made specific decisions. Specifically, I’m looking for investigations related to the following areas:

  • Event Analysis: You received some kind of alert and investigated it to determine whether it was a true positive or false positive.
  • Incident Response: You received notification of a breach and performed incident response to locate and/or remediate affected machines.

Ideally, these should be scenarios where you felt challenged to employ a wide range of your skills. In either domain, the scenario doesn’t have to lead to a positive confirmation of attacker activity. Failed investigations that led to a dead end are also applicable here.

A few other notes:

  • You will be kept anonymous
  • Any affected organization names are not needed, and you don’t have to give specifics there. Even if you do, I won’t use them in the research.
  • You will be asked to fill out a short (less than five minute) demographic survey
  • The phone interview will be recorded for my review
  • The phone interview should take no longer than thirty minutes
  • If you have multiple scenarios you’d like to walk through, that’s even better
  • At most, the scenario will be generalized and described at a very high level in a research paper, but it will be done in a generic manner that is not attributable to any person or organization.

If you’d like to help, please e-mail me at with the subject line “Investigation Case Study.”

Applied Network Security Monitoring, the book!

I’m thrilled to announce my newest project, Applied Network Security Monitoring, the book, along with my co-authors Liam Randall and Jason Smith.

Better yet, I’m excited to say that 100% of the royalties from this book will be going to support some great charities, including the Rural Technology Fund, Hackers for Charity, Hope for the Warriors, and Lighthouse Youth Services.

You can read more about the book, including a full table of contents at its companion site, here: