NIST SP 800-12 Rev. 1 日本語訳

NIST Special Publication 800-12

Revision 1

Michael Nieles Kelley Dempsey Victoria Yan Pillitteri

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-12r1

NIST Special Publication 800-12

Revision 1

Michael Nieles Kelley Dempsey Victoria Yan Pillitteri

Computer Security Division Information Technology Laboratory

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-12r1

June 2017

U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology

Kent Rochford, Acting NIST Director and Under Secretary of Commerce for Standards and Technology

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the 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. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-12 Revision 1 Natl. Inst. Stand. Technol. Spec. Publ. 800-12 Rev. 1, 101 pages (June 2017) CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-12r1

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: sec-cert@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in systems security as well as its collaborative activities with industry, government, and academic organizations.

Organizations rely heavily on the use of information technology (IT) products and services to run their day-to-day activities. Ensuring the security of these products and services is of the utmost importance for the success of the organization. This publication introduces the information security principles that organizations may leverage to understand the information security needs of their respective systems.

assurance; computer security; information security; introduction; risk management; security controls; security requirements

The authors would like to thank everyone who took the time to review and make comments on the draft of this publication, specifically Celia Paulsen, Ned Goren, Isabel Van Wyk, and Rathini Vijayaverl of the National Institute of Standards and Technology (NIST). The authors would also like to acknowledge the original authors, Barbara Guttman and Edward A. Roback, as well as all those individuals who contributed to the original version of this publication.

This publication serves as a starting-point for those new to information security as well as those unfamiliar with NIST information security publications and guidelines. The intent of this special publication is to provide a high-level overview of information security principles by introducing related concepts and the security control families (as defined in NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations) that organizations can leverage to effectively secure their systems¹ and information. To better understand the meaning and intent of the security control families described later, this publication begins by familiarizing the reader with various information security principles.

After the introduction of these security principles, the publication provides detailed descriptions of multiple security control families as well as the benefits of each control family. The point is not to impose requirements on organizations, but to explore available techniques for applying a specific control family to an organization’s system and to explain the benefit(s) of employing the selected controls.

Since this publication provides an introduction to information security, detailed steps as to how security controls are implemented or how to check for security control effectiveness are not included. Rather, separate publications that may provide more detailed information about a specific topic will be noted as a reference.

The target audience for this publication are those new to the information security principles and tenets needed to protect information and systems in a way that is commensurate with risk. This publication provides a basic foundation of concepts and ideas to any person tasked with or interested in understanding how to secure systems.

For that reason, this publication is a good resource for anyone seeking a better understanding of information security basics or a high-level view on the topic. The tips and techniques described in this publication may be applied to any type of information or system in any type of organization. While there may be differences in the way federal organizations, academia, and the private sector process, store, and disseminate information within their respective systems, the basic principles of information security are applicable to all.

This publication is organized as follows:

The term Information System is defined by 44 U.S.C., Sec. 3502 as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.” For this publication, the term system is used in lieu of the term information system to reflect the broader applicability of information resources of any size or complexity, organized expressly for the collection, processing, use, sharing, dissemination, maintenance, or disposition of data or information. Some other key terms to be familiar with are:²

including means for protecting personal privacy and proprietary information.

Data Integrity – The property that data has not been altered in an unauthorized o manner. Data integrity covers data in storage, during processing, and while in transit. System Integrity – The quality that a system has when it performs its intended o function in an unimpaired manner, free from unauthorized manipulation of the system, whether intentional or accidental.

Within the Federal Government, many laws and regulations mandate that federal organizations protect their systems, the information processed, stored, or transmitted by systems, and related technology resources (e.g., telecommunications). A sampling of these laws and regulations is listed below.

This is not a comprehensive list of laws and regulations related to federal systems. There are more specific requirements imposed on federal agencies depending on the type of information they store, process, and disseminate. Additionally, some existing laws that affect non-government organizations were not included on this list. Examples of these laws include: the Health Insurance Portability and Accountability Act (HIPAA), which requires protection of the privacy and security of health information; and the Sarbanes-Oxley (SOX) Act, which requires protection for the public from accounting errors and fraudulent practices in financial systems.

Federal managers are responsible for familiarizing themselves and complying with applicable legal requirements. However, laws and regulations do not typically provide detailed instructions for protecting information. Instead, they specify broad, flexible requirements such as restricting the availability of personal data to authorized users. This publication provides guidance on developing an effective, overall information security approach to meet applicable laws or policies.

When it comes to information security and risk management, there are a specific set of Federal Information Processing Standards (FIPS) and NIST Special Publications (SPs) that apply. They include:

This publication addresses eight major elements regarding information security to help the reader gain a better understanding of how the security requirements and controls discussed in Chapter 10 support the overall operations of the organization. These eight concepts are:

In Chapter 1, information security was defined as the protection of information and systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. The careful implementation of information security controls is vital to protecting an organization’s information assets as well as its reputation, legal position, personnel, and other tangible or intangible assets.

An organization’s inability to select and implement appropriate security rules and procedures is likely to have a negative impact on the mission of the organization. However, well-chosen security rules and procedures that are put in place to protect important assets support the overall organizational mission. In today’s environment of malicious code, system breaches, and insider threats, publicized security issues can have dire consequences, especially to profitability and to the reputation of the organization. Private and public-sector organizations improve both profit and service to customers when appropriate security protections are in place. Information security, therefore, is a means to an end and not an end in itself.

It is critical to understand the organizational mission and how each system supports that mission. After a system's role has been defined, the security requirements implicit in that role can also be defined. Security can then be explicitly stated in terms of the organization's mission.

The roles and functions of a system may not be constrained to a single organization. In an inter-organizational system, each organization benefits from securing the system. For example, for electronic commerce to be successful, each of the participants requires security controls to

The roles and functions of a system may not be constrained to a single organization. In an inter-organizational system, each organization benefits from securing the system. For example, for electronic commerce to be successful, each of the participants requires security controls to protect their resources. Good security on the buyer's system also benefits the seller; the buyer's system is less likely to be used for fraud, to become unavailable, or to otherwise negatively affect the seller. (The reverse is also true.)

Management personnel are ultimately responsible for determining the level of acceptable risk for a specific system and the organization as a whole, taking into account the cost of security controls. Since information security risk cannot be completely eliminated, the objective is to find the optimal balance between protecting the information or system and utilizing available resources. It is vital for systems and related processes to have the ability to protect information, financial assets, physical assets, and employees, while also taking resource availability into consideration.

When an organization's information and systems are linked with external systems, management's responsibilities extend beyond organizational boundaries. This may require that management (1) know what general level or type of security is employed on the external system(s), and/or (2) seek assurance that the external system provides adequate security for the organization’s information and system. For example, cloud service providers (CSPs) and cloud supply chain participants may assume the management role for storing, processing, and transmitting organizational information. However, that does not leave the organization⁵ free of any security-related responsibility. It is up to the organization to ensure that the CSPs and cloud supply chain participants provide an appropriate level of security for the information being stored, processed, and transmitted.

Risk to a system can never be completely eliminated. Therefore, it is crucial to manage risk by striking a balance between usability and the implementation of security protections. The primary objective of risk management is to implement security protections that are commensurate with risk. Applying unnecessary protections may waste resources and make systems more difficult to use and maintain. Conversely, not applying protections needed to protect the system may leave it and its information vulnerable to breaches in confidentiality, integrity, and availability, all of which could impede or even halt the mission of the organization.

Federal organizations use impact levels (high, moderate, and low) to identify and categorize the impact that a loss of confidentiality, integrity, or availability of information and/or a system may have on the organization’s operations and allow them to identify appropriate protections. The accurate categorization of information and systems is integral in determining how to protect information commensurate with risk. Security categories convey the impact that a loss of confidentiality, integrity, or availability may have on the mission of the organization. To determine the impact level of a system, organizations may refer to the guidance in FIPS 199, NIST SP 800-30, and NIST SP 800-60.

An accurate determination of the system impact level provides the information needed to select an appropriate set of security controls from NIST SP 800-53. The selection process includes an assessment of the costs to implement and maintain the security controls and the expected security benefits (i.e., risk reduction) from applying those controls.

Security benefits have both direct and indirect costs. Direct costs include purchasing, installing, and administering security protections (e.g., access control software or fire-suppression systems). Indirect costs may affect both system and business performance, employee morale, or retraining requirements. In some cases, indirect costs may exceed the direct cost of the control. Organizational management is responsible for weighing the cost versus benefit of the appropriate protection implementation and making risk-based decisions.

The roles and responsibilities of system owners, common control providers, authorizing officials, system security officers, users, and others are clear and documented. If the responsibilities are not made explicit, management may find it difficult to hold personnel accountable for future outcomes.

Documenting information security responsibilities is not dependent on the size of the organization. Even small organizations can prepare a document that states the organizational policy and identifies the information security responsibilities for a system or for the entire organization.

Roles and responsibilities are discussed briefly in Chapter 3 of this publication. For more detailed information specific to key information security participants, refer to Appendix D of NIST SP 800-37.

Users of a system are not always located within the boundary of the system they use or have access to. For example, when an interconnection between two or more systems is in place, information security responsibilities might be shared amongst the participating organizations. When such is the case, the system owners are responsible for sharing the security measures used by the organization to provide confidence to the user that the system is adequately secure and capable of meeting security requirements. In addition to sharing security-related information, the incident response team has a duty to respond to security incidents in a timely fashion in order to prevent damage to the organization, personnel, and other organizations.

Providing effective information security requires a comprehensive approach that considers a variety of areas both within and outside of the information security field. This approach applies throughout the entire system life cycle.

For example, defense-in-depth is a security principle used to protect organizational information and systems from threats by implementing multi-layered security countermeasures. Defense-in-depth utilizes administrative defenses (e.g., policies, procedures) and security technologies (e.g., intrusion detection systems, firewalls, configuration settings, and antivirus software) in tandem with physical security defenses (e.g., gates, guards) to minimize the probability of a successful attack on the system. These measures not only help reduce the likelihood that a security breach will compromise access to system assets or have detrimental effects on confidentiality, integrity, or availability, but also give the organization near-real time notification once an attack has been initiated.

Security controls are seldom put in place as stand-alone solutions to a problem. They are typically more effective when paired with another control or set of controls. Security controls, when selected properly, can have a synergistic effect on the overall security of a system. Each security control in NIST SP 800-53 has a related controls section listing security control(s) that compliment that specific control. If users do not understand these interdependencies, the results can be detrimental to the system.

Interdependencies between and amongst security controls are not the only factor that can influence the effectiveness of security controls. System management, legal constraints, quality assurance, privacy concerns, and internal and management controls can also affect the functionality of the selected controls. System managers must be able to recognize how information security relates to other security disciplines like physical and environmental security. Understanding how those relationships work together will prove beneficial when implementing a more holistic security strategy. NIST SP 800-160, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, provides much more detailed information on considerations to engineering a trustworthy system.

Understanding the relationships between security controls is especially important when systems are connected to other systems or interconnected to a globally distributed supply chain ecosystem. Supply chains consist of public- and private-sector entities and use geographically-diverse routes to provide a highly-refined, cost-effective, reusable information and communications technology (ICT) solution. For more information on supply chain risk management, see NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations.

Information security is not a static process and requires continuous monitoring and management to protect the confidentiality, integrity, and availability of information as well as to ensure that new vulnerabilities and evolving threats are quickly identified and responded to accordingly. In the presence of a constantly evolving workforce and technological environment it is essential that organizations provide timely and accurate information while operating at an acceptable level of risk.

Information Security Continuous Monitoring (ISCM) is defined in NIST SP 800-137 as the maintenance of ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. ISCM provides a clear understanding of organizational risk tolerance to assist officials in setting priorities and managing risk throughout the organization in a consistent manner. ISCM ensures that the selected security controls remain effective and maintains organizational awareness of threats and vulnerabilities.

For more detailed information on continuous monitoring fundamentals and the continuous monitoring process, refer to NIST SP 800-137. NIST SP 800-53A can also be leveraged to provide insight on assessment procedures.

Societal factors influence how individuals understand and use systems which consequently impacts the information security of the system and organization. Individuals perceive, reason, and make risk-based decisions in different ways. To address this, organizations make information security functions transparent, easy to use, and understandable. Additionally, providing regularly scheduled security awareness training mitigates individual differences of risk perception. As with societal factors, how an organization conducts business can serve as a culture factor worth considering when dealing with information security. An organization’s own culture can impact its response to information security. Careful explanation of the risks associated with the business practices can help in the transparency and acceptance of the recommended information security practices.

It is incumbent on organizations to find a balance between information security requirements and usability. Organizations can leverage a variety of tools that meet the security requirements of their system(s) without unduly burdening the user. For example, consider a system that requires a user to input their username and password multiple times to access different applications during a single session. In that scenario, organizations can choose which types of applications, if any, will permit password and password hash storage based on a consideration of the risks versus the convenience of the users.

Privacy was once considered to be unrelated to information security—the two functions were discussed as if they could not co-exist in a system. Today, a symbiotic relationship between privacy and information security is essential. Organizations cannot protect the privacy of individuals without a basic foundation of information security. However, privacy is more than security as it also relates to problems that individuals may experience as a result of the authorized processing of their information throughout the data life cycle. Protecting the privacy of individuals is a fundamental responsibility of organizations that collect, use, maintain, share, and dispose of personally identifiable information (PII). For more detailed privacy information see NISTIR 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems and NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII).

Overall, the relationship between security and societal norms need not necessarily be antagonistic. Societal norms can have both a positive and negative impact on information security. For example, a negative impact on information security can be seen in the form of a user writing down passwords and keeping them near their computer. A positive impact can be seen by a broader implementation of multi-factor authentication—where in order for a user to reset a password, more than one form of authentication is required (e.g., text message to user, physical token). Security can enhance the access and flow of data and information by providing more accurate and reliable information as well as greater availability of systems. Security mechanisms can also enhance individuals’ privacy (e.g., encryption). Some security mechanisms may present new vulnerabilities (e.g., single sign-on). Thus, it is important to consider how to implement security solutions in ways that optimize broader societal goals.

