Security Experts:

The Pen is Mightier Than Hot Air: Why Documentation is Key

I once worked for a boss who would often remind me that “if it isn’t written down, it didn’t happen.”  The more time I spend in the information security profession, the wiser these words appear to me.  You see, we information security professionals are quick to share our opinion on something (whether solicited or unsolicited).  But writing things down?  That we’re not so great at.  We seem to have documentation challenges as a community.

I was recently reminded of the documentation challenges we face.  I was organizing a multi-day workshop recently, and I noticed something bizarre.  When I had people on the phone, they would make suggestions and share ideas.  However, repeated requests to document various different things went unanswered.  I soon realized that in order to document things properly, I needed to essentially record their thoughts as they were dictating them to me.  Once I took this approach, I very quickly achieved the results I was after.  But this example is one that happens over and over again and is indicative of a larger problem we have in the information security field.

Writing is a skill that is developed over time through practice.  For example, there is no magic that goes into writing these articles.  Is it as easy for me to write as it is to analyze log data?  Of course not.  Does that mean I shouldn’t push myself to write down my thoughts so that others can benefit from them?  No way.

But this piece isn’t about me.  It’s about so much more than that. We have a documentation and writing problem in the information security field, and it holds us back. Sure, documentation isn’t exactly the most exciting part of our job.  But it is incredibly critical to a successful security program.

Let’s take a look at a partial (far from complete) list of the reasons why writing and documenting is a good idea:

● Incident response plan:  Having an incident response plan is increasingly important.  Auditors, insurance underwriters, customers, partners, and others want to know that those they do business with understand the need for security operations and incident response, are organized, and have a plan.  Given this, it’s remarkable that many organizations still do not have one documented.  Having an incident response plan is a great way to document security processes and procedures, in addition to showing key stakeholders that you’re committed to and serious about security.

● Risk register:  Do we as an organization understand the risks and threats we face on a daily basis?  Have we documented and prioritized them?  Having a risk register gives us a huge head start when we think about where we should prioritize our investments in time and money.  In fact, without a risk register, it’s hard to understand how any organization can make decisions around where to invest time and money in security.

● Content development:  Detection will likely be one way in which we will seek to mitigate the risks identified in the risk register.  We can build upon the risk register and leverage it to build and document a list of logic and alerts we will use to mitigate various risks through detection.  Having this in an organized manner allows us to document why we have a given alert.  Further, we can map back individual alerts to the risks they help to mitigate.  We can also measure how well a given alert or a number of alerts are helping us mitigate a given risk, as well as whether or not they are polluting our work queue with intolerable noise.  All of these different possibilities open up an entirely new world of metrics that we can report to management, thus helping us bridge the communication gap between operations and executives.

● Process:  Once an alert fires, that is merely the beginning of our work.  We still need to assemble the puzzle of what actually happened through analysis, investigation, and forensics.  We also need to reach a decision regarding what type of response is necessary (if any), and subsequently respond appropriately.  Having the analysis and response processes thoroughly documented makes this process far more consistent.  It also makes onboarding new staff far easier.  Lastly, these processes show us precisely what steps we take and where we may have inefficiencies and waste.  This allows us to understand where orchestration and automation can introduce significant efficiency and productivity gains.

● Key stakeholders:  Which key stakeholders will we need to involved for which types of incidents?  Involving the right stakeholders is an important part of incident response.  It is something that is definitely too important to be left to chance.  Definitely a great candidate for documentation.

● Important contacts:  Who are the right points of contact during different types of incidents?  How can they be reached?  Not surprisingly, this information is also an important part of incident response and also a good candidate for documentation.

● Third party providers:   With so many business functions and applications moving to the cloud, who are the appropriate security contacts at various different third party providers?  This information can be extremely helpful come crunch time and merits documenting.

● Constructive discourse:  Anyone with a Twitter account can be a critic.  It is easy to criticize, mock, and tear down what someone else has written.  But a better approach is to write down how you would approach a given topic differently and why your ideas and thoughts are better.  That is the key to opening up the type of constructive discourse that the information security profession so desperately needs.

I know that writing and documenting aren’t the most exciting activities. But they have tremendous potential, both in improving security operations and incident response, as well as in opening up a constructive dialogue that the information security community so desperately needs.

If someone has thoughts on a topic or wants to share from his or her experiences, there are plenty of outlets for those thoughts. Start a blog. Publish on LinkedIn. Write a paper and submit it to several different journals.

One thing is for sure. If we as a community don’t encourage people to write things down, we can never have the dialogue and communication that’s needed for us to rise to the challenges we face.

view counter
Joshua Goldfarb (Twitter: @ananalytical) is CTO – Emerging Technologies at FireEye and has over a decade of experience building, operating, and running Security Operations Centers (SOCs). Before joining nPulse Technologies, which was acquired by FireEye, as its Chief Security Officer (CSO), he worked as an independent consultant where consulted and advised numerous clients in both the public and private sectors at strategic and tactical levels. Earlier in his career Goldfarb served as the Chief of Analysis for US-CERT where he built from the ground up and subsequently ran the network, physical media and malware analysis/forensics capabilities. Goldfarb holds both a B.A. in Physics and a M.Eng. in Operations Research and Information Engineering from Cornell University.