云与山的彼端

The purpose of this document is to compare and contrast Extensible Access Control Markup Language (XACML) and Next Generation Access Control (NGAC) — two very different access control standards with similar goals and objectives. The document explains the basics of both standards and provides a comparative analysis based on attribute based access control (ABAC) considerations identified in NIST Special Publication (SP) 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations [2].

NIST SP800-177r1.pdf

The Computer Security Division’s computer scientists, mathematicians, IT specialists, support staff and others support CSD’s mission and responsibilities through five groups that are described in the following sections: • Cryptographic Technology Group • Security Components and Mechanisms Group • Secure Systems and Applications Group • Security Outreach and Integration Group • Security Testing, Validation, and Measurement Group

INTRODUCTION THE NEED TO PROTECT CONTROLLED UNCLASSIFIED INFORMATION oday, more than at any time in history, the federal government is relying on external service providers to help carry out a wide range of federal missions and business functions using state-of-the-practice information systems. Many federal contractors, for example, routinely process, store, and transmit sensitive federal information in their information systems1 to support the delivery of essential products and services to federal agencies (e.g., providing credit card and other financial services; providing Web and electronic mail services; conducting background investigations for security clearances; processing healthcare data; providing cloud services; and developing communications, satellite, and weapons systems). Additionally, federal information is frequently provided to or shared with entities such as State and local governments, colleges and universities, and independent research organizations. The protection of sensitive federal information while residing in nonfederal information systems2 and organizations is of paramount importance to federal agencies and can directly impact the ability of the federal government to successfully carry out its designated missions and business operations, including those missions and functions related to the critical infrastructure. The protection of unclassified federal information in nonfederal information systems and organizations is dependent on the federal government providing a disciplined and structured process for identifying the different types of information that are routinely used by federal agencies. On November 4, 2010, the President signed Executive Order 13556, Controlled Unclassified Information.3 The Executive Order established a governmentwide Controlled Unclassified Information (CUI)4 Program to standardize the way the executive branch handles unclassified information that requires protection and designated the National Archives and Records Administration (NARA) as the Executive Agent5 to implement that program. Only information that requires safeguarding or dissemination controls pursuant to federal law, regulation, or governmentwide policy may be designated as CUI. The CUI Program is designed to address several deficiencies in managing and protecting unclassified information to include inconsistent markings, inadequate safeguarding, and needless restrictions, both by standardizing procedures and by providing common definitions through a CUI Registry.6 The CUI Registry is the online repository for information, guidance, policy, and

Cryptographic publications of the National Institute of Standards and Technology (NIST) provide guidance regarding how cryptographic protection is to be implemented, but do not specify when cryptographic protection is required. The decision regarding whether or not to employ cryptographic protection rests with the owner of the information to be protected. Decisions concerning the use of cryptographic protection are generally based on a thorough risk analysis that establishes the sensitivity of the information to be protected and the security controls that need to be used to protect that information, both during transmission and while in storage. This document provides guidance on the basis for determining requirements for using cryptography. It includes a summary of the laws, directives, standards, and guidelines concerning the protection of the Federal government’s sensitive but unclassified information; guidance regarding the conduct of risk assessments to determine what information needs to be protected and how best to protect that information; and a discussion of application-relevant security documentation (e.g., various policy and practice documents). While the use of this guideline outside the Federal Government is strictly voluntary, many of the processes and references included herein may be useful in non-federal contexts. The primary policy documents that apply to federal cryptographic systems include Public Laws, Presidential Executive Orders and Directives, and other guidance from Executive Office of the President organizations. Some Department of Commerce and NIST publications are identified in these policy documents as being mandatory for Federal organizations. Relevant NIST cryptographic publications are discussed in Special Publication (SP) 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms.

Cryptographic publications of the National Institute of Standards and Technology (NIST) provide guidance regarding how cryptographic protection is to be implemented, but do not specify when cryptographic protection is required. The decision regarding whether or not to employ cryptographic protection rests with the owner of the information to be protected. Decisions concerning the use of cryptographic protection are generally based on a thorough risk analysis that establishes the sensitivity of the information to be protected and the security controls that need to be used to protect that information, both during transmission and while in storage. This document provides guidance on the basis for determining requirements for using cryptography. It includes a summary of the laws, directives, standards, and guidelines concerning the protection of the Federal government’s sensitive but unclassified information; guidance regarding the conduct of risk assessments to determine what information needs to be protected and how best to protect that information; and a discussion of application-relevant security documentation (e.g., various policy and practice documents). While the use of this guideline outside the Federal Government is strictly voluntary, many of the processes and references included herein may be useful in non-federal contexts. The primary policy documents that apply to federal cryptographic systems include Public Laws, Presidential Executive Orders and Directives, and other guidance from Executive Office of the President organizations. Some Department of Commerce and NIST publications are identified in these policy documents as being mandatory for Federal organizations. Relevant NIST cryptographic publications are discussed in Special Publication (SP) 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms.

