Change Management, Incident resolution, Emergency modifications, infrastructure updates, database flushes, reboots, process kills… all these IT functions in very large organizations have a tracking and approval system around them. What for? Is it a checkbox because audit says you need it? Is it used for tracking changes on when they can go in? Are they used for accountability when changes go awry? Or is it a process that was thought up just to have a process to show the process makers are worthy of having an existence?
Like everything in the corporate world, simple, common sense activities that do have a purpose gets added to, modified, tweaked, revamped, into an obese complex lump of coal. Process to monitor the process to ensure the other process doesn’t fail the process on which the approval process drives. Didn’t you get the email? I attached the 45 page spreadsheet that explains it and you haven’t filled out cell JR 1304 yet with a Yes or No.
VP -> Director -> Release Mgr -> Project Manager -> Server Team -> QA team -> Engineer -> Implementation Guy
The string of approvals. Everyone has to say yes before a change can ‘go in’. Now, if a change fails, who do you think get’s the blame? Everyone or just a few? Why isn’t every one that approved put in the hot seat? Isn’t that what an approval is for? It’s like agreeing to a software’s terms and conditions without reading it.
The other interesting aspect is how approvals are obtained. If time gets crunched and the approvals aren’t aligned how do you get the right people to approve it? In that scenario you need to get many changes approved in a short amount of time. The best way to do it is shoot off an email asking for an approval of all those changes. You get a reply with two simple words ‘I approve’. From an auditing point of view is that a worthy approval?
It all goes back to the original purpose of getting approvals for changes to the environments. There will be a point where a change will go in that complete wipes out a server, deletes a filesystem, blows away a firewall rules table because the deployment plan was terrible. It’s the fault of the designer for making such a crappy technical product for starters. In addition the pyramid of approvers all agreed it could go in. They are all at fault for not reading, understanding and ensuring quality once they put those two little words out there – ‘I approve’.
End of Line.
– Posted using BlogPress from my iPad
Binary Blogger has spent 20 years in the Information Security space currently providing security solutions and evangelism to clients. From early web application programming, system administration, senior management to enterprise consulting I provide practical security analysis and solutions to help companies and individuals figure out HOW to be secure every day.