Information Technology Laboratory
Computer Security Resource Center
Computer Security Resource Center
The purpose of the United States Government Configuration Baseline (USGCB) initiative is to create security configuration baselines for Information Technology products widely deployed across the federal agencies. The USGCB baseline evolved from the Federal Desktop Core Configuration (FDCC)mandate. While not addressed specifically as the FDCC, the process (now termed the USGCB process) for creating, vetting, and providing baseline configurations settings was originally described in a 22 March 2007 memorandum from OMB to all Federal agencies and department heads and a corresponding memorandum from OMB to all Federal agency and department Chief Information Officers (CIO).
The USGCB is a Federal government-wide initiative that provides guidance to agencies on what should be done to improve and maintain effective configuration settings focusing primarily on security.
The Department of Defense (DoD), with NIST assistance and IT vendor consultation, developed the Windows, IE, and Red Hat USGCB configuration settings. They field-tested these settings on typical enterprise-connected desktop and laptop computers, and submitted the configuration settings to the NIST National Checklist Program (NCP) as the DoD Consensus Security Configuration Checklist for Microsoft IE Revision 1.0, the DoD Consensus Security Configuration Checklist for Microsoft Windows 7 Revision 1.0, and the DoD Consensus Security Configuration Checklist for Red Hat Enterprise Linux 5. These checklists were posted to checklists.nist.gov according to the process detailed in NIST SP 800-70 Rev. 4. NIST, at the request of the Federal CIO Council's Architecture and Infrastructure Committee's (AIC) Technology Infrastructure Subcommittee (TIS), evaluated these settings for Federal civilian agency use, normalized them with existing recommendations for Windows platforms, and recommend them to the TIS of what should be considered for Federal-wide adoption.
NIST releases USGCB candidates for a 30-day public comment. During this time, NIST collects and consolidates public comments and submits them to the TIS for consideration. If changes from the original settings are required, NIST posts the final candidate USGCB settings for an additional 30-day public comment period.
Please provide comments to the National Institute of Standards and Technology (NIST) at usgcb@nist.gov.
Agencies are ultimately responsible for ensuring that proper procedures for testing and implementing the USGCB settings are followed within their organization. Agencies should make risk-based decisions as they customize the baseline to support functional requirements in their operational environment and document any changes to the USGCB settings.
The USGCB is a baseline recommendation of security settings. It is an agency's prerogative to have stricter settings.
The Federal CIO Council originally created the Technology Information Subcommittee (TIS) at the direction of OMB to govern, among other federal activities, the FDCC initiative. The twofold purpose of the TIS included providing recommended security baselines for Information Technology products widely deployed across agencies, and serving as the Change Control Board (CCB) for the configuration setting portion of the FDCC mandate. To better support configuration setting baseline guidance under the FDCC mandate, USGCB was created and USGCB configuration settings replaced the original FDCC configuration settings for the existing supported platform baselines. More recently, the responsibility for governance of the USGCB was transferred from the TIS to the Information Security and Identity Management Committee (ISIMC). Under the ISIMC, settings for existing baselines were modified per federal agency input, and new baselines are currently under development. Baselines developed by the USGCB should be applied to Federal systems. See https://usgcb.nist.gov/ and https://cio.gov/cio-council-streamlines-configuration-baseline-process for more information.
The platforms addressed by USGCB are Microsoft's Windows 7, Windows 7 Firewall, Windows Vista, Windows Vista Firewall, Windows XP, Windows XP Firewall, Internet Explorer 7, Internet Explorer 8, and Red Hat Enterprise Linux 5. Additional platforms may be introduced at the TIS' direction. New platforms will follow the USGCB process as defined in SP 800-70 Rev. 4.
No. NIST does not endorse the use of any particular product or system. NIST is not mandating the use of Windows, Red Hat Linux, or any application. Nor is NIST establishing conditions or prerequisites for Federal agency procurement or deployment of any system. NIST is not precluding any Federal agency from procuring or deploying other computer hardware or software for which NIST has not developed a publication, security configuration checklist, or virtual testing environment.
No. NIST is currently working with a number of IT vendors on standardizing security settings and their expression in SCAP for a wide variety of IT products and environments. NIST does this through the NIST Security Configuration Checklists Program for IT Products. The NIST process for creating, vetting, and making security checklists available for public use is documented in NIST SP 800-70 Revision 4 - Security Configuration Checklists Program for IT Products: Guidance for Checklists Users and Developers. For more information about the National Checklist Program, visit https://checklists.nist.gov/. If IT vendors would like to standardize additional security settings with NIST, please contact checklists@nist.gov.
To assist in implementation, NIST is working with vendors to provide automated methods for assessing and implementing USGCB settings (SCAP content). The USGCB baselines and supporting content are available at https://usgcb.nist.gov.
In accordance with SP 800-70 Rev. 4 Executive Summary page 2 (ES-2), users from Federal civilian agencies should first search for USGCB checklists hosted by NIST at https://usgcb.nist.gov. If no USGCB checklist is available, the agencies are encouraged to use the following checklists, starting with the top of the list and moving to the next checklist only if it is not available.
These types of checklists are available at the National Checklist Program Repository at https://checklists.nist.gov.
The FDCC mandated use of the SCAP checklists for Windows XP, Windows Vista, Windows XP Firewall, Windows Vista Firewall, and Internet Explorer 7. This mandate remains in effect and includes additional SCAP checklists derived from the USGCB process.
USGCB settings were developed and tested on enterprise-connected laptops and desktop computers. The primary targets of USGCB are general-purpose systems such as managed desktops and laptops. Embedded computers, process control systems, specialized scientific or experimental systems, and similar systems are outside the scope of USGCB. Of course, such systems still require appropriate protection and application of sound risk management principles. For such systems, agencies should examine the USGCB security configuration for applicability where feasible and appropriate.
OMB may require compliance reporting of USGCB implementation as part of their standard operating procedures. This FAQ will be updated should we receive any information about future data calls.
Yes. Windows 7, Windows XP and Vista computers that are owned or operated by a contractor on behalf of or for the USG or are integrated into a Federal system are subject to FDCC.
IT product vendors are actively testing their applications for compliance with the USGCB Security Content Automation Protocol (SCAP), and information on compliance will be made available at the vendors' sites. Agencies are welcome to share USGCB compliance testing information with the understanding that each individual CIO is responsible for fulfilling the requirements in OMB Memorandum M-07-18.
There is no formal compliance process; vendors of information technology products must self-assert USGCB compliance. They are expected to ensure that their products function correctly with computers configured with the USGCB settings. The product installation process must make no changes to the USGCB settings. Applications must work with users who do not have administrative privileges, the only acceptable exception being information technology management tools. Vendors must test their products on systems configured with the USGCB settings, they must use SCAP validated tools with USGCB Scanner capability to certify their products operate correctly with USGCB configurations and do not alter USGCB settings. The OMB provided suggested language in OMB Memorandum M-07-18; vendors are likely to encounter similar language when negotiating with agencies.
The USGCB includes both machine settings and user settings; the latter are stored in each user's profile. When a user logs in Windows loads their profile and maps the user-specific registry settings to the HKEY_Current_User hive, commonly referred to as HKCU. For automated scanners it is exceedingly difficult to determine whether user settings such as the screen saver time out and AutoComplete settings for Internet Explorer are configured correctly. If no user is logged on then HKCU will not exist; the scanner could attempt to examine all of the user profiles stored on the computer, however these may include some that do not need the USGCB settings. Vendors may attempt to address this situation in various ways, however in many cases the administrator will have to manually verify the user-specific settings.
The SUPPORT_388945a0 account is a special account built into Windows XP that is used for the Remote Assistance feature. The USGCB settings require the following user rights be assigned to this account: "Denied Access To This Computer From The Network", "Denied Logon As A Batch Job", and "Denied Logon Locally." If the account is deleted then there is no reason to assign these rights to it. In other cases where the the SCAP content checks to see whether an account does or does not have a specific user right a well-known security identifier (SID) is used. A SID is a numerical identifier that maps to the user-friendly name of the account. Many built-in accounts such as the Administrators group and the Guest account have the same SID on every computer running Windows, but the SUPPORT_388945a0 account is assigned a random SID during the installation of Windows XP. This means that the SCAP content checks for the literal existence of the SUPPORT_388945a0 account name in the list of accounts for each of these user rights, there is no way for the SCAP content to distinguish between the deletion of the account and renaming of the account.
VHD's include all patches available prior to being posted on https://usgcb.nist.gov.. for download. Subsequent patches released by Microsoft are included the next time the VHD is updated, which may be several months. As a result, these patches are not present on the VHD and will therefore show up as missing during the scan. This is expected behavior and does not indicate a deficiency in the product used to scan the VHD.
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which security software products communicate software flaw and security configuration information. For more information about SCAP please see NIST SP 800-117 and SP 800-126.
SCAP expressed content encapsulates both the settings and methods for assessing those settings through SCAP validated products. In practice, an organization can produce well-formed SCAP content and expect the content to execute properly in SCAP validated tools. The USGCB, like its predecessor FDCC, uses SCAP-based technology to assess that systems are properly configured according to the recommended USGCB baseline settings.
The following table lists the current releases of the SCAP content and their expiration date:
| SCAP Content | SCAP Version | Platforms | Release Date | Expiration Date |
|---|---|---|---|---|
| USGCB-Major-Version-1.2.7.1 | SCAP 1.2 OVAL 5.10, digitally signed data stream | IE8, Win7, Win7-Energy, Win7-Firewall | September 21st, 2011 | TBD |
| USGCB-Major-Version-2.0.7.1 | SCAP 1.2 OVAL 5.10, digitally signed data stream | IE7, WinVista, WinVista-Energy, WinVistaFirewall, WinXP, WinXP-Firewall | September 21st, 2011 | TBD |
| USGCB-Version-1.x.5.0 | SCAP 1.1 OVAL 5.8 data stream | RHEL 5 Desktop | February 28th, 2011 | TBD |
The maintenance of the SCAP 1.0 content expires on December 31st, 2013.
No, the monthly patch updates for the SCAP 1.0 content will not continue after December 31st, 2013.
Yes, NIST will continue to provide support for USGCB / FDCC SCAP 1.2 content for at least 39 months after its release date.
United States government agencies should not use expired USGCB/FDCC content.
Yes, the USGCB/FDCC SCAP 1.0 content will be archived as expired content and accessible via the National Checklist Program Repository. It available for historical purposes, but should not be used for current configuration and patch scanning assessments to satisfy the FDCC/USGCB use case. SCAP 1.2 USGCB/FDCC content is available for the FDCC/USGCB use case.
Yes, authors of SCAP content/checklists may continue to produce and maintain SCAP 1.0 and 1.1 versioned content according to their technology requirements and follow the recommended least version principle for the SCAP content described in SCAP Content Conventions.
In October of 2011, the SCAP 1.0 FDCC and USGCB content was versioned to SCAP 1.2 to increase the number of automatically-checked configuration settings, improve the accuracy of configuration setting and patch application scanning, and to keep pace with technology as dictated by vendor progression in operating system and application technologies.
To enable the goals originally set forth in OMB Memorandum M-07-18, it is necessary to have security configuration scanning tools that can use official SCAP content. In response, NIST established the SCAP validation program. Implemented through the NIST National Voluntary Laboratory Accreditation Program (NVLAP), independent laboratories can be accredited to perform the testing necessary to validate that security tools can accurately parse the SCAP content required for their specific functionality. Additional details on SCAP validation are available at https://scap.nist.gov/validation/.
Tools that have achieved NIST SCAP-validated with authenticated configuration scanner status are listed at https://nvd.nist.gov/scapproducts.cfm. Tools are referenced by their type (configuration scanner, vulnerability scanner, etc), as well as by the vendor, tool name, and specific SCAP components in which the tool has achieved compliance.
Although NIST is in the process of establishing formal validation testing for Windows, IE, and Windows Firewall, many of the already SCAP validated products with FDCC Scanner capability may be able to process the NIST provided SCAP content for these three USGCB platforms.
The XCCDF-based SCAP content contains Common Configuration Enumeration (CCE) identifiers. The CCEs are mapped to the 800-53 controls and posted to the National Vulnerability Database (NVD) data feed located at https://nvd.nist.gov/cce.cfm. CCE to 800-53 mappings can also be obtained on a per checklist basis for Tier III checklists at checklists.nist.gov. This data can be used to demonstrate NIST Special Publication (SP) 800-53 assessment and compliance evidence.
Microsoft Hyper-V is a bare metal hypervisor that allows users to run a virtual instance of an operating system (aka Virtual Hard Disk). The Virtual Hard Disk (VHD) can utilize the hardware of the computer (e.g., hard drive, Ethernet card, USB ports) in the same way the non-virtual OS does.
VHDs are very useful for both laboratory and deployment testing. While software can be installed on a VHD in the same way software is installed on normal operating systems, VHDs can be discarded and re-implemented very quickly for the purposes of ensuring a pristine testing environment or if something malfunctioned with the previous VHD. Additionally, multiple VHDs can be run over a single physical platform to achieve cost savings.
According to Microsoft licensing, VHD licenses expire after 120 days. USGCB test VHDs will be published quarterly and can be found at: https://usgcb.nist.gov/usgcb_content.html.
The Windows virtual hard disks are created without a license key supplied and has a 30 day evaluation period. Once this period of time lapses, "not genuine" pop-ups will appear. You can "rearm" the licensing clock using the 'slmgr /rearm' command to extend the evaluation period for another 30 days. You can rearm Windows 7 three times.
To view the amount of time remaining in the evaluation period and remaining rearm count type the command 'slmgr /dlv.'
The USGCB technical Web site contains policy documentation, VHD files, Group Policy Object (GPO) files, and SCAP content files for Windows, Windows Firewall, Internet Explorer.
To enable more manageable download of the multi-gigabyte virtual images, NIST elected to provide WinZip segmented files. To the best of our knowledge, these files can only be re-assembled with WinZip. Agency/department representatives who prefer a non-segmented virtual machine image can write to usgcb@nist.gov with their affiliation and a shipping address. Once affiliation is confirmed, a non-segmented virtual machine image will be shipped on a DVD to your attention.
It is recommended that VHDs, GPOs, .inf, and SCAP content be used in a test and evaluation environment. After careful and comprehensive testing, an organization may decide to use the GPO, .inf, and/or SCAP content in the production environment. VHDs are provided for laboratory testing purposes only and are not to be used as a deployment image.
Yes, this is a known issue https://support.microsoft.com/kb/974639. The GPO will still work. Here are the steps to correct:
Windows 7
User: USGCB_Admin
Password: P@ssw0rd123456
NIST suggests you first make a backup copy of the downloaded VHD files. Then install the Hyper-V Server 2008 R2 software as obtained from Microsoft. Next, import the reference Windows x86 and x64 VHDs.
NIST recommends that you install and configure antivirus software and set the VPC networking setting to "Local only" or "Not Connected." Consult the Virtual PC documentation for information about these settings.
At the request of the TIS, Microsoft produces the VHDs.
No, there are a number of settings that cannot be automated at this time. Settings not checked by SCAP content can be found Known Issues spreadsheets on https://usgcb.nist.gov..
Please review the USGCB FAQs and send any unresolved inquiries to usgcb@nist.gov.
VHD's include all patches available prior to being posted on https://usgcb.nist.gov for download. Subsequent patches released by Microsoft are included the next time the VHD is updated, which may be several months. As a result, these patches are not present on the VHD and will therefore show up as missing during the scan. This is expected behavior and does not indicate a deficiency in the product used to scan the VHD.
While settings for other browsers were not tested, Federal organizations are free to use other Web browser software instead of or in addition to Internet Explorer (IE). If agencies are using Internet Explorer, NIST recommends that they use IE8. When using other browsers agencies must extrapolate the USGCB settings for IE to their chosen browser whenever possible.
Microsoft Office is not part of the USGCB mandate. It is not installed on the VHDs nor are Microsoft Office settings included in GPOs
No. The USGCB Security Content Automation Protocol (SCAP) requires the use of a personal firewall and includes the Microsoft Windows Firewall settings, because it is enabled with the operating system installation. However, Federal organizations are free to use other desktop firewall software instead of the Microsoft Windows Firewall.To comply with the USGCB, are Federal organizations required to use the Microsoft Windows Firewall?
The USGCB includes security settings that do not appear in the default user interface for the group policy editor. The settings with the "MSS:" prefix were introduced by Microsoft in their security guides for Windows Server 2003 and Windows XP. Microsoft has published a utility that is bundled with their Security Compliance Manager (SCM) which you can use to update the user interface of the group policy management tools.
[Windows 10 Update: As Microsoft is no longer developing the Security Compliance Manager (SCM) utility (though the guidance depicted here is still valid), the best place to go for Windows 10 and other security guidance from Microsoft is their blog on TechNet named Microsoft Security Guidance, and you can use the URL http://blogs.technet.com/b/secguide/ to reach it. There you will find more current utilities and security guidance for their current platform versions.]
There are a number of settings that will impact system functionality and agencies should test thoroughly before they are deployed in an operational environment.
Organizations have taken a variety of approaches. Some smaller organizations may implement local configuration through batch and *.inf files, others might employ local group policy. Larger organizations could implement the USGCB security settings using Active Directory Microsoft Group Policy Objects (GPO). Approximately 98% of all USGCB settings may be implemented through GPOs. The remaining security settings must be implemented locally through *.inf, batch, or manual methods. Other enterprise management technologies can be used instead.What is the envisioned deployment method for USGCB?
What works best will vary from one organization to the next. The VHDs are very useful because they already have the USGCB settings applied and you can begin testing quickly. Additionally, by keeping the original VHDs you downloaded from NIST pristine and creating copies of it for actual testing you can quickly reconstitute your test environment for each round of testing. You can also use Virtual PCs undo disks to make it easier to revert to an earlier version of your VHD. However, when you need to deploy the USGCB settings into production the VHDs won't be very useful, as there is no documented method for creating domain-based group policies from the local configuration on these stand-alone computers. On the other hand, the GPOs can be copied into whatever Active Directory test domain you already have established, and when testing is complete you can use the Group Policy Management Console to backup the final GPOs. Then you can copy these backed up files into your production environment and import them into your production Active Directory domain. Some SCAP-validated tools may also be able to enforce the mandated settings, check with the tool vendors to determine the capabilities of their tools.USGCB Agency Testing
As viewed through the Microsoft Group Policy Management Console (GPMC), applying GPOs to specific Windows operating systems can be accomplished using a Windows Management Instrumentation (WMI) filter (WMI filtering is only recognized on Windows Vista, Windows XP, and Windows Server 2003). More specifically, create a WMI filter that selects applicable operating systems, and link that filter to the GPO applicable for those operating systems. If computers with Windows 2000 or previous Windows operating systems are present within the enterprise, these computers must be granted exception from the group policy using the Deny Read and Deny Apply Group Policy settings. The following resources provide additional detail:
The nomenclature for NIST's SCAP content is a bit complex in order to represent several pieces of important data. If the nomenclature is represented as w.x.y.z then each digit means the following:
So, 1.0.7.0 indicates that the content is USGCB Major Version 1.0, with OVAL 5.10 content.Additionally, when the USGCB content is updated, the general guidance from a version update perspective is that if there are settings changes, the major version should be incremented. If the content is being updated due to a bug fix, then the minor version should be incremented. Finally, when the major version is incremented, the minor version should be reset to 0 (zero), even if both settings changes and bug fixes are completed during the same update cycle.
[Windows 10 Update: As Microsoft is no longer developing the Security Compliance Manager (SCM) utility (though the guidance depicted here is still valid), the best place to go for Windows 10 and other security guidance from Microsoft is their blog on TechNet named Microsoft Security Guidance, and you can use the URL http://blogs.technet.com/b/secguide/ to reach it. There you will find more current utilities and security guidance for their current platform versions.]
NIST is not able to provide an official position regarding what must and must not be implemented. That is determined by OMB Policy as published in their memos addressing FDCC and further clarified by this FAQ. We would appreciate the continued dialog to discover any technical interoperability issues; however, your choice to implement or not implement settings based on functional impact, risk-based decision, etc. is between your organization and the OMB.
[Windows 10 Update: As Microsoft is no longer developing the Security Compliance Manager (SCM) utility (though the guidance depicted here is still valid), the best place to go for Windows 10 and other security guidance from Microsoft is their blog on TechNet named Microsoft Security Guidance, and you can use the URL http://blogs.technet.com/b/secguide/ to reach it. There you will find more current utilities and security guidance for their current platform versions.]
One final note: If more than one of the GPO backups include Advanced Audit Policy settings only the latest one will apply. This is due to the way that Advanced Audit Policies work when applied locally. This should not be an issue with the FDCC GPO backups due to the fact that only one contains audit policy settings for each version of Windows.
There are a few scenarios that would be impacted by the 4 USGCB power management settings:
Wake-on-LAN (WOL) is a feature supported by many hardware and software vendors, it uses a special network message colloquially known as magic packets to "wake up" hibernating computers. At the hardware level, WOL is implemented in the network card (NIC), motherboard, and BIOS. Although the technology has been around for many years, there are likely still some PCs deployed that do not support it. NICs that do provide WOL support a variety of different features including rudimentary security, the ability to wake a PC that is completely powered down, and TLS encryption. Agencies need to plan ahead and configure each PC to take advantage of this technology.
From an enterprise perspective, the magic packet is broadcast to a subnet. In most networks it will not be forwarded across subnets unless internal routers and switches are configured to allow this type of broadcast data. Haphazardly forwarding broadcast traffic exposes the network to the risk of accidental or deliberate saturation by broadcasts, so the intermediate network devices should be configured to only forward this specific type of traffic. Another way to reduce the risk of broadcast floods is to use Subnet Directed Broadcasts (SDB) so that the WOL packet is forwarded to the target subnet rather than the entire internal. Magic packets are specially formatted broadcast frames that contain the target computer's MAC address. Only the PC with the matching MAC address will wake up. WOL can be used to address the first two scenarios.
Many enterprise management tools can send a magic packet to wake up managed PCs, including most of the SCAP validated tools. The EPA site discusses how agencies can also use Windows Task Scheduler to wake up PCs and schedule a series of tasks to wake the PC, check for updates, etc. on a regular basis. See the following for more information: https://www.energystar.gov/index.cfm?c=power_mgt.pr_power_mgt_win_task.
For mobile users, agencies could provide remote users with a utility to wake up their office PC after they have connected to the VPN. Once their PC is awake they could then connect via RDS. The EPA collected a list of tools there are many others. See the following for more information: https://www.energystar.gov/index.cfm?c=power_mgt.pr_power_mgt_comm_packages.
The Department of Defense (DoD) developed the Red Hat Enterprise Linux 5 (RHEL5) configuration settings based on work represented in the National Security Agency's "Guide to the Secure Configuration of Red Hat Enterprise Linux 5". The configuration settings were designed for a system acting as a desktop and were field-tested on typical desktop computers. After field testing, the settings and content were submitted to the NIST National Checklist Program (NCP) as the DoD Consensus Security Configuration Checklist for RedHat Rel5 (1.0). This checklist was posted to checklists.nist.gov according to the process detailed in SP 800-70 Rev. 4. NIST, at the request of the Federal CIO Council's Architecture and Infrastructure Committee's (AIC) Technology Infrastructure Subcommittee (TIS), evaluated these settings for Federal civilian agency use, normalized them as appropriate with existing USGCB recommendations, and recommended them to the TIS for consideration for Federal-wide adoption.
The RHEL5 USGCB settings were designed for a system acting as a desktop. The desktop environment tested by the DoD and NIST includes the following packages and package groups ("@" indicates a package group):
Several packages that are typically installed by default were removed:
A desktop system operates a graphical environment and provides applications for everyday business use, such as a web browser, mail client, spreadsheet and word processor. A server does not run a graphical environment or any of those applications, but can host network services such as a web server or directory server. Systems should never be configured to act in both roles.
No. However, server administrators should review the recommended security settings for desktops and determine if the server could benefit from any of the security configuration decisions and practices (e.g., use of blacklisting).
Some settings are 'Conditional' meaning these configurations should be applied if the technology is in use. The 'Conditional' settings are for IPv6, wireless, and kernel support for XD/NX features applicable to 32-bit systems only.
While nearly all configuration settings are supported via the kickstart scripts, not all of the settings can be automatically assessed using SCAP. In the alpha release, the SCAP 1.1 content supports approximately 80% of the RHEL5 Desktop USGCB settings. Additional configurations will be automated in later versions of the SCAP content.
The RHEL5 USGCB content is compliant with SCAP 1.1 which uses OVAL 5.8. Regular expressions are written using Perl 5's regular expressions as indicated in the OVAL 5.8 specification.
OVAL 5.8 is the only data stream available at this time.
Some SCAP validated tools may require root access via ssh to scan and return comprehensive results.
NIST has not validated any products using the USGCB RHEL5 content; however, in developing the SCAP content, NIST used a variety of reference implementations, COTS, and GOTS validated products to ensure the SCAP content was created correctly. In this SCAP content creation and testing process, it was noted that CCE-4060-0, the login banner check which checks for text in the /etc/issue file caused inconsistent behavior in some of the products. As a result, this configuration check was marked as a manual check. The "usgcb-rhel5desktop-issues" spreadsheet that is available at https://usgcb.nist.gov documents all known issues identified with RHEL5 Desktop USGCB.
The current content references to the Red Hat hosted patch content; therefore, the SCAPVal tool should be run with the online and maxsize options. If you need to run the content through the SCAPVal tool, in offline mode, or from a network that cannot reach the Red Hat servers, follow the instructions below:
The kickstart available on the usgcb.nist.gov website was created by Red Hat in a collaborative effort with NIST and DoD.
Please send all questions regarding configuration settings, SCAP content, kickstart scripts, etc. to usgcb@nist.gov.
Red Hat developed a kickstart script that can be used during installation to configure a RHEL5 system to be USGCB compliant. The kickstart script is meant to be used by a Red Hat administrator with experience installing and configuring RHEL5 systems. This kickstart configures a system for an IPv4 environment.
Note that this is applicable if the kickstart is hosted on a web server. See Red Hat kickstart guidance for additional installation instruction. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch-kickstart2.html
Yes. Site specific information should be customized. Also note that the kickstart configures a system for an IPv4 environment. It is assumed that the user of the kickstart has familiarity with installing Red Hat and using kickstart scripts.
The kickstart script was created to facilitate the setup of a non-operational environment where USGCB settings can be tested prior to being applied to operational systems. Although the USGCB settings have been field tested and reviewed by NIST, DoD, and Red Hat, it is not possible to test every possible site specific scenario. Always test any configuration script prior to deploying to operational systems.
The bootloader password in the kickstart script is rhel5. This should be modified to an unknown password for operational systems.
The root password set in the kickstart script is password. This should be modified to an unknown password, or removed so the administrator must enter the password during installation.
The Department of Defense (DoD) created the Puppet manifest available on the usgcb.nist.gov website. As the champion agency for the RHEL5 Desktop USGCB configuration, DoD worked closely with NIST and Red Hat during the USGCB process. The intent of the Puppet manifest is to facilitate configuration and management of RHEL5 systems across an enterprise.
The Puppet manifest on the usgcb.nist.gov website is maintained by the Department of Defense. Questions about use of Puppet for USGCB may be sent to usgcb@nist.gov. Additional information about Puppet can be found at http://docs.puppetlabs.com/.
The Puppet manifests are intended for use by experienced Red Hat administrators with familiarity using Puppet. There are several steps for deploying Puppet across an enterprise. Detailed instructions are included with the Puppet files. To summarize the instructions distributed with the manifests: customize configuration files (see next section), set up a Puppetmaster server using these configuration files, and install Puppet on workstations, pointing them at your Puppetmaster server. Always test the configuration in a lab environment before deploying them to operational systems. Refer to Puppet documentation for additional guidance. http://docs.puppetlabs.com/
Yes. The following is a list of files that should be modified with appropriate site-specific settings in order to achieve maximum compliance. (all paths are relative to the root of the Puppet manifest directory)
autosign.confSet the site-specific domain SSL certificates will be signed for.
tagmail.confPut email addresses and appropriate Puppet module tags for which user will receive notifications when actions are taken.
manifests/settings.ppConfigure the names of local dns, ntp, and syslog servers here. Note that the $domain variable is set automatically from the local system at runtime.
manifests/site.ppContains several global site variables including filebucket which must be set to the Puppet server name.
manifests/nodes/nodes.ppConfigure this file appropriately for local groups of workstations and what modules they inherit.
The Puppet manifests were created to manage systems in a non-operational environment where USGCB settings can be tested prior to being applied to operational systems. Although the USGCB settings have been field tested by the champion agency and reviewed by NIST, DoD, and Red Hat, it is not possible to test every possible site specific scenario. Always test any configuration script prior to deploying to operational systems.
The Puppet manifest on the usgcb.nist.gov website does not set the bootloader password. Although, it is possible for Puppet to set the bootloader password, it is strongly recommended to have it set at install-time by the kickstart.
The root password must be set manually at the time of installation by an administrator, or by a kickstart script. The Puppet manifests do not modify the root password.
The Puppet manifests and the kickstart file perform distinctive tasks. The USGCB kickstart file was designed to configure a fully-compliant USGCB system right from installation while the Puppet manifests were designed to keep a system in a managed state of continual compliance. The two can thus be used in concert on a system installed using the options present in the kickstart file and then managed via Puppet to ensure it stays up-to-date.
Security and Privacy: configuration management, security automation, vulnerability management