INTRODUCTION THE NEED TO PROTECT CONTROLLED UNCLASSIFIED INFORMATION oday, more than at any time in history, the federal government is relying on external service providers to help carry out a wide range of federal missions and business functions using state-of-the-practice information systems. Many federal contractors, for example, routinely process, store, and transmit sensitive federal information in their information systems1 to support the delivery of essential products and services to federal agencies (e.g., providing credit card and other financial services; providing Web and electronic mail services; conducting background investigations for security clearances; processing healthcare data; providing cloud services; and developing communications, satellite, and weapons systems). Additionally, federal information is frequently provided to or shared with entities such as State and local governments, colleges and universities, and independent research organizations. The protection of sensitive federal information while residing in nonfederal information systems2 and organizations is of paramount importance to federal agencies and can directly impact the ability of the federal government to successfully carry out its designated missions and business operations, including those missions and functions related to the critical infrastructure. The protection of unclassified federal information in nonfederal information systems and organizations is dependent on the federal government providing a disciplined and structured process for identifying the different types of information that are routinely used by federal agencies. On November 4, 2010, the President signed Executive Order 13556, Controlled Unclassified Information.3 The Executive Order established a governmentwide Controlled Unclassified Information (CUI)4 Program to standardize the way the executive branch handles unclassified information that requires protection and designated the National Archives and Records Administration (NARA) as the Executive Agent5 to implement that program. Only information that requires safeguarding or dissemination controls pursuant to federal law, regulation, or governmentwide policy may be designated as CUI. The CUI Program is designed to address several deficiencies in managing and protecting unclassified information to include inconsistent markings, inadequate safeguarding, and needless restrictions, both by standardizing procedures and by providing common definitions through a CUI Registry.6 The CUI Registry is the online repository for information, guidance, policy, and

Overview: CTG’s work in the field of cryptography includes researching, analyzing, and standardizing cryptographic technology, such as hash algorithms, symmetric and asymmetric cryptographic techniques, key management, authentication, and random number generation. CTG’s goal is to identify and promote methods to enhance trust in communications, data, and storage through cryptographic technology, encouraging innovative development and helping technology users to manage risk. In Fiscal Year (FY) 2013, CTG continued to make an impact in the field of cryptography, both within and outside the Federal Government, by collaborating with national and international agencies, academic and research organizations, and standards bodies to develop interoperable security standards and guidelines. In addition, CTG worked with industry partners to promote the use of NIST-approved cryptographic methods.

Approximate matching is a promising technology designed to identify similarities between two digital artifacts. It is used to find objects that resemble each other or to find objects that are contained in another object. This can be very useful for filtering data for security monitoring, digital forensics, or other applications. The purpose of this document is to provide a definition and terminology to describe approximate matching in order to promote discussion, research, tool development and tool acquisition. Approximate matching has the potential to provide valuable filtering in a world inundated with information, but the technique is not widely used. The goal of the document is to provide infrastructure to support advances in approximate matching and its use in forensics and security.

The Cryptographic Technology Group’s (CTG) work in cryptographic mechanisms addresses topics such as hash algorithms, symmetric and asymmetric cryptographic techniques, key management, authentication, and random number generation. Strong cryptography is used to improve the security of information systems and the information they process. Users then take advantage of the availability of secure applications in the marketplace made possible by the appropriate use of standardized, highquality cryptography.

When deploying a new technology, an organization should be aware of the potential security impact it may have on the organization’s IT resources, data, and users. While new technologies may offer the promise of productivity gains and new capabilities, they may also present new risks. Thus, it is important for an organization’s IT professionals and users to be fully aware of these risks and either develop plans to mitigate them or accept their consequences. Recently, there has been a paradigm shift where organizations have begun to deploy new mobile technologies to facilitate their business processes. Such technologies have increased productivity by providing (1) an unprecedented level of connectivity between employees, vendors, and customers; (2) real-time information sharing; (3) unrestricted mobility; and (4) improved functionality. These mobile technologies comprise mobile devices (e.g., smartphones and tablets) and related mobile applications (or apps) that provide mission-specific capabilities needed by users to perform their duties within the organization (e.g., sales, distribution, and marketing). Despite the benefits of mobile apps, however, the use of apps can potentially lead to serious security risks. This is so because, like traditional enterprise applications, apps may contain software vulnerabilities that are susceptible to attack. Such vulnerabilities may be exploited by an attacker to steal information or control a user's device. To help mitigate the risks associated with software vulnerabilities, organizations should employ software assurance processes. Software assurance refers to “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner” [1]. The software assurance process includes “the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures” [2]. A number of government and industry legacy software assurance standards exist that are primarily directed at the process for developing applications that require a high level of assurance (e.g., space flight, automotive systems, and critical defense systems).1 Although considerable progress has been made in the past decades in the area of software assurance, and research and development efforts have resulted in a growing market of software assurance tools and services, the state of practice for many today still includes manual activities that are time-consuming, costly, and difficult to quantify and make repeatable. The advent of mobile computing adds new challenges because it does not necessarily support traditional software assurance techniques.

