NIST SP800-70 Rev2：IT产品检查清单程序指南

需积分: 15 23 浏览量更新于2024-07-16 1 收藏 1.6MB PDF 举报

"NIST SP800-70-rev2.pdf" 是一份由美国国家标准与技术研究所（NIST）发布的文档，旨在指导IT产品清单的使用者和开发者如何利用NIST国家清单程序（NCP）。该文档涵盖了清单的使用、好处以及管理，并详述了参与NCP的政策、程序和一般要求。文档结构如下： 1.2 文档组织： - 第2部分介绍了清单的基本概念，阐述了NIST NCP的优势及其运作方式。它强调了清单在安全实践中的作用和价值。 - 第3部分深入探讨了预定义的清单操作环境，这些环境用于帮助开发者创建与安全实践相一致的清单。同时，它也为清单用户提供了选择适合自己操作环境的清单的指导。 - 第4部分面向潜在的清单用户，解释了如何通过NCP找到并检索最符合需求的清单。这部分还包含了实施清单的指南，包括如何分析特定的操作环境以及如何根据需要调整清单。 - 第5部分是针对当前和潜在的清单开发者的指南，详细说明了准备和提交清单到NIST以纳入清单库的过程和步骤。此外，附录提供了额外的信息： - 附录A列出了文档的参考文献。 - 附录B列出了参与NCP所需的程序性和法律要求。 - 附录C包含NCP参与和标志使用协议表格。 - 附录D详细说明了美国政府配置基线（USGCB）清单必须满足的附加要求。 - 附录E列出了文档中使用的缩写词。 - 附录F提供了一个术语表。 - 附录G给出了文档最新版本的变更日志。 NIST SP800系列标准是美国政府对IT安全控制的推荐指南，本文件SP800-70-rev2特别关注清单的使用和开发，对于确保IT产品的安全配置和合规性具有重要意义。通过遵循这些指南，组织和个人能够更有效地管理和评估其IT系统的安全状态。

NATIONAL CHECKLIST PROGRAM FOR IT PRODUCTS: GUIDELINES FOR CHECKLIST USERS AND DEVELOPERS

2-2

 Configuration files that automatically set or verify various security settings (e.g., executables, security

templates that modify settings, Security Content Automation Protocol (SCAP) XML files, and

scripts).

 Documentation (e.g., text file) that guides the checklist user to manually configure an IT product

 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 mechanisms

(e.g., passwords), and perimeter security.

Not all instructions in a security configuration checklist address security settings. Checklists can also

include administrative practices that improve an IT product’s security. Often, successful attacks on

systems result from poor administrative practices, such as not changing default passwords or not applying

vendor patches.

Typically, a system administrator or end user follows the instructions in the checklist to configure a

product or system to the level of security implemented in the checklist or to verify that a product or

system is already configured properly. The system administrator may need to modify the checklist to

incorporate the local security policy.

Examples of the types of devices and software for which security checklists are intended are as follows:

 General-purpose operating systems

 Common desktop applications such as email clients, web browsers, word processors, personal

firewalls, and antivirus software

 Infrastructure devices such as routers, firewalls, virtual private network (VPN) gateways, intrusion

detection systems (IDS), wireless access points, and telecommunication systems

 Application servers such as Domain Name System (DNS), Dynamic Host Configuration Protocol

(DHCP), web, Simple Mail Transfer Protocol (SMTP), and database servers

 Other network devices such as mobile devices, scanners, printers, copiers, and faxes.

2.2 Benefits of Using Security Checklists

Security configuration checklists, when developed correctly, can help users configure IT products so that

they have more protection than the installed out-of-the-box defaults provide. Applying checklists to

operating systems and applications can reduce the number of vulnerabilities that attackers can attempt to

exploit and lessen the impact of successful attacks. Using checklists improves the consistency and

predictability of system security, particularly in conjunction with user training and awareness activities

and other supporting security controls. Additional benefits associated with using checklists include the

following:

 Provides a base level of security to protect against common and dangerous local and remote threats

(e.g., viruses and worms, denial-of-service attacks, unauthorized access, and inappropriate usage)

More information about SCAP can be found at http://scap.nist.gov/ and NIST Special Publication 800-126, The Technical

Specification for the Security Content Automation Protocol (SCAP) [21].

NATIONAL CHECKLIST PROGRAM FOR IT PRODUCTS: GUIDELINES FOR CHECKLIST USERS AND DEVELOPERS

2-3

 Verify the configuration of certain technical security controls for system assessments, such as

confirming compliance with certain FISMA requirements or other sets of requirements, and

understanding the exposure caused by misconfigurations

 Significantly reduces the time required to research and develop appropriate security configurations

for installed IT products

 Allows smaller organizations to leverage outside resources to implement recommended practice

security configurations

 Reduces the likelihood of public loss of confidence or embarrassment resulting from a compromise of

publicly accessible systems.

Although using security configuration checklists can significantly improve overall levels of security in

organizations, using a checklist cannot make a system or a product 100 percent secure. However, using

checklists that emphasize hardening of systems against the hidden software flaws will typically result in

greater levels of product security and protection from future threats (e.g., zero-day vulnerabilities). IT

vendors that configure their products using checklists that adhere to the FISMA-associated security

control requirements will provide more consistency in configuration settings within the federal agencies.

