Change Management and some Misc stuff

Fist up, I want to thank everyone that came out to the Advanced Pointsec / Protector class that I was teaching on Friday. I hope that everyone learned some new tricks and that everyone had a good time. Sorry about the hiccups and some of the language, but like I tell my professor friend: The Black Fist show is rated PG-13! Make sure you hit me up with some of your questions using the contact email that you can find on the right. And if you need any consulting help....well again there is that contact link on the right.

OK, let's talk about Change Management, shall we? There are certain things that everyone who works in IT security knows. For example, we all know that running anti-virus on our computers is a good move. We also all know that Change Management is a good thing. The difference between the two is that the second item is true and the first is a load of crap. However, it can be a real pain to try to convince other people that Change Management is necessary...especially the people that have to give something up in CM.

I'm talking about giving up control. In my organization there is an application development group, a help desk group, a computer lab group, a networking group, and a server admin group. There are a couple others, but we'll ignore them for now. For the most part, Change Management is a process by which the development group, server admin group, and networking group tell the others what they're going to be doing and get their feedback. Many of them are resistant to CM because they feel that they shouldn't have to ask permission to do what they want to do with the systems they manage. There is also a legitimate fear that they will be boxed into only making changes in the wee hours of the evening and that there will be no extra compensation or balancing of these hours. For the others, they are pleased to hear what is being planned and not have as many things come up as a surprise.

Since I came in the door at my University I have been talking about Change Management and the clear message from my boss was "I'm not listening." After we had a couple audits that both suggested we implement a CM process the message was "how can we comply with this on paper without changing anything?" This is why I feel that all IT security managers should try to scratch and claw their way into reporting to the highest ranking figure they can. In the beginning I reported to someone that does not support CM, but then I managed to get in a position where I reported to someone higher up that was neutral about CM. And that is really the first step in getting CM off the ground. You need to get important people to care about it. So make sure you've got your bullet points handy when you're selling this.

• Transparency - no more secret changes that make everyone ask "WTF just happened?"
• Communication - not just improved communication in the department, but also with the customers.
• Documentation - A dirty word to be sure, but documenting your processes is a sign of a mature IT shop.
• Quality Assurance - This is a chance to make sure that important changes have been tested and that there is a rollback plan if things go poorly.
  
• Coordination - If system A and B both need to go down, but the administrators of these systems don't know about the other systems change, then they will likely be brought down at different times causing two separate outages. Change Management allows your staff to coordinate these events into one single outage. Better for the help desk and better for your customers.
• Best Practice - I know it's crappy to use the "everyone else is doing it" sales pitch, but you can still respect yourself in the morning if you're pushing something that really is good and this bullet point isn't the strongest thing you've got.
  

Still, sometimes even a really good list of reasons wont sell Change Management. In my case I had a boss that was neutral to CM. Every time I would sell it to the boss, my former boss would unsell it. The main argument against it was that we haven't had a problem so far that would have been solved by CM (totally not true) and that this process was only adding more bureaucracy to our jobs and wasting man-hours. So another thing you're going to want to do is keep track of service affecting changes that caused problems. Having specifics helps. For example, we made a change to our wireless controllers that played hell with Vista users for a few months. I hate to say it but in some places (like mine) something will have to go really wrong to get traction behind CM.

Coming up, I'm going to write about how I got Change Management off the ground after we had a disaster that got me the support I needed. Here's a hint...start slowly.