When deploying a new technology, an organization should be aware of the potential security impact it may have on the organization’s IT resources, data, and users. While new technologies may offer the promise of productivity gains and new capabilities, they may also present new risks. Thus, it is important for an organization’s IT professionals and users to be fully aware of these risks and either develop plans to mitigate them or accept their consequences. Recently, there has been a paradigm shift where organizations have begun to deploy new mobile technologies to facilitate their business processes. Such technologies have increased productivity by providing (1) an unprecedented level of connectivity between employees, vendors, and customers; (2) real-time information sharing; (3) unrestricted mobility; and (4) improved functionality. These mobile technologies comprise mobile devices (e.g., smartphones and tablets) and related mobile applications (or apps) that provide mission-specific capabilities needed by users to perform their duties within the organization (e.g., sales, distribution, and marketing). Despite the benefits of mobile apps, however, the use of apps can potentially lead to serious security risks. This is so because, like traditional enterprise applications, apps may contain software vulnerabilities that are susceptible to attack. Such vulnerabilities may be exploited by an attacker to steal information or control a user's device. To help mitigate the risks associated with software vulnerabilities, organizations should employ software assurance processes. Software assurance refers to “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner” [1]. The software assurance process includes “the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures” [2]. A number of government and industry legacy software assurance standards exist that are primarily directed at the process for developing applications that require a high level of assurance (e.g., space flight, automotive systems, and critical defense systems).1 Although considerable progress has been made in the past decades in the area of software assurance, and research and development efforts have resulted in a growing market of software assurance tools and services, the state of practice for many today still includes manual activities that are time-consuming, costly, and difficult to quantify and make repeatable. The advent of mobile computing adds new challenges because it does not necessarily support traditional software assurance techniques.

CHAPTER ONE INTRODUCTION nformation and Communications Technology (ICT) relies on a complex, globally distributed, and interconnected supply chain ecosystem that is long, has geographically diverse routes, and consists of multiple tiers of outsourcing. This ecosystem is composed of public and priv

INTRODUCTION THE NEED FOR CYBER RESILIENT SYSTEMS he need for trustworthy secure systems1 stems from a variety of stakeholder needs that are driven by mission, business, and other objectives and concerns. The principles, concepts, and practices for engineering trustworthy secure systems can be expressed in various ways, depending on which aspect of trustworthiness is of concern to stakeholders. [NIST 800-160, Vol.1] provides guidance on systems security engineering with an emphasis on protection against asset loss.2 In addition to security, other aspects of trustworthiness include, for example, reliability, safety, resilience, and privacy. Specialty engineering disciplines address different aspects of trustworthiness. While each specialty discipline frames the problem domain and the potential solution space for its aspect of trustworthiness somewhat differently, [NIST 800-160, Vol. 1] includes systems engineering processes to align the concepts, frameworks, and analytic processes from multiple disciplines to make trade-offs within and between the various aspects of trustworthiness applicable to a system-of-interest.3 NIST Special Publication 800-160, Volume 2 focuses on the property of cyber resiliency, which has a strong relationship to security and resilience, but which provides a distinctive framework for its identified problem domain and solution space. Cyber resiliency is the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources regardless of the source.4 Cyber resiliency supports mission assurance in a contested environment, for missions which depend on systems which include cyber resources. A cyber resource is an information resource which creates, stores, processes, manages, transmits, or disposes of information in electronic form and which can be accessed via a network or using networking methods. A cyber resource which can be accessed via a network exists in or has a presence in cyberspace. However, some information resources are designed to be accessed using a networking method only intermittently (e.g., via a low-power connection to check the status of an insulin pump; via a wired connection to upgrade software in an embedded avionic device). These cyber resources are characterized as operating primarily in stand-off mode.5