Societal norms change and so too must the information security protections placed on systems. Security controls that are presently sufficient may not keep pace with the constantly changing computing environment. The culture and security environment of the organization also plays an important role in the employees’ perception of risk. Insufficient or non-existent security standards may lead to the degradation of the organization’s security posture. Providing updated and recurring training on what is and what is not an acceptable use of organizational systems helps safeguard the overall security of the system.

The following chapter outlines specific organizational roles and their respective responsibilities. Clearly defined roles and responsibilities help the organization and its employees work in a more efficient manner by designating who is responsible for performing certain tasks. In a large organization, this will help by ensuring that no task is overlooked. In a small, less structured organization, the workload can be more evenly distributed as an employee may be required to take on more than one task.

The list provided below is not intended to be a comprehensive list of all the possible roles within an organization. Each organization may define their own specific roles or have a different naming convention based on their mission or organizational structure. However, the basic functions remain the same. For a more detailed description of the responsibilities assigned to each role, see Appendix D in NIST SP 800-37.

The Risk Executive Function is an individual or group (e.g., board members, CEO, CIO) within an organization responsible for ensuring that: (i) risk-related considerations for individual systems are viewed from an organization-wide perspective, taking into consideration the overall strategic goals of the organization in carrying out its core missions and business functions, and (ii) the management of system-related security risks is consistent across the organization, reflects organizational risk tolerance, and is considered along with other types of risks in order to ensure mission/business success.

Responsibilities include, but are not limited to:

The Chief Executive Officer is the highest-level senior official or executive in an organization with the overall responsibility to provide information security protections commensurate with the risk and magnitude of harm (i.e. impact) to organizational operations assets, individuals, other organizations, and the Nation that may result from unauthorized access, use, disclosure, disruption, modification, or destruction of: (i) information collected or maintained by or on behalf of the organization; and (ii) systems used or operated by an agency, or by a contractor of an agency, or another organization on behalf of an agency.

Responsibilities include, but are not limited to:

The Chief Information Officer is an organizational official responsible for: (i) designating a senior agency information security officer; (ii) developing and maintaining security policies, procedures, and control techniques to address all applicable requirements; (iii) overseeing personnel with significant responsibilities for information security and ensuring that personnel are adequately trained; (iv) assisting senior organizational officials with their security responsibilities; and (v) in coordination with other senior officials, reporting annually on the overall effectiveness of the organization’s information security program, including progress of remedial actions. Responsibilities include, but are not limited to:

The Information Owner/Steward is an organizational official with statutory, management, or operational authority for specified information who is responsible for establishing the policies and procedures governing its generation, collection, processing, dissemination, and disposal. Responsibilities include, but are not limited to:

The Senior Agency Information Security Officer is an organizational official responsible for: (i) carrying out the chief information officer security responsibilities under FISMA; and (ii) serving as the primary liaison between the chief information officer and the organization’s authorizing officials, system owners, common control providers, and system security officers. In some organizations, this role might also be known as the Chief Information Security Officer (CISO). Responsibilities include, but are not limited to:

The Authorizing Official is a senior official or executive with the authority to formally assume responsibility for operating a system at an acceptable level of risk to organizational operations and assets, individuals, and other organizations. Responsibilities include, but are not limited to:

The Authorizing Official Designated Representative is an organizational official who acts on behalf of an authorizing official to coordinate and conduct the required day-to-day activities associated by the security authorization process. The designated representative carries out the functions of the AO, but cannot accept risk for the system. Responsibilities include, but are not limited to:

The Senior Agency Official for Privacy is a senior organizational official who has the overall responsibility and accountability for ensuring the agency’s implementation of information privacy protections, including the agency’s full compliance with federal laws, regulations, and policies relating to information privacy, such as the Privacy Act. Responsibilities include, but are not limited to:

The Common Control Provider is an individual, group, or organization responsible for the development, implementation, assessment, and monitoring of common controls (i.e. security controls inherited by systems). Responsibilities include, but are not limited to:

The System Owner is an organizational official responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of a system. Responsibilities include, but are not limited to:

The System Security Officer is responsible for ensuring that an appropriate operational security posture is maintained for a system and as such, works in close collaboration with the system owner. Responsibilities include, but are not limited to:

The Information Security Architect is an individual, group, or organization responsible for ensuring that the information security requirements necessary to protect the organization’s core missions and business processes are adequately addressed in all aspects of enterprise architecture, including reference models, segment and solution models, and the resulting systems supporting those missions and business processes. Responsibilities include, but are not limited to:

The System Security Engineer is an individual, group, or organization responsible for conducting system security engineering activities. Responsibilities include, but are not limited to:

The Security Control Assessor is an individual, group, or organization responsible for conducting a comprehensive assessment of the managerial, operational, and technical security controls and control enhancements employed within or inherited by a system to determine the overall effectiveness of the controls (i.e., 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). Responsibilities include, but are not limited to:

The System Administrator is an individual, group, or organization responsible for setting up and maintaining a system or specific components of a system. Responsibilities include, but are not limited to:

The User is an individual, group, or organization granted access to organizational information in order to perform assigned duties. Responsibilities include, but are not limited to:

A vulnerability is a weakness in a system, system security procedure, internal controls, or implementation that could be exploited by a threat source.⁶ Vulnerabilities leave systems susceptible to a multitude of activities that can result in significant and sometimes irreversible losses to an individual, group, or organization. These losses can range from a single damaged file on a laptop computer or mobile device to entire databases at an operations center being compromised. With the right tools and knowledge, an adversary can exploit system vulnerabilities and gain access to the information stored on them. The damage inflicted on compromised systems can vary depending on the threat source.

A threat source can be adversarial or non-adversarial. Adversarial threat sources are individuals, groups, organizations, or entities that seek to exploit an organization’s dependence on cyber resources. Even employees, privileged users, and trusted users have been known to defraud organizational systems. Non-adversarial threat sources refer to natural disasters or erroneous actions taken by individuals in the course of executing their everyday responsibilities.

If the system is vulnerable, threat sources can lead to threat events. A threat event is an incident or situation that could potentially cause undesirable consequences or impacts. An example of a threat source leading to a threat event is a hacker installing a keystroke monitor on an organizational system. The damage that threat events may cause on systems varies considerably. Some affect the confidentiality and integrity of the information stored in a system while others only affect the availability of the system. For more information on threat sources and threat events, see NIST SP 800-30.

This chapter presents a broad overview of the environment in which systems operate today and may prove valuable to organizations seeking a better understanding of specific threat environment. The list provided herein is not intended to be an all-inclusive list. The scope of the information provided here may be too broad, and threats against specific systems could be quite different from what is discussed in this chapter.

In order to protect a system from risk and to implement the most cost-effective security measures, system owners, managers, and users need to know and understand the vulnerabilities of the system as well as the threat sources and events that may exploit the vulnerabilities. When determining the appropriate response to a discovered vulnerability, care should be taken to minimize the expenditure of resources on vulnerabilities where little or no threat is present. See Chapter 6, Information Security Risk Management, for more detailed information on how threats, vulnerabilities, safeguard selection, and risk response are related.

The previous section defined threat sources and threat events. This section provides several examples of each followed by a description.

Systems can be exploited for fraud and theft by “automating” traditional methods of fraud or by utilizing new methods. System fraud and theft can be committed by insiders (i.e. authorized users) and outsiders. Authorized system administrators and users with access to and familiarity with the system (e.g., resources it controls, flaws) are often responsible for fraud. An organization’s former employees also pose a threat given their knowledge of the organization’s operations particularly if access is not terminated promptly.

Financial gain is one of the chief motivators behind fraud and theft, but financial systems are not the only systems at risk. There are several techniques that an individual can use to gather information they would otherwise not have had access to. Some of these techniques include:

Employees can represent an insider threat to an organization given their familiarity with the employer’s systems and applications as well as what actions may cause the most damage, mischief, or disorder. Employee sabotage—often instigated by knowledge or threat of termination—is a critical issue for organizations and their systems. In an effort to mitigate the potential damage caused by employee sabotage, the terminated employee’s access to IT infrastructure should be immediately disabled, and the individual should be escorted off company premises.

Examples of system-related employee sabotage include, but are not limited to:

Malicious hacker is a term used to describe an individual or group who use an understanding of systems, networking, and programming to illegally access systems, cause damage, or steal information. Understanding the motivation that drives a malicious hacker can help an organization implement the proper security controls to prevent the likelihood of a system breach. Malicious hacker is a broad category of adversarial threats that can be broken out into smaller categories depending on the specific actions or intent of the malicious hacker. Some of the sub-categories adapted from NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security, include:

In some instances, threats posed by foreign government intelligence services may be present. In addition to possible economic espionage, foreign intelligence services may target unclassified systems to further their intelligence missions. Some unclassified information that may be of interest includes travel plans of senior officials, civil defense and emergency preparedness, manufacturing technologies, satellite data, personnel and payroll data, and law enforcement, investigative, and security files.

Malicious code refers to viruses, Trojan horses, worms, logic bombs, and any other software created for the purpose of attacking a platform.

Errors and omissions can be inadvertently caused by system operators who process hundreds of transactions daily or by users who create and edit data on organizational systems. These errors and omissions can degrade data and system integrity. Software applications, regardless of the level of sophistication, are not capable of detecting all types of input errors and omissions. Therefore, it is the responsibility of the organization to establish a sound awareness and training program to reduce the number and severity of errors and omissions. Errors by users, system operators, or programmers may occur throughout the life cycle of a system and may directly or indirectly contribute to security problems. In some cases, the error is a threat, such as a data entry error or a programming error that crashes a system. In other cases, the errors cause vulnerabilities. Programming and development errors, often referred to as “bugs,” can range from benign to catastrophic.

The loss of supporting infrastructure includes power failures (e.g., outages, spikes, brownouts), loss of communications, water outages and leaks, sewer malfunctions, disruption of transportation services, fire, flood, civil unrest, and strikes. A loss of supporting infrastructure often results in system downtime in unexpected ways. For example, employees may not be able to get to work during a winter storm, although the systems at the work site may be functioning as normal. Additional information can be found in section 10.11, Physical and Environmental Protection.

The accumulation of vast amounts of personally identifiable information by government and private organizations has created numerous opportunities for individuals to experience privacy problems as a byproduct or unintended consequence of a breach in security. For example, migrating information to a cloud service provider has become a viable option that many individuals and organizations utilize. The ease of accessing data from the cloud has made it a more attractive solution for long term storage. Everything that is written, uploaded, or posted is stored in a cloud system that individuals do not control. However, unbeknownst to the cloud service user, personal information can be accessed by a stranger with the right tools and technical skill sets. Individuals’ voluntarily sharing PII through social media has also contributed to new threats that allow malicious hackers to use that information for social engineering or to bypass common authentication measures. Linking all this information and technology together, malicious hackers have the ability to create accounts using someone else’s information or gain access to networks. Organizations may share information about cyber threats that includes PII. These disclosures could lead to unanticipated uses of such information, including surveillance or other law enforcement actions.

The term policy has more than one definition when discussing information security. NIST SP 800-95, Guide to Secure Web Services, defines policy as “statements, rules or assertions that specify the correct or expected behavior of an entity.” For example, an authorization policy might specify the correct access control rules for a software component. The term policy can also refer to specific security rules for a system or even the specific managerial decisions that dictate an organization’s email privacy policy or remote access security policy.

Information security policy is defined as an aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information. In making these decisions, managers face difficult decisions with regard to resource allocation, competing objectives, and organizational strategy, all of which relate to protecting technical and information resources as well as guiding employee behavior. Managers at all levels make choices that can affect policy, with the scope of the policy’s applicability varying according to the scope of the manager’s authority.

Managerial decisions on information security issues vary greatly. To differentiate various kinds of policy, this chapter categorizes them into three basic types: Program Policy, Issue-specific Policy, and System-specific Policy.

Policy controls are addressed by the “-1” controls for every security control family found in NIST SP 800-53. The “-1” controls establish policy and procedures for the effective implementation of the selected security control and control enhancement.

Because policy is written at a broad level, organizations also develop standards, guidelines, and procedures that offer users, managers, system administrators, and others a clearer approach to implementing policy and meeting organizational goals. Standards and guidelines specify technologies and methodologies to be used to secure systems. Procedures are yet more detailed steps to be followed to accomplish security-related tasks. Standards, guidelines, and procedures may be promulgated throughout an organization via handbooks, regulations, or manuals.

Some organizations issue overall information security manuals, regulations, handbooks, or similar documents. These may mix policy, guidelines, standards, and procedures, since they are closely linked. While manuals and regulations can serve as important tools, it is often useful if they clearly distinguish between policy and its implementation. This can help in promoting flexibility and cost-effectiveness by offering alternative implementation approaches to achieving policy goals.

Program policy is used to create an organization’s information security program. Program policies set the strategic direction for security and assign resources for its implementation within the organization. A management official—typically the SISO—issues program policy to establish or restructure the organization’s information security program. This high-level policy defines the purpose of the program and its scope within the organization, addresses compliance issues, and assigns responsibility to the information security organization for direct program implementation as well as other related responsibilities.

Program policy addresses the following:

An important aspect of developing compliance policy is to remember that an employee’s violation of policy may be unintentional. For example, nonconformance can often be the result of a lack of knowledge or training. The need to obtain guidance from appropriate legal counsel is critical when addressing issues involving penalties and disciplinary action for individuals. The policy does not need to restate penalties already addressed by law, although they can be listed if the policy will also be used as an awareness or training document.

