Category Archives: Writing

Writing for Security: Action Items that Provoke Change

quillMost people don’t realize it, but the success of what you write will probably be measured by how actionable it is. I’ve read hundreds of security assessments and forensic reports that go into a perfect level of detail, only to find that they fall short of delivering what every report needs: something actionable.

Imagine watching a great movie. They’ve done a wonderful job developing complex characters, the plot engagingly builds, and you’re on the edge of your seat the entire time. Right as the climax is happening and the story is coming to it’s pivotal point…the credit start rolling. It’s over. Although you might have enjoyed the couple of hours you invested up unto that point, you’re going to walk away with a bad taste in your mouth because you were robbed of a satisfactory conclusion. We all know movies like this, and usually chalk it up to lazy writing. This is exactly what you’re doing when you write without providing something actionable.

Whether you’re writing a security assessment report or an incident response report, your purpose isn’t merely to inform, it’s also to persuade. It isn’t enough that someone knows there is a vulnerability on their network. They have to be persuaded to implement controls that mitigate the risk of that vulnerability. It doesn’t matter if your forensic report does a good job explaining how an attacker got in. It has to persuade the reader to implement the necessary process changes or install the right tools to prevent it from happening again.

There are plenty of techniques you can use to be persuasive when you write, but before you do that you must identify what you want the reader to do. These are your action items, and the ability to identify them is what makes you an expert. Plenty of people can find vulnerabilities or find evidence of an attacker, but if you can’t identify actions to mitigate the risk associated with those findings then you’re report isn’t useful.

Identifying action items is all about mitigating risk. You should give the reader advice that prevents bad guys from doing some thing, or detects when they do it. You should always do both when possible.

Prevention Action Items

Prevention is as simple as making changes that keep bad things from happening. If you can give your reader steps they can take that prevent an attacker from doing something, that’s usually a win.

In reporting, I like to conceptualize change in terms of how difficult it is to accomplish. After all, it’s a lot harder to persuade someone to make a change if it’s going to be insanely difficult. Part of good writing is being honest with your readers, so it helps if to identify the level of effort required with a requested change. If it’s going to be easy you should make that clear so the reader is compelled to do it quickly. If it’s going to be difficult, be up front about and break it into steps. Your readers will appreciate this and will trust you more.

Changes will typically be categorized in terms of people, process, and technology.

  • People: Changing mindsets, providing training, hiring new staff, replace existing staff.
  • Process: Changing the way human or tech-centric things are done, adding new processes.
  • Technology: Configuration changes, additional software, new technology.

In most case, technology changes will be the easiest and people changes will be the hardest. It’s easy to manipulate systems, but it’s very difficult to acquire new people or change the way existing people think. The latter requires a lot more political and financial capital. This hierarchy of difficulty is how you should approach identifying prevention actions in your report. You should also report them in order of easiest to hardest within each individual finding.

In a lot of cases, some changes might touch all three areas. For example, building a security operations team requires hiring new people, building new processes, and implementing new technology. These massive changes should be saved for last and you should provide plenty of ancillary resources for the reader, as they will often involve topics that need to be covered in much larger depth.

When you are ready to start identifying action items, it’s helpful to ask yourself these three questions, filling in the blanks with the pertinent details from the finding you’re addressing:

  1. Are there any changes that can be made to prevent an attacker from __________?
  2. Is there anything new that can be done to prevent an attacker from __________?
  3. Is there anything that should be stopped in order to prevent an attacker from __________?

Let’s look at some examples of common findings and their action items. Notice that some action items combine categories, and some categories aren’t present.


Security Assessment: Web Server – Utilizing Plaintext Authentication

  • Technology: Change authentication method


Security Assessment: Local Windows Admin Account – No Password Rotation

  • Technology: Purchase password management software
  • Process: Institute manual change process


Incident Report: Attacker Guessed VPN Password

  • Technology: Institute lockout after three failed authentication attempts. Enforce stronger password requirements and more frequent rotation.
  • Technology + Process: Implement two-factor authentication.
  • People: Train users to use passwords that can’t be easily guessed


Incident Report: Workstation Compromised Because User Clinked Phishing Link

  • Technology: Install an e-mail threat protection appliance.
  • Process: Force users to use non-admin accounts and escalate privileges when administrative actions are needed.
  • People: Provide phishing awareness training to users.


Incident Report: Attacker Moved Laterally with Ease Due to Flat Network

  • Technology: Architect network for better segmentation.


