Steady State
Building and managing secure Microsoft Windows desktop environments can be a daunting task.
Microsoft provides a wealth of configuration options that agencies can apply to control everything from password policies to Internet proxy settings, and before March 2007, most agencies were given a fair bit of latitude in how they secured their end-user systems. Although this freedom provided the flexibility to account for the idiosyncrasies of maintaining many software and hardware components, it came with a price: little cross-agency standardization and no common baseline for security.
To develop governmentwide standards and — with the introduction of the Vista operating system — seize a unique opportunity to build in security at the onset of a deployment, the Office of Management and Budget worked with the National Institute of Standards and Technology, Defense Department and the Homeland Security Department to develop the Federal Desktop Core Configuration.
FDCC is essentially a security configuration for all federal desktop and notebook systems that run either Windows XP or Vista. OMB in March of last year mandated that agencies adopt FDCC and report regularly to NIST about their compliance with the security settings. The first reports were submitted this March.
Implementing FDCC is not without technical and logistical challenges. You need to understand what key settings may impact your infrastructure, what tools are available to help roll out secure systems and what you need to do to incorporate these into your management work flow.
Great Expectations
When considering infrastructure fallout, it is important to note that the FDCC settings standards are available for both Windows XP Service Pack 2 (SP2) and Vista Enterprise operating systems; you are not limited to running Vista to meet the OMB mandate. This flexibility makes it easier and significantly less expensive to integrate the configurations into an agency’s existing environment.
You must push these configurations only to standard, managed desktop and portable PCs, including contractors’ systems. Embedded and process-control systems and specialized scientific, experimental and lab systems are exempt from full FDCC compliance, though agencies must maintain them at the highest level of security possible.
When testing your initial deployment configurations, there are two immediate problems you may encounter. The first is software compatibility. Although the government requires that all vendors ensure their software is FDCC-compatible, there will still be applications that do not run well or at all on FDCC desktops — especially apps that require elevated privileges.
The second issue involves internal and external hardware devices that may no longer work. FDCC mandates the use of signed device drivers that are likely to be unavailable for hardware in use for many years. For these two problems, agencies must document any deviation from the standard. OMB has said it will grant exceptions only if agencies can justify the software and/or devices as business- or mission-critical.
To get an initial idea of how far your existing environment is from FDCC requirements, you should compare your existing baseline with both the FDCC settings and the NIST security specifications in Special Publication 800-68. That way, you can prioritize the changes you will need to make to your configurations.
Deployment Toolbox
If the outcome of OMB’s joint project had been merely a single spreadsheet that listed required settings, agencies would be completely on their own on how to implement the new configuration. To increase the likelihood of creating a true governmentwide standard desktop configuration — and because most agencies use Windows Active Directory or other deployment tools that work with Microsoft Group Policy Objects — NIST has crafted a set of ready-to-use GPOs that have required settings embedded in them.
You can use standard tools, such as Microsoft Group Policy Editor, to integrate the requirements into your overall configurations. You can set up a process to automate the revision of the GPOs across the network. It is also possible to apply the published GPOs to the local system security policy for any standalone systems that fall under the FDCC mandate.
Both NIST and Microsoft understood the need for a means to test the configurations without forcing administrators to constantly rebuild physical desktop systems. Agencies can use a set of virtual machines (one for XP and one for Vista) created by NIST and Microsoft that have the FDCC configuration baked in. The VMs work with Microsoft Virtual PC so that agencies can test all software and tweak any settings before ever touching an actual PC.
Possible Configuration Pitfalls
| FDCC Configuration | Impact |
| Minimum 12-character password that must change every 60 days | The password controls can create usability and interoperability issues and may require adapting some apps and single sign-on password-management systems to meet the limitations. |
| Windows Wireless services disabled by default (including Wireless Zero Configuration and Remote Access Connection Manager) | When applied, FDCC settings disable all wireless devices on a system. RACM also provides the foundation for virtual private network functionality. Although this does not prohibit the use of wireless networks or VPNs, you must document those configurations along with a deviation report. |
| Windows Firewall on by default | The built-in firewall, especially in Vista, may block network connections for some apps. You must test each app and define individual exceptions in the firewall policy that must be applied only to systems requiring the settings. |
| FIPS 140-2 requirement for browser security | Internal and external Web sites may not be configured to utilize 140-2-approved algorithms. Although there is little you can do about external sites, you can tune internal servers for compatibility. |
| Local file-sharing and peer-to-peer file-sharing disabled | All local Microsoft file and print services are disabled; the built-in firewall is configured to block access to them as well. Users or teams rely on this feature for sharing information on an FDCC-compliant system. |
| Java applets and ActiveX plug-ins require prompting | Web applications that use Java and ActiveX will not function automatically. Users will be prompted to let applets run that may impact the functionality of some sites. Any change to the settings requires the filing of a deviation report. |
Maintaining Compliance
The final critical component is maintaining systems to FDCC standards, which will be updated quarterly, and the need to report on compliance levels for desktop environments.
Did You Know?
Even though Microsoft Windows XP and Vista make up the bulk of end-user system deployments at most agencies, you are not required or limited to running Windows as long as whatever desktop environment you run is configured to the level of security prescribed in the Federal Desktop Core Configuration.
To ensure consistency and ease of use, NIST has also built and will maintain FDCC Security Content Automation Program (SCAP) files along with all updates to settings. SCAP lets agencies audit their systems against the current FDCC settings. The process is fairly straightforward: Agencies choose a SCAP scanner to test their deployments, identify discrepancies and prepare compliance reports.
There will be some manual audits that IT will need to make. As of early spring, out of the 729 settings that make up FDCC, seven XP checks and nine Vista checks require human intervention to validate that systems settings comply.
As part of embedding FDCC into an agency’s change-management process, it’s vital to maintain complete records on all system deviations, including any supporting vendor documentation and internal justifications on the critical nature of each application, device or service that requires altering the FDCC standard. That repository, along with your regular scans, should satisfy all audit requirements.
Ultimately, implementing FDCC should help IT create a desktop and notebook environment that’s easier to manage across the agency, is more secure, costs less to support and maintain, and provides practically bullet-proof audits.