FIPS 201 originally required that all PIV credentials and associated keys be stored in a PIV Card. While the use of the PIV Card for electronic authentication works well with traditional desktop and laptop computers, it is not optimized for mobile devices. In response to the growing use of mobile devices within the Federal government, FIPS 201 was revised to permit the issuance of an additional credential, a Derived PIV Credential, for which the corresponding private key is stored in a cryptographic module with an alternative form factor to the PIV Card. Derived PIV Credentials leverage the current investment in the PIV infrastructure for electronic authentication and build upon the solid foundation of well-vetted and trusted identity of the PIV cardholder – achieving substantial cost savings by leveraging the identity-proofing results that were already performed to issue PIV cards. This document provides the technical guidelines for the implementation of Derived PIV Credentials. The use of a Derived PIV Credential is one possible way to PIV-enable a mobile device. In other cases it may be practical to use the PIV Card itself with the mobile device, using either the PIV Card’s contact or contactless interface, rather than issuing a Derived PIV Credential. Mobile devices are generally too small to integrate smart card readers into the device itself, requiring alternative approaches for communicating between the PIV Card and the mobile device. Some of these approaches are possible by today’s set of available products. Other, newer technologies are addressed by new guidelines in the existing set of PIV Special Publications. The current solution for PIV enablement directly uses PIV Cards with mobile devices through smart card readers. This has the advantage of avoiding the additional time and expense required to issue and manage Derived PIV Credentials. The approach requires smart card readers that are separate from, but attached to, the mobile device itself. These readers interface with the mobile device over a wired interface (e.g., USB) or wireless interface. The use of PIV Cards with mobile devices is functionally similar to their use with laptop and desktop computers. It does not involve new or different requirements to communicate with the PIV Card. Instead, the existing contact interface specifications of the PIV Card, as outlined in SP 800-73, form the basis for these types of readers to communicate with the PIV Card. Newer technology on mobile devices can directly communicate with and use PIV Cards over a contactless interface using Near Field Communication (NFC). Similarly to the mobile devices and attached reader scenario, the use of NFC technology with PIV cards also avoids the additional time and expense required to issue and manage Derived PIV Credentials. NFC uses radio frequency to establish communication between NFC-enabled devices. An NFC-enabled mobile device can interact with a PIV Card over its contactless interface at a very close range, allowing the mobile device to use the keys on the PIV Card without a physical connection. The user would need to hold or place the card next to the mobile device. Earlier PIV specifications did not allow the use of certain keys over the contactless interface, as existing technologies and standards did not support a secure channel between the smart card and the mobile device over NFC. SP 800-73-4 will include a new capability to enable access to all non-card-

FIPS 201 originally required that all PIV credentials and associated keys be stored in a PIV Card. While the use of the PIV Card for electronic authentication works well with traditional desktop and laptop computers, it is not optimized for mobile devices. In response to the growing use of mobile devices within the Federal government, FIPS 201 was revised to permit the issuance of an additional credential, a Derived PIV Credential, for which the corresponding private key is stored in a cryptographic module with an alternative form factor to the PIV Card. Derived PIV Credentials leverage the current investment in the PIV infrastructure for electronic authentication and build upon the solid foundation of well-vetted and trusted identity of the PIV cardholder – achieving substantial cost savings by leveraging the identity-proofing results that were already performed to issue PIV cards. This document provides the technical guidelines for the implementation of Derived PIV Credentials. The use of a Derived PIV Credential is one possible way to PIV-enable a mobile device. In other cases it may be practical to use the PIV Card itself with the mobile device, using either the PIV Card’s contact or contactless interface, rather than issuing a Derived PIV Credential. Mobile devices are generally too small to integrate smart card readers into the device itself, requiring alternative approaches for communicating between the PIV Card and the mobile device. Some of these approaches are possible by today’s set of available products. Other, newer technologies are addressed by new guidelines in the existing set of PIV Special Publications. The current solution for PIV enablement directly uses PIV Cards with mobile devices through smart card readers. This has the advantage of avoiding the additional time and expense required to issue and manage Derived PIV Credentials. The approach requires smart card readers that are separate from, but attached to, the mobile device itself. These readers interface with the mobile device over a wired interface (e.g., USB) or wireless interface. The use of PIV Cards with mobile devices is functionally similar to their use with laptop and desktop computers. It does not involve new or different requirements to communicate with the PIV Card. Instead, the existing contact interface specifications of the PIV Card, as outlined in SP 800-73, form the basis for these types of readers to communicate with the PIV Card. Newer technology on mobile devices can directly communicate with and use PIV Cards over a contactless interface using Near Field Communication (NFC). Similarly to the mobile devices and attached reader scenario, the use of NFC technology with PIV cards also avoids the additional time and expense required to issue and manage Derived PIV Credentials. NFC uses radio frequency to establish communication between NFC-enabled devices. An NFC-enabled mobile device can interact with a PIV Card over its contactless interface at a very close range, allowing the mobile device to use the keys on the PIV Card without a physical connection. The user would need to hold or place the card next to the mobile device. Earlier PIV specifications did not allow the use of certain keys over the contactless interface, as existing technologies and standards did not support a secure channel between the smart card and the mobile device over NFC. SP 800-73-4 will include a new capability to enable access to all non-card-

