Getting started in compliance: Start by doing the right thing

I had a couple of discussions this week about compliance, and the traps of plain old check-the-box compliance, and how to get started in it when regulatory compliance suddenly gets sprung on you.

The key is working backwards. Start with the very reason regulatory compliance exists.

Regulatory compliance exists to force companies to do the right thing. Pure and simple.

My own career experience validates this. I had a few incidents where an auditor scanned systems using the wrong regulatory compliance standard, and guess what happened?

Well, the systems failed, but barely. We’re talking like two items out of dozens. Passing score is 100 percent, so that’s why they failed.

We got them to re-scan with the right compliance standard and the systems passed 100%. But the lesson is that if you know one standard, you stand a fighting chance of being able to comply with another one. And if you just do the right thing in the first place, you stand a chance of being pretty close to compliant. Most likely a few adjustments will get you the rest of the way there.

Now let’s talk about check-the-box compliance.

I evaluated a system last year that was close to being the worst possible system, security-wise. I could completely own their network if I knew the IP address of the system, which is why I went out of my way not to know it. That way when the network gets owned–when, not if, when–I won’t be a suspect.

I’m not sure I could design a worse system if I tried. But the people responsible for enforcing security didn’t want to change it or fix a thing about it, because all the right boxes were checked. A system can be compliant without being good.

Earlier in my career, I observed that we were wasting a lot of time every month. Patch Tuesday happened every second Tuesday of the month. We knew, without fail, that on that day, some patches would come out and that we would eventually have to install them.

Now for the unpredictable part: Sometimes we would receive an IAVA or a TCNO or a NOTAM on Thursday, demanding that we install the patch by Monday. It was rare, and not possible to do–it took a week to test and a week to install, minimum–but it happened from time to time. And sometimes that IAVA or TCNO or NOTAM would take a month to show up, and then it might be due in a matter of days, or sometimes wouldn’t be due for another month.

Not all of the patches for a given month would have the same due date, either. Nor was the due date predictable, at least by any measure I could decipher. Sometimes a critical patch would have a long due date and sometimes a minor patch would have a short one.

And one time–just once in a three-year period–a minor patch came out, and no TCNO ever came out for it, at all. An auditor slapped us for not having the patch installed, in spite of the lack of an order.

I spent more time doing paperwork, scheduling meetings, and writing extension requests than I spent deploying patches. We could have saved a lot of time, effort, and ultimately, money by deploying patches to the test environment on Wednesday, then giving ourselves a week to test and a week to deploy. At the end of the month, every month, we would be 100% compliant. And if an order to patch was slow to come out, I would just report compliance when the order came in.

The guy who ran our change control board wouldn’t let us do it. He was a check-the-box guy, to the extreme. Even though what I wanted to do was better security, better IT, and better accounting, he insisted on checking the boxes as the boxes appeared, and not a moment sooner.

Oddly enough, I think my approach was better compliance, too. If the goal is to be as close to 100% compliance as possible at any given time, my way would have gotten us closer. Literally half the time, we would be a work in progress, with patches either in testing or in the process of being deployed two weeks out of the month. But for two weeks out of the month, we would have no pending patches.

That’s what being focused on the goal, rather than the work, gets you.

Eventually that guy took a different job, and we got to try doing it my way. Nothing bad happened, and I actually had time to dedicate to administering IIS, in addition to my security duties.

I don’t know where I read it this week, but it stated it well. Compliance is the low bar–the minimum. You don’t want to go crazy installing $150,000 worth of security to protect $1,000 worth of data, but refusing to install a patch until the day someone comes and orders you to do it is a couple of steps short of negligent.

If you found this post informative or helpful, please share it!