Based on the guidance from the information security policy, issue-specific policies are developed to address areas of current relevance and concern to an organization. The intent is to provide specific guidance and instructions on proper usage of systems to employees within the organization. An issue-specific policy is meant for every technology the organization uses and is written in such a way that it will be clear to users. Unlike program policies, issue-specific policies must be reviewed on a regular basis due to frequent technological changes in an organization.

There are many areas for which issue-specific policy may be appropriate. New technologies and the discovery of new threats often require the creation of an issue-specific policy. Examples of issue-specific policy include:

Other topics that are candidates for issue-specific policy include, but are not limited to: approach to risk management and contingency planning, protection of confidential/proprietary information, unauthorized software, unauthorized use of equipment, violations of policy, use of external storage, rights of privacy, and physical emergencies.

An issue-specific policy can be broken down into the following components:

Program and issue-specific policies are broad, high-level policies written to encompass the entire organization where system-specific policies provide information and direction on what actions are permitted on a particular system. These policies are similar to issue-specific policies in that they relate to specific technologies throughout the organization. However, system-specific policies dictate the appropriate security configurations to the personnel responsible for implementing the required security controls in order to meet the organization’s information security needs. To develop a cohesive and comprehensive set of security policies, officials may use a management process that derives security rules from security goals. It is helpful to consider a two-level model for system security policy: security objectives and operational security rules. Closely linked and often difficult to distinguish, however, is the implementation of the policy in technology. Similar to issue-specific policies, it is recommended that system-specific policies be reviewed as required by organization defined time period to ensure conformance to the most current security procedures.

The first step in the management process is to define security objectives commensurate with risk for the specific system. Although this process may begin with an analysis of the need for integrity, confidentiality, and availability, it may not stop there. A security objective needs to be specific, concrete, well defined, and stated in such a way that it is a clearly achievable objective. Stakeholders play an important role in developing comprehensive, yet practical, policy. Therefore, it is imperative to remember that policy is not created by management personnel only.

After management determines the security objectives, rules for managing and operating a system can be identified and documented. For example, the rules may define authorized modifications— specifying individuals allowed to take certain actions under particular conditions with regard to specific classes and records of information. The degree of specificity needed for operational security varies from system-to-system. The more detailed the rules are, the easier it is for administrators to determine when a violation has occurred. A detailed description can also streamline automating policy enforcement.

In addition to deciding the level of detail, management determines the degree of formality in documenting the system-specific policy. Once again, the more formal the documentation, the easier it is to enforce and to follow the policy. For example, a helpful practice would be to draft a statement of the access privileges for a system as well as the assignment of security responsibilities. The rules for system usage and the consequences of noncompliance should also be addressed. Documenting access control policy can make it substantially easier to follow and to enforce.

Policy decisions in other areas of information security, such as those described in this publication, are often documented in the risk analysis, accreditation statements, or procedural manuals. However, any controversial, atypical, or uncommon policies will also need formal statements. Atypical policies may include areas in which the system policy varies from organizational policy or from normal practice within the organization. The documentation for a typical policy contains a statement explaining the reason for deviation from the organization's standard policy.

Technology plays an important role in enforcing system-specific policies but it is not solely responsible for meeting an organization’s security needs. When technology is used to enforce policy, it is important to consider manual methods. For example, technical system-based controls could be used to limit the printing of confidential reports to a specific printer. However, corresponding physical security measures would also have to be in place to limit access to the printer output or the desired security objective would not be achieved.

Technological methods frequently used to implement system-security policy are likely to include the use of logical access controls. Some examples of access controls would be: separation of duties, which is a control designed to address the potential for abuse of authorized privileges and helps reduce the risk of malevolent activity without collusion; and least privilege, which allows only authorized access for users or processes acting on behalf of users that is necessary to accomplish assigned tasks in accordance with organizational missions and business functions. However, there are other automated means of enforcing or supporting security policy that typically supplement logical access controls. For example, intrusion detection software can alert system administrators to suspicious activity or even take action to stop such activity.

Technology-based enforcement of system-security policy has both advantages and disadvantages. A system, properly designed, programmed, installed, configured, and maintained, consistently enforces policy within the system, although no system can force users to follow all procedures. Management controls also play an important role in policy enforcement, so neglecting them would be detrimental to the organization. In addition, deviations from the policy may sometimes be necessary and appropriate; such deviations may be difficult to implement easily with some technical controls. This situation occurs frequently if implementation of the security policy is too rigid, which can occur when the system analysts fail to anticipate contingencies and prepare for them.

Policy is related to many of the topics covered in this publication:

A number of potential costs are associated with developing and implementing information security policies. The most significant costs are implementing the policy and addressing its subsequent impacts on the organization, its resources, and personnel. The establishment of an information security program, accomplished through policy, likely does not come at a negligible cost. Other costs may be those incurred through the policy development process. Numerous administrative and management activities may be required for drafting, reviewing, coordinating, clearing, disseminating, and publicizing policies. In many organizations, successful policy implementation may require additional staffing and training. In general, the costs to an organization for information security policy development and implementation will be dependent upon how extensive the change must be in order for management to decide that an acceptable level of risk has been reached. The cost of securing information and systems is unavoidable. The objective is to ensure that security protections are commensurate with risk by striking a balance between the protections required to meet the security objectives of the organization and the cost of such protections.

Risk is a measure of the extent an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Individuals manage risks every day, though they may not be aware of it. Actions as routine as buckling a car safety belt, carrying an umbrella when rain is forecasted, or writing down a list of things to do rather than trusting to memory all fall under the purview of risk management. Individuals recognize various threats to their best interests and take precautions to guard against them or to minimize their effects.

Both government and industry routinely manage a myriad of risks. For example, to maximize their return on investments, businesses must often choose between growth investment plans that are aggressive and high-risk or slow and secure. These decisions require analysis of risk relative to potential benefits, consideration of alternatives, and, finally, the implementation of what management determines to be the best course of action.