The purpose of this publication is to provide organizations with recommendations for improving the security configuration and monitoring of their IEEE 802.11 wireless local area networks (WLANs) and their devices connecting to those networks. The scope of this publication is limited to unclassified wireless networks and unclassified facilities within range of unclassified wireless networks. This publication supplements other NIST publications by consolidating and strengthening their key recommendations, and it points readers to the appropriate NIST publications for additional information (see Appendix C for the full list of references and Appendix A for a list of major security controls relevant for WLAN security). This publication does not eliminate the need to follow recommendations in other NIST publications, such as [SP800-48] and [SP800-97]. If there is a conflict between recommendations in this publication and another NIST wireless publication, the recommendation in this publication takes precedence.

This Profile for U.S. Federal Cryptographic Key Management Systems (FCKMSs1) is based on [SP 800-130], entitled “A Framework for Designing Cryptographic Key Management Systems (CKMS),” which provides a foundation for designing and implementing CKMSs. The Framework specifies requirements for designing any commercial or Federal CKMS, while this Profile provides more-specific design requirements for an FCKMS, and includes additional requirements for testing, procuring, installing, managing, operating, maintaining, and using FCKMSs. This Profile specifies requirements for all FCKMSs. It is intended to assist CKMS designers and implementers to select and support appropriate security services and key-management functions, and to assist FCKMS procurers, administrators, service-providing organizations, and service-using organizations to select appropriate CKMSs or CKMS services. This Profile specifies requirements for all organizations desiring to operate or use an FCKMS, either directly or under contract; makes recommendations for Federal organizations having special security needs and desiring to augment the base security and key-management services; and suggests additional FCKMS features that may be desirable for Federal organizations to implement and use now or in the future This Profile can be used by agencies and organizations to understand their FCKMSs, and to adopt, adapt and migrate their FCKMSs to comply with the Profile requirements over time. NIST does not expect that these requirements would be implemented immediately, but that agencies would use these requirements when creating or procuring FCKMSs or FCKMS services for their Enterprise Architectures. Agencies can also use these requirements to assess and understand potential gaps that exist in their current FCKMSs. As agencies plan for changes, migrations and upgrades, these requirements and the gap assessment can be used to improve the security of FCKMs overall.

This document provides guidelines for preventing the unauthorized modification of Basic Input/Output System (BIOS) firmware on PC client systems. Unauthorized modification of BIOS firmware by malicious software constitutes a significant threat because of the BIOS’s unique and privileged position within the PC architecture. A malicious BIOS modification could be part of a sophisticated, targeted attack on an organization —either a permanent denial of service (if the BIOS is corrupted) or a persistent malware presence (if the BIOS is implanted with malware). As used in this publication, the term BIOS refers to conventional BIOS, Extensible Firmware Interface (EFI) BIOS, and Unified Extensible Firmware Interface (UEFI) BIOS. This document applies to system BIOS firmware (e.g., conventional BIOS or UEFI BIOS) stored in the system flash memory of computer systems, including portions that may be formatted as Option ROMs. However, it does not apply to Option ROMs, UEFI drivers, and firmware stored elsewhere in a computer system. Section 3.1 of this guide provides platform vendors with recommendations and guidelines for a secure BIOS update process. Additionally, Section 3.2 provides recommendations for managing the BIOS in an operational environment. Future revisions to this publication will also address the security of critical system firmware that interact with the BIOS. While this document focuses on current and future x86 and x64 client platforms, the controls and procedures are independent of any particular system design. Likewise, although the guide is oriented toward enterprise-class platforms, the necessary technologies are expected to migrate to consumer-grade systems over time. Future efforts may look at boot firmware security for enterprise server platforms.

The purpose of this document is to explain the cloud computing technology area in plain terms, and to provide recommendations for information technology decision makers. Cloud computing is a developing area and its ultimate strengths and weakness are not yet fully researched, documented and tested.

