NIST FDCC Implementor's Workshop Notes

I attended the January 25th, NIST Federal Desktop Core Configuration Implementers Workshop  this  past week and wanted to share some of my thoughts and take-aways from it.

Some Organizations Were Already Close to FDCC

Several CSO/CTO speakers from a variety of different federal agencies spoke about how they went about doing a gap analysis between their current configuration policies and those of the FDCC.

The trend seemed to be that of the ~700 Microsoft settings covered by FDCC, if an organization didn't comply, the gap was between 10-20 specific settings that were not covered. This means that whatever control and configuration processes existed, they merely had to be tweaked to also handle these new configuration settings. Organizations that had been following CIS, NSA, DISA, recommended vendor or other types of guides were already close to FDCC standards.

I spoke with several of our customers there about their deployments of Nessus and the Security Center to perform FDCC auditing and monitoring and they reported similar trends. The work they had been performing over 2007 had set them up to have an easier time with FDCC.

I'm sure there are some federal organizations that are not doing as well as others, but most have been working towards FDCC compliance since the OMB mandate. In a public setting though, it is difficult to make this a general conclusion because you won't have an agency stand up and say they aren't compliant or don't have a plan.

Issues Performing These Assessments

Only one speaker commented about technical issues deploying tools to perform these audits. I was expecting more discussion around the need to deploy an agent, to scan with credentials, to audit without impacting the mission and so on. I also thought there would have been more guidance given as to dissemination of FDCC audit results. This is fairly sensitive data that can directly effect funding from OMB.

Instead, almost every speaker gave advice on how auditors should befriend their allies in the CIO's chain of command or in operational IT. It was much better to show progress and success in some areas than to try and force a change in an organization that is against this. I think this is good advice in both the federal and commercial markets as it is much harder to argue against demonstrated success than unknown change.

Hardest to Implement Configuration Settings

Dave Dixon, a Microsoft employee working in their FDCC consulting group, gave an overview of the most difficult settings to implement for federal agencies.

The number one item on his list was FIPS 140 compliance. The requirement is to only use certain government authorized encryption algorithms. Microsoft OSes have a security policy setting that can be enabled to enforce this. Getting the thousands if not tens of thousands of desktops to have this setting turned on isn't the problem though. Many of the secure web sites within the federal government and external to the government don't support FIPS 140 encryption algorithms. Enabling this setting effectively cuts off some Windows systems from secure web sites they may need to gain access to.

Also on his list was when to harden a gold build. Depending on the mix of applications (Microsoft SQL, Outlook, Access, .etc), when to harden the registry, disk or services privileges is very important. For example, some of these applications are required to be run or installed as the system administrator, to add new accounts and so on. If a system is overly hardened, building these "gold build" images can become very difficult.

I was very glad that the build and procurement processes are being considered for FDCC. Trying to make a change to a system after it has been deployed is the most expensive and disruptive time to do it. 

Dave Dixon's presentation, along with all of the others, is located at http://nvd.nist.gov/workshop.cfm

Best Questions and Comments From the Audience

The workshop had open mikes where audience members from the federal government could ask questions and make comments. Some of the more interesting comments and questions were (para-phrased) as follows:

Have any of you been able to complete FDCC audits without exceptions?

This was asked to a panel of representatives from four different government agencies. The question was rejected by the moderator as being out of ground rules. I also think the question was unfair because the base FDCC requirements would prevent you from participating in a Windows domain and this is one of the first exceptions most organizations need to consider.

Are you trusting your builds from Dell?

This was asked to a representative who stated they were receiving Windows XP systems configured to be FDCC compliant. I was not clear on the representative's answer, but even if Dell comes close or makes some semi-intelligent effort, this can only help the government move their systems towards FDCC compliance.

Has any thought been paid to the security of the audit and management tools?

I felt this was a very intelligent question. In many ways, if you have thousands or tens of thousands of systems configured the same way, you expose them to vulnerabilities of a mono-culture. This is a valid argument, but I'm much more in favor of lower operational cost to run and secure my network than perhaps relying on "random" configurations as a defense mechanism of some sort. The questioner also wanted to know if source code audits of systems performing these audits and configuration changes were part of SCAP. Tenable has not gone through our SCAP validation lab yet, but source code auditing, or even a security evaluation of the solution, is not part of the audit.

You'll know when FDCC is in place because satellites will be falling from the sky!

This last comment was from someone who was very concerned about the operational impact of these settings. We have several customers who've implemented all FDCC settings across their entire population of Windows desktops without much effect. These customers typically express more confidence in their desktop platforms now that these changes are uniform than when they first entered the FDCC process.

Absolutely No Vista

One final note I think worth mentioning is that there was very little content mentioned about Vista. If it was mentioned at all, it was mentioned that Vista was not approved, or that these configuration changes settings would be taken into account when Vista was rolled out "after 2008" one speaker even said.

For More Information about FDCC

Tenable offers the ability to audit Windows system configurations for FDCC compliance. Previously, we've blogged about FDCC auditing at these following links:

• Using Nessus to Audit FDCC Configurations
• Federally Mandated Configuration Settings for Vista and XP