How far along are you in developing your configuration management strategy? We are still in process. Cable started...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
out as a local business, which exploded into consolidation during the past five or six years. As a result, people are doing things they are not accustomed to in both scope and complexity. Each unit used to be fairly autonomous, so now we are bringing in IT people to get a handle on what is going on.
When I arrived (about two years ago), my first task was to put standards in place. I started looking at tools and got an [enterprise configuration management] system. It's been working for about six months.
[The configuration manager] helps us figure out what kinds of software licensing issues we have and what people have on their PCs. There are technical exposures, legal exposures to consider. What has this tool taught you so far?
We have more stuff than we ever imagined. This tool looks at the registry, file system and hardware platform. In Windows, even if you run a secure platform, it still requires users to have administration rights. With that, any strategy for locking your machine down is gone, and things get out of hand.
Our configuration management tool [from Configuresoft Inc.] can alert us to changes in the environment. It goes out and does nightly surveys. It tracks the delta for all the parameters we want to see. We can produce a report from which we can see all that is changed from yesterday. And because it's done on a regular basis and stored in a relational database, we can query that database as far back as we need to. We have an add-on that pulls down XML information from a Microsoft database, scans the database and compares the [machines] to the vulnerabilities.
But these tools point out the need for a process for determining when a patch should get applied. We have the frustration of having the tool to apply patches, but not the process. Do you test patches in your own lab?
I am looking at building a test environment using something like VMware. Is anything missing from today's patch managers?
I don't find them lacking. They have to understand what's in the Microsoft bulletin database and look at the characteristics of a machine and determine if that machine is vulnerable, and then pull that patch down.
Beyond that, what type of data store is used? I prefer when things are stored in ODBC [Open Database Connectivity]. Anything else we may have considered would be overkill. We didn't want [Microsoft's] SMS, and we didn't want a massive suite like those offered by [IBM Tivoli] and [Computer Associates]. Are you using the freebie Microsoft tools -- Microsoft Baseline Security Analyzer and Software Update Services?
Functionally, SUS just couldn't compete with the commercial products. I haven't looked at MBSA. The freebies that come with Windows are OK if your needs are minimal, but you can get something better if you pay for it. Did you have any policies in place?
No. We are a maturing shop. Microsoft sends patches out at a rapid frequency, and then some of the patches are breaking stuff [in the enterprise]. We had this tool that helps us push [patches] out, but how do we decide which to apply? How do we do it in a consistent way that safeguards the integrity of the environment? Can you calculate your cost savings using configuration managers?
There are some ROI figures. The easiest ones to document are patch management. We pay about $5 per workstation for licensing, versus the cost of manually patching a PC. If I have to push out a patch to 700 workstations, I've already saved money compared with if I had to do that job manually.
As far as configuration management is concerned, you can only measure that by the outages you think you may have prevented.
FOR MORE INFORMATION:
Product & Vendor SolutionCenter: Configuration management