- What
is a security checklist?
- Why
use security configuration checklists?
- What
is the Special Publication 800-70?
- What
is the motivation behind the NIST program?
- What
legislation is the NIST program in response to?
- What
technologies is the NIST program targetting?
- What
is the checklist repository and when will it be available?
- What
checklists are available currently?
- Who
creates the security checklists listed by the NIST program?
- What
are the program's operational environments?
- Should
home or enterprise users apply the Specialized Security-Limited
Functionality checklists?
- How
do you create and submit a checklist?
- What
process does NIST follow to list the checklists?
- Who
will maintain the checklists?
- How
does this help agencies in meeting FISMA-related requirements?
- Is
there any relationship with the NIAP?
- What
is the checklist program logo?
1.
What is a security checklist?
A security
configuration checklist (sometimes referred to as a lockdown guide,
hardening guide, or benchmark configuration ) is essentially a document
that contains instructions or procedures for configuring an IT product
to a baseline level of security. Checklists can be developed not
only by IT vendors, but also by consortia, academia, and industry,
Federal agencies and other governmental organizations, and others
in the public and private sectors. 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 manually configure
software
- Documents
that explain the recommended methods to securely install and configure
a device
- Policy
documents that set forth guidelines for such things as auditing,
authentication security (e.g., passwords), and perimeter security
Not
all instructions in a security configuration checklist need to be
for security settings. Checklists can also include administrative
practices for an IT product that go hand-in-hand with 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.
2.
Why use security configuration checklists?
There are many threats to users’ computers, ranging from remotely
launched network service exploits to malicious code spread through
e-mails, malicious web sites, and file downloads. Vulnerabilities
in IT products are discovered on an almost daily basis, and many
ready-to-use exploits are widely available on the Internet. Because
IT products are often intended for a wide variety of audiences,
restrictive security controls are usually not enabled by default,
so many IT products are immediately vulnerable out-of-the-box. It
is a complicated, arduous, and time-consuming task for even experienced
system administrators to identify a reasonable set of security settings
for many IT products.
While
the solutions to IT security are complex, one basic yet effective
tool is the security configuration checklist. To facilitate the
development of security configuration checklists and to meet the
requirements of the Cyber
Security Act, NIST has developed a program to (a) provide vendors
and other groups with guidance for developing standardized, high-quality
checklists to secure IT products, (b) establish a formal framework
for the submission of checklists to NIST, and (c) assist users by
making available a checklist repository.
Some
of the benefits that organizations and individuals can achieve by
using checklists are as follows:
-
Providing a baseline level of security to protect against common
and dangerous local and remote threats and a consistent approach
to securing systems
-
Significantly reducing the time required to research and develop
appropriate security configurations for installed IT products
-
Allowing smaller organizations to leverage outside resources to
implement recommended practice security configurations
-
Preventing public loss of confidence or embarrassment due to compromise
of publicly accessible systems.
While
the use of security configuration checklists can greatly improve
overall levels of security in organizations, no checklist can permit
a system or a product to become 100% secure. However, use of checklists
that emphasize hardening of systems against flaws or bugs inherent
in software will typically result in greater levels of product security
and protection from future threats.
3.
What is the Special Publication 800-70?
NIST,
with sponsorship from the Department
of Homeland Security (DHS), has produced
Special Publication 800-70: Security Configuration Checklists Program
for IT Products - Guidance for Checklist Users and Developers
to facilitate the development and dissemination of security configuration
checklists so that organizations and individual users can better
secure their IT products.
This
publication is intended for users and developers of IT product security
configuration checklists. For checklist
users, this document gives an overview of the NIST Checklist
Program, explains how to retrieve checklists from NIST’s repository,
and provides general information about threat models and baseline
technical security policies for associated operational environments.
For checklist developers, the
document sets forth the policies, procedures, and general requirements
for participation in the NIST Checklist Program.
4.
What is the motivation behind the NIST program?
Many organizations have created various checklists; however, these
checklists may vary widely in terms of quality and usability, and
may have become outdated as software updates and upgrades have been
released. Because there is no central checklist repository, they
can be difficult to find. They may not be well documented with the
result being that one checklist may differ significantly from another
in terms of the level of security provided. It may be difficult
to determine if the checklist is current, or how the checklist should
be implemented. While many existing checklists are of high quality
and quite usable , the majority of checklists aren’t accessible
or directly usable by most audiences. Consequently, the
goals of the NIST program are:
-
To facilitate the development and sharing of security configuration
checklists by providing a framework for developers to submit checklists
to NIST
-
To assist developers in making checklists that conform to common
operational environments and associated baseline levels of security
-
To assist developers and users by providing guidelines for making
checklists better documented and more usable
-
To provide a managed process for the review, update, and maintenance
of checklists
-
To provide an easy-to-use repository of checklists.
NIST’s
program also serves to assist vendors in the process of making their
checklists available to users out-of-the-box. In such cases, it
will still be advisable for product users to consult the NIST checklist
repository for updates to pre-installed checklists.
5.
What legislation is the NIST program in response to?
The
Cyber Security
Research and Development Act of 2002 (Public Law 107-305) tasks
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.”
In addition, the Common
Configuration Working Group Report of the Technical Standards and
Common Criteria Task Force, formed at the Department of Homeland
Security's first National Cyber Security Summit in 2003, recommended
government promotion of the use of a NIST central repository for
IT security configuration checklists. In response, this document
has been developed by NIST in furtherance of its statutory responsibilities
under the Cyber Security Act as well as the Federal
Information Security Management Act (FISMA) of 2002 (Public
Law 107-347).
6.
What technologies is the NIST program targetting?
The
key IT product technology areas include: operating systems, database
systems, web servers, e-mail servers, firewalls, routers, intrusion
detection systems, file private Networks, biometric devices, smart
cards, mobile devices (e.g., PDAs), multi-purpose devices, telecommunication
switching devices, and web browsers.
7.
What is the checklist repository and when will it be available?
The
NIST beta checklist repository
contains checklists that have been developed and screened to meet
the requirements of the program. Users will be able to browse the
checklist descriptions to locate and retrieve a particular checklist
using a variety of different fields, including the following:
Product
Category: The main product category of the IT product,
e.g. firewall, IDS, operating system, web server, etc.
Vendor: Contains the name of the manufacturer of
the IT product.
Submitting Organization: The name of the organization
and authors that produced the checklist.
8.
What checklists are available currently?
NIST
has produced checklists for Microsoft Windows 2000 and XP Professional,
available at http://csrc.nist.gov/itsec.
NIST is currently working with other checklist-producing organizations
and IT product vendors to include their checklists in the planned
NIST repository, including those available from the Defense
Information Systems Agency (DISA), the National
Security Agency (NSA) and the Center
for Internet Security (CIS).
9.
Who creates the security checklists listed by the NIST program?
Ideally,
product vendors will create checklists as they release new products.
The vendor is often in the best position to create the checklists,
however in some cases 3rd-party checklists could be submitted, such
as from recognized security groups, state governments, and corporations.
The Microsoft Windows™ XP templates included with the NIST
Windows XP System Administration Guidance Special Publication
represents an example of consensus settings by a 3rd-party working
group. NIST's program will also work in conjunction with other agencies
and IT prodcut vendors to develop and disseminate security configuration
checklists for IT products.
10.
What are the program's operational environments?
The
NIST program identifies several broad and specialized operational
environments, any one of which should be common to most audiences.
By identifying and describing these environments, developers can
better target their checklists to the general security baselines
associated with the environments. End-users can better select the
checklists that are most appropriate for their operating environments.
The operational environments are as follows:
- Standalone
or
Small Office/Home Office (SOHO) describes small, informal
computer installations that are used for home or business purposes.
Standalone encompasses a variety of small-scale environments and
devices, ranging from laptops, mobile devices, or home computers,
to telecommuting systems, to small businesses and small branch
offices of a company.
- Managed
or Enterprise are typically large organizational systems
with defined, organized suites of hardware and software configurations,
usually consisting of centrally-managed workstations and servers
protected from the Internet by firewalls and other network security
devices.
- Custom
environments contain systems in which the functionality and degree
of security do not fit the other environments. Two typical Custom
environments are Specialized Security-Limited Functionality
and Legacy:
- Specialized
Security-Limited Functionality. A Specialized Security-Limited
Functionality environment contains systems and networks at
high risk of attack or data exposure, with security taking
precedence over functionality. It assumes systems have limited
or specialized (not general purpose workstations or systems)
functionality in a highly threatened environment such as an
outward facing firewall or public web server or whose data
content or mission purpose is of such value that aggressive
trade-offs in favor of security outweigh the potential negative
consequences to other useful system attributes such as legacy
applications or interoperability with other systems. 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 another environment.
- Legacy.
A Legacy environment contains older systems or applications
that may 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. A Legacy environment
could be a subset of a Standalone or Managed environment.
11.
Should home users apply the Specialized Security-Limited Functionality
checklists?
Almost
never. The Specialized Security-Limited Functionality checklists
generally reduce the functionality of products and are recommended
only for specialized environments. Home users or users that require
maximum functionality of a product will find that Specialized Security-Limited
Functionality checklists will cause applications to break. For example,
applying a Specialized Security-Limited Functionality checklist
to a desktop operating system would likely cause installed applications
such as home productivity software and games to cease working.
12.
How do you create and submit a checklist?
For
specific information on creating and submitting a new or existing
checkling, see the FAQ for vendors
and checklist developers.
The
NIST Checklist Program provides a lifecycle
process and guidance for developing checklists in a consistent
fashion. For checklist developers,
steps include the initial development of the checklist, checklist
testing, documenting the checklist according to the guidelines of
the program, and submitting a checklist package to NIST. NIST then
screens the checklist according to program requirements prior to
a public review of the checklist, which typically lasts 30 to 60
days. After the public review period and any subsequent issue resolution,
it will be listed on the NIST checklist repository (http://checklists.nist.gov)
with a detailed description. NIST will periodically ask checklist
developers to review their checklists and provide updates as necessary.
NIST will retire or archive checklists as they become outdated or
incorrect.
13.
What process does NIST follow to list the checklists?
After
the checklist information is submitted to NIST, NIST will screen
the checklist for adherence to the development criteria and format.
After addressing any issues with the checklist submitter, NIST will
post the checklist for public review. Issues raised during the review
will be addressed by the producer. After all issues are addressed
satisfactorily, the checklist or checklist description will be posted
on the NIST checklist repository.
14.
Who will maintain the checklists?
Checklist
submitters will be responsible for maintaining their associated
checklists when new versions of the products appear. When the final
checklist is listed, NIST will set a periodic review schedule with
the developer. Typically, the timeframe for the review will be one
year; however, it could be sooner depending on certain 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.
15.
How does this help agencies in meeting FISMA-related requirements?
FISMA
(section 3544(b)(2)(D)(iii)) 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. The
development and sharing of these checklists can greatly reduce what
would otherwise be a “reinvention of the wheel” for
IT products that are widely used in the Federal government, e.g.,
common operating systems and office applications.
16.
Is there any relationship with the NIAP?
The
National Information Assurance Partnership
(NIAP) is independent of the IT security checklists program. NIAP
includes a formal testing program requiring vendors to submit their
products to validated testing laboratories. The checklist program
has less overhead and expense for vendors, however ever it does
not contain the same formal testing benefits as with NIAP.
17.
What is the checklist program logo?
Checklist
producers, e.g., vendors, will be able to use a checklist program
logo on 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.
The logo does not convey NIST endorsement of the checklist or IT
product.
Please
send comments if your questions
were not answered here.
Top
of Page
|