When security takes a backseat to process…

Stick — Mon, 16 Feb 2009 15:54:16 +0000

We are currently going through an ITIL implementation. It’s had it’s ups and downs and philosophically I don’t really believe in it (certainly not in our implementation), but it’s had a few successes and a few failures. Without droning too much about it, to make any ‘production’ change you have to file an RFC that gets reviewed by a management team. There is a relatively recent DNS attack that involves using root zone recursion to DOS a target server. We’re vulnerable to being used in this manner. It really doesn’t affect us much as that our servers handle the requests fine, but we’re assisting in a DDOS and that’s not good. For us the fix is pretty straight forward, because of some historical decisions we have to allow recursion for certain ips, so I need to segment things off into a tighter view and eliminate recursion there. This is a pretty straight forward change and one that I would do without a second thought (after testing). Due to our current climate of process I have to file an RFC, which is fine, I’m not real happy about it but I’ll live.

However my RFC was denied not because of any technical reason, not because of any concern over the technology, the implementation, or the timing. It was denied because I didn’t put the correct information into the details page and because my dates were wrong. I’m all for doing process right (when it makes sense), but does it make sense to derail a security fix for 4 days because the form was incorrect? Especially when there exists a forum in which you can be asked to clarify anything regarding your RFC.

Now when security takes a backseat to process, your organization has truly begun the decent to failure. This may indeed be the straw…

Miscellaneous Ramblings » process

When security takes a backseat to process…