The purpose of this document is to explain the cloud computing technology area in plain terms, and to provide recommendations for information technology decision makers. Cloud computing is a developing area and its ultimate strengths and weakness are not yet fully researched, documented and tested. This document gives recommendations on how and when cloud computing is an appropriate tool, and indicates the limits of current knowledge and areas for future analysis.

Interest in cloud computing has grown rapidly in recent years due to the advantages of greater flexibility and availability in obtaining computing resources at lower cost. Security and privacy, however, are a concern for agencies and organizations considering transitioning applications and data to public cloud computing environments, and form the impetus behind this document. 1.1 Authority The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III. This guideline has been prepared for use by federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired. Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. 1.2 Purpose and Scope The purpose of this document is to provide an overview of public cloud computing and the security and privacy challenges involved. The document discusses the threats, technology risks, and safeguards for public cloud environments, and provides the insight needed to make informed information technology decisions on their treatment. The document does not prescribe or recommend any specific cloud computing service, service arrangement, service agreement, service provider, or deployment model. Each organization must perform its own analysis of its needs, and assess, select, engage, and oversee the public cloud services that can best fulfill those needs.

Interest in cloud computing has grown rapidly in recent years due to the advantages of greater flexibility and availability in obtaining computing resources at lower cost. Security and privacy, however, are a concern for agencies and organizations considering transitioning applications and data to public cloud computing environments, and form the impetus behind this document. 1.1 Authority The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III. This guideline has been prepared for use by federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired. Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. 1.2 Purpose and Scope The purpose of this document is to provide an overview of public cloud computing and the security and privacy challenges involved. The document discusses the threats, technology risks, and safeguards for public cloud environments, and provides the insight needed to make informed information technology decisions on their treatment. The document does not prescribe or recommend any specific cloud computing service, service arrangement, service agreement, service provider, or deployment model. Each organization must perform its own analysis of its needs, and assess, select, engage, and oversee the public cloud services that can best fulfill those needs.

Software implementation errors are one of the most significant contributors to information system security vulnerabilities, making software testing an essential part of system assurance. Combinatorial methods can help reduce the cost and increase the effectiveness of software testing for many applications. This publication provides a self-contained tutorial on using combinatorial testing for real-world software. It introduces the key concepts and methods, explains use of software tools for generating combinatorial tests (freely available on the NIST web site csrc.nist.gov/acts), and discusses advanced topics such as the use of formal models of software to determine the expected results for each possible set of test inputs. The material is accessible to an undergraduate student of computer science or engineering, and includes an extensive set of references to papers that provide more depth on each topic.

PAGE 1 CHAPTER ONE INTRODUCTION nformation security continuous monitoring (ISCM) is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. 2 This publication specifically addresses assessment and analysis of security control effectiveness and of organizational security status in accordance with organizational risk tolerance. Security control effectiveness is measured by correctness of implementation and by how adequately the implemented controls meet organizational needs in accordance with current risk tolerance (i.e., is the control implemented in accordance with the security plan to address threats and is the security plan adequate).3 • Maintaining situational awareness of all systems across the organization; Organizational security status is determined using metrics established by the organization to best convey the security posture of an organization’s information and information systems, along with organizational resilience given known threat information. This necessitates: • Maintaining an understanding of threats and threat activities; • Assessing all security controls; • Collecting, correlating, and analyzing security-related information; • Providing actionable communication of security status across all tiers of the organization; and • Active management of risk by organizational officials. Communication with all stakeholders is key in developing the strategy and implementing the program. This document builds on the monitoring concepts introduced in NIST SP 800-37 Rev. 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach. An ISCM program helps to ensure that deployed security controls continue to be effective and that operations remain within stated organizational risk tolerances in light of the inevitable changes that occur over time. In cases where security controls are determined to be inadequate, ISCM programs facilitate prioritized security response actions based on risk. An ISCM strategy is meaningful only within the context of broader organizational needs, objectives, or strategies, and as part of a broader risk management strategy, enabling timely 2 The terms “continuous” and “ongoing” in this context mean that security controls and organizational risks are assessed and analyzed at a frequency sufficient to support risk-based security decisions to adequately protect organization information. Data collection, no matter how frequent, is performed at discrete intervals. 3 NIST SP 800-53A, as amended, defines security control effectiveness as “the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.”

This document specifies security requirements for existing application-specific key derivation functions in:  American National Standard (ANS) X9.42-2001-Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography (ANS X9.42-2001)

