NIST - Security Configuration check list

DISASTER CHECK LIST
COMMUNICATION AND COMMAND BREAK DOWN

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, includes over fifty 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."

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.

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.

NIST checklist repository
http://csrc.nist.gov/checklists/repository/index.html

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


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

--

Software insecurity: Plenty of blame to go around
http://www.gcn.com/online/vol1_no1/40437-1.html
04/18/06

The reason software so often is not secure is the fault either of developers or of users.
[ ... Stuart Katzke of the National Institute of Standards and Technology said that standards and guidelines developed by NIST could help provide that methodology. He said the suite of documents produced for the Federal Information Security Management Act effectively establish a level of due diligence for government IT systems. "It is likely to become due diligence for the private sector as well,"
he said. The NIST publications establish requirements for agencies to comply with FISMA. Development of the standards and supporting guidelines are the first phase of FISMA implementation, he said. "We're completing the last document now," Katzke said. That is Special Publication 800-53A , a security control assessment guide. NIST has
begun the second phase of implementation, which is an accreditation program for security assessment providers. A third phase, development of a system to validate FISMA compliance tools, is "out in he future." "The framework that we have established for federal agencies is really applicable to any environment," Katzke said. He said NIST is working with the IEEE to standardize its suite of documents that would help any organization go through the categorization, assessment and accreditation process required of government systems by FISMA.]

UCITA - BAD SOFTWARE - The Right Of Return - Warranties for "Free" Software - It does not require software publishers to reveal known defects www.affect.ucita.org

[ ... Evaluation can take months or years and can cost from
hundreds-of-thousands to millions of dollars. One person said theCommon Criteria evaluation was not worth the $150,000 "entry fee" a vendor could expect to pay unless the vendor had a government contract in hand that would justify the process.