Michael On Security

[editorial note: this article is part of a series that I am drafting to ultimately be included in a small guide to effective information security. I do not consider my views to be the final word, and am therefore soliciting feedback from anyone who has an opinion on my approach. You may either use the comment form below, or contact me directly here. Thanks!]

In a previous post, I argued that information security is much more effective when approached as a management methodology rather than as a technological fix. It has to be incorporated in your operational framework to be effective. I outlined the four steps of a basic Systems Management Cycle:

• You must write down your intentions (policy)
• You must document the procedures you use to manifest those intentions
• You must regularly audit your environment to make sure that you are actually doing as you say
• You must improve

The next step is one of genesis. Where do you begin? Assuming that you are not building a company from scratch, you’re probably in a pretty active environment. Technologies are already in place, projects are being executed, and your support queue is well worn.

In that situation, I suggest that one shouldn’t go running around trying to figure out what they need to document. That’s a brute force method that guarantees an anxiety attack. Instead, you can coax most of these undocumented goblins out of hiding by instituting one of the most powerful controls that I’ve ever witnessed: change management.

Quickly: What is Change Management?

Change management forces people to state their intentions before acting. Rather than walking up to a production server and installing new software, the sysadmin must fill out a quick form explaining the who, what, when, where and how of his actions.

A policy such as this makes day to day action in your environment transparent. As a manger, you see what your team is doing and you can therefore make better decisions. You can see where improvement needs to be made, and it can act as a set of breaks to put a stop to things before serious mistakes are made.

This is your core policy. You’ll write it down and spread the word. Rather than talk in vague terms about a theoretical document, I’m going to take you through the steps of making one. By the end of the article, you should be on track.

Real Steps to Making it Happen

Before anything else, you’re going to need a place to store your documents. I prefer to use a wiki, as they stay out of your way. If you don’t already have one in play, I recommend FogBugz On Demand [see disclaimer]. It’s just a few clicks to get going, you get a 45 day free trial, and it includes a really nice wiki along with a full blown project management suite. As always, though, choose the solution that meets your needs.

Once you have procured a document library for your team, create a section called ‘Policies and Procedures’. Within that, write your first policy called ‘Change Management Policy’. Follow my example here and tailor to your needs.

I prefer to keep my first versions very simple. Notice that I only ask for one business day notice for a standard change and consider all requests approved by default. In more mature organizations, this will be at least 5 business days and include a formal change management meeting prior to any approval - but you have to start somewhere. Remember, you want to lead your organization out of the wilderness without declaring marshal law. Let everyone acclimate to recording their changes first, as you will gain immensely from that.

As soon as you have it written, send it out there! Let your team know that you’re working to improve things, and that this is where you will start. There might be some resistance from some members, particularly those that have never been introduced to this methodology before. It’s ok. Reinforce that you are only asking people to state their plan of action before acting. If yours is like any organization I’ve ever worked in, you can probably find a nice list of past mistakes that could have been avoided if this simple rule had been followed.

Reaping the Benefits

Your team is now making and recording changes about various systems, some of which you may not have even known to have existed before! Since your policy is requiring that sysadmins create documentation for each task, your library of procedures is actually growing, and everyone is really thinking through their work. When you see planned changes fail, you are able to analyze them better and improve.

As time goes on, your change management policy will mature. You may create a change control board consisting of the key stakeholders in your organization and hold weekly review meetings to approve or deny changes. Full approval from your QA department may be a requirement before any change can be implemented. You’ll have to evolve this policy to best fit your organization.

From the standpoint of a security-minded individual, I don’t see what could be better than starting here. Systems availability is a key term on the CIA Triad, and this paves the path. All change requests can be scrutinized to ensure that best practices are being followed and audits can be scheduled to ensure that new holes were not created by these changes.

Best of luck!