Cryptography is often used in an information technology security environment to protect data that is sensitive, has a high value, or is vulnerable to unauthorized disclosure or undetected modification during transmission or while in storage. Cryptography relies upon two basic components: an algorithm (or cryptographic methodology) and a cryptographic key. The algorithm is a mathematical function, and the key is a parameter used by that function. The National Institute of Standards and Technology (NIST) has developed a wide variety of Federal Information Processing Standards (FIPS) and NIST Special Publications (SPs) to specify and approve cryptographic algorithms for Federal government use. In addition, guidance has been provided on the management of the cryptographic keys to be used with these approved cryptographic algorithms. This Recommendation discusses the generation of the keys to be used with the approved cryptographic algorithms. The keys are either generated using mathematical processing on the output of approved Random Bit Generators and possibly other parameters, or generated based upon keys that are generated in this fashion.

Cryptography is often used in an information technology security environment to protect data that is sensitive, has a high value, or is vulnerable to unauthorized disclosure or undetected modification during transmission or while in storage. Cryptography relies upon two basic components: an algorithm (or cryptographic methodology) and a cryptographic key. The algorithm is a mathematical function, and the key is a parameter used by that function. The National Institute of Standards and Technology (NIST) has developed a wide variety of Federal Information Processing Standards (FIPS) and NIST Special Publications (SPs) to specify and approve cryptographic algorithms for Federal government use. In addition, guidance has been provided on the management of the cryptographic keys to be used with these approved cryptographic algorithms. This Recommendation discusses the generation of the keys to be used with the approved cryptographic algorithms. The keys are either generated using mathematical processing on the output of approved Random Bit Generators and possibly other parameters, or generated based upon keys that are generated in this fashion.

The randomness of cryptographic keys is essential for the security of cryptographic applications. In some applications, such as the protection of electronically stored data, passwords may be the only input required from the users who are eligible to access the data. Due to the low entropy and possibly poor randomness of those passwords, they are not suitable to be used directly as cryptographic keys. This Recommendation specifies a family of password-based key derivation functions (PBKDFs) for deriving cryptographic keys from passwords or passphrases for the protection of electronically-stored data or for the protection of data protection keys.

At the beginning of the 21st century, the National Institute of Standards and Technology (NIST) began the task of providing cryptographic key management guidance. This included lessons learned over many years of dealing with key management issues, and is intended to encourage the definition and implementation of appropriate key management procedures, to use algorithms that adequately protect sensitive information, and to plan ahead for possible changes in the use of cryptography because of algorithm breaks or the availability of more powerful computing techniques. General key management guidance, including the general approach for transitioning from one algorithm or key length to another, is addressed in Part 1 of Special Publication (SP) 800-57 [SP 800-57]. This Recommendation (SP 800-131A) is intended to provide more detail about the transitions associated with the use of cryptography by Federal government agencies for the protection of sensitive, but unclassified information. The Recommendation addresses the use of algorithms and key lengths; the validation of cryptographic modules that utilize them is provided in [SP 800-131B]. The dates provided in SP 800-131A may differ from the dates originally provided in the 2005 version of [SP 800-57]. The revised dates provided herein attempt to deal with the realities associated with an orderly transition and are based on a better understanding of the risks associated with extending the dates in those cases where this was done. Note that an upper-date limit is not provided herein for many of the algorithms and key lengths discussed; that information is provided in [SP 800-57], and should be considered valid unless different guidance is provided in the future.

At the beginning of the 21st century, the National Institute of Standards and Technology (NIST) began the task of providing cryptographic key management guidance. This included lessons learned over many years of dealing with key management issues, and is intended to encourage the definition and impl

At the beginning of the 21st century, the National Institute of Standards and Technology (NIST) began the task of providing cryptographic key management guidance. This included lessons learned over many years of dealing with key management issues, and is intended to encourage the definition and implementation of appropriate key management procedures, to use algorithms that adequately protect sensitive information, and to plan ahead for possible changes in the use of cryptography because of algorithm breaks or the availability of more powerful computing techniques. General key management guidance, including the general approach for transitioning from one algorithm or key length to another, is addressed in Part 1 of Special Publication (SP) 800-57 [SP 800-57]. This Recommendation (SP 800-131A) is intended to provide more detail about the transitions associated with the use of cryptography by Federal government agencies for the protection of sensitive, but unclassified information. The Recommendation addresses the use of algorithms and key lengths; the validation of cryptographic modules that utilize them is provided in [SP 800-131B]. The dates provided in SP 800-131A may differ from the dates originally provided in the 2005 version of [SP 800-57]. The revised dates provided herein attempt to deal with the realities associated with an orderly transition and are based on a better understanding of the risks associated with extending the dates in those cases where this was done. Note that an upper-date limit is not provided herein for many of the algorithms and key lengths discussed; that information is provided in [SP 800-57], and should be considered valid unless different guidance is provided in the future.

