[ISN] ITL Bulletin for June 2005

[InfoSec News]

Forwarded from: Elizabeth Lennon <elizabeth.lennon at nist.gov>

NIST'S SECURITY CONFIGURATION CHECKLISTS PROGRAM FOR IT PRODUCTS
Shirley Radack, Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Technology Administration
U.S. Department of Commerce

The National Institute of Standards and Technology (NIST)  is
cooperating with other federal agencies, IT vendors, and with industry
to advance the development and use of security configuration
checklists. A security configuration checklist (sometimes called a
security configuration guide, lockdown guide, hardening guide,
security technical implementation guide, or benchmark) is basically a
series of instructions for configuring an information technology (IT)
product to an operational environment. Checklists can be useful tools
for reducing vulnerabilities to systems, especially for small
organizations with limited resources.  IT vendors often create
checklists for their own products, but other organizations such as
consortia, academic groups, and government agencies have also
developed them.

Checklists can be used to counter threats to computers, such as
remotely launched attacks through networks and the spread of malicious
code through e-mails, malicious websites, and file downloads.
Vulnerabilities in IT products are discovered almost daily. Because
many IT products are designed to serve a wide variety of users, they
may not provide needed restrictive security controls routinely. As a
result, computers can be vulnerable to threats when the products are
installed. Even experienced system administrators may find it
difficult and time-consuming to identify the right set of security
settings for many IT products.

The NIST checklists program, described in this ITL Bulletin, serves
both checklists developers, e.g., vendors, and users, e.g., federal
agencies. NIST provides checklist developers with guidance for
developing standardized, high-quality checklists to secure IT
products. Checklist developers are invited to submit their
well-documented and usable checklists to NIST for review and for
listing in an easy-to-use repository of checklists.  NIST has
developed a formal process to review, update, and maintain the
checklists in the repository. Users are invited to browse through the
descriptions in the repository to locate a particular checklist. The
checklists repository is organized by product category, vendor, and
submitting organization, and currently includes over fifty checklists.  
Information about the program and access to the checklist repository
is available from the NIST web page:  
<http://csrc.nist.gov/checklists/>http://csrc.nist.gov/checklists/.

Why Checklists Are Needed

The Cyber Security Research and Development Act of 2002 (Public Law
107-305) designates NIST to "develop, and revise as necessary, a
checklist setting forth settings and option selections that minimize
the security risks associated with each computer hardware or software
system that is, or is likely to become, widely used within the Federal
Government."

Checklists provide a baseline of security to protect against common
and dangerous threats, and they provide a consistent approach to
securing systems. This is especially important for small
organizations, which may not have the resources to investigate and
develop their own security settings for installed products. Checklists
alone cannot guarantee complete security, but they can reduce an
organization’s vulnerabilities when used with well-developed guidance,
leveraged with high-quality security expertise, vendor product
knowledge, operational experience, and accompanied with tools.

What are Checklists

A security checklist in its simplest form can be a document that
contains instructions or procedures for configuring an IT product to a
baseline level of security. Checklists are also commonly referred to
as lockdown guides, hardening guides, security technical
implementation guides (STIGS), or benchmarks. A checklist could
contain scripts, templates, and pointers to patches, or updates or
firmware upgrades that can be applied to a product. A checklist might
include any of the following:

* Configuration files that automatically set various security settings 
  (e.g., executables, security templates that modify settings, 
  scripts);

* Documentation (e.g., text file) that guides the checklist user to
  configure software manually;

* Documents that explain the recommended methods for the secure
  installation and configuration of a device; and/or

* Policy documents that set forth guidelines for activities such as
  audits, authentication security (e.g., passwords), and perimeter 
  security.

The instructions in a security configuration checklist can apply to
administrative practices as well as security settings for an IT
product to support improvements to the product's security. Often,
successful attacks on systems are the direct result of poor
administrative practices such as not changing default passwords or
failure to apply new patches.

While many checklists have been developed, they vary in quality,
usability, and documentation, and they may not be kept current with
software updates. The NIST program provides a consistent process for
the development, review, and use of checklists.  Examples of IT
product technology areas that are included are: operating systems,
database systems, web servers, e-mail servers, firewalls, routers,
intrusion detection systems, virtual private networks, biometric
devices, smart cards, telecommunication switching devices, and web
browsers.

The NIST Checklists Program

NIST is currently working with other checklist-producing organizations
including the Defense Information Systems Agency (DISA), the National
Security Agency (NSA), and the Center for Internet Security (CIS), as
well as IT product vendors and vendors of configuration and management
products.