These are just examples, but you can see where we started with technology and moved towards people. In most cases, the technology solution is going to be the easiest to implement in terms of labor hours. Of course, this doesn’t mean that a technology solution is always the best, but it is a step in the right direction. You want to give the reader the easy wins so they are more compelled to keep working towards to bigger wins. The first step is the hardest to take.

Detection Action Items

Detective controls are designed to detect when bad things happen. The vast majority of reports you’ve read probably don’t include them, which is a shame. Whenever you are making preventive recommendations, you should also make detective recommendations. There are a few reasons why:

  • Many organizations won’t be able to implement protective changes in a timely manner, or at all due to political or budgeting restraints.
  • Prevention eventually fails, and a key tenant of security is having multiple layers of controls.
  • The findings you’ve identified may have already been exploited, and an ability to retroactively detect this can help uncover a breach.

If you’re a consultant, writing detection action items can be difficult because there are a wide array of detection technologies. It’s hard to tailor detection content exclusively for a single customer without an intimate knowledge of their detection strategy. As a place to start, consider asking your client about their detection strategy and relevant technologies so that you can tailor your recommendations to them. This can be a part of the initial scoping call.

If you’re findings are related to your own network, or you’re writing a blog post, it’s a lot easier provide detection action items based on the precise technologies your using, or at a minimum prevailing open source standards. You can start with these questions:

  1. Are there any network-based indicators that can be used for detection?
  2. Are there any network-based behaviors that can be used for detection?
  3. Are there any host-based indicators that can be used for detection?
  4. Are there any host-based behaviors that can be used for detection?

This isn’t all encompassing, but in a lot of cases you will be able to derive some type of host or network based indicators or behaviors. An indicator can be something simple like a list of MD5’s or domain names, and will usually be representative of known evil. A behavior is usually more complex and will indicate a behavior that is normally legitimate, but could be the results of an attackers actions in some cases. This might be an action like a user account being added to an administrative group, or the use of the command “ping -n 1”. Both normal activities, but something that might not be done too often and worth of investigation in relation to the identified activity as it relates to the attacker or breach you’re describing.

In all of these cases, recommendations towards specific technologies are what will differentiate you. Don’t just give someone a list of domain names, also give them a Snort or Suricata rule that will detect them, including relevant context and information links. Don’t just give someone malware characteristics, give them the YARA rule to search for it. You might think that’s time consuming, and you’re right. Don’t be lazy! If you truly want to promote change and you expect your reader to go the extra mile, you’re writing has to do it as well. Something as small as creating a 10 line bash script to detect something will endear your reader/client to you forever, and will show your hands-on expertise.

More on Writing

If the things you write require the user to take action, you’re going to have to work harder to get them to do it. Just because you’ve written a very clear and informative statement on what a problem is and how to fix it doesn’t necessarily mean someone will take the action you want. The easier you can make this for people, the more they will be likely to actually pursue your recommendations. Going the extra mile in your writing will be rewarded with actions. If you can outline some prevention and detection action items, you’ll be writing content that will get people moving.

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: Making People Give a Damn

quillIf you really want your technical content to matter for people you have to appeal to their needs. There are primary needs like food, water, sleep, or sex, but it’s difficult to tie those things to malware analysis or threat intelligence reports. If you look to secondary needs you will find things like employment, resources, morality, family, self-esteem, confidence, achievement, and respect. Hopefully, a light bulb went off when looking at this list. If you really want people to care about your content you have to appeal to one or more of these things. Let’s dig into a few of them.

Employment, Achievement, and Respect

I want to lead with employment because it is the secondary need most tied to primary needs. Everyone needs to eat, and unless your Silicon Valley startup actually made it past the second round of funding you probably need a job to buy food for yourself and your family. If your writing can appeal to someone’s need for employment, they are going to care about it.

Tangentially related are achievement and respect, because everyone wants to achieve success in the workplace and be respected while doing it. These are grouped together because most believe that being well respected and achieving positive things will lead to further career success. In most places this is definitely true.

When you’re writing something, ask yourself if it will help someone get a better job or a higher salary in their current job. You may want to think it’s much more complicated than that, but it really isn’t. You may be a person who says “Chris, I’m not in this line of work for the money, so I can’t relate to that.” If you were being completely honest with yourself, you certainly wouldn’t do your job for free, or probably even for half of your current salary. You have to eat and you have to provide for your family and so does everyone else. If you can write something that helps your reader do that, you are appealing to primal psychological needs and people will gravitate towards that.

