Guiding the NSA Security Guides

Guiding Principles, Using Principles

I spent most of my National Security Agency (NSA) career as a manager of technical organizations. While I tried to do my best, I don’t think I consistently followed any specific management philosophy or style. But there’s one tool I come back to repeatedly. Here’s how it started.

In August of 1998, I became the Deputy Chief of the System and Network Attack Center (the SNAC, also known by the internal designator “C4”). As part of the defensive mission at NSA (Information Assurance), the SNAC performed the security analysis of a wide range of software and network technologies. One of our 4 Divisions was the NSA Blue Team, which conducted cooperative testing of operational (“real life”) systems for the DoD and other customers. And a byproduct of their testing was a collection of recommendations for Windows NT loosely known as the “NSA Configuration Guide” (also known as the “NSA Security Guide”).

The NSA Configuration Guide was very well regarded and included analysis from across the entire SNAC. It was used as both a training guide and a handout to select customers. In the very late 1990’s, organizations across the industry started to recognize the importance of security configuration management as a bedrock principle of defense, and we saw the early days of very similar things like DISA STIGs, NIST Checklists, and the non-profit Center for Internet Security’s Benchmarks (later, in 2000).

Paul Bartock was the Team Leader for the NSA Security Guide (he might have been the Technical Director of the NSA Blue Team by then). Very early in 2000, he stopped by my office and said, “Tony, our Windows NT Guide is great, but Windows 2000 is coming to the DoD. We’ll be dealing with thousands more recommendations (registry keys, etc.) to consider. And Windows NT won’t be going away for a decade or more in the DoD. I don’t think we have enough resources to keep them both current.”

We talked a bit, and I asked Paul to ”make me a list of every government agency that has created something like our Windows NT Guide, and let’s see who wants to work together instead of separately.” To make a long story short, throughout an afternoon, the list went from about 14 government sources to less than a handful. (Lessons for me: This was lunacy. Did we have 14 different problems to solve in the USG? And why do so many government programs start with a bang and a bag of money, but with no plan for sustainment? We also contacted industry, which led to my initial connection (via Alan Paller of SANS) to the newly formed Center for Internet Security.

So Paul and I discussed bringing together several public-private organizations around Windows 2000 (W2K). It would take a lot of coordination and “cat herding” across government and industry. And there was a surprising amount of internal NSA controversy around the Guide, also: Who should oversee it? Why should we cooperate with those other Agencies? Shouldn’t it be an internal-only document? Operational guidance seemed like grunt work compared to ‘real’ analysis – shouldn’t NSA leave that to others? Was it an NSA mission at all?

Before Paul started the project and the outreach, I called him in and handed him a piece of paper, titled “Guiding Principles for C4’s Development of a W2K Configuration Guide” (dated March 2000). Sorry for the ratty image, but this is a copy of a photo of a copy of……

“Paul, this is your project, and it will get complicated. There’ll be a lot of “cat herding”. And tough decisions you need to make. If you ever have any doubt about what to do, look here first. If that doesn’t help, then see me and we’ll figure it out together. “

To be clear, Paul didn’t need this list to understand what we were trying to achieve – we had already figured out that part together. This simple list was primarily “top cover” for him to run the internal NSA team. I wanted a clear statement to the team that the greater good would be served by agreement, not by NSAer’s arguing that they were smarter than folks from other Agencies, or that our ideas were better than “theirs”. And to remind people – internally and externally - that it would take a lot of cooperation to create significant, positive change. We’re not interested in publishing some grand stone-tablet shelf-ware.

There’s an even longer, more complicated story to tell. But for now, I think of this work by NSA, NIST, DISA, SANS, CIS, and many others (yes, including Microsoft) as one of the industry’s high-water marks of collaboration in operational security management. The work was endorsed and announced by the President’s Cyber Security Advisor Richard Clarke in July 2002. The US Air Force CIO (John Gilligan) announced that these benchmarks would be integrated into their future procurements. The Center for Internet Security released free measurement tools. NIST also published “Security Administration Guidance for Windows 2000 Professional,“ featuring implementation details and security templates for rapid deployment.

Also note, this is the first documented note I have that we intended to release this work to the public, which happened in June of 2001. Another story, another day.

I’m not sure how important the Guiding Principles were to Paul’s work as Team Leader. But the act of writing them was certainly important to me. The exercise forced me to think about the greater goals and impact that we might achieve through community cooperation and by thinking through the life-cycle applications of the Guide. It also allowed me to “name the game” internally, to point out that NSA’s “cultural trap” (every organization has them) was “intellectual arrogance”.

This general idea of “Guiding Principles” has stayed with me the rest of my career, sometimes written down, sometimes not. For example, after retirement, when I eventually took over the Critical Security Controls project from SANS, the first thing I did was write down Guiding Principles for Development of the Critical Controls – a tradition that continues today at the Center for Internet Security. The general idea is to establish the Principles - with the Team - up front, and use them as a reminder of what we are trying to achieve, to define foundational behavior, and to show how to resolve disputes.

I did something similar when I joined the Center for Internet Security in 2015. Here’s a version of the original Principles, but with “Notes” added sometime in 2016 or after.

And please enjoy a chuckle at my last note, “tell me who to schmooze”. A treasured gift (from a treasured colleague) on my book shelf is “The Golden Rule of Schmoozing - The Authentic Practice of Treating Others Well”. One quote: “Schmoozing is the Golden Rule at full throttle.”

Maybe I do have a management philosophy after all.