This configuration will also provide a much more cost-effective method for establishing and verifying the

minimum configuration settings, even if the agencies must modify the checklists to fine-tune the

configuration settings for their specific applications and operational environments.

2.3 Overview of NIST National Checklist Program

Many organizations have created checklists; however, these checklists vary widely in terms of quality and

usability, and they may become outdated as software updates and upgrades are released. Without a central

checklist repository, finding security checklists can be difficult. In addition, checklists may differ

significantly from one another in terms of the level of security provided. Also, it may be difficult to

determine if the checklist is current or how the checklist should be implemented.

To facilitate development of security configuration checklists for IT products and to make checklists more

organized and usable, NIST established the NCP. The goals of the NCP are to—

 Facilitate development and sharing of checklists by providing a formal framework for vendors and

other checklist developers to submit checklists to NIST

 Provide guidance to developers to help them create standardized, high-quality checklists that conform

to common operational environments

 Help developers and users by providing guidelines for making checklists better documented and more

usable

 Encourage software vendors and other parties to develop checklists

 Provide a managed process for the review, update, and maintenance of checklists

 Provide an easy-to-use repository of checklist metadata

 Provide checklist content in a standardized format

 Encourage the use of automation technologies for applying checklists.

NATIONAL CHECKLIST PROGRAM FOR IT PRODUCTS: GUIDELINES FOR CHECKLIST USERS AND DEVELOPERS

2-4

Federal agencies are required to use appropriate security configuration checklists from the NCP when

available. In February 2008, revised Part 39 of the Federal Acquisition Regulation (FAR) was published.

Paragraph (d) of section 39.101 states, ―In acquiring information technology, agencies shall include the

appropriate IT security policies and requirements, including use of common security configurations

available from the NIST website at http://checklists.nist.gov. Agency contracting officers should consult

with the requiring official to ensure the appropriate standards are incorporated.‖

2.3.1 Types of Checklists Listed by National Checklist Program

The NCP deals with checklists that are tied to specific IT products, such as a checklist for a specific brand

and model of a router. Some checklists may guide a user to other checklists. For example, a checklist for a

database product may reference the checklist for the operating system on which the database product runs.

The NCP includes two major groups of checklists:

 Automated. An automated checklist is one that is used through one or more tools that automatically

alter or verify settings based on the contents of the checklist. Many checklists are written in

Extensible Markup Language (XML), and there are special tools that can use the contents of the XML

files to check and alter system settings.

For example, the Security Content Automation Protocol

(SCAP) is commonly used to express checklist content in a standardized way that can be processed

by tools that support SCAP.

 Non-Automated. As the name implies, a non-automated checklist is one that is designed to be used

manually, such as English prose instructions that describe the steps an administrator should take to

secure a system or to verify its security settings.

Security configuration checklists in the NCP can help organizations meet FISMA requirements. FISMA

requires each agency to determine minimally acceptable system configuration requirements and to ensure

compliance with them. Checklists can also map specific technical control settings to the corresponding

NIST SP 800-53 controls, which can make the verification of compliance more consistent and efficient.

Accordingly, federal agencies, as well as vendors of products for the federal government, are encouraged

to acquire or develop and to share such checklists using the NIST repository. The development and

sharing of checklists can reduce what would otherwise be a ―reinvention of the wheel‖ for IT products

that are widely used in the federal government, such as common operating systems, servers, and client

applications.

The NIST checklist repository (located at http://checklists.nist.gov/) contains information on automated

and non-automated checklists that have been developed and screened to meet the requirements of the

NCP. The repository also hosts copies of some checklists, primarily those developed by the federal

government, and has pointers to the other checklists’ locations. Users can browse checklist descriptions to

locate and retrieve a particular checklist using a variety of different fields, including such fields as

product category, vendor name, and submitting organization. A mailing list for the checklist program is

available at http://nvd.nist.gov/home.cfm?emaillist.

http://www.acquisition.gov/far/current/html/FARTOCP39.html

The Extensible Checklist Configuration Description Format (XCCDF) is an XML-based format for automating tool usage

and eliminating interpretation issues. The XCCDF XML format can be used for both technical checklists (e.g., operating

systems, software applications, and hardware configurations) and non-technical checklists (e.g., physical security for IT

systems). More information on XCCDF is available from NIST Interagency Report (IR) 7275 Revision 3, Specification for

the Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4, which is available for download at

http://nvd.nist.gov/scap/xccdf/docs/xccdf-spec-1.1.4-20071102.pdf. Another XML-based format for checklists is the Open

Vulnerability and Assessment Language (OVAL), which is used to exchange technical details about how to check for the

presence of vulnerabilities and configuration issues on systems. More information on OVAL is available at

http://oval.mitre.org/.

剩余73页未读，继续阅读

艾米的爸爸

粉丝: 800
资源: 314

NIST SP800-70 Rev2：IT产品检查清单程序指南

NIST SP800-70r4.pdf

NIST SP 800-53A: 联邦信息系统中安全控制评价指南

NIST SP800-88_rev1.pdf

NIST SP800-53-rev2-final.pdf

NIST SP800-60 Vol2 Rev1.pdf

NIST SP800-51rev1.pdf

NIST SP800-61 rev1.pdf

NIST SP800-22rev1a.pdf

NIST SP800-135 rev1.pdf

NIST SP800-66 Rev1.pdf

最新资源