With respect to information security, risk management is the process of minimizing risks to organizational operations (e.g., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation resulting from the operation of a system. NIST SP 800-39 identifies four distinct steps for risk management. Risk management requires organizations to (i) frame risk, (ii) assess risk, (iii) respond to risk, and (iv) monitor risk.

(ii) Assessing Risk – describes how organizations analyze risk within the context of the organizational risk frame. The purpose of the risk assessment component is to identify: (i) threats to organizations operations and assets, individuals, other organizations, and the Nation; (ii) internal and external vulnerabilities of organizations; (iii) the harm (i.e., consequences/impact) to organizations that may occur given the potential for threats exploiting vulnerabilities; and (iv) the likelihood that harm will occur.

(iii) Responding to Risk – addresses how organizations respond to risk once that risk is determined based on the results of risk assessments. The purpose of the risk response component is to provide a consistent, organization-wide response to risk in accordance with the organizational risk frame by: (i) developing alternative courses of action for responding to risk; (ii) evaluating the alternative courses of action; (iii) determining appropriate courses of action consistent with organizational risk tolerance; and (iv) implementing risk responses based on selected courses of action.

(iv) Monitoring Risk – addresses how organizations monitor risk over time. The purpose of the risk monitoring component is to: (i) verify that planned risk response measures are implemented and that information security requirements derived from/traceable to organizational missions/business functions, federal legislation, directives, regulations, policies, standards, and guidelines are satisfied; (ii) determine the ongoing effectiveness of risk response measures following implementation; and (iii) identify risk-impacting changes to organizational systems and the environments in which the systems operate.

To help organizations manage information security risk at the system level, NIST developed the Risk Management Framework (RMF). The RMF promotes the concepts of near real-time risk management and ongoing system authorization through the implementation of robust continuous monitoring processes. The RMF also provides senior leaders the necessary information to make cost-effective, risk-based decisions with regard to the organizational systems supporting their core missions and business functions, and integrates information security into the enterprise architecture and system development life cycle (SDLC). See NIST SP 800-160.

The six steps that comprise the RMF include:

Figure 1 - Risk Management Framework (RMF) Overview

The first step of the RMF focuses on the categorization of the system. Here, organizations categorize the system and the information processed, stored, and transmitted by that system based on an impact analysis. Security categorization guidance for non-national security systems can be found in FIPS 199 and NIST SP 800-60.7

The second step of the RMF process involves selecting an initial set of baseline security controls for the system based on the security categorization as well as tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions. Security control selection guidance is provided in NIST SP 800-53 and in FIPS 200.

In the third step, the organization is responsible for implementing security controls and describing how the controls are employed within the system and its environment of operation. Many NIST publications provide information on security control implementations and are available for reference on the Computer Security Resource Center website.

The fourth step ensures that the organization assesses the security controls using appropriate assessment procedures and to determine 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. NIST SP 800-53A provides guidelines for the development of assessment methods and procedures to determine security control effectiveness in federal systems and for reporting assessment findings in the security assessment report.

In the fifth step, a senior manager officially authorizes a system to operate or continue to operate based on the results of a complete and thorough security control assessment. This decision is based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the system and the decision that this risk is acceptable.

The sixth step of the RMF is to continuously monitor the security controls in the system to ensure that they are effective over time as changes occur in the system and the environment in which the system operates. Organizations monitor the security controls in the system on an ongoing basis, including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials. Specific guidance on continuous monitoring can be found in NIST SP 800-137.

Information assurance is the degree of confidence one has that security measures protect and defend information and systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of systems by incorporating protection, detection, and reaction capabilities.

Assurance is not, however, an absolute guarantee that the measures will work as intended. Understanding this distinction is crucial as quantifying the security of a system can be daunting. Nevertheless, it is something individuals expect and obtain, often without realizing it. For example, an individual may routinely receive product recommendations from colleagues but may not consider such recommendations as providing assurance.

This chapter discusses planning for assurance and presents two categories of assurance methods and tools: the design and subsequent implementation of assurance and operational assurance (further categorized into audits and monitoring). The division between the two categories can be ambiguous at times as there is significant overlap. While such issues as configuration management or audits are discussed under operational assurance, they may also be vital during a system’s development. The discussion tends to focus more on technical issues during design and implementation assurance and is a mixture of management, operational, and technical issues under operational assurance.

Authorization is the official management decision to authorize the operation of a system. The authorizing official (a senior organizational executive) explicitly accepts the risk of operating the system to organizational operations (e.g., mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security and privacy controls. There is a need for a collaborative relationship between the authorizing official and the SAOP. OMB A-130 gives SAOPs review and approval of privacy plans prior to authorization, and review of authorization packages for systems with PII. Therefore, before making risk determination and acceptance decisions, the authorizing official communicates with the SAOP to address any privacy-related concerns before the final authorization decision is made. The authorization process requires managers and technical staff to work together to find practical, cost-effective solutions given security needs, technical and operational constraints, requirements of other system quality attributes such as privacy, and mission or business requirements.

To facilitate sound risk-based decision making, decisions are based on reliable and current information about the implementation and effectiveness of both technical and nontechnical safeguards. These include:

The Authorizing Official is responsible for authorizing the system before it is allowed to operate and have a plan in place for how that system will be continuously monitored.

Assurance is an integral element in making the decision to authorize a system to operate. Assurance addresses whether the technical measures and procedures are operating according to a set of security requirements and specifications as well as general quality principles.

The authorizing official makes the final decision on how much and what types of assurance are needed for a system. In order to make a sound decision, the authorizing official considers the system categorization/impact level and reviews the results of risk assessments. The authorizing official analyzes the benefits and disadvantages of the cost of assurance, cost of controls, and risks to the organization. When the authorization process is complete, it is the responsibility of the authorizing official to accept the residual risk in the system.

The authorization of another product or system to operate in a similar situation can be used to provide some assurance (e.g., reciprocity). However, it is important to realize that an authorization is specific to the environment and the system. Since authorization balances risks and advantages, the same product may be appropriately authorized for one environment but not for another, even by the same authorizing official. For instance, an authorizing official might approve the use of cloud storage for research data but not for human resource data under the purview of the same system.

The size and complexity of today’s systems make building a trustworthy system a priority. Systems security engineering provides an elementary approach for building dependable systems in today’s complex computing environment. For more information on security engineering, refer to NIST SP 800-160.

For new systems or for system upgrades, assurance requirements begin during the planning phase of the system life cycle. Planning for assurance as part of system requirements also is practical and helps authorizing officials make cost-effective decisions when building a system or when purchasing the components/equipment required to provide assurance for an older system.

Design and implementation assurance addresses a system’s design as well as whether the features of a system, application, or component meet security requirements and specifications. Design and implementation assurance examines system design, development, and installation and is usually associated with the development/acquisition and implementation phase of the system life cycle. However, it may also be considered throughout the life cycle as the system is modified.

In the development of both commercial off-the-shelf (COTS) products and customized systems, the use of advanced or trusted system architectures, development methodologies, or software engineering techniques can provide assurance. Examples include security design and development reviews, formal modeling, mathematical proofs, ISO 9000 quality techniques, ISO 15288 (a systems security engineering standard), or the use of security architecture concepts, such as a trusted computing base (TCB).

Since assurance in information technology products cannot be fully guaranteed, there are recognized evaluation processes available to establish a level of confidence that the security functionality of these IT products and the assurance measures applied to these IT products meet certain requirements. The Common Criteria (CC) allows for the comparability of results between independent evaluations. The CC is useful as a guide for the development, evaluation, and procurement of IT products with security functionality. For more information about the CC, see http://www.commoncriteriaportal.org or https://buildsecurityin.us-cert.gov/articles/best-practices/requirements-engineering/the-common-criteria.

Some system architectures are intrinsically more reliable, such as systems that use fault-tolerance, redundancy, shadowing, or redundant array of independent disks (RAID) features. These examples are primarily associated with system availability.

One factor in reliable security is the concept of ease of safe use, which postulates that a system that is easier to secure is more likely to actually be secure. Security features may be more likely utilized when the initial system defaults to the "most secure" option. In addition, a system's security may be deemed more reliable if it refrains from using new technology that has yet to be tested in the “real” world (often called “bleeding-edge” technology). Conversely, a system that uses older, well-tested software may be less likely to contain bugs.

A product evaluation normally includes testing. Evaluations can be performed by many types of organizations, including: domestic and foreign government agencies; independent organizations such as trade and professional organizations; other vendors or commercial groups; or individual users or user consortia. Product reviews in trade literature are a form of evaluation, as are more formal reviews made against specific criteria. Important factors to consider when using evaluations are the degree of independence of the evaluating group, whether the evaluation criteria reflect needed security features, the rigor of the testing, the testing environment, the age of the evaluation, the competence of the evaluating organization, and the limitations placed on the evaluations by the evaluating group (e.g., assumptions about the threat or operating environment).

The ability to describe security requirements and how they were met can reflect the degree to which a system or product designer understands applicable security issues. Without a comprehensive understanding of the requirements, it is unlikely that the designer will be able to meet them.

Assurance documentation can address the security for a system or for specific components. System-level documentation describes the system's security requirements and how they have been implemented, including interrelationships among applications, the operating system, or networks. System-level documentation addresses more than just the operating system, the security system, and applications; it describes the system as integrated and implemented in a particular environment. Component documentation will generally be an off-the-shelf product, whereas the system designer or implementer will typically develop system documentation.

Warranties are an additional source of assurance. A manufacturer, producer, system developer, or integrator that is willing to correct errors within certain time frames or by the next release, gives the system manager a sense of commitment to the product and also speaks to the product’s quality. An integrity statement is a formal declaration or certification of the product. It can be augmented by a promise to (a) fix the item (i.e., warranty) or (b) pay for losses (i.e., liability) if the product does not conform to the integrity statement.

The published assertion or formal declarations of a manufacturer or developer provide a limited amount of assurance based on reputation. When there is a contract in place, reputation alone will be insufficient given the legal liabilities imposed on the manufacturer.

It is often important to know that software has arrived unmodified, especially if it is distributed electronically. In such cases, check bits or digital signatures can provide high assurance that code has not been modified. Anti-virus software can be used to check software that comes from sources with unknown reliability (e.g., internet forum).

Design and implementation assurance addresses the quality of security features built into systems. Operational assurance addresses whether the system's technical features are being bypassed or have vulnerabilities and whether required procedures are being followed. It does not address changes in the system's security requirements, which could be caused by changes to the system and its operating or threat environment. (These changes are addressed in section 10.15).

Security tends to degrade during the operational phase of the system life cycle. System users and operators discover new ways to intentionally or unintentionally bypass or subvert security, especially if there is a perception that bypassing security improves functionality or that there will be no repercussions to them or their systems. Strict adherence to procedures is rare. Policy becomes outdated, and errors in the system's administration commonly occur.

Organizations use three basic methods to maintain operational assurance:

In general, the more "real-time" an activity is, the more it falls into the category of monitoring. This distinction can create some unnecessary linguistic hairsplitting, especially concerning system-generated audit trails. Daily or weekly reviewing of the audit trail for unauthorized access attempts is generally considered to be monitoring, while a historical review of several months' worth of the trail (e.g., tracing the actions of a specific user) is generally considered an audit. Overall, though, the specific terms applied to assurance-related activities are much less important than the real work of actually maintaining operational assurance.

Assessments can address the quality of the system as built, implemented, or operated. Assessments can be performed throughout the development cycle, after system installation, and throughout its operational phase. Assessment methods include interviews, examinations, and testing. Some common testing techniques feature functional testing (to see if a given function works according to its requirements) or penetration testing (to see if security can be bypassed). These techniques can range from trying several test cases to in-depth studies using metrics, automated tools, or multiple detailed test cases. See NIST SP 800-53A for assessment guidance.

An audit conducted to support operational assurance examines whether the system is meeting stated or implied security requirements as well as system and organization policies. Some audits also examine whether security requirements are appropriate, though this is outside of the scope of operational assurance. (See section 10.15.) Less formal audits are often called security reviews. Audits can be self-administered or independent—meaning they can be administered internally or externally. Both types can provide excellent information about technical, procedural, managerial, or other aspects of security. The essential difference between a self-audit and an independent audit is objectivity. Reviews conducted by system management staff—often called self-audits/assessments—present an inherent conflict of interest. The system management staff may have little incentive to report that the system was poorly designed or is carelessly operated. On the other hand, they may be motivated by a strong desire to improve the security of their system. In addition, they are knowledgeable about the system and may be able to find hidden problems. The independent auditor, by contrast, has no professional stake in the system. A person who performs an independent audit is organizationally independent and free from personal or external constraints that may impair their independence. An independent audit may be performed by a professional audit staff in accordance with generally accepted auditing standards.

There are numerous methods and tools that can be used to audit, some of which are described here.

Even for small multiuser systems, manually reviewing security features may require significant resources. Automated tools make it feasible to review even large systems for a variety of security flaws.

There are two types of automated tools: (1) active tools, which find vulnerabilities by trying to exploit them; and (2) passive tests, which only examine the system and infer the existence of problems from the state of the system.

Automated tools can be used to help uncover a variety of threats and vulnerabilities, such as improper access controls or access control configurations, weak passwords, lack of system software integrity, or not applying all relevant software updates and patches. These tools are often very successful at finding vulnerabilities and are sometimes used by hackers to break into systems. Utilizing these tools gives system administrators an advantage. Many of the tools are simple to use. However, some programs (e.g., access-control auditing tools for large mainframe systems) require specialized skill to use and interpret.

An auditor can review controls in place and determine whether they are effective. The auditor will often analyze both system and non-system based controls. Techniques used include inquiry, observation, and testing of both the data and the controls themselves. The audit can also detect illegal acts, errors, irregularities, or a lack of compliance with laws and regulations. System Security Plans and penetration testing, discussed below, may be used.

The system security plan provides implementation details against which the system can be audited. This plan, discussed in section 10.12, outlines the major security considerations for a system, including management, operational, and technical issues. One advantage of using a system security plan is that it reflects the unique security environment of the system, rather than a generic list of controls. Security control sets can be developed, including national or organizational security policies and practices (often referred to as baselines). The SSP is also used for historical purposes and, in such instances where a system interconnection exists, may need to be shared with other organizations.

Baselines are the starting point of the security control selection process for systems. Three security control baselines have been identified corresponding to the low-impact, moderate-impact, and high-impact systems using the high-water mark⁹ defined in FIPS 200 to provide an initial set of security controls for each impact level. Once a security control baseline is selected, organizations use the tailoring guidance in NIST SP 800-53 to remove controls from the baseline

(with a justification based on risk) or to add compensating or supplemental controls to strengthen the security posture of a specific system.

Care needs to be taken to ensure that deviations from the baseline are based on an assessment of the associated risk as the changes may be appropriate for the system's particular environment or technical constraints.

Penetration testing can use many methods to attempt a system break-in. In addition to using active automated tools as described above, penetration testing can be done "manually." The most useful type of penetration testing involves the use of methods that might be used against the system. For hosts on the Internet, this would certainly include automated tools. For many systems, lax procedures or a lack of internal controls on applications are common vulnerabilities that penetration testing can target. Another method is social engineering, which involves deceiving users or administrators into divulging information about systems, including their passwords.

Security monitoring is an ongoing activity that seeks out vulnerabilities and security problems. Many of the methods are similar to those used for audits but are done more regularly or, for some automated tools, in real time.

A periodic review or use of automated tools to analyze system-generated logs can detect security problems, including attempts to exceed access authority or gain system access during unusual hours (see section 10.15).

Several types of automated tools monitor a system for security problems. Some examples follow:

Configuration management provides assurance that the system in operation has been configured to organizational needs and standards, that any changes to be made are reviewed for security implications, and that such changes have been approved by management prior to implementation. Configuration management can be used to help ensure that changes take place in an identifiable and controlled environment and that they do not unintentionally harm any of the system's properties, including its security. Some organizations, particularly those with very large systems (e.g., the Federal Government), use a configuration control board for configuration management. When such a board exists, it is crucial for an information security expert to participate. Changes to the system can have security implications. Such changes may introduce or mitigate vulnerabilities and may require updating the contingency plan, risk analysis, or authorization. For more details on configuration management, see section 10.5.

In addition to monitoring the system, it is useful to monitor external sources for information. Such sources as trade literature, both printed and electronic, have information about security vulnerabilities, patches, and other areas that impact security. The Forum of Incident Response Teams (FIRST) has an electronic mailing list that receives information on threats, vulnerabilities, and patches. The National Vulnerability Database (NVD) is a repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security-related software flaws, misconfigurations, product names, and impact metrics. The United States Computer Emergency Readiness Team (US-CERT), a DHS component, responds to major incidents, analyzes threats, and exchanges critical cybersecurity information with trusted partners around the world. Also, Information Sharing and Analysis Centers (ISACs) communicate critical sector-specific information about physical, cyber threats, and mitigation in order to maintain sector-wide situational awareness.

Assurance is an issue for every control and safeguard discussed in this publication. One important point to reemphasize here is that assurance is not only for technical controls, but for operational controls as well. Although this chapter focused on systems assurance, it is also important to have assurance that management controls are working properly. Are user IDs and access privileges kept up to date? Has the contingency plan been tested? Can the audit trail be tampered with? Is the security program effective? Are policies understood and followed? As noted in the introduction to this chapter, the need for assurance is more widespread than individuals often realize.

Assurance is closely linked to planning for security in the system life cycle. Systems can be designed to facilitate various kinds of testing against specified security requirements. By planning for such testing early in the process, costs can be reduced. Some kinds of assurance cannot be obtained without proper planning.

There are many methods of obtaining assurance that security features work as anticipated. Since assurance methods tend to be qualitative rather than quantitative, they will need to be evaluated. Assurance can also be quite expensive, especially if extensive testing is done. It is useful to evaluate the amount of assurance received for the cost to make a best-value decision. In general, personnel costs drive up the cost of assurance. Automated tools are generally limited to addressing specific problems, but they tend to be less expensive.

System support and operations refers to all aspects involved in running a system. This includes both system administration and tasks external to the system that support its operation (e.g., maintaining documentation). It does not include system planning or design. The support and operation of any system—from a three-person local area network to a worldwide application serving thousands of users—is critical to maintaining the security of a system. Support and operations are routine activities that enable systems to function correctly. These include fixing software or hardware problems, installing and maintaining software, and helping users resolve problems.

The failure to consider security as part of the support and operations of systems, can be detrimental to the organization. Information security system literature includes examples of how organizations undermined their often-expensive security measures with poor documentation, old user accounts, conflicting software, or poor control of maintenance accounts. An organization’s policies and procedures often fail to address many of these important issues. Some major categories include:

Even though the goals of system support and operation and information security are closely related, there is a distinction between the two. The primary goal of system support and operations is the continued and correct operation of the system, whereas the information security goals of a system include confidentiality, availability, and integrity.

This chapter addresses the support and operations activities directly related to security. Every control discussed in this publication relies, in one way or another, on system support and operations. However, this chapter focuses on areas not covered in other chapters. For example, operations personnel normally create user accounts on the system. This topic is covered in section 10.7. Similarly, the input from support and operations staff to the security awareness and training program is covered in section 10.2.

In many organizations, user support takes place through a service desk. Service desks can support an entire organization, a subunit, a specific system, or a combination of these. For smaller systems, the system administrator typically provides direct user support. Experienced users provide informal user support on most systems. It is not unusual for user support to be closely linked to the organization’s ability to handle incident response.

An important security consideration for user support personnel is being able to recognize which problems (brought to their attention by users) are security-related. For example, users’ inability to log on to a system may result from the disabling of their accounts due to too many failed access attempts. This could indicate the presence of malicious users trying to guess a user’s password.

In general, system support and operations staff need to be able to identify security problems, respond accordingly, and inform appropriate individuals. A wide range of possible security problems may exist; some will be internal to custom applications, while others apply to off-the-shelf products. Additionally, problems can be software- or hardware-based.

The more responsive and knowledgeable system support and operation staff personnel are, the less user support will be provided informally. The support other users provide can be valuable, but they may not be aware of all the issues across the organization or how they are related.

Software is the heart of an organization's system operations, whatever the size and complexity of the system. Therefore, it is essential that software function correctly and be protected from corruption. There are many elements of software support.

The first element is controlling what software is used on a system. If users or systems personnel can install and execute any software on a system, the system is more vulnerable to viruses, unexpected software interactions, and software that may subvert or bypass security controls. One method of controlling software is to inspect or test software before it is installed (e.g., determine compatibility with custom applications, identify other unforeseen interactions). This can apply to new software packages, upgrades, off-the-shelf products, or to custom software, as deemed appropriate. In addition to controlling the installation and execution of new software, organizations also oversee the configuration and use of powerful system utilities. System utilities can compromise the integrity of operating systems and logical access controls.

The second element in software support can be to ensure that software has not been modified without proper authorization. This involves the protection of software and backup copies and can be done with a combination of logical and physical access controls.

Many organizations also include a program to ensure that software is properly licensed, as required. For example, an organization may audit systems for illegal copies of copyrighted software. This problem is primarily associated with user systems (or devices), but can apply to any type of system.

Closely related to software support is configuration management—the process of tracking and approving changes to the system. Configuration management can be formal or informal and normally addresses hardware, software, networking, and other changes. The primary security goal of configuration management is to ensure that changes to the system do not unintentionally or unknowingly diminish security. Some of the methods discussed under software support (e.g., such as inspecting and testing software changes) can be used. Chapter 7 discusses other methods.

Note that the security goal is to know what changes occur, not to prevent security from being changed. There may be circumstances under which reducing security is deemed an acceptable risk due to the need to accomplish the mission. In such cases, the decrease in security is based on a decision by the authorizing official who considered all appropriate factors. Furthermore, the resulting increase in risk is monitored on an ongoing basis.

A second security goal of configuration management is to ensure that changes to the system are reflected in other documentation, such as the contingency plan. If the change is major, it may be necessary to reanalyze some or all of the security of the system. This is discussed in section 10.15.

Support and operations personnel and sometimes users back up software and data. This function is critical to contingency planning. The frequency of backups depends on how often data changes and how important those changes are. Consult with system administrators to determine what backup schedule is appropriate. Also, it is important to test that backup copies are actually usable. Finally, store backups securely (discussed below).

Media controls include a variety of measures to provide physical and environmental protection and accountability for digital and non-digital media. Examples of digital media include diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Examples of non-digital media include paper and microfilm. From a security perspective, media controls are designed to prevent the loss of confidentiality, integrity, or availability of information, including data or software, when stored or disseminated outside of the system. This can include storage of information before it is input into the system and after it is output.

The extent of media control depends on many factors, including the type of data, the quantity of media, and the nature of the user environment. Physical and environmental protection is used to prevent unauthorized individuals from accessing the media and protects against such factors as heat, cold, or harmful magnetic fields. When necessary, logging the use of individual media (e.g., a tape cartridge) provides detailed accountability—so that the organizations may hold authorized individuals responsible for their actions. For more information on media protection, see section 10.10.

Documentation of all aspects of system support and operations is important to ensure continuity and consistency. Formalizing operational practices and procedures with sufficient detail helps to eliminate security lapses and oversights, gives new personnel sufficiently detailed instructions, and provides a quality assurance function to help ensure that operations are performed correctly and efficiently.

The specific security implementation details of a system are also documented. This includes many types of documentation, such as security plans, contingency plans, risk analyses, and security policies and procedures. Much of this information, particularly risk and threat analyses, has to be protected against unauthorized disclosure. Security documentation also needs to be both current and accessible. Accessibility takes special factors into consideration such as the need to find the contingency plan during a disaster.

Some security documentation may need to be designed to fulfill the needs of different system roles. For this reason, many organizations separate documentation into policy and procedures. A security procedures manual may be written to inform system users on how to do their jobs securely. For systems operations and support staff, a security procedures manual may address a wide variety of technical and operational concerns in considerable detail.

System maintenance requires either physical or logical access to the system. Support and operations staff, hardware or software vendors, or third-party service providers may maintain a system. Maintenance may be performed on-site or remotely via communications connections. It may also be necessary to move equipment to a repair site for maintenance. If someone who does not typically have access to the system performs maintenance, then a security vulnerability is introduced.

In some circumstances, it may be necessary to take additional precautions (e.g., background investigation of service personnel) to prevent some problems such as "snooping around" the physical area. However, once someone has access to the system, it is very difficult for supervision to prevent damage done through the maintenance process.

Many systems provide maintenance accounts. These special login accounts are normally preconfigured at the factory with pre-set, widely-known passwords. It is critical to change these passwords or otherwise limit access to the accounts. Develop procedures to ensure that only authorized maintenance personnel have access to the preconfigured accounts. If the account is to be used remotely, authentication of the maintenance provider can be performed using call-back confirmation. This helps ensure that remote diagnostic activities actually originate from an established phone number at the vendor's site. Other helpful techniques include encryption and decryption of diagnostic communications, strong identification and authentication techniques such as tokens, and remote disconnect verification.

Manufacturers of larger systems and third-party providers may offer more diagnostic and support services, and larger systems may have diagnostic ports. It is critical to ensure that these ports are only used by authorized personnel, cannot be accessed by malicious users, and are only active when required.

There are support and operations components in most of the controls discussed in this publication, such as:

The cost of ensuring adequate security in day-to-day support and operations is largely dependent upon the size and characteristics of the operating environment and the nature of the processing being performed. It may not be necessary to hire additional support and operations security specialists. If sufficient support personnel are already available, it is important that they be trained in the security aspects of their assigned jobs. Initial and ongoing training is a cost of successfully incorporating security measures into support and operations activities.

Another cost is that associated with creating and updating documentation to ensure that security concerns are appropriately reflected in support and operations policies, procedures, and duties.

Cryptography is a branch of mathematics based on the transformation of data. It is an important tool for protecting information and is used in many aspects of information security. For example, cryptography can help provide data confidentiality and integrity. These security objectives can be accomplished using various cryptographic algorithms such as electronic signatures, and advanced user authentication. Although modern cryptography relies upon advanced mathematics, users can reap its benefits without understanding its mathematical underpinnings.

NIST has published an array of Special Publications (SPs) and Federal Information Processing Standards (FIPS) that are applicable to the use of cryptography within the Federal Government. A list of such SPs and FIPS can be found in Appendix A of NIST SP 800-175B, Guideline for Using Crypto Standards: Cryptographic Mechanisms. Public Laws, Presidential Executive Orders and Directives, and other guidance from organizations in the Executive Office of the President drive the SPs and FIPS written by NIST. Legislative mandates, policies, and directives specific to cryptography are introduced in NIST SP 800-175A, Guideline for Using Crypto Standards: Directives, Mandates, and Policies.

Cryptography alone will not satisfy the information assurance needs of any organization. Rather, when combined with other security measures, cryptography is a useful tool for satisfying a wide spectrum of information security needs and requirements. This chapter describes fundamental aspects of the basic cryptographic technologies and some specific ways cryptography can be applied to improve security. The chapter also explores some of the important issues to be considered when incorporating cryptography into systems.

Cryptography is used to protect data both inside and outside the boundaries of a system. Data within a system may be sufficiently protected with logical and physical access controls (perhaps supplemented by cryptography). However, outside of the system, cryptography is sometimes the only way to protect data. For instance, data cannot be protected by the originator’s logical or physical access controls when in transit across communications lines or resident on another system. Cryptography provides a solution by protecting data even when the data is no longer in the control of the originator.

One of the best ways to obtain cost-effective data confidentiality is through the use of encryption. Encryption transforms intelligible data, called plaintext, into an unintelligible form, called ciphertext. This is reversed through the process of decryption. One way to protect electronic data is by using the advanced encryption standard (AES). The AES algorithm is a cryptographic algorithm that can be used to encrypt and decrypt information. Once data is encrypted, the ciphertext does not have to be protected against disclosure. However, if ciphertext is modified, it will not decrypt correctly. A more comprehensive explanation of AES can be found in FIPS 197, Advanced Encryption Standard (AES).

Both secret and public key cryptography can be used for data encryption although not all public key algorithms provide for data encryption. To use a secret key algorithm, data is encrypted using a specific key. The same key must be used to decrypt the data. When public key cryptography is used for encryption, any party may use any other party's public key to encrypt a message. However, only the party with the corresponding private key can decrypt, and thus read, the message. There are several reasons to choose one form of cryptography over the other. For example, an organization may decide to go with public key cryptography because it is more secure and convenient to use since private keys do not have to be transmitted to anyone. In order for secret-key cryptography to function, the secret keys must be transmitted due to the fact that the same key is used for the encryption and decryption of that specific data. More detailed guidance on public key infrastructure (PKI) is available in NIST SP 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, NIST SP 800-57 Part 3, Recommendation for Key Management: Part 3 – Application Specific Key Management Guidance, and NIST SP 800-152, A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS).

Integrity is a property whereby data has not been altered in an unauthorized manner since it was created, transmitted, or stored. In systems, it is not always possible for humans to scan information to determine if data has been erased, added, or modified. Even if scanning were possible, the individual may have no way of knowing what the correct data is supposed to be. For example, "do" may be changed to "do not," or $1,000 may be changed to $10,000. It is therefore desirable to have an automated means of detecting both intentional and unintentional modifications of data.

While error detection codes (e.g., parity bits) have long been used in communications protocols, to detect unintentional modifications, an attacker intercepting and modifying the message can also replace the message’s error detection code. Cryptography can effectively detect both intentional and unintentional modification.

Today's systems store and process documents in electronic form. Having documents in electronic form permits rapid processing and transmission and improves overall efficiency. The approval of a paper document has traditionally been indicated by a written signature. What is needed, therefore, is the electronic equivalent of a written signature that can be recognized as having the same legal status as a written signature. In addition to the integrity protections discussed above, cryptography can provide a means of linking a document with a particular person, as is done with a written signature. Electronic signatures can use either secret key or public key cryptography. However, public key methods are generally easier to use.

Simply taking a digital picture of a written signature does not provide adequate security. Such a digitized written signature could easily be copied from one electronic document to another with no way to determine whether it is legitimate. Electronic signatures, on the other hand, can be validated uniquely for one message and only for that message. For example, a cryptographic hash function¹⁰, like SHA-3, can be used to increase the security and efficiency of a digital signature providing assurance that the original message could not have been altered to a different message with the same hash value, and hence, the same signature. To learn more about cryptographic hash functions, specifically SHA-3, see FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions.

An electronic signature can be implemented using secret key message authentication codes, or MACs. For example, if two parties share a secret key, and one party receives data with a MAC that is correctly verified using the shared key, that party may assume that the other party signed the data. This also assumes that the two parties trust each other. Through the use of a MAC, data integrity and a form of electronic signature are obtained. Using additional controls, such as key notarization¹¹ and key attributes¹², it is possible to provide an electronic signature even if the two parties do not trust each other.

Another type of electronic signature is called a digital signature and is implemented using public key cryptography. Data is electronically signed by applying the originator's private key to the data. (The exact mathematical process for doing this is not important for this discussion.) To increase the speed of the process, the private key is applied to a shorter form of the data, called a "hash" or "message digest," rather than to the entire set of data. The resulting digital signature can be stored or transmitted along with the data. The signature can be verified by any party using the public key of the signer. This feature is very useful, for example, when distributing signed copies of virus-free software. Any recipient can verify that the program remains virus-free. If the signature verifies properly, then the verifier has confidence that the data was not modified after being signed and that the owner of the public key was the signer. NIST has published standards for a digital signature and a secure hash for use by the federal government in FIPS 186-4, Digital Signature Standard and FIPS 180-4, Secure Hash Standard.

Authentication is a process that provides assurance of the source of information to a receiving entity. Cryptography can increase security in user authentication techniques. As discussed in section 10.7, cryptography is the basis for several advanced authentication methods. Instead of communicating passwords over an open network, authentication can be performed by demonstrating knowledge of a cryptographic key. Using these methods, a one-time password, which is not susceptible to eavesdropping, can be used. User authentication can use either secret or public key cryptography.

This section explores several important issues to consider when using (e.g., designing, implementing, integrating) cryptography in a system. NIST has developed several FIPS and SPs that apply to the implementation of cryptography in federal information and federal systems. A list of these FIPS and SPs is located in Appendix A of NIST SP 800-175B.

NIST and other organizations have developed numerous standards for designing, implementing, and using cryptography and for integrating it into automated systems. By using these standards, organizations can reduce costs and protect their investments in technology. Standards provide solutions that have been accepted by a wide community and reviewed by experts in relevant areas. Standards help ensure interoperability among different vendors' equipment, thus allowing an organization to select from various products in order to find cost-effective solutions.

Managers and users of systems choose the appropriate cryptographic standard based on a cost-effectiveness analysis, trends in the standard's acceptance, and interoperability requirements. In addition, each standard is carefully analyzed to determine if it is applicable to the organization and the desired application.

The trade-offs among security, cost, simplicity, efficiency, and ease of implementation need to be studied by managers acquiring various security products meeting a standard. Cryptography can be implemented in software, hardware, or firmware. Each has its related costs and benefits.

In general, software is less expensive and slower than hardware, although for large applications, hardware may be less expensive. In addition, software may be less secure, since it is more easily modified or bypassed than equivalent hardware products. Tamper resistance in hardware is usually considered more reliable.

In many cases, cryptography is implemented in a hardware device (e.g., electronic chip, ROM-protected processor), but is controlled by software. This software requires integrity protection to ensure that the hardware device is provided with correct information (e.g., controls, data) and is not bypassed. Thus, a hybrid solution is generally provided, even when the basic cryptography is implemented in hardware. Effective security requires correct management of the entire hybrid solution.

Firmware can be found in nearly every piece of technology used today, including cell phones, smart TVs, and even in USB keyboards. Thus, securing firmware implementations is critical. One way to protect your system is by purchasing hardware with built-in protection that prevents malicious firmware modification. For more information on hardening firmware, refer to NIST SP 800-147, BIOS Protection Guidelines, and NIST SP 800-155 (DRAFT), BIOS Integrity Measurement Guidelines.

The security of information protected by cryptography directly depends upon the protection afforded to keys. All keys need to be protected against modification, and secret and private keys require protection against unauthorized disclosure. Key management involves the procedures and protocols, both manual and automated, used throughout the entire life cycle of the keys. This includes the generation, distribution, storage, entry, use, destruction, and archiving of cryptographic keys.

In a small community of users, public keys and their "owners" can be strongly bound by simply exchanging public keys (e.g., putting them on a CD-ROM or other media). However, conducting electronic business on a larger scale—potentially involving geographically and organizationally distributed users—necessitates a means for obtaining public keys electronically with a high degree of confidence in their integrity and binding to individuals. The support for the binding between a key and its owner is generally referred to as a public key infrastructure.

Users also need the ability to enter the community of key holders, generate keys (or have them generated on their behalf), disseminate public keys, revoke keys (for example, in case of compromise of the private key), and change keys. In addition, it may be necessary to incorporate time/date stamping and to archive keys for verification of old signatures.

For more information on key management, see NIST SP 800-57 Part 1, Recommendation for Key Management, part 1: General, NIST SP 800-57 Part 2, Recommendation for Key Management, Part 2: Best Practices for Key Management Organization, and NIST SP 800-57 Part 3.

Cryptography is typically implemented in a module of software, firmware, hardware, or some combination thereof. This module contains the cryptographic algorithm(s), certain control parameters, and temporary storage facilities for the key(s) being used by the algorithm(s). The proper functioning of cryptography requires the secure design, implementation, and use of the cryptographic module. This includes protecting the module against tampering.

Conformance to standards can be important for many reasons, including interoperability or strength of security provided. NIST established the Cryptographic Module Validation Program (CMVP) which validates cryptographic modules to FIPS 140-2, Security Requirements for Cryptographic Modules. The goal of the CMVP is to promote the use of validated cryptographic modules and provide federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules. A list of modules that have been validated by NIST is available on the Computer Security Resource Center (CSRC) website.

原本PDFの抜粋画像

FIPS 140-2 specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The standard defines four security levels for cryptographic modules, with each level providing a significant increase in security over the preceding level. The four levels allow for cost-effective solutions that are appropriate for varying degrees of data sensitivity and different application environments. The user can select the best module for any given application or system, avoiding the cost of unnecessary security features.

The use of cryptography within networking applications often requires special considerations. In these applications, the suitability of a cryptographic module may depend on its capability for handling special requirements imposed by locally attached communications equipment or by the network protocols and software.

Encrypted information, MACs, or digital signatures may require transparent communications protocols or equipment to avoid being misinterpreted by the communications equipment or software as control information. It may be necessary to format the encrypted information, MAC, or digital signature to ensure that it does not confuse the communications equipment or software. It is essential that cryptography satisfy the requirements imposed by the communications equipment and does not interfere with the proper and efficient operation of the network.

Data is encrypted on a network using either link encryption or end-to-end encryption. In general, link encryption is performed by service providers, such as a data communications provider. Link encryption encrypts all of the data along a communications path (e.g., a satellite link, telephone circuit, T3 line). Since link encryption also encrypts routing data, communications nodes need to decrypt the data to continue routing. In end-to-end encryption, data is encrypted when being passed through a network, but routing information remains visible. End-to-end encryption is generally performed by the end user organization. Some examples of modern usage of end-to-end encryption include Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extensions (S/MIME) for email. It is possible to combine both types of encryption.

The U.S. Government controls the export of cryptographic implementations. The rules governing export can be quite complex since they consider multiple factors. Additionally, cryptography is a rapidly evolving field, and rules may change from time to time. Address questions concerning the export of cryptographic implementations to the appropriate legal counsel.

There are many interdependencies among cryptography and other security controls highlighted in this publication. Cryptography both depends on other security safeguards and assists in providing them. For example:

Cryptographic systems are monitored and periodically audited to ensure that they are still satisfying their security objectives. All parameters associated with correct operation of the cryptographic system are reviewed; operation of the system itself is periodically tested; and the results are audited. Certain information, such as secret keys or private keys in public key systems, are not subject to audit. However, non-secret or non-private keys could be used in a simulated audit procedure.

Using cryptography to protect information has both direct and indirect costs, which are determined in part by product availability. A wide variety of products exist for implementing cryptography in integrated circuits, add-on boards or adapters, and stand-alone units.

The direct costs of cryptography include:

The indirect costs of cryptography include:

To ensure the protection of confidentiality, integrity, and availability, FIPS 200 specifies minimum security requirements in multiple security-related areas. The areas which are introduced below, represent a broad-based, balanced information security program that addresses the management, operational, and technical aspects of protecting federal information and systems.

The intent of this section is to provide a brief description of each security control family. Each family has a list of controls that address a specific security goal. To view the complete security control catalog and a description of all controls, refer to NIST SP 800-53.

The requirements for using—and prohibitions against the use of—various system resources vary considerably from one system to another. For example, some information must be accessible to all users, some may be needed by several groups or departments, and some may be accessed by only a few individuals. While users must have access to specific information needed to perform their jobs, denial of access to non-job-related information may be required. It may also be important to control the kind of access that is permitted (e.g., the ability for the average user to execute, but not change, system programs). These types of access restrictions enforce policy and help ensure that unauthorized actions are not taken.

Access is the ability to make use of any system resource. Access control is the process of granting or denying specific requests to: 1) obtain and use information and related information processing services; and 2) enter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances). System-based access controls are called logical access controls. Logical access controls can prescribe not only who or what (in the case of a process) is to have access to a specific system resource, but also the type of access that is permitted. These controls may be built into the operating system, incorporated into applications programs or major utilities (e.g., database management systems, communications systems), or implemented through add-on security packages. Logical access controls may be implemented internally to the system being protected or in external devices.