The purpose of this document is to provide information to organizations regarding the security capabilities of wireless communications using WiMAX networks and to provide recommendations on using these capabilities. WiMAX technology is a wireless metropolitan area network (WMAN) technology based upon the IEEE 802.16 standard. It is used for a variety of purposes, including, but not limited to, fixed last-mile broadband access, long-range wireless backhaul, and access layer technology for mobile wireless subscribers operating on telecommunications networks. The scope of this document is limited to the security of the WiMAX air interface and user subscriber devices, to include: security services for device and user authentication; data confidentiality; data integrity; and replay protection. This document does not address WiMAX network system specifications, which address core network infrastructure and are primarily employed by commercial network operators.4 This publication, while containing requirements specific to Federal agencies, serves to provide security guidance for organizations considering the implementation of WiMAX systems

with minimally acceptable system configuration requirements, as determined by the agency” within their information security program.5 Managing system configurations is also a minimum security requirement identified in FIPS 200,6 and NIST SP 800-537 defines security controls that support this requirement.

This document provides the definitive technical specification for Version 1.0 of the Security Content Automation Protocol (SCAP). SCAP (pronounced S-CAP) consists of a suite of specifications for standardizing the format and nomenclature by which security software communicates information about software flaws and security configurations. This document describes the basics of the SCAP component specifications and their interrelationships, the characteristics of SCAP content, as well as SCAP requirements not defined in the individual component specifications. The scope of this document is limited to SCAP Version 1.0. Other versions of SCAP and the component specifications, including emerging specifications and future versions of SCAP, are not addressed here. Future versions of SCAP will be defined in distinct revisions of this document, each clearly labeled with a document revision number and the appropriate SCAP version number.

This document provides the definitive technical specification for Version 1.0 of the Security Content Automation Protocol (SCAP). SCAP (pronounced S-CAP) consists of a suite of specifications for standardizing the format and nomenclature by which security software communicates information about software flaws and security configurations. This document describes the basics of the SCAP component specifications and their interrelationships, the characteristics of SCAP content, as well as SCAP requirements not defined in the individual component specifications. The scope of this document is limited to SCAP Version 1.0. Other versions of SCAP and the component specifications, including emerging specifications and future versions of SCAP, are not addressed here. Future versions of SCAP will be defined in distinct revisions of this document, each clearly labeled with a document revision number and the appropriate SCAP version number.

This document provides the definitive technical specification for Version 1.0 of the Security Content Automation Protocol (SCAP). SCAP (pronounced S-CAP) consists of a suite of specifications for standardizing the format and nomenclature by which security software communicates information about software flaws and security configurations. This document describes the basics of the SCAP component specifications and their interrelationships, the characteristics of SCAP content, as well as SCAP requirements not defined in the individual component specifications. The scope of this document is limited to SCAP Version 1.0. Other versions of SCAP and the component specifications, including emerging specifications and future versions of SCAP, are not addressed here. Future versions of SCAP will be defined in distinct revisions of this document, each clearly labeled with a document revision number and the appropriate SCAP version number.

This document provides the definitive technical specification for Version 1.0 of the Security Content Automation Protocol (SCAP). SCAP (pronounced S-CAP) consists of a suite of specifications for standardizing the format and nomenclature by which security software communicates information about software flaws and security configurations. This document describes the basics of the SCAP component specifications and their interrelationships, the characteristics of SCAP content, as well as SCAP requirements not defined in the individual component specifications. The scope of this document is limited to SCAP Version 1.0. Other versions of SCAP and the component specifications, including emerging specifications and future versions of SCAP, are not addressed here. Future versions of SCAP will be defined in distinct revisions of this document, each clearly labeled with a document revision number and the appropriate SCAP version number.

The purpose of the guide is to discuss the security concerns associated with full virtualization technologies for server and desktop virtualization, and to provide recommendations for addressing these concerns. All forms of virtualization other than server and desktop full virtualization are outside the scope of this document. Most existing recommended security practices remain applicable in virtual environments. The practices described in this document build on and assume the implementation of practices described in other NIST publication

The purpose of this document is to provide an overview of cell phone and PDA devices in use today and offer insight into making informed information technology security decisions on their treatment. The discussion gives details about the threats, technology risks, and safeguards for these devices. This document may be used by organizations interested in enhancing security to reduce related security incidents for current and future use of handheld devices. This document presents generic principles that apply to all such systems. This guideline does not cover the following aspects relating to securing handheld devices: