Q&A on cyber writing for NIST

I recently did a Q&A session with members of Cybersecurity Club on my experiences writing for NIST, and I had the best time! With their kind permission, I’m sharing edited highlights from that Q&A with you, including a big announcement about an upcoming NIST-related project we’ll be doing at the Annex.

You can join Cybersecurity Club through their Discord for “knowledge, networking, and hands-on learning.”

Q1: Can you tell us about your background?

A: I've been working in IT since the early 90s. I have master's degrees in computer science and technical writing. I've specialized in cybersecurity for 25 years. I've done everything from technical support, training, and auditing to system administration, security architecture/engineering, intrusion detection signature development, and of course security writing and research.

I started supporting NIST as a contractor in 2003, and my first project was writing new guidance on incident response. This was so long ago that most organizations didn't have incident response capabilities. The result was SP 800-61, Computer Security Incident Handling Guide, which became one of the foundational documents that many organizations used to stand up their first incident response capabilities.

In 2006 I became a NIST employee for four years. I did a lot of vulnerability scoring and metrics research, and I co-authored CVSS v2 (the Common Vulnerability Scoring System) and similar systems for scoring software misconfiguration (CCSS) and misuse (CMSS) vulnerabilities. I left NIST because of the three-hour-a-day commute. Since then I've been self-employed as a freelance cyber writer, with NIST as one of my clients.

I've co-authored over 150 NIST publications since 2003. Recent ones include the Secure Software Development Framework (SSDF) and the Cybersecurity Framework (CSF) 2.0.

Q2: What your role is in relation to the NIST guidelines?

A: My role varies a lot from one NIST guideline to another. Sometimes I'm helping mainly with the writing. I make sure the documents are technically accurate and clear and that the writing is crisp and easy to understand. I help make the documents more usable. Sometimes I'm digging into the technical topic, giving myself a crash course and thinking about what would be helpful for people to know.

One super-cool thing about the NIST documents is that almost all of them go out for public comment. NIST literally invites everyone in the world to read the draft and share their insights. Most NIST documents are not specific to the US federal government; they're meant to be used by any organization anywhere in the world.

Q3: What are the top three mistakes you see commonly made in the wild when implementing the guides?

A: Probably the biggest mistake I see is when people think that the recommendations in the guides are really requirements. We purposely use "should" language to say, this is a good idea and something you should do if it's reasonable, but it's not always necessary. Unfortunately, a lot of people treat the recommendations as requirements, and they think they have to do every "should" item or they'll be violating the NIST standard.

With just a few exceptions, such as NIST standards for cryptographic algorithms and protocols, NIST guidance is meant to help organizations but not mandate what they do. It's impossible to write a guideline that is full of requirements and that will work for every organization, large or small, all sectors, around the world. For example, conventional wisdom is that every company needs a written set of cybersecurity policies…but I’m self employed, so I don’t. The goal is to encourage organizations to do what's helpful and prudent, not to waste time on busywork.

Another common mistake I see is that people often aren’t aware of static content becoming dated. People sometimes assume that if the publication hasn't been retired, it's all up to date. It's a reasonable assumption, but unfortunately it's often wrong. The publication may have info that's become false, or there may be significant new developments missing altogether.

Q4: We heard that you are planning to update NIST SP 800-115, Technical Guide to Information Security Testing and Assessment. It has been over 15 years since the release of SP 800-115. What is prompting the update now in 2025?

A: Because of changes from the new administration, I'm not directly supporting NIST much these days. There's not much funding for contractors, so I'm mainly working on my own and that includes doing things that supplement what NIST does. For example, my colleague Matthew Smith and I at Trusted Cyber Annex have been "annotating" the new NIST Digital Identity Guidelines to make them easier and faster for readers to understand and use, and releasing those annotated versions for free.

The original SP 800-115 hasn’t been updated since its original release in 2008. NIST doesn’t currently have the resources (staff or budget) to be updating publications like 800-115. But I have heard time and time again that many organizations, both inside and outside the federal government, are still using it. Some even require its use.

That's not so bad because like most of the NIST guides I've worked on, 800-115 does not address specific tools or technologies. It doesn't provide low-level information on how to do things because that changes so quickly and is so different across organizations, platforms, and such. 800-115 has a lot of stable material like defining basic terms, explaining basic techniques at a high level, and defining approaches for conducting testing and assessments. And much of that may still be OK today.

But a lot of 800-115, especially the appendices, is badly outdated: broken links, content that's no longer relevant, and a lot of developments since 2008 (hello, cloud! hello, AI!) that aren't covered much or at all in 800-115.

So what we'd like to do at the Annex is update 800-115 to bring it to the current day. NIST publications aren't copyrighted, so we can just take what's released as a starting point, then share drafts with the community and get their feedback on what would help them in regards to security testing and assessment. Think of it this way. If your employer or client said "hey, you have to comply with this publication," what would you want to have to comply with that would be genuinely useful and reasonable?

Q5: What are the biggest changes that need to be made to SP 800-115 from your point of view? What needs to be added/removed/revised the most?

A: Obviously strike all the outdated material (like the appendix on what tools to include in a "live distribution CD").More broadly, recognize that a lot of the basic concepts we needed to explain in 2008, because they were new to so many people, are now second-nature to people. I think we can escalate our assumptions. It's safe to assume that people know a lot more of the basics than they used to. But that also means we need to identify what more advanced topics would be helpful for them instead.

I'd also like to make 800-115 more usable. For example, add separate forms and templates that supplement the 800-115 content. Another thought is to put links to resources on a webpage so they can be updated asynchronously from updating 800-115 itself.

Q6: If others want to get involved with NIST security research, what would be the steps for them to do so?

A: The best way to help NIST, besides yelling at Congress to increase their funding, is to read their publications, spread the word about all the great work they do (on a shoestring budget), and if you're knowledgeable about a topic they have a draft publication on, providing them feedback. You can access the full NIST cybersecurity library and sign up for their mailing lists at https://csrc.nist.gov.