Examples of access control security controls include: account management, separation of duties, least privilege, session lock, information flow enforcement, and session termination.

Organizations limit: (i) system access to authorized users; (ii) processes acting on behalf of authorized users; (iii) devices, including other systems; and (iv) the types of transactions and functions that authorized users are permitted to exercise.

Often, it is the user community that is recognized as being the weakest link in securing systems. This is due to users not being aware of how their actions may impact the security of a system. Making system users aware of their security responsibilities and teaching them correct practices helps change their behavior. It also supports individual accountability, which is one of the most important ways to improve information security. Without knowing the necessary security measures or how to use them, users cannot be truly accountable for their actions. The importance of this training is emphasized in the Computer Security Act, which requires training for those involved with the management, use, and operation of federal systems.

The purpose of information security awareness, training, and education is to enhance security by: (i) raising awareness of the need to protect system resources; (ii) developing skills and knowledge so system users can perform their jobs more securely; and (iii) building in-depth knowledge as needed to design, implement, or operate security programs for organizations and systems. The organization is responsible for making sure that managers and users are aware of the security risks associated with their activities and that organizational personnel are adequately trained to carry out their information security-related duties and responsibilities.

Examples of awareness and training security controls include: security awareness training, role-based security training, and security training records.

Organizations: (i) ensure that managers and users of organizational systems are made aware of the security risks associated with their activities and of the applicable laws, executive orders, directives, policies, standards, instructions, regulations, or procedures related to the security of organizational systems; and (ii) ensure that organizational personnel are adequately trained to carry out their assigned information security-related duties and responsibilities.