The best way to appeal to these needs is to provide an opportunity for meaningful action. That action will vary depending on what you’re writing, but here are a few examples:

Penetration Testing Report [You want the reader to fix a finding]:

  • An example of how a finding would be exploited so it can be independently validated and recreated.
  • A news story showing how a similar finding was attacked that can be used to justify the time/resources to fix it to management.
  • A detection signature that can be applied to a Snort/Suricata/Bro IDS so the user can detect exploitation if it can’t be fixed in a timely manner.
  • A list of log types that can be ingested by a SIEM if detective controls are a primary risk reduction strategy.

Threat Intel Blog Post [You want the reader to defend against this threat actor]:

  • A diagram showing the flow of the attack and where protective/detective controls could be applied.
  • Reference links to attacks conducted by this threat group that can be used to justify the time/resources to fix it to management.
  • A detection signature that can be applied to a Snort/Suricata/Bro IDS to that can be used to detect actor activity.
  • A listing of network and host based artifacts that the user can build into their own detection infrastructure and SIEM.

Alert Investigation Ticket [You want management to provide funding for bigger sensors]:

  • A timeline showing the flow of the investigation and areas where it was stalled due to lack of visibility to justify the ask to management.
  • A hypothetical description of how the investigation could have gone and how much time might have been saved if more data was available.
  • A list of the exact type of sensor you need along with a broad cost estimate.
  • A success stories from a colleague/peer who has the level of visibility you desire.

Forensic Report [You want the company to educate users on spear phishing]:

  • A diagram showing how an attacker was able to gain an initial foothold into the network by phishing a number of users.
  • Industry reporting on statistics of users who are susceptible to phishing.
  • Links to news articles of other breaches showing how phishing was a primary attack vector.
  • A guide explaining how the IT staff could conduct a phishing test with the user base to determine how vulnerable they truly are.
  • A list of vendors (or if you’re a vendor, a price quote) on performing an external phishing test.
  • Links to free or paid phishing awareness training programs.
  • A list of tips that can be e-mailed to all users within the company.

If you give the reader a chance to take action from your writing then you’re giving them the chance to achieve something and to gain respect from their peers and boss by doing it. Doing this in a way that truly empowers them is a bit of a balancing act, which we’ll talk about next.

Confidence and Self-Esteem

Nobody likes feeling stupid. If you write something with a lot of technical detail it’s probably a good thing, but if it goes so aimlessly in–depth that it goes over the head of most people reading it, they aren’t going to connect with you. Appealing to primary and secondary needs doesn’t matter if your reader walks away thinking they aren’t smart enough to do anything about the problem you present. That’s why it’s so crucial to go the extra mile. In infosec, your goal is usually to inform, but it’s frequently to persuade. If you want someone to head down a path towards a goal you must realize that the hardest step for them to take is the first. The more work you can do for the reader up front, the more likely they are to take that first step. This means providing actionable examples and step-by-step guides that get them moving. This is more work on you up front as the author, but readers don’t reward lazy writing.

If you provide a call to action that asks the reader to write 10,000 lines of code or change the entire culture of their corporation, they aren’t going to feel confident enough to act on it. There’s a place for that type of writing, but most of the time it shows laziness on your part for not going the extra mile to give them actionable techniques for getting started down whatever path your trying to get them to take.

Figuring out where to position your material can be tricky, but there are a few things to think about when writing it:

  • What’s the lowest common denominator you are trying to appeal to?
    You don’t have to dumb everything down far enough that someone with no experience should be able to get going, but you should assume that most of your readers aren’t as smart as you. If they were, why would they need to read what you’re writing?
  • What is something the reader can do today/tomorrow/next week?
    If you can phase out your action items over the course of time it makes it can make a larger task become less overwhelming. Even something as simple as downloading a tool or sending an e-mail is a step. If the reader can accomplish that step, they are going to build confidence and be more likely to accomplish the next step. It’s a snowball effect.
  • Where can the reader learn more about the concepts they need to make this actionable?
    If you are correctly assuming the reader isn’t as knowledgable about the topic as you are, then you need to do whatever you can to minimize that gap. If you want them to take action on something they don’t know much about, you absolutely must provide reference to resources where they can learn more. If you want a user to write a signature for a malware family, link or provide supporting information about the techniques the malware uses and the libraries it relies on. If you want a user to fix an XSS vulnerability in a piece of code, link or provide examples of different types of XSS protection and libraries that demonstrate different techniques.

