"... but you won't tell me how to fix it." I remember that quote coming out of my mouth when I was dealing with auditors from one of the big accounting firms many moons ago. My point is if you are going to tell someone that what they have is wrong, you need to be able to provide expectations of what is right. And those expectations should be realistic and doable.

The auditors had an issue with a control we had in place, saying it wasn't good enough. The control was the collecting of event logs on a daily basis, with a subsequent review. The collection and reporting were automated. They didn't have a problem with that. The events were being reviewed. They didn't have a problem with that either. What they had a problem with was that it wasn't "in real time."

So that naturally begged the question, "What's you definition of real time?" I got some hemming and hawing, and in what is in hindsight an unprofessional approach I said something like, "In physics we talk about instantaneous velocity and things like that. Is that what you mean by real time? If you don't mean that, why isn't daily good enough?" And I got the blank stares that said they didn't understand the phrase "instantaneous velocity." I figured they wouldn't, which meant we were stuck. Hence the reason I say in hindsight it was unprofessional. It did nothing to further the conversation or solve the issue. It was a hidden jab, and one I delivered because I was furious. This was the latest in a long line of controls they had deemed were inappropriate yet provided no guidance on what was appropriate. While my reaction was inappropriate, my frustration was justified.

I calmed down and then I took a different approach. They were a big accounting firm. They had Windows Active Directory, they had SQL Server, they had many of the same technologies that we did. So I turned the question back on them. "Okay, our controls aren't sufficient. You run the same technology we do. I'm assuming your controls are considered sufficient, right? What do you do?" Again, I got blank stares, but for a totally different reason. They understood what I was asking. They just didn't know the answer. It was a valid question, and one which they had no "out." Either their controls were insufficient or they could tell us what they were, we adopt them, and then we were good from their perspective. So they went back and asked around. Two weeks later they came back. I asked if they had defined what "real time" was with regards to their systems. Turns out it was... wait for it... daily. Same as the control we currently had in place.

If I say a level of auditing isn't sufficient, I should be giving what is enough. If I say a bit of code is not acceptable, I should be able to say why (you used a cursor when the solution for a set-based operation was easily doable is one example). If I say anything isn't good enough, it doesn't do anyone any good if I can't share what is acceptable. A second part to that is the expectation must be realistic and doable. If I expect auditing "in real time," I had better define "in real time" because that literally means as the event happens. It doesn't take a physicist to see that isn't going to be able to happen. Likewise, if I want to institute a control, like no DBAs in the local Administrators group, it had better be doable. If the server administrators cannot provide the level of support needed in a timely manner to meet SLAs, then the audit control makes no sense. On the other hand, if the server admins are that responsible, then the control is realistic and doable. Otherwise, what's the point?