An audit is an independent review and examination of records and activities to assess the adequacy of system controls and ensure compliance with established policies and operational procedures. An audit trail is a record of individuals who have accessed a system as well as what operations the user has performed during a given period. Audit trails maintain a record of system activity both by system and application processes and by user activity of systems and applications. In conjunction with appropriate tools and procedures, audit trails can assist in detecting security violations, performance issues, and flaws in applications.

Audit trails may be used as a support for regular system operations, a kind of insurance policy, or both. As insurance, audit trails are maintained but not used unless needed (e.g., after a system outage). As a support for operations, audit trails are used to help system administrators ensure that the system or resources have not been harmed by hackers, insiders, or technical problems.

Examples of audit and accountability controls include: audit events, time stamps, non-repudiation, protection of audit information, audit record retention, and session audit.

Organizations: (i) create, protect, and retain system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate system activity; and (ii) ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable.

A security control assessment is the testing and/or evaluation of the management, operational, and technical security controls on a system to determine 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. The assessment also helps determine if the implemented controls are the most effective and cost-efficient solution for the function they are intended to serve. Assessment of the security controls is done on a continuous basis to support a near real-time analysis of the organization’s current security posture.

Following a complete and thorough security control assessment, the authorizing official makes the decision to authorize the system to operate (for a new system) or to continue to operate.

Examples of security assessment and authorization controls include: security assessments, system interconnections, plans of action and milestones, and continuous monitoring.

Organizations: (i) periodically assess the security controls in organizational systems to determine if the controls are effective in their application; (ii) develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems; (iii) authorize the operation of organizational systems and any associated system connections; and (iv) monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.

Configuration management is a collection of activities focused on establishing and maintaining the integrity of information technology products and systems through the control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the SDLC. Configuration management consists of determining and documenting the appropriate specific settings for a system, conducting security impact analyses, and managing changes through a change control board. It allows the entire system to be reviewed to help ensure that a change made on one system does not have adverse effects on another system. For more information on configuration management, see NIST SP 800-128.

Common secure configurations (also known as security configuration checklists) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for information technology platforms and products. Once implemented, checklists can be used to verify that changes to the system have been reviewed from a security point-of-view. A common audit examines the system's configuration to see if major changes (such as connecting to the Internet) have occurred that have not yet been analyzed. The NIST checklist repository, maintained as part of the National Vulnerability Database (NVD), provides multiple checklists which can be used to check compliance with the secure configuration specified in the system security plan. The checklists can be accessed at https://web.nvd.nist.gov/view/ncp/repository.

Examples of configuration management controls include: baseline configuration, configuration change control, security impact analysis, least functionality, and software usage restrictions.

Organizations: (i) establish and maintain baseline configurations and inventories of organizational systems, including hardware, software, firmware, and documentation throughout the respective SDLC; and (ii) establish and enforce security configuration settings for information technology products employed in organizational systems.

An information security contingency is an event with the potential to disrupt system operations, thereby disrupting critical mission and business functions. Such an event could be a power outage, hardware failure, fire, or storm. Particularly destructive events are often referred to as “disasters.” To avert potential contingencies and disasters or minimize the damage they cause, organizations can take early steps to control the outcome of the event. Generally, this activity is called contingency planning.

A contingency plan is a management policy and procedure used to guide organizational response to a perceived loss of mission capability. The System Contingency Plan (SCP) is used by risk managers to determine what happened, why, and what to do. The SCP may point to the Continuity of Operations Plan (COOP) or Disaster Recovery Plan (DRP) for major disruptions. Contingency planning involves more than planning for a move offsite after a disaster destroys a data center. It also addresses how to keep an organization's critical functions operational in the event of disruptions, both large and small. This broader perspective on contingency planning is based on the distribution of system support throughout an organization. For more information on contingency planning, see NIST SP 800-34.

Examples of contingency planning controls include: contingency plan, contingency training, contingency plan testing, system backup, and system recovery and reconstitution.

Organizations: (i) establish, maintain, and effectively implement plans for emergency response, (ii) backup operations, and (iii) oversee post-disaster recovery for organizational systems to ensure the availability of critical information resources and the continuity of operations in emergency situations.

For most systems, identification and authentication is often the first line of defense. Identification is the means of verifying the identity of a user, process, or device, typically as a prerequisite for granting access to resources in a system. Identification and authentication is a technical measure that prevents unauthorized individuals or processes from entering a system.

Identification and authentication is a critical building block of information security since it is the basis for most types of access control and for establishing user accountability. Access control often requires that the system be able to identify and differentiate between users. For example, access control is often based on least privilege, which refers to granting users only those accesses required to perform their duties. User accountability requires linking activities on a system to specific individuals and, therefore, requires the system to identify users.

Systems recognize individuals based on the authentication data the systems receive. Authentication presents several challenges: collecting authentication data, transmitting the data securely, and knowing whether the individual who was originally authenticated is still the individual using the system. For example, a user may walk away from a terminal while still logged on, and another person may start using it.

There are four means of authenticating a user's identity that can be used alone or in combination. User identity can be authenticated based on:

While it may appear that any of these individual methods could provide strong authentication, there are problems associated with each. If an individual wanted to impersonate someone else on a system, they can guess or learn another user’s password or steal or fabricate tokens. Each method also has drawbacks for legitimate users and system administrators: users forget passwords and may lose tokens, and administrative overhead for keeping track of identification and authorization data and tokens can be substantial. Biometric systems have significant technical, user acceptance, and cost problems as well.

Examples of identification and authentication controls include: device identification and authentication, identifier management, authenticator management, authenticator feedback, and re-authentication.

Organizations: (i) identify system users, processes acting on behalf of users, or devices and (ii) authenticate or verify the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational systems.

Engagement with individuals whose information is being processed by a system is an important aspect of privacy protection and the development of trustworthy systems. System functioning can have significant impacts on people’s quality of life and their ability to be autonomous individuals. Effective engagement can help to mitigate these risks and prevent a range of problems. For example, individuals may feel surveilled by a system, which may create chilling effects on ordinary behavior or cause them to alter their interactions with the system in unexpected ways. They may feel information has been appropriated – or used for profit or organizational gain without their permission or sufficient economic benefit. Excluding access to information can affect data quality that could lead to adverse decision-making about users, including inappropriate restrictions on access to products or services or other types of discrimination. The Individual Participation controls address user interaction with the system to enable them to develop reliable assumptions about how the system is processing information about them. In addition, these controls create touch points so that users can better engage with the system and the management of their information. Users who have the ability to participate in decisions about their information processing may be more likely to have trust in the system and engage with it in constructive ways. Furthermore, enabling users to correct inaccurate information can improve system functioning, and protect these users from experiencing problems arising from system actions based on the processing of inaccurate information. With Individual Participation controls, organizations keep individuals notified about the processing of their PII. These controls also, when appropriate, engage individuals as active participants in the decision-making process regarding their PII through information access and consent options, and provide them the ability to have their PII corrected or amended through appropriate redress mechanisms. Examples of individual participation controls include: consent, redress, privacy notice, privacy act statements for federal agencies, and individual access. Organizations: (i) request consent for processing PII; (ii) provide access to PII and redress opportunities for individual to amend or correct PII; and (iii) provide notice to individuals regarding the processing of PII.