Ideally, product vendors create checklists as they release new
products. The vendor is often in the best position to create the
checklists; however, in some cases, third-party checklists may be
submitted, such as from recognized security groups, state governments,
and corporations. After testing their checklists and documenting them
according to the guidelines of the program, checklist developers can
submit a checklist package to NIST.

NIST screens the checklist package for adherence to the development
criteria and format.  After addressing any identified issues with the
checklist submitter, NIST posts the checklist for public review.
Issues that are raised during the review will be referred to the
checklist developer. After all issues have been addressed
satisfactorily, the checklist or checklist description will be posted
on the NIST checklist repository
(http://csrc.nist.gov/checklists/repository/index.html).

Checklist submitters are responsible for maintaining their checklists
when new versions of the products appear. When the final checklist is
listed, NIST will set up a periodic review schedule with the
developer. The review will take place in one year, or sooner,
depending upon factors such as the discovery of new vulnerabilities.
If the developer decides to update the checklist, NIST will announce
that the checklist is in the process of being updated. If the
checklist contains major changes, it will be accepted as if it were a
new submission; it must undergo the same reviews as a new submission.
Outdated or incorrect checklists will be retired or archived.

Checklist producers can use the special checklist program logo on
their product literature or websites to show participation in the NIST
program and ownership of a checklist on the repository. To use the
logo, the producer must provide checklist-related assistance to users.
The logo does not convey NIST endorsement of the checklist or IT
product. See http://csrc.nist.gov/checklists

Using Checklists

Organizations usually conduct a requirements analysis before selecting
and purchasing IT products. NIST Special Publication 800-30, Risk
Management Guide for Information Technology Systems, provides useful
guidance for federal agencies on conducting the requirements analysis
and the subsequent risk assessment. Users should identify their
functional needs to determine what functions an IT product must
perform and what security controls should be used.  Next, threats
related to particular products and vulnerabilities that could be
exploited in the product should be identified. Then the needed
security controls should be determined to minimize or eliminate the
likelihood of threats exploiting system vulnerabilities.  After
determining local operational product requirements, users can research
and retrieve the checklists that match their operational environment
and security requirements.  Users are able to modify and document the
checklist to take into account local policies and needs, test the
checklist, and provide any feedback to NIST and the checklist
developers after applying the checklist in their systems.

Users can browse a database of checklist descriptions to locate and
retrieve a particular checklist using a variety of different fields,
including the following:

* Checklist Summary: Summarizes the purpose of the checklist and its
  settings.

* Status: Whether Candidate, Final, or Archived.

* Version: Indicates the version or release number of the checklist.

* Revision Date: States the date when the checklist was last revised.

* Vendor: Contains the name of the manufacturer of the IT product.

* Point of Contact: Provides the e-mail address where questions,
  comments, suggestions, and problem reports can be sent in reference 
  to the checklist. The point of contact should be an e-mail address 
  that the checklist developer monitors for checklist problem reports.

* Product Category: The main product category of the IT product, e.g.,
  firewall, Intrusion Detection System (IDS), operating system, web
  server, etc.

* Product Name: The official IT product name.

* Product Role: Specifies the primary use or function of the IT
  product as described by the checklist, e.g., Client Desktop Host, 
  Web Server, Bastion Host, Network Border Protection, Intrusion 
  Detection, etc.

* Product Version: The specific software or firmware released version
  number of the IT product, including service pack or patch level as
  appropriate.

* Rollback Capability: Whether the changes in product configuration
  made by applying the checklist can be rolled back, and if so, how to
  rollback the changes.

* Target Audience: Intended audience that should be able to install,
  test, and use the checklist, including suggested minimum skills and
  knowledge required to correctly use the checklist.

* Target Operational Environment: The IT product's operational
  environment, e.g., SOHO, Managed, Custom (with description such as
  Specialized Security-Limited Functionality or Legacy).

* Testing Information: Platforms on which checklist was tested. Can
  include any additional testing-related information such as summary 
  of testing procedures used.

* Product Support: Vendor will accept support calls from users who
have applied the checklist on their IT product;  warranty for the IT
product has not been affected. This support is required for
participation in the Checklist Program and use of the Checklist
Program logo.

Operational Environments

NIST has identified four types of operational environments to help
developers to target their checklists to the security baselines that
are associated with the different environments. Users can select the
checklists that are most appropriate for their operating environments.

* Small Office/Home Office (SOHO), sometimes called Standalone,
  describes small, informal computer installations that are used for
  home or business purposes.  SOHO encompasses a variety of 
  small-scale environments and devices, ranging from laptops, mobile 
  devices, or home computers, to telecommuting systems located on 
  broadband networks, to small businesses and small branch offices of 
  a company. These environments may be less secure than the others and 
  may be supported by less experienced system administrators.

* Managed or Enterprise environments are environments that are
  structured in terms of hardware and software configurations, usually
  consisting of centrally managed workstations and servers protected
  from the Internet by firewalls and other network security devices.
  Generally, a skilled staff supports users and provides security from
  initial system deployment through system maintenance. The structure
  and the staff contribute to the implementation and maintenance of
  consistent security practices.

* Custom environments contain systems in which the functionality and
  degree of security do not fit into the other two environments. There
  are two typical custom environments:

o Specialized Security-Limited Functionality environments contain
systems and networks at high risk of attack or data exposure.
Protecting the security of these systems may be a higher priority than
the usability of the systems or their interoperability with other
systems. These systems have limited or specialized functionality in a
highly threatened environment such as an outward facing firewall or
public web server.  Checklists for this environment are not
recommended for home users or for large-scale, general purpose
systems. A Specialized Security-Limited Functionality environment
could be a subset of a SOHO or an enterprise environment.

o Legacy environments contain older systems or applications that use
older, less-secure communication mechanisms. Other machines operating
in a legacy environment may need less restrictive security settings so
that they can communicate with legacy systems and applications. These
environments could exist within a SOHO or an enterprise environment.

NIST Special Publication 800-70, Security Configuration Checklists
Program for IT Products

NIST recently issued NIST Special Publication 800-70, Security
Configuration Checklists Program for IT Products.  Written by Murugiah
Souppaya, John Wack, and Karen Kent, this guide was developed with the
sponsorship of the Department of Homeland Security (DHS) and is
available on NIST's web pages ( http://csrc.nist.gov/checklists ).

The publication discusses checklists and their benefits, and explains
the operation of the checklists program. It describes the policies,
procedures, and general requirements for participation in the program,
and explains how to retrieve checklists from NIST's repository. It
also provides general information about threat models and baseline
technical security policies for associated operational environments.

NIST has developed checklists for Microsoft Windows' 2000 and for
Microsoft Windows XP systems. Draft Special Publication (SP) 800-68,
Guidance for Securing Microsoft Windows XP Systems for IT
Professionals: A NIST Security Configuration Checklist:
Recommendations of the National Institute of Standards and Technology,
and NIST SP 800-43, The Systems Administration Guidance for Windows
2000 Professional, are both available at:  
http://checklists.nist.gov/repository/

How Checklists Will Help Federal organizations

Checklists will help federal organizations carry out the requirements
of the Federal Information Security Management Act (FISMA) of 2002
(Public Law 107-347).  Section 3534(b)  (2) (D) (iii) of this Act
requires each agency to determine minimally acceptable system
configuration requirements and ensure compliance with them.
Accordingly, federal agencies, as well as vendors of products for the
federal government, are encouraged to acquire or develop and share
such checklists using the NIST repository.

For More Information

The NIST website ( http://csrc.nist.gov/checklists/ )  provides links
to the checklist repository, announcements, answers to frequently
asked questions, and to documents and forms for participation in the
checklists program.  Information is available about a workshop held by
NIST in 2003 to identify federal government checklist activities and
needs, voluntary efforts for building security checklists, and
industry capabilities for developing checklists for IT products widely
used by the federal government. Also available is information about
XCCDF, a specification language for writing security checklists,
benchmarks, and related kinds of documents. An XCCDF document
represents a structured collection of security configuration rules for
some set of target systems. XCCDF provides a uniform foundation for
expression of security checklists, benchmarks, and other configuration
guidance, to help foster more widespread application of good security
practices.

NIST welcomes comments on all aspects of the checklists program.
Comments may be submitted to checklists at nist.gov.

Disclaimer
Any mention of commercial products or reference to commercial
organizations is for information only; it does not imply
recommendation or endorsement by NIST nor does it imply that the
products mentioned are necessarily the best available for the purpose.


Elizabeth B. Lennon
Writer/Editor
Information Technology Laboratory
National Institute of Standards and Technology
100 Bureau Drive, Stop 8900
Gaithersburg, MD 20899-8900
Telephone (301) 975-2832
Fax (301) 840-1357