Are you better off with FDCC? How do you know?

Over the past few months, I’ve had the chance to speak with many different federal government customers who have rolled out FDCC compliance programs. These programs feature central management and auditing of large numbers of desktop configurations. A few years ago, I heard a government administrator proclaim that “satellites would fall out of the sky” when these settings went in place, but recently, I hear federal executives speak about a reduction in volume of help-desk calls and fewer virus outbreaks. So how do you know if FDCC is working for your organization?

This blog discusses some key issues to consider when looking at FDCC or any other type of configuration auditing guidelines. I often ask potential customers, conference speakers and federal CIOs the following questions. The answers I receive often provide clues into how effective the overall FDCC program is.

Are there fewer help desk calls?

As a “security product vendor” I often get confused looks when I ask this question. Networks are large and complex; and when they break users call the help desk. If we simplify the complexity, there should be fewer things that can go wrong, and thus fewer calls to the help desk.

FDCC specifies 700 to 800 different configuration settings for Windows XP and Vista. Pushing these settings throughout your network reduces configuration randomness and complexity. Right now, these settings have been determined by a variety of sources including Microsoft, the OEM who distributed the operating system, third party software, driver manufacturers and a sampling of IT staff and users. Creating consistency in these settings ensures uniform behavior in your software, and this in turn results in fewer crashes, compatibility issues and help desk tickets.

Are there fewer virus outbreaks?

Another interesting statistic to track is the overall number of virus infections. There are many factors that can impact a virus infection;  vulnerable client software, vulnerable server software, outdated anti-virus agents, and lack of virus agents.

FDCC does not have a magic setting that prevents all virus infections, however, many of the settings limit what malicious software can do within a computer and when communicating with other local computers.

I’ve also spoken with customers who have said that the effort to secure their desktops with FDCC settings also uncovered deficiencies in how they were managing, updating and auditing their anti-virus deployments. These customers encountered scenarios where IT administration issues had eventually caused outages on their anti-virus deployments.

Are you more confident to adopt new technologies?

When Tenable first got into FDCC auditing, we were working with a large federal client who was not very happy with their existing agent-based solution. It was not really the fault of the specific agent technology; rather it was the fact that all of the computers had many combinations of settings that made getting the agent to work consistently difficult. After auditing their systems with Tenable’s agent-less solution and moving their configurations to the FDCC standard, the organization is now confident they can roll out a variety of agent-based solutions for asset inventory, anti-virus, performance and more.

Anyone who has worked in the government or DOD knows that there are hundreds if not thousands of “common” operating environments that do not work well together. However, with the advent of FDCC, I’m seeing federal organizations start to feel confident about testing and deploying new software across the entire enterprise. Organizations that were “stuck” using MSIE 6 for their official browser are now investigating MSIE 7, MSIE 8, Firefox or Opera. I’ve also talked to some organizations that felt they were “locked” into their anti-virus agent solution.  Now, with the confidence of knowing that their systems are configured identically, they  are more likely to consider an anti-virus vendor change.

Has FDCC exposed any deficiencies or best practices in your IT organization?

Before federal organizations were required to monitor system configurations of their desktops, they had no knowledge of when these systems became non-compliant. Organizations that I have spoken with that have “become compliant” with FDCC have said they were surprised where non-compliant settings originated from. Some of the anecdotal reasons I have been told include:

• Installation of any printer, scanner, camera or other driver required to operate some external computer hardware made changes to the underlying OS configuration.
• Virus infections have made changes to various settings which have made systems non-FDCC compliant.
• Organizations that did not enforce restrictions on “unauthorized software” installations often had the side effect of experiencing configuration changes made by the use of these programs.
• System administrators or systems administration tools were configured incorrectly and were in fact pushing out non-compliant FDCC settings.
• Operating systems which were placed into production directly from the vendor uncovered a procedural error where these systems should have been hardened and configured per FDCC requirements before being used.

At Tenable, one of the things we help our customers do is sample the configuration of their systems or perform an entire audit of every system. In either case, an organization can efficiently monitor very large networks for many types of changes.

For More Information

Tenable offers several different types of agent-less configuration auditing solutions based on the Tenable Nessus vulnerability scanner. Tenable’s Security Center management console is certified to perform FDCC audits on Windows XP and Vista systems. Customers can also audit their networks and systems for configuration standards available for technologies such as Unix, SQL and applications such as IIS and Apache.

I’ve also recorded a vendor neutral webinar that discusses the benefits of a configuration auditing program, how it can be used to enhance your vulnerability scanning, SIM, IDS or NBAD deployments and why it should be the basis of any security monitoring program. The recorded webinar is available to the public here.

We also have many more articles on the various types of security metrics you can use for tracking compliance ans measuring risk.