Systems are subject to a wide range of threat events, from corrupted data files to viruses to natural disasters. Vulnerability to some threat events can be mitigated by having relevant standard operating procedures that can be followed in the event of an incident. For example, frequently occurring events like mistakenly deleting a file can usually be repaired through restoration from the backup file. More severe threat events, such as outages caused by natural disasters, are normally addressed in an organization's contingency plan. Threat events can also result from a virus, other malicious code, or a system intruder (either an insider or an outsider). They can more generally refer to those incidents that could result in severe damage without a technical expert response. An example of a threat event that would require an immediate technical response would be an organization experiencing a denial-of-service attack. This kind of attack would require swift action on the part of the incident response team in order to reduce the affect the attack will have on the organization. The definition of a threat event is somewhat flexible and may vary by organization and computing environment. Although the threats that hackers and malicious code pose to systems and networks are well known, the occurrence of such harmful events remains unpredictable. Security incidents on larger networks (e.g., the Internet), such as break-ins and service disruptions, have harmed various organizations' computing capabilities. When initially confronted with such incidents, most organizations respond in an ad hoc manner. However, recurrence of similar incidents can make it cost-beneficial to develop a standard capability for quick discovery of and response to such events. This is especially true since incidents can often "spread" when left unchecked, thus escalating the damage and seriously harming an organization. Incident handling is closely related to contingency planning. An incident handling capability may be viewed as a component of contingency planning because it allows for the ability to react quickly and efficiently to disruptions in normal processing. Broadly speaking, contingency planning addresses events with the potential to interrupt system operations. Incident handling can be considered that portion of contingency planning specifically that responds to malicious technical threats. For more information on incident response, see NIST SP 800-61, Computer Security Incident Handling Guide. Examples of incident response controls include: incident response training, incident response testing, incident handling, incident monitoring, and incident reporting. Organizations: (i) establish an operational incident handling capability for organizational systems that includes adequate preparation, detection, analysis, containment, recovery, and user response activities; and (ii) track, document, and report incidents to appropriate organizational officials and/or authorities.

To keep systems in good working order and to minimize risks from hardware and software failures, it is paramount that organizations establish procedures for the maintenance of organizational systems. There are many different ways an organization can address these maintenance requirements. Controlled maintenance of a system deals with maintenance that is scheduled and performed in accordance with the manufacturer’s specifications. Maintenance performed outside of a scheduled cycle, known as corrective maintenance, occurs when a system fails or generates an error condition that must be corrected in order to return the system to operational conditions. Maintenance can be performed locally or non-locally. Nonlocal maintenance is any maintenance or diagnostics performed by individuals communicating through a network either internally or externally (e.g., the Internet). Examples of maintenance controls include: controlled maintenance, maintenance tools, nonlocal maintenance, maintenance personnel, and timely maintenance. Organizations: (i) perform periodic and timely maintenance on organizational systems; and (ii) provide effective controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.

Media protection is a control that addresses the defense of system media, which can be described as both digital and non-digital. Examples of digital media include: diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Examples of non-digital media include paper or microfilm. Media protections can restrict access and make media available to authorized personnel only, apply security labels to sensitive information, and provide instructions on how to remove information from media such that the information cannot be retrieved or reconstructed. Media protections also include physically controlling system media and ensuring accountability, as well as restricting mobile devices capable of storing and carrying information into or outside of restricted areas. Examples of media protection controls include: media access, media marking, media storage, media transport, and media sanitization. Organizations: (i) protect system media, both paper and digital; (ii) limit access to information on system media to authorized users; and (iii) sanitize or destroy system media before disposal or release for reuse.

To better protect individuals’ privacy and limit problems arising from system processing of their information, organizations should have a clear rationale for the collection, use, maintenance, and sharing of personally identifiable information (PII). Overly broad collection and maintenance of information may create the potential for security vulnerabilities or allow for internal abuses or expanded uses that cross privacy boundaries. Individuals could be stigmatized by the release of their information or suffer from identity theft. Third parties with whom information is shared may disregard the purpose or context in which information is collected and use that information in a manner that contradicts individuals’ privacy interests. As a result, individuals could lose trust in these systems, which could lead to abandonment or threaten the adoption of new technologies, even those designed to improve access to public services. Organizations may have to comply with external laws or regulations, as well as internal policies pertaining to the processing of PII. Privacy Authorization controls aid an organization in ensuring that it is only processing PII in ways that it has the authority for and clear purposes for doing so. This assurance facilitates an organization’s accountability for following relevant policies, and minimizes potential noncompliance costs and reputational damage. Documenting this information also supports individuals’ understanding of a system’s processing of their PII. Examples of privacy authorization controls include: authority to collect, purpose specification, and information sharing with external parties. Organizations: (i) identify the legal bases that authorize particular personally identifiable information (PII) collection use, maintenance, and sharing; (ii) specify in their notices the purpose(s) for which PII is collected; and (iii) manage the sharing of PII with external parties.

The term physical and environmental security refers to measures taken to protect systems, buildings, and related supporting infrastructure against threats associated with their physical environment. Physical and environmental controls cover three broad areas:

Examples of physical and environmental controls include: physical access authorizations, physical access control, monitoring physical access, emergency shutoff, emergency power, emergency lighting, alternate work site, information leakage, and asset monitoring and tracking. Organizations: (i) limit physical access to systems, equipment, and the respective operating environments to authorized individuals; (ii) protect the physical plant and support infrastructure for systems; (iii) provide supporting utilities for systems; (iv) protect systems against environmental hazards; and (v) provide appropriate environmental controls in facilities containing systems.

Systems have increasingly taken on a strategic role in the organization. They assist organizations in conducting their daily activities and support decision making. With proper planning, systems can provide a security level commensurate with the risk associated with the operation of the system, improve productivity and performance, and enable new ways of managing and organizing. Planning for systems is crucial in the development and implementation of the organization’s information security goals. System security plans (SSPs)¹³ are developed to provide an overview of the security requirements of the system and how the security controls and control enhancements meet those security requirements. Having security controls in place alone does not guarantee the overall protection of a system. Organizations also need to develop, document, and disseminate how these controls are implemented, rules that describe the responsibility of users, and how the organization operates the system from the perspective of information security. Examples of planning controls include: system security plan, rules of behavior, security concept of operations, information security architecture, and central management. Organizations: develop, document, periodically update, and implement security plans for organizational systems that describe the security controls in place or planned for the system, as well as the rules of behavior for individuals accessing the systems.

Systems and the information they process are critical to many organizations' ability to perform their missions and business functions. It makes sense that executives view system security as a management issue and seek to protect their organization's information technology resources as they would any other valuable asset. To do this effectively requires the development of a comprehensive management approach. Many security programs, distributed throughout the organization, have different elements performing various functions. While this approach has benefits, the distribution of the system security functions in many organizations is haphazard, usually based upon history (i.e., who was available in the organization to do what when the need arose). Ideally, the distribution of system security functions is the result of a planned and integrated management philosophy. Managing system security at multiple levels has its benefits. Each level contributes to the overall system security program with different types of expertise, authority, and resources. In general, higher-level officials (e.g., those at the headquarters, unit levels in the agency described above) better understand the organization as a whole and have more authority. On the other hand, lower-level officials (e.g., at the system facility and applications levels) are more familiar with the specific technical and procedural requirements and problems of the systems and users. The levels of system security program management are complementary; each can help the other be more effective. Examples of program management controls include: information security program plan, information security resources, plan of action and milestone process, system inventory, enterprise architecture, risk management strategy, insider threat program, and threat awareness program.

Users play a vital role in protecting a system as many important issues in information security involve users, designers, implementers, and managers. How these individuals interact with the system and the level of access they need to do their jobs can also impact the system’s security posture. Almost no system can be secured without properly addressing these aspects of personnel security. Personnel security seeks to minimize the risk that staff (permanent, temporary, or contractor) pose to organizational assets through the malicious use or exploitation of their legitimate access to the organization’s resources. An organization’s status and reputation can be adversely affected by the actions of its employees. Employees may have access to extremely sensitive, confidential, or proprietary information, the disclosure of which can destroy an organization’s reputation or cripple it financially. Therefore, organizations must be vigilant when recruiting and hiring new employees, as well as when an employee transfers or is terminated. The sensitive nature and value of organizational assets requires in-depth personnel security measures. Examples of personnel control include: personnel screening, personnel termination, personnel transfer, access agreements, and personnel sanctions. Organizations: (i) ensure that individuals occupying positions of responsibility within organizations (including third-party service providers) are trustworthy and meet established security criteria for those positions; (ii) ensure that organizational information and systems are protected during and after personnel actions such as terminations and transfers; and (iii) employ formal sanctions for personnel failing to comply with organizational security policies and procedures.

Organizations are dependent upon information technology and associated systems to successfully carry out their missions. While the increasing number of information technology products used in various organizations and industries can be beneficial, in some instances they may also introduce serious threats that can adversely affect an organization’s systems by exploiting both known and unknown vulnerabilities. The exploitation of vulnerabilities in organizational systems can compromise the confidentiality, integrity, or availability of the information being processed, stored, or transmitted by those systems. Performing a risk assessment is one of four components of risk management as described in NIST SP 800-39. Risk assessments identify and prioritize risks to organizational operations, assets, individuals, other organizations, and the Nation that may result from the operation of a system. Risk assessments, which can be conducted at all three tiers in the risk management hierarchy, inform decision makers and support risk responses by identifying: (i) relevant threats to organizations or threats directed through organizations against other organizations; (ii) vulnerabilities both internal and external to organizations; (iii) impact (i.e., harm) to organizations that may occur given the potential for threats exploiting vulnerabilities; and (iv) the likelihood that harm will occur. For more information on risk assessments, see NIST SP 800-30.

Examples of risk assessment controls include: security categorization, risk assessment, vulnerability scanning, and technical surveillance countermeasures survey.

Organizations: periodically assess the risk to organizational operations (e.g., mission, functions, image, reputation), organizational assets, and individuals, which may result from the operation of organizational systems and the associated processing, storage, or transmission of organizational information.

As with other aspects of information processing systems, security is most effective and efficient if planned and managed throughout a system's life cycle, from initial planning to design, implementation, operation, and disposal. Many security-relevant events and analyses occur during a system's life which begins with the organization acquiring the necessary tools and services. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the SDLC and that those considerations are directly related to the organizational mission/business processes.

SSPs can be developed for a system at any point in the life cycle. However, to minimize costs and prevent the disruption of ongoing operations, the recommended approach is to incorporate the plan at the beginning of the system’s life cycle. It is significantly more expensive to add security features to a system than it is to include them from the very beginning. It is important to ensure that security requirements keep pace with changes to the computing environment, technology, and personnel.

Examples of system and service acquisition controls include: allocation of resources, acquisition process, system documentation, supply chain protection, trustworthiness, criticality analysis, developer-provided training, component authenticity, and developer screening.

Organizations: (i) allocate sufficient resources to adequately protect organizational systems; (ii) employ SDLC processes that incorporate information security considerations; (iii) employ software usage and installation restrictions; and (iv) ensure that third-party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization.

System and communications protection controls provide an array of safeguards for the system. Some of the controls in this family address the confidentiality and integrity of information at rest and in transit. The protection of confidentiality and integrity can be provided by these controls through physical or logical means. For example, an organization can provide physical protection by segregating certain functions to separate servers, each having its own set of IP addresses.

Organizations can better safeguard their information by separating user functionality and system management functionality. Providing this type of protection prevents the presentation of system management-related functionality on an interface for non-privileged users. System and communications protection also establishes boundaries that restrict access to publicly-accessible information within a system. Using boundary protections, an organization can monitor and control communications at external boundaries as well as key internal boundaries within the system.

Examples of system and communication protection controls include: application partitioning, denial of service protection, boundary protection, trusted path, mobile code, session authenticity, thin nodes, honeypots, transmission confidentiality and integrity, operations security, protection of information at rest and in transit, and usage restrictions.

Organizations: (i) monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of the systems; and (ii) employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

Integrity is defined as guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. It is the assertion that data can only be accessed or modified by the authorized personnel. System and information integrity provides assurance that the information being accessed has not been meddled with or damaged by an error in the system.

Examples of system and information integrity controls include: flaw remediation, malicious code protection, security function verification, information input validation, error handling, non-persistence, and memory protection.

Organizations: (i) identify, report, and correct information and system flaws in a timely manner; (ii) provide protection from malicious code at appropriate locations within organizational systems; and (iii) monitor system security alerts and advisories and respond appropriately.

[CSA of 1987] Computer Security Act of 1987, Public Law 100-235, 101 Stat 1724 https://www.gpo.gov/fdsys/pkg/STATUTE-101/pdf/STATUTE-101-Pg1724.pdf

[E-Gov Act] E-Government Act of 2002, Public Law 107-347, 116 Stat 2899. http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

[Clinger-Cohen Act] Clinger-Cohen Act, Public Law 107-217, 116 Stat 1234. https://www.gsa.gov/graphics/staffoffices/Clinger.htm

[FISMA2002] Federal Information Security Management Act of 2002, Pub. L. 107-347 (Title III), 116 Stat. 2946. https://www.gpo.gov/fdsys/pkg/CHRG-107hhrg86343/pdf/CHRG-107hhrg86343.pdf

[FISMA 2014] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073. http://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf

[OMB Circular A-130] Office of Management and Budget (OMB), Managing Information as a Strategic Resource, OMB Memorandum Circular A-130, Revised July 28, 2016. https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf

[FIPS140-2] U.S. Department of Commerce. Security Requirements for Cryptographic Modules, Federal Information Processing Standards (FIPS) Publication 140-2, May 25, 2001 (with Change Notices through December 3, 2002), 69pp. https://doi.org/10.6028/NIST.FIPS.140-2

[FIPS180-4] U.S. Department of Commerce. Secure Hash Standard (SHS), Federal Information Processing Standards (FIPS) Publication 180-4, August 2015, 36pp. https://doi.org/10.6028/NIST.FIPS.180-4

[FIPS186-4] U.S. Department of Commerce. Digital Signature Standard (DSS), Federal Information Processing Standards (FIPS) Publication 186-4, July 2013, 130pp. https://doi.org/10.6028/NIST.FIPS.186-4

[FIPS 197] U.S. Department of Commerce. Advanced Encryption Standard, Federal Information Processing Standards (FIPS) Publication 197, November 2001, 51pp. https://doi.org/10.6028/NIST.FIPS.197

[FIPS199] U.S. Department of Commerce. Standards for Security Categorization of Federal Information and Information Systems, Federal Information Processing Standards (FIPS) Publication 199, February 2004, 13pp. https://doi.org/10.6028/NIST.FIPS.199