If you read all of this and don’t think you need to go the extra mile because your writing is to inform and not to persuade, then I’d say you’re probably fooling yourself, or you’re a lazy writer. Both will result in content that isn’t appealing to your readers, and it will be forgotten.


One of the oldest debates in history is whether mankind is inherently good or evil. I’m certainly not going to solve that debate here, but I think it’s safe to say that you probably got into information security because you have some sense of right vs. wrong. In most cases, the network you are protecting or assessing represents good, and the real or hypothetical bad guys who want to steal something from it represent evil.

Whether it’s nature or nurture, most humans have a sense of morality from a young age. Whether you realize it or not, you’ve built archetypes of the good guys and the bad guys and in most cases you probably want to be the guy with the cape saving the day. This is important to consider when you write, because if you can tap into someone’s sense of morality then you are going to reach parts of the reader that most writing can’t touch.

I want to be clear on this that I don’t want you to start making moral decisions for someone. In our field, it’s ridiculously easy to stumble into a debate about things like privacy vs. security, and you probably aren’t going to change someone’s mind there. Furthermore, a lot of people enter a way of thinking in irrational ways. Cognitive psychology tells us that someone who enters a line of thought irrationally is not likely to leave that mindset because of rational though. The goal isn’t to manipulate someone’s sense of morality; it is to appeal to it by causing the reader to ask questions.

So what if there is a new piece of malware being used to attack agriculture companies? These companies are targeted all the time. Nobody is really going to care about that unless they work at one of the targeted companies who were affected. Now, what if you consider that the malware caused a significant financial loss that led to a Q2 earnings miss resulting in layoffs of hundreds of people? That changes things a bit. Because someone used the malware to attack this organization, real people were hurt, and the reader will ask themselves whether this is morally wrong. Again, your job isn’t to tell people it’s wrong. Your job is to get them to ask themselves where this action points on their moral compass.

Getting people to ask questions about the moral disposition of something isn’t always easy, and it often requires some digging. One method for getting to this point is by using the 5 Why’s method. Take a fact that you are writing about and ask yourself why it matters, then ask yourself why that matters. For example:


Hypothetical Fact: A government contractor was the victim of an attack, resulting in the theft of intellectual property

  1. Why does that matter? The attacks on the government contractor was linked to group X due to similar TTPs
  2. Why does that matter? Group X is comprised of operators believe to be North Korean
  3. Why does that matter? North Korean threat actors have attacked a number of western media outlets and government contractors and are advancing their capability
  4. Why does that matter? The North Korean government has expressed interest in harming western countries through advancing weapons technology
  5. Why does that matter? If North Korea succeeds, the consequences could result in conflict or war.


Hypothetical Fact: A newly discovered piece of malware redirects users to a site that scrapes their social media profile if they are logged into Facebook and harvests personal information

  1. Why does that matter? An unknown attacker could gain access to your personal information.
  2. Why does that matter? The attacker could use this personal information to obtain more information about you through social engineering or password reset questions.
  3. Why does that matter? The attacker could collect enough information to steal your identity
  4. Why does that matter? The attacker could cause significant financial loss or ruin your credit score, preventing you from being able to take out a loan on a car or home.


In both of these examples, I’ve presented scenarios that mirrors things you’ve probably actually read at some point,  and gone through a process to translate them into their core; things that should provoke questions of morality. Is it right/wrong for North Korea to start a conflict? Is it right/wrong for someone to steal your identity? In these cases both answers are probably pretty clear-cut. In a lot of cases it won’t be so obvious. The important thing is to get people to ask the question.

More on Writing

Writing is a lot more enjoyable when people care about what you’ve written. In the current security landscape you can’t go more than a couple of days without someone writing a blog post detailing the latest threat actor campaign or malware they’ve discovered. If you’re responsible for writing content like this, whether internally or externally, appealing to primary and secondary needs will guarantee that people care more about what you have to say.

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: Making it Matter to You

quillIn the last two posts in this series I talked about why writing was painful, and why most people are afraid of it. If you stopped with those you might run away screaming and never write another thing again. Alas, things are going to take a positive turn. In this post I’m going to talk about why writing matters. Specifically, I’m going to talk about why it should matter to you. I’m not talking about fluffy, generic reasons. I’m talking about real reasons that matter like making more money, getting more time to do what you love, and impacting real change in an organization.

Getting a [Better] Job

