STIGLord Begins

I would have loved to kick things off with a technical deep dive, but I'm waiting on some things to simmer in the background. Instead, I'm going to give you some of the history that drives my thought processes. When I joined my current team back in 2017 I felt like I had finally arrived, even though I was frantically teaching myself all of the ins and outs of the technology, policies, and processes present at my new workplace. The position was pitched to me as becoming the "virtualization guy" on the core infrastructure team. I had been a "network guy" for an ISP for about 7 years (and loved what I did). Then, I spent the next 7 in the world of Government acquisitions. (Business and regulatory hell, how lovely!) Still, I was excited to be somewhere new. Besides, how much could there possibly be to learn?

Then reality settled in. The chief administrator was in the process of molting into The Overlord over the entire team supporting the lab and its associated testbeds. There was another administrator who was young, but gifted beyond normal human means. (Seriously, the man is way beyond the casual definition of smart.) Unfortunately, he was away finishing his Master's degree. I wouldn't meet him face to face until months, maybe year later. We had people who handled things like patching, antivirus, network stuff, hardware support, compliance paperwork, management, etc. Thank goodness for all of my new friends, too, because I had to learn. Fast.

And not just virtualization. Oh no. The group policy structure alone was something that might give a lot of folks nightmares. It required someone showing me the method behind the apparent madness before I saw the sheer genius behind the design. (Remember the administrator away at school? Again, Brilliant with a big B.) The job really entailed doing anything and everything it took to keep the lab running. It's in this backdrop of rapid learning and my poor mind slowly starting to unravel that I heard those dreaded words.

"Hey, have you ever done STIGs before?"

This was back in what was, for me, the bad ol' days of our enclaves. You see, we supported the customer's Research, Development, Test, and Evaluation (RDT&E) mission. The general attitude at the time had been one of "Eh, we're not an operational site, so it doesn't matter." This was before buzzwords like "digital supply chain" existed. I knew better, even back then, but I didn't know how to get to a more compliant end state. I was still in reaction mode trying to fix every problem that popped up. Domain replication woes, VDI pools blowing up, smart card login suddenly failing after a patch distribution, accidentally rebooting a live hypervisor #3 from one network when I meant to do the #3 on another network that was already in maintenance mode? Yeah, that was my life.

So no, I hadn't "done STIGs" before. At the time, it sounded like I was being asked if I had consumed some kind of designer drug. Boy, I had no idea how close to the truth I was. For those who stumbled in here by accident, STIG stands for Secure Technical Implementation Guide. These documents contain recommended settings that are intended to provide a more secure computing state. The Defense Information Systems Agency (DISA) publishes the STIGs. You would think that something with the word Guide in the name would be just that, but it turns out in the DoD that many folks consider STIGs to be The Law, which is hilarious given how poorly thought out some of the individual guidelines can be sometimes. Still, we're held to them like some kind of oppressive standard, so comply we must.

My soon to be very good friend and amazing teammate had come back to work, and we endured an inspection called the Command Cyber Readiness Inspection, or CCRI. We busted our humps applying setting after setting. Now, my approach up until this point had been manually grind until my eyes bled. Yes, I had shortcuts, and yes, I had some minor scripts to help me achieve results more quickly, but we had not taken the deep dive into scalable automation at this point. It was only through sheer effort and the amazing combined skill of our entire team that we managed to cruise through the CCRI when DISA finally showed up.

The experience of going through that inspection and all of the prep work ahead of time was unpleasant, to say the least. We were very stressed, and we had pulled out all the stops and employed every dirty trick we knew at the time to get everything ready. Then, the two of us made a single decision that would drive everyone around us nuts:

We would change our entire design philosophy from "We're RDT&E, it doesn't matter" to "Compliance first, exceptions allowed with documented mission need."

In the beginning, that meant a lot of manual STIGs, but over time we added technology and learned skills that empowered us. The powers that be eventually added another member of our team, and we started learning even more by teaching each other things and cross-pollenating our skillsets. We learned about automation products like Ansible (my favorite, no sarcasm). We converted our environment from 100% Windows to about a 60-40 split between Windows and Red Hat. We learned to do weird things with PowerShell, Python, BASH, and a host of other scripting options at our disposal. Our resident genius taught us the technical specifics on a lot of the things we encountered while I played the role of diabolical mastermind, tossing bits of inspiration around while we made our twisted dreams a reality.

We continued to refine our processes, create and streamline documentation artifacts, and employ automation to the point that many of our internal assets build themselves because we have defined them "as code". We can do more in less time and with less effort because we've become the masters of applied laziness. We even added three more members to our team, two of whom are fresh out of college. They continue to amaze me with how quickly they digest what we teach them. Somehow along the way, I became the supervisor for the support contractors in the lab, and my friend the inhuman genius become the Government lead over the infrastructure team. So now we juggle management and leadership roles along with our technical load. It takes a special kind of crazy to love this work, but love it we do.

We still have a ways to go before we achieve our true goal of "It'll build itself, and they can show up or not; we don't care." Field of Dreams, this isn't. Instead, we're building the dream that will build itself. Honey Badger style. We're eating cobra for lunch, and there isn't a whole lot anyone can do about it.

So yeah, TLDR: Had a bad experience with a CCRI, decided to work smarter, not harder. Things STIG themselves now.