Writing for Security: Why You Fear It

In 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.

1 comment on “Writing for Security: Why You Fear It”

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.

Stay Updated!

I use my mailing list to send out exclusive content, training discounts, and it's the best way to stay up to date on new classes I conduct on topics like network security monitoring, packet analysis, technical writing, and more.

* indicates required

Email Address *

First Name

Last Name

Applied Network Security Monitoring

Applied Network Security Monitoring is the essential guide to becoming an NSM analyst from the ground up. This book takes a fundamental approach, complete with real-world examples that teach you the key concepts of NSM.

Practical Packet Analysis

It's easy to capture packets with Wireshark, the world's most popular network sniffer, whether off the wire or from the air. But how do you use those packets to understand what's happening on your network? This extensively revised second edition of the best-selling Practical Packet Analysis will teach you how to make sense of your PCAP data.

100% of the author royalties for sales of Practical Packet Analysis go to support the Rural Technology Fund

Rural Technology Fund

Established in 2008, the Rural Technology Fund (RTF) seeks to reduce the digital divide between rural communities and their more urban and suburban counterparts. This is done through targeted scholarship programs, community involvement, and the general promotion and advocacy of technology in rural areas.