Simply put, the need to communicate your knowledge effectively on paper isn’t going away. No matter how good you are at the technical aspects of your profession, the ability to relay your expertise in writing can be the difference in succeeding in your current job, getting a promotion, or landing your dream job.

I conducted a survey amongst several individuals I know responsible for hiring and promoting penetration testers and incident responders. I asked two questions:

In candidates you’ve interviewed, what is the primary reason you didn’t choose to hire them?

35% cited a lack of effective communication skills

For existing employees, what is the primary reason you didn’t choose to promote them when a career advancement opportunity was available?

41% cited a lack of communication skills

Of course, communication involves more than just writing. However, after talking to nearly all of these managers after the survey, they all explicitly called out a lack of effective writing ability in the majority of their employees.

One manager went on to tell me, “any time I find someone who has great technical skills and can write effectively, I feel like I’ve discovered a unicorn.”

Another manager said, “I just don’t expect someone with strong technical skills to be a great writer. We just hope they’re good enough, but if someone comes in excelling at both then they’re much more valuable to the organization.”

If you have an ability to write well, it will differentiate you amongst your peers.

Getting more time to hunt, pen test, etc

If spending time writing prevents you from being able to do the fun part of your job, then investing time improving your writing skills might seem counter intuitive, but it shouldn’t. Being a better writer doesn’t simply mean that your work is more fun to read (although that’s another benefit). It also means that you’ll start building a toolbox of writing techniques based on your system.

Let’s put this into perspective. Let’s say that you’ve discovered a SQL injection vulnerability in a web server you’re testing. SQL injection isn’t always super fun to exploit (until you succeed), and writing about it can be even worse. You have to relay how you spent hours painstakingly changing field input one character at a time until you were finally able to find the right combination that allowed you to start dumping database tables. The scope of the engagement is limited so you don’t have time or authorization to show the system owner the real damage that could be done with this type of vulnerability, so you have to find a way to relay the importance of it, along with your recommendations for mitigating the risk.

Instead of writing all of that information from scratch, imagine a scenario where you’ve created two or three methods for effectively relaying the stellar work you’ve done in your report. When you get to this point, you’ve essentially developed variations on a script you can use every time you have to write about web vulnerabilities. We aren’t talking about simple find-and-replace templates here. We’re talking about a dynamic system that allows you to tell the reader a story and make it matter to them.

By assigning roles to your characters (the attacker, the system, and the vulnerability) you can create a sense of plot. While you may not naturally excel at technical writing, most people are good at telling a story. When you can build a system around your writing that simplifies it into story telling, it makes the process that much faster. You won’t waste time anymore and you’ll get to spend more time catching bad guys or breaking things.

Provoking change

Going back to the pen testing example, a simple description of your finding and how it can be exploited might give the report recipient enough information to act on, but will they? My experience tells me they won’t a lot in many cases. If you don’t paint a good enough picture of what could happen if they don’t act, then your next interaction with them could be finding the same vulnerability a year later, or worse, getting a call that they’ve been breached.

All things being equal, the ability to write remarkable content is what separates action from inaction. If your report doesn’t do a good job of explaining why someone should care about a finding or occurrence, then they aren’t likely to take action to mitigate or remedy it. You have to make it real for people, or they won’t care. It’s basic human psychology. If you can appeal to someone’s primary or secondary needs, they are more likely to take action. Primary needs like food, water, sleep, and sex are a bit tricky, but secondary needs are much more approachable. This includes things like employment, resources, morality, family, self esteem, confidence, achievement, and respect. If you want to shift your writing from informative to persuasive, you have to appeal to one or more of these areas.

Remember as well that change doesn’t only come from reports. Your blog is a powerful tool for this as well. In many cases, a highly actionable personal blog that appeals to the needs of an organization will cause more change than all the external assessment reports in the world. With proper motivation, expertise, and experience this is something that we’re all capable of.

At most, great technical writing can help you land a better or hiring paying job, or provoke change in an organization that could help them defend their networks against attackers. At worst, it could help you develop systems for writing that speed up the process and allow you to spend more time doing the parts of the job you really love. I’ll continue to talk about more these systems and ways to make your writing matter more as we go along.

More on Writing

Although you might not enjoy writing, being good at it can have a profound impact on your career. When you choose to embrace this, you can start developing the systems that will allow you to differentiate yourself in positive ways. In the next few articles I’ll start introducing more of my personal strategies for better technical writing so you can get a better job or get more free time as well.

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