[FIPS200] U.S. Department of Commerce. Minimum Security Requirements for Federal Information and Information Systems, Federal Information Processing Standards (FIPS) Publication 200, March 2006, 17pp.

https://doi.org/10.6028/NIST.FIPS.200

[FIPS 202] U.S. Department of Commerce. SHA-3: Permutation-Based Hash and Extendable-Output Functions, Federal Information Processing Standards (FIPS) Publication 202, August 2015, 37pp. https://doi.org/10.6028/NIST.FIPS.202

[NISTIR Kissel, R., Glossary of Key Information Security Terms, NISTIR 7298 7298]

Revision 2, National Institute of Standards and Technology, Gaithersburg, Maryland, May 2013, 222pp. https://doi.org/10.6028/NIST.IR.7298r2

[NISTIR Brooks, S., Garcia, M., Lefkovitz, N., Lightman, S., Nadeau, E., An 8062]

Introduction to Privacy Engineering and Risk Management in Federal Systems, NISTIR 8062, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2017, 49pp. https://doi.org/10.6028/NIST.IR.8062

[SP800-18] NIST Special Publication (SP) 800-18 Revision 1, Guide for Developing Security Plans for Systems, National Institute of Standards and Technology, Gaithersburg, Maryland, February 2006, 48pp. https://doi.org/10.6028/NIST.SP.800-18r1

[SP800-30] NIST Special Publication (SP) 800-30 Revision 1, Guide for Conducting Risk Assessments, National Institute of Standards and Technology, Gaithersburg, Maryland, September 2012, 95pp.

https://doi.org/10.6028/NIST.SP.800-30r1

[SP800-32] NIST Special Publication (SP) 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, National Institute of Standards and Technology, Gaithersburg, Maryland, February 2001, 54pp. https://doi.org/10.6028/NIST.SP.800-32

[SP800-34] NIST Special Publication (SP) 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems, National Institute of Standards and Technology, Gaithersburg, Maryland, May 2010 (updated November 2010), 149pp. https://doi.org/10.6028/NIST.SP.800-34r1

[SP800-37] NIST Special Publication (SP) 800-37 Revision 1, Guide for Applying the Risk Management Framework to Systems: A Security Life Cycle Approach, National Institute of Standards and Technology, Gaithersburg, Maryland, February 2010 (updated June 2014), 102pp. https://doi.org/10.6028/NIST.SP.800-37r1

[SP800-39] NIST Special Publication (SP) 800-39, Managing Information Security Risk: Organization, Mission, and Information System View, National Institute of Standards and Technology, Gaithersburg, Maryland, March 2011, 88pp. https://doi.org/10.6028/NIST.SP.800-39

[SP800-53] NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2013 (updated January 2015), 462pp. https://doi.org/10.6028/NIST.SP.800-53r4

[SP800-53A] NIST Special Publication (SP) 800-53A Revision 4, Assessing Security and Privacy Controls in Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, Maryland, December 2014, 487pp. https://doi.org/10.6028/NIST.SP.800-53Ar4

[SP800-57 part 1] NIST Special Publication (SP) 800-57 part 1 Revision 4, Recommendation for Key Management, Part 1: General, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2016, 160pp. https://doi.org/10.6028/NIST.SP.800-57pt1r4

[SP800-57 part 2] NIST Special Publication (SP) 800-57 part 2, Recommendation for Key Management, Part 2: Best Practices for Key Management Organizations, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2005, 79pp. https://doi.org/10.6028/NIST.SP.800-57p2

[SP800-57 part 3] NIST Special Publication (SP) 800-57 part 3 Revision 1, Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2015, 102pp. https://doi.org/10.6028/NIST.SP.800-57Pt3r1

[SP800-60] NIST Special Publication (SP) 800-60 volume 1 Revision 1, Guide for Mapping Types of Information Systems to Security Categories, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2008, 53pp. https://doi.org/10.6028/NIST.SP.800-60v1r1

[SP800-61] NIST Special Publication (SP) 800-61 Revision 2, Computer Security Incident Handling Guide, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2012, 79pp. https://doi.org/10.6028/NIST.SP.800-61r2

[SP800-82] NIST Special Publication (SP) 800-82 Revision 2, Guide to Industrial Control Systems (ICS) Security, National Institute of Standards and Technology, Gaithersburg, Maryland, May 2015, 247pp. https://doi.org/10.6028/NIST.SP.800-82r2

[SP800-95] NIST Special Publication (SP) 800-95, Guide to Secure Web Services, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2007, 128pp. https://doi.org/10.6028/NIST.SP.800-95

[SP800-122] NIST Special Publication (SP) 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), National Institute of Standards and Technology, Gaithersburg, Maryland, April 2010, 59pp. https://doi.org/10.6028/NIST.SP.800-122

[SP800-128] NIST Special Publication (SP) 800-128, Guide for Security-Focused Configuration Management of Information Systems, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2011, 88pp. https://doi.org/10.6028/NIST.SP.800-128

[SP800-137] NIST Special Publication (SP) 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, Maryland, September 2011, 80pp. https://doi.org/10.6028/NIST.SP.800-137

[SP800-147] NIST Special Publication (SP) 800-147, BIOS Protection Guidelines, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2011, 26pp. https://doi.org/10.6028/NIST.SP.800-147

[SP800-152] NIST Special Publication (SP) 800-152, A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS), National Institute of Standards and Technology, Gaithersburg, Maryland, October 2015, 147pp. https://doi.org/10.6028/NIST.SP.800-152

[SP800-155] NIST Special Publication (SP) 800-155 (DRAFT), BIOS Integrity Measurement Guidelines, National Institute of Standards and Technology, Gaithersburg, Maryland, December 2011, 47pp. http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf

[SP800-160] NIST Special Publication (SP) 800-160, Systems Security Engineering:

Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, National Institute of Standards and Technology, Gaithersburg, Maryland, May 2016, 307pp. https://doi.org/10.6028/NIST.SP.800-160

[SP800-161] NIST Special Publication (SP) 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2015, 282pp. https://doi.org/10.6028/NIST.SP.800-161

[SP800-162] NIST Special Publication (SP) 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2014, 46pp. https://doi.org/10.6028/NIST.SP.800-162

[SP800-175A] NIST Special Publication (SP) 800-175A, Guideline for Using Cryptographic Standards in the Federal Government: Directives, Mandates and Policies, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2016, 44pp. https://doi.org/10.6028/NIST.SP.800-175A

[SP800-175B] NIST Special Publication (SP) 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms, National Institute of Standards and Technology, Gaithersburg, Maryland, March 2016, 81pp. https://doi.org/10.6028/NIST.SP.800-175B

Access Control — The process of granting or denying specific requests to: 1) obtain and use information and related information processing services; and 2) enter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances).

Accountability — The security goal that generates the requirement for actions of an entity to be traced uniquely to that entity. This supports non-repudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal action.

SOURCE: SP 800-27 Rev. A

Assurance — Grounds for confidence that the other four security goals (integrity, availability, confidentiality, and accountability) have been adequately met by a specific implementation. “Adequately met” includes (1) functionality that performs correctly, (2) sufficient protection against unintentional errors (by users or software), and (3) sufficient resistance to intentional penetration or by-pass.

SOURCE: SP 800-27 Rev. A

Attack — Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself.

Audit — Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures.

Authentication — Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in a system.

Authorization — The official management decision given by a senior official to authorize operation of a system or the common controls inherited by designated organizations systems and to explicitly accept the risk to organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security and privacy controls. Also known as authorization to operate.

SOURCE: OMB Circular A-130, adapted

Authorizing Official (AO) — A senior (federal) official or executive with the authority to formally assume responsibility for operating a system at an acceptable level of risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

SOURCE: SP 800-37 Rev 1

Back door — An undocumented way of gaining access to computer system. A backdoor is a potential security risk.

SOURCE: NIST SP 800-82 Rev 2

Biometrics — A measurable physical characteristic or personal behavioral trait used to recognize the identity, or verify the claimed identity, of an applicant. Facial images, fingerprints, and iris scan samples are all examples of biometrics.

Bit — A binary digit having a value of 0 or 1.

Challenge-Response Protocol — An authentication protocol where the verifier sends the claimant a challenge (usually a random value or a nonce) that the claimant combines with a secret (often by hashing the challenge and a shared secret together, or by applying a private key operation to the challenge) to generate a response that is sent to the verifier. The verifier can independently verify the response generated by the Claimant (such as by re-computing the hash of the challenge and the shared secret and comparing to the response, or performing a public key operation on the response) and establish that the Claimant possesses and controls the secret.

Checksum — A value that (a) is computed by a function that is dependent on the content of a data object and (b) is stored or transmitted together with the object, for detecting changes in the data

SOURCE: IETF RFC 4949 Ver. 2

Ciphertext — Data in its encrypted form.

SOURCE: SP 800-57 Part 1 Rev. 4

Denial of Service — The prevention of authorized access to resources or the delaying of time-critical operations. (Time-critical may be milliseconds or it may be hours, depending upon the service provided).

Digital Signature — The result of a cryptographic transformation of data which, when properly implemented, provides the services of: 1. origin authentication, 2. data integrity, and 3. signer non-repudiation.

Encryption — The cryptographic transformation of data to produce ciphertext.

End-to-End Encryption — Communications encryption in which data is encrypted when being passed through a network, but routing information remains visible.

Firewall — A gateway that limits access between networks in accordance with local security policy.

Gateway — An intermediate system (interface, relay) that attaches to two (or more) computer networks that have similar functions but dissimilar implementations and that enables either one-way or two-way communication between the networks.

SOURCE: IETF RFC 4949 Ver. 2

Hacker — Unauthorized user who attempts to or gains access to an information system.

Incident — An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.

Information — 1. Facts and ideas, which can be represented (encoded) as various forms of data.

SOURCE: IETF RFC 4949 Ver. 2

Information Assurance — Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities.

Information Security — The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

SOURCE: 44 U.S.C., Sec. 3542

Information Security Policy — Aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information.

Information Security Risk — The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and/or a system.

SOURCE: SP 800-30 Rev 1

Information System — A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [Note: Information systems also include specialized systems such as industrial/process controls systems, telephone switching and private branch exchange (PBX) systems, and environmental control systems.]

SOURCE: 44 U.S.C., Sec. 3502

Information Technology — (A) with respect to an executive agency means any equipment or interconnected system or subsystem of equipment, used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency, if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that requires the use— (i) of that equipment; or (ii) of that equipment to a significant extent in the performance of a service or the furnishing of a product; (B) includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources; but (C) does not include any equipment acquired by a federal contractor incidental to a federal contract.

SOURCE: 40 U.S.C., Sec. 11101

Integrity — Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

SOURCE: 44 U.S.C., Sec. 3542

Intrusion Detection System (IDS) — Software that automates the intrusion detection process.

SOURCE: SP 800-94

Key — A parameter used in conjunction with a cryptographic algorithm that determines its operation.

Examples applicable to this Standard include:

Key Management — The activities involving the handling of cryptographic keys and other related security parameters (e.g., initialization vectors) during the entire lifecycle of the keys, including their generation, storage, establishment, entry and output, use and destruction.

SOURCE: SP 800-57 Part 1 Rev 4

Keystroke Monitoring

The process used to view or record both the keystrokes entered by a computer user and the computer’s response during an interactive session. Keystroke monitoring is usually considered a special case of audit trails.

Least Privilege

The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function.

Link Encryption

Encryption of information between nodes of a communications system.

Logic Bomb

A piece of code intentionally inserted into a software system that will set off a malicious function when specified conditions are met.

Malicious Code

Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of a system. A virus, worm, Trojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code.

Malware

See Malicious Code.

Password

A string of characters (letters, numbers, and other symbols) used to authenticate an identity or to verify access authorization.

Penetration Testing

A test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system.

Phishing

A technique for attempting to acquire sensitive data, such as bank account numbers, through a fraudulent solicitation in email or on a web site, in which the perpetrator masquerades as a legitimate business or reputable person.

SOURCE: IETF RFC 4949 Ver 2

Private Key

A cryptographic key, used with a public key cryptographic algorithm, that is uniquely associated with an entity and is not made public.

Privilege

A right granted to an individual, a program, or a process.

Public Key

A cryptographic key used with a public key cryptographic algorithm that is uniquely associated with an entity and that may be made public.

Public Key Cryptography

Encryption system that uses a public-private key pair for encryption and/or digital signature.

Public Key Infrastructure (PKI)

A Framework that is established to issue, maintain, and revoke public key certificates.

Reciprocity

Mutual agreement among participating enterprises to accept each other’s security assessments in order to reuse information system resources and/or to accept each other’s assessed security posture in order to share information.

Risk

A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. [Note: System-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. Adverse impacts to the Nation include, for example, compromises to systems that support critical infrastructure applications or are paramount to government continuity of operations as defined by the Department of Homeland Security.]

Risk Assessment — The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis.

Risk Management — The program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, and includes: (i) establishing the context for risk-related activities; (ii) assessing risk; (iii) responding to risk once determined; and (iv) monitoring risk over time.

Risk Management Framework (RMF) — A structured approach used to oversee and manage risk for an enterprise.

Role — A job function or employment position to which people or other system entities may be assigned in a system.

SOURCE: IETF RFC 4949 Ver 2

Safeguards — Protective measures prescribed to meet the security requirements (i.e., confidentiality, integrity, and availability) specified for a system. Safeguards may include security features, management constraints, personnel security, and security of physical structures, areas, and devices. Synonymous with security controls and countermeasures.

Secret Key — A cryptographic key, used with a secret key cryptographic algorithm, that is uniquely associated with one or more entities and should not be made public.

Security — A condition that results from the establishment and maintenance of protective measures that enable an enterprise to perform its mission or critical functions despite risks posed by threats to its use of information systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the enterprise’s risk management approach.