Kicking off the FDCC blog

Current Status 

 

On March 19, Karen Evans, Administrator, Office of E-Government and Information Technology for the Office of Management and Budget, sent a memo to all Federal government CIO’s requiring agencies to move to a standard configuration for computers running Microsoft Windows by February 1, 2008. Since then Microsoft has been collaborating with a handful of federal agencies to create actionable guidance and tools that agencies can use to implement the standard desktop and organziations who do business with the federal government can use to ensure their solutions are compatible with the locked-down configurations. I use the plural "configurations" because there are 2, one for Windows Vista and another for Windows XP. They are very similar but not identical because the latest version of Windows includes many features not available before. These configurations are collectively known as the Federal Desktop Core Configuration, or FDCC.

 

I know that many organizations are eager to see the details of the FDCC configuration. I've heard from federal agencies that want to start preparing to deploy FDCC as soon as possible. I've also talked to software companies that want to ensure their applications will be fully functional when run FDCC systems. I've also heard from systems integrators and IT services companies that want to be ready to help their federal customers to deploy and support the FDCC configurations. The challenge for the organizations defining the configuration and preparing the resources needed to deploy it is that we have to get it right the first time. Microsoft has been working closely with the OMB, NIST, NSA, DISA, DHS, and the USAF and none of us want to publish guidance, tools, and other resources that will have to be updated and corrected repeatedly over the first few weeks. Such a situation would be confusing and frustrating to every organization responding to the OMB mandate.

 

What exactly are we all preparing? What should you expect to see in the coming weeks and months? There are deliverables that Microsoft is creating, these I can speak about authoritatively but there are also resources being created by the aforementioned government agencies which you will need to learn about from them rather than me or someone else at Microsoft. You can expect the OMB and NIST to be the primary sources of information in federal, when these agencies and others publish significant things we'll add links to them on this blog's Resources page: https://blogs.technet.com/fdcc/pages/resources.aspx

 

At Microsoft we're creating and testing Virtual PC (VPC) images that we hope will help agencies and solutions providers to develop and test applications to run on FDCC compliant systems. These VPC images are not suitable for deployment, they'll be evaluation copies of Windows that will expire after a set period of time, but since they will be preconfigured they should help organizations to jumpstart their testing. We are also planning on creating installation discs of Windows XP and Windows Vista that agencies can use to create their deployment builds of the operating systems. These installation discs will only be available to volume licensing customers through their secured website, you won't see them for sale at retail outlets. These discs will work like a normal Windows installation disc, only when the operating system installation is complete the FDCC settings will be applied. We're also creating a customized solution offering through Microsoft Consulting Services (MCS), a MCS consultants will work onsite with the agencies to incorporate the FDCC configurations into their existing deployment systems and to test applications for compatibility with the locked-down settings.

You still want to know more details about the settings, don't you? The single most important requirement in the FDCC is that all normal users will have to log in without administrative privileges. Experience has shown us that taking away admin rights from users causes the most challenges: some applications stop working and some users get frustrated that they can no longer install whatever software they want and they can no longer make whatever configuration changes they want to their computers. You can get an idea of what the FDCC configurations will look like by taking a look at the Microsoft security guides (listed on the Resources page), the FDCC settings are similar to the Specialized Security - Limited Functionality (SSLF) settings in our guides. Some of the settings are less restrictive in the FDCC than the SSLF settings, additionally the FDCC covers several dozen less impactful settings that are not documented in the Microsoft security guides. I am only suggesting that you take a quick look at our guides so that you have an idea of what sorts of changes are included in the FDCC, the differences are significant and it would probably be wasted energy to start your testing and development work based on the SSLF settings.

That's what I have on current status for today, the rest of this post includes some background information that won't help you to create your plans for implementing and supporting FDCC, but may be of interest if you'd like to have a better understanding of how things evolved to this point over the past few years.

Historical Background

Over the past decade the National Security Agency (NSA), the Defense Information Systems Agency (DISA), and the National Institutes for Standards and Technology (NIST) have all published hardening guidance for various operating systems and applications. The laudable goal of these efforts was to improve the security of the computers and networks used by federal agencies, but there were unforeseen side effects including contradictory advice between these agencies and with other sources of guidance as well as performance and application compatibility issues. The NSA guidance hasn’t been considered a formal standard, but rather actionable advice to help Department of Defense (DoD) agencies improve their information system security posture. Their documents are available at https://www.nsa.gov/snac/downloads_os.cfm?MenuID=scg10.3.1.1. DISA has been publishing Security Technical Implementation Guides (STIG) and checklists that define requirements for DoD agencies to follow when deploying information technology, they are available at https://iase.disa.mil/stigs/. NIST has written special publications for securing various platforms and applications can be found here: https://csrc.nist.gov/publications/nistpubs/index.html. While not a Federal Information Processing Standards (FIPS) standard may civilian agencies meticulously apply the settings recommended within NIST’s guidance.

The Microsoft Solutions for Security and Compliance (MSSC) team was finishing up its first project, a comprehensive security guide for Windows 2000 servers, in the fall of 2002 when they first contacted the team at the NSA that had been publishing security guidance for commercial off-the-shelf IT products (COTS). The information security experts at the NSA agreed that a collaborative effort to improve the usability and reduce contradictions between the various sources of guidance would benefit all affected parties. The NSA introduced the MSSC team to their peers at DISA and NIST and they all began reviewing alpha and beta versions of the Windows Server 2003 and Windows XP security guides that Microsoft published in the spring of 2003. The collaborative effort continued after publication, and subsequent versions of guidance produced by all of these organizations grew more and more harmonious, by 2005 the recommendations for hardening Windows Server 2003 and Windows XP were virtually identical between all of these organizations. The shared endeavor culminated in the fall of 2006 when Microsoft’s security guide for Windows Vista was published: DISA has been telling the DoD that the Microsoft guide is the STIG, the NSA has been telling the DoD that they won’t be publishing separate guidance and they recommend agencies refer to DISA’s checklists and Microsoft’s guidance, NIST’s guide for Windows Vista hasn’t been published yet but its expected to contain the same specific suggestions that Microsoft’s guide provides.

In 2003 the USAF identified enhanced configuration management as a key goal for reducing the cost of managing computers running Windows. When they started each of the major commands had one or more configurations in deployment and most end users had full admin access. Working with MCS their IT team developed a single configuration for all of the Air Force, the image was based on the SSLF settings in Microsoft's Windows XP Security Guide and the guidance in DISA's STIG for Windows XP. Since then this configuration has been deployed to well over 400,000 PCs throughout the Air Force. According to USAF executives the cost savings have been significant.

The success at the USAF caught the eye of officials at the Office of Management and Budget, inspiring Clay Johnson and Karen Evans to send out memos directing all federal agencies to develop plans for deploying a standard desktop configuration.

I believe that the mandate is a good thing for federal agencies, vendors who do business with our national government, and for Microsoft. Its good for the government agencies for many reasons including increased security and reduced support costs. Its good for vendors because they now have a specific configuration to target when developing and testing solutions that interact with our platform. Its good for Microsoft because we anticipate agencies experiencing lower deployment and support costs, faster deployment of platforms and applications, and fewer security incidents. These benefits will acrue over several years time though, agencies that do not have centralized management of desktops and laptops will have to invest significant resources initially, but they should see savings over the long haul.

Comments

• Anonymous
  May 03, 2012
  This is a great summary of FDCC and USGCB! I want to make one thing clear... and that is the issue with removing local administrative privileges does cause severe issues with the computers and users that use them. The issue is that some applications require local admin... that is just reality. As a solution, please check out PowerBroker Desktops from BeyondTrust! It is amazing, stable, and the leader in solving this issue! Hands down. you can get eval version at www.beyondtrust.com. If you have other least privilege issues, please email me at derekm@braincore.net [Aaron Margosis]  Thanks for using our blog as an advertising channel, but Istrongly disagree with your assessment of BeyondTrust's offering (and those of its competitors).  All those solutions do is to grant those applications admin rights.  There are many other ways to get legacy apps to run on Windows 7 that don't increase the risk of unauthorized elevation of privilege (EoP).  These include UAC's automatic file and registry virtualization, application compatibility shims, and augmenting the app installer (when the app performs installation steps on first run).  AppDNA and ChangeBase both have offerings that have helped many customers without increasing EoP risk.  Even changing permissions on specific app-owned data folders/files is usually much less risky than giving the app admin rights.  And every time I see customers use BeyondTrust to fix one problem, they start applying it to every other perceived admin-rights issue.  The more it's used, the higher the risk.  FWIW, we could have included a setuid-like capability (like BT's) into Windows when we made non-admin the default, but we specifically chose not to, for very good reasons.