This revision of the OSCAL representation of the NIST SP 800-171 Rev 3 provides a bug fix for empty statements in security requirements.
OSCAL v1.1.3 representation of the content of SP800-171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.
organization-defined time period
the time period for account inactivity before disabling is defined.
organization-defined time period
the time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined.
organization-defined time period
the time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined.
organization-defined time period
the time period within which to notify account managers and designated personnel or roles when system usage or the need-to-know changes for an individual is defined.
organization-defined time period
the time period of expected inactivity requiring users to log out of the system is defined.
organization-defined circumstances
circumstances requiring users to log out of the system are defined.
Define the types of system accounts allowed and prohibited.
Create, enable, modify, disable, and remove system accounts in accordance with policy, procedures, prerequisites, and criteria.
Specify:
Authorized users of the system,
Group and role membership, and
Access authorizations (i.e., privileges) for each account.
Authorize access to the system based on:
A valid access authorization and
Intended system usage.
Monitor the use of system accounts.
Disable system accounts when:
The accounts have expired,
The accounts have been inactive for
The accounts are no longer associated with a user or individual,
The accounts are in violation of organizational policy, or
Significant risks associated with individuals are discovered.
Notify account managers and designated personnel or roles within:
Require that users log out of the system after
This requirement focuses on account management for systems and applications. The definition and enforcement of access authorizations other than those determined by account type (e.g., privileged access, non-privileged access) are addressed in 03.01.02. System account types include individual, group, temporary, system, guest, anonymous, emergency, developer, and service. Users who require administrative privileges on system accounts receive additional scrutiny by personnel responsible for approving such accounts and privileged access. Types of accounts that organizations may prohibit due to increased risk include group, emergency, guest, anonymous, and temporary. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of both. Other attributes required for authorizing access include restrictions on the time of day, day of the week, and point of origin. When defining other system account attributes, organizations consider system requirements (e.g., system upgrades, scheduled maintenance) and mission and business requirements (e.g., time zone differences, remote access to facilitate travel requirements). Users who pose a significant security risk include individuals for whom reliable evidence indicates either the intention to use authorized access to the system to cause harm or that adversaries will cause harm through them. Close coordination among mission and business owners, system administrators, human resource managers, and legal staff is essential when disabling system accounts for high-risk individuals. Time periods for the notification of organizational personnel or roles may vary. Inactivity logout is behavior- or policy-based and requires users to take physical action to log out when they are expecting inactivity longer than the defined period. Automatic enforcement of inactivity logout is addressed by 03.01.10.
system accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
system accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
system accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
system accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
system accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
system account types allowed are defined.
system account types prohibited are defined.
authorized users of the system are specified.
group and role memberships are specified.
access authorizations (i.e., privileges) for each account are specified.
access to the system is authorized based on a valid access authorization.
access to the system is authorized based on intended system usage.
the use of system accounts is monitored.
system accounts are disabled when the accounts have expired.
system accounts are disabled when the accounts have been inactive for
system accounts are disabled when the accounts are no longer associated with a user or individual.
system accounts are disabled when the accounts violate organizational policy.
account managers and designated personnel or roles are notified within
account managers and designated personnel or roles are notified within
account managers and designated personnel or roles are notified within
system accounts are disabled when significant risks associated with individuals are discovered.
users are required to log out of the system after
access control policy and procedures
personnel termination or transfer policies and procedures
procedures for account management
list of active system accounts and the name of the individual associated with each account
system design documentation
list of conditions for group and role membership
system configuration settings
notifications of recent transfers, separations, or terminations of employees
list of recently disabled system accounts and the name of the individual associated with each account
list of user activities that pose significant organizational risks
access authorization records
account management compliance reviews
system monitoring and audit records
system security plan
system-generated list of accounts removed
system-generated list of emergency accounts disabled
system-generated list of disabled accounts
other relevant documents and records
personnel with account management responsibilities
system administrators
personnel with information security responsibilities
system developers
processes for account management on the system
mechanisms for implementing account management
Enforce approved authorizations for logical access to CUI and system resources in accordance with applicable access control policies.
Access control policies control access between active entities or subjects (i.e., users or system processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. Types of system access include remote access and access to systems that communicate through external networks, such as the internet. Access enforcement mechanisms can also be employed at the application and service levels to provide increased protection for CUI. This recognizes that the system can host many applications and services in support of mission and business functions. Access control policies are defined in 03.15.01.
approved authorizations for logical access to CUI are enforced in accordance with applicable access control policies.
approved authorizations for logical access to system resources are enforced in accordance with applicable access control policies.
access control policy and procedures
procedures for access enforcement
system design documentation
system configuration settings
list of approved authorizations (i.e., user privileges)
system audit records
system security plan
other relevant documents or records
personnel with access enforcement responsibilities
system administrators
personnel with information security responsibilities
system developers
mechanisms for implementing the access control policy
Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems.
Information flow control regulates where CUI can transit within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include keeping CUI from being transmitted in the clear to the internet, blocking external communications traffic that claims to be sourced from within the organization, restricting requests to the internet that are not from the internal web proxy server, and limiting CUI transfers between organizations based on data structures and content. Transferring CUI between organizations may require an agreement that specifies how the information flow is enforced (see 03.12.05). Transferring CUI between systems that represent different security domains with different security policies introduces the risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes prohibiting CUI transfers between interconnected systems (i.e., allowing information access only), employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security attributes and security labels. Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of CUI between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., encrypted tunnels, routers, gateways, and firewalls) that use rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement.
approved authorizations are enforced for controlling the flow of CUI within the system.
approved authorizations are enforced for controlling the flow of CUI between connected systems.
access control policy and procedures
information flow control policies
procedures for information flow enforcement
security architecture and design documentation
system configuration settings
system baseline configuration
system audit records
list of information flow authorizations
system security plan
other relevant documents or records
system administrators
personnel with security architecture responsibilities
personnel with information security responsibilities
system developers
mechanisms for implementing the information flow enforcement policy
Identify the duties of individuals requiring separation.
Define system access authorizations to support separation of duties.
Separation of duties addresses the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and support functions among different individuals or roles, conducting system support functions with different individuals or roles (e.g., quality assurance, configuration management, network security, system management, assessments, and programming), and ensuring that personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of their systems and system components when developing policies on separation of duties. This requirement is enforced by 03.01.02.
duties of individuals requiring separation are identified.
system access authorizations to support separation of duties are defined.
access control policy and procedures
procedures for the separation of duties and the division of responsibilities
system configuration settings
system audit records
system access authorizations
list of divisions of responsibility and separation of duties
system security plan
other relevant documents or records
personnel with responsibilities for defining the separation of duties and the division of responsibilities
personnel with information security responsibilities
system administrators
mechanisms for implementing the separation of duties policy
organization-defined security functions
security functions for authorized access are defined.
organization-defined security-relevant information
security-relevant information for authorized access is defined.
organization-defined frequency
the frequency at which to review the privileges assigned to roles or classes of users is defined.
Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks.
Authorize access to
Review the privileges assigned to roles or classes of users
Reassign or remove privileges, as necessary.
Organizations employ the principle of least privilege for specific duties and authorized access for users and system processes. Least privilege is applied to the development, implementation, and operation of the system. Organizations consider creating additional processes, roles, and system accounts to achieve least privilege. Security functions include establishing system accounts and assigning privileges, installing software, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information. Security-relevant information includes threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, security architecture, cryptographic key management information, access control lists, and audit information.
system access for users (or processes acting on behalf of users) is authorized only when necessary to accomplish assigned organizational tasks.
access to
access to
the privileges assigned to roles or classes of users are reviewed
privileges are reassigned or removed, as necessary.
access control policy and procedures
procedures for least privilege
list of assigned access authorizations (i.e., privileges)
system configuration settings
system audit records
list of security functions (implemented in hardware, software, and firmware)
security-relevant information for which access must be explicitly authorized
list of system-generated roles or classes of users and assigned privileges
validation reviews of privileges assigned to roles or classes of users
records of privilege removals or reassignments for roles or classes of users
system security plan
system design documentation
other relevant documents or records
personnel with responsibilities for defining least privileges
personnel with information security responsibilities
system administrators
mechanisms for implementing least privilege functions
mechanisms for implementing reviews of user privileges
organization-defined personnel or roles
personnel or roles to which privileged accounts on the system are to be restricted are defined.
Restrict privileged accounts on the system to
Require that users (or roles) with privileged accounts use non-privileged accounts when accessing non-security functions or non-security information.
Privileged accounts refer to accounts that are granted elevated privileges to access resources (including security functions or security-relevant information) that are otherwise restricted for non-privileged accounts. These accounts are typically described as system administrator or super user accounts. For example, a privileged account is often required in order to perform privileged functions such as executing commands that could modify system behavior. Restricting privileged accounts to specific personnel or roles ensures that only those authorized users can access and manipulate security functions or security-relevant information. Requiring the use of non-privileged accounts when such access is not needed can limit unauthorized access to and manipulation of security functions or security-relevant information.
privileged accounts on the system are restricted to
users (or roles) with privileged accounts are required to use non-privileged accounts when accessing non-security functions or non-security information.
access control policy and procedures
procedures for least privilege
list of system-generated privileged accounts
list of system administration personnel
system audit records
system configuration settings
system security plan
list of system-generated security functions or security-relevant information assigned to system accounts or roles
other relevant documents or records
personnel with responsibilities for defining least privileges
personnel with information security responsibilities
system administrators
mechanisms for implementing least privilege functions
Prevent non-privileged users from executing privileged functions.
Log the execution of privileged functions.
Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, changing system configuration settings, or administering cryptographic key management activities. Non-privileged users do not possess the authorizations to execute privileged functions. Bypassing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. This requirement represents a condition achieved by the definition of authorized privileges in 03.01.01 and privilege enforcement in 03.01.02. The misuse of privileged functions — whether intentionally or unintentionally by authorized users or by unauthorized external entities that have compromised system accounts — is a serious and ongoing concern that can have significant adverse impacts on organizations. Logging the use of privileged functions is one way to detect such misuse and mitigate risks from advanced persistent threats and insider threats.
the execution of privileged functions is logged.
non-privileged users are prevented from executing privileged functions.
access control policy and procedures
procedures for least privilege
system design documentation
system configuration settings
system audit records
list of audited events
list of privileged functions to be audited and associated user account assignments
system security plan
other relevant documents or records
personnel with responsibilities for reviewing least privileges
personnel with information security responsibilities
system developers
system administrators
mechanisms for auditing the execution of least privilege functions
mechanisms for implementing least privilege functions for non-privileged users
organization-defined number
the number of consecutive invalid logon attempts by a user allowed during a time period is defined.
organization-defined time period
the time period to which the number of consecutive invalid logon attempts by a user is limited is defined.
organization-defined time period
the time period for an account or node to be locked is defined (if selected).
Enforce a limit of
Automatically
Due to the potential for denial of service, automatic system lockouts are in most cases, temporary and automatically release after a predetermined time period established by the organization (i.e., using a delay algorithm). Organizations may employ different delay algorithms for different system components based on the capabilities of the respective components. Responses to unsuccessful system logon attempts may be implemented at the system and application levels. Organization-defined actions that may be taken include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of a full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles, such as location, time of day, IP address, device, or Media Access Control (MAC) address.
a limit of
access control policy and procedures
procedures for unsuccessful logon attempts
system design documentation
system audit records
system configuration settings
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing the access control policy for unsuccessful logon attempts
Display a system use notification message with privacy and security notices consistent with applicable CUI rules before granting access to the system.
System use notifications can be implemented using messages or warning banners. The messages or warning banners are displayed before individuals log in to a system that processes, stores, or transmits CUI. System use notifications are used for access via logon interfaces with human users and are not required when human interfaces do not exist. Organizations consider whether a secondary use notification is needed to access applications or other system resources after the initial network logon. Posters or other printed materials may be used in lieu of an automated system message. This requirement is related to 03.15.03.
a system use notification message with privacy and security notices consistent with applicable CUI rules is displayed before granting access to the system.
access control policy and procedures
privacy and security policies, procedures for system use notification
documented approval of system use notification messages
system audit records
user acknowledgements of system use notification messages
system design documentation
system configuration settings
system use notification messages
system security plan
other relevant documents or records
personnel with information security responsibilities
legal counsel
system developers
system administrators
mechanisms for implementing system use notifications
organization-defined time period
the time period of inactivity after which a device lock is initiated is defined (if selected).
Prevent access to the system by
Retain the device lock until the user reestablishes access using established identification and authentication procedures.
Conceal, via the device lock, information previously visible on the display with a publicly viewable image.
Device locks are temporary actions taken to prevent access to the system when users depart from the immediate vicinity of the system but do not want to log out due to the temporary nature of their absences. Device locks can be implemented at the operating system level or application level. User-initiated device locking is behavior- or policy-based and requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of the system (e.g., when organizations require users to log out at the end of workdays). Publicly viewable images can include static or dynamic images, such as patterns used with screen savers, solid colors, photographic images, a clock, a battery life indicator, or a blank screen with the caveat that controlled unclassified information is not displayed.
access to the system is prevented by
information previously visible on the display is concealed via device lock with a publicly viewable image.
the device lock is retained until the user reestablishes access using established identification and authentication procedures.
access control policy and procedures
procedures for session lock and identification and authentication
system design documentation
system configuration settings
display screen with session lock activated
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing the access control policy for session lock
session lock mechanisms
organization-defined conditions or trigger events requiring session disconnect
conditions or trigger events that require session disconnect are defined.
Terminate a user session automatically after
This requirement addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., disconnecting from the network) in 03.13.09. A logical session is initiated whenever a user (or processes acting on behalf of a user) accesses a system. Logical sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination ends all system processes associated with a user’s logical session except those processes that are created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events that require automatic session termination can include organization-defined periods of user inactivity, time-of-day restrictions on system use, and targeted responses to certain types of incidents.
a user session is terminated automatically after
access control policy and procedures
procedures for session termination
system design documentation
system configuration settings
list of conditions or trigger events requiring session disconnect
system audit records
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
automated mechanisms for implementing user session termination
Establish usage restrictions, configuration requirements, and connection requirements for each type of allowable remote system access.
Authorize each type of remote system access prior to establishing such connections.
Route remote access to the system through authorized and managed access control points.
Authorize the remote execution of privileged commands and remote access to security-relevant information.
Remote access is access to systems (or processes acting on behalf of users) that communicate through external networks, such as the internet. Monitoring and controlling remote access methods allows organizations to detect attacks and ensure compliance with remote access policies. Routing remote access through managed access control points enhances explicit control over such connections and reduces susceptibility to unauthorized access to the system, which could result in the unauthorized disclosure of CUI. Remote access to the system represents a significant potential vulnerability that can be exploited by adversaries. Restricting the execution of privileged commands and access to security-relevant information via remote access reduces the exposure of the organization and its susceptibility to threats by adversaries. A privileged command is a human-initiated command executed on a system that involves the control, monitoring, or administration of the system, including security functions and security-relevant information. Security-relevant information is information that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Privileged commands give individuals the ability to execute sensitive, security-critical, or security-relevant system functions.
types of allowable remote system access are defined.
usage restrictions are established for each type of allowable remote system access.
configuration requirements are established for each type of allowable remote system access.
connection requirements are established for each type of allowable remote system access.
each type of remote system access is authorized prior to establishing such connections.
remote access to the system is routed through authorized access control points.
remote access to the system is routed through managed access control points.
remote execution of privileged commands is authorized.
remote access to security-relevant information is authorized.
access control policy and procedures
procedures for remote system access
remote system access configuration and connection requirements
configuration management plan
system configuration settings
remote access authorizations
system audit records
system design documentation
procedures for remote access to the system
system monitoring records
list of managed network access control points
system security plan
other relevant documents or records
personnel with responsibilities for managing remote access connections
personnel with information security responsibilities
system administrators
mechanisms for monitoring and controlling remote access methods
mechanisms for routing remote accesses through managed access control points
remote access management capability for the system
Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system.
Authorize each type of wireless access to the system prior to establishing such connections.
Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment.
Protect wireless access to the system using authentication and encryption.
Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries. Establishing usage restrictions, configuration requirements, and connection requirements for wireless access to the system provides criteria to support access authorization decisions. These restrictions and requirements reduce susceptibility to unauthorized system access through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. Organizations authenticate individuals and devices to protect wireless access to the system. Special attention is given to the variety of devices with potential wireless access to the system, including small form factor mobile devices (e.g., smart phones, tablets, smart watches). Wireless networking capabilities that are embedded within system components represent a potential vulnerability that can be exploited by adversaries. Strong authentication of users and devices, strong encryption, and disabling wireless capabilities that are not needed for essential mission or business functions can reduce susceptibility to threats by adversaries involving wireless technologies.
each type of wireless access to the system is defined.
usage restrictions are established for each type of wireless access to the system.
configuration requirements are established for each type of wireless access to the system.
connection requirements are established for each type of wireless access to the system.
each type of wireless access to the system is authorized prior to establishing such connections.
wireless networking capabilities not intended for use are disabled prior to issuance and deployment.
wireless access to the system is protected using authentication.
wireless access to the system is protected using encryption.
access control policy and procedures
procedures for wireless system access
wireless system access configuration and connection requirements
configuration management plan
system configuration settings
wireless access authorizations
system audit records
system design documentation
system security plan
other relevant documents or records
personnel with responsibilities for managing wireless access connections
personnel with information security responsibilities
system developers
system administrators
wireless access management capability for the system
mechanisms for implementing wireless access protections to the system
mechanisms for managing the disabling of wireless networking capabilities
Establish usage restrictions, configuration requirements, and connection requirements for mobile devices.
Authorize the connection of mobile devices to the system.
Implement full-device or container-based encryption to protect the confidentiality of CUI on mobile devices.
A mobile device is a computing device with a small form factor such that it can be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable, or removable data storage; and includes a self-contained power source. Mobile device functionality may include on-board sensors that allow the device to capture information, voice communication capabilities, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, smart watches, and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capabilities of mobile devices may be comparable to or a subset of notebook or desktop systems, depending on the nature and intended purpose of the device. Some organizations may consider notebook computers to be mobile devices. The protection and control of mobile devices are behavior- or policy-based and require users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which the organization provides physical or procedural controls to meet the requirements established for protecting CUI. Due to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions, configuration requirements, and connection requirements for mobile devices include configuration management, device identification and authentication, implementing mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting operating system and possibly other software integrity checks, and disabling unnecessary hardware. On mobile devices, secure containers provide software-based data isolation designed to segment enterprise applications and information from personal apps and data. Containers may present multiple user interfaces, one of the most common being a mobile application that acts as a portal to a suite of business productivity apps, such as email, contacts, and calendar. Organizations can employ full-device encryption or container-based encryption to protect the confidentiality of CUI on mobile devices.
usage restrictions are established for mobile devices.
configuration requirements are established for mobile devices.
connection requirements are established for mobile devices.
the connection of mobile devices to the system is authorized.
full-device or container-based encryption is implemented to protect the confidentiality of CUI on mobile devices.
access control policy and procedures
procedures for mobile device access control
system design documentation
configuration management plan
system configuration settings
authorizations for mobile device connections to organizational systems
system audit records
encryption mechanisms and associated configuration documentation
system security plan
other relevant documents or records
personnel with access control responsibilities for mobile devices
personnel using mobile devices to access organizational systems
personnel with information security responsibilities
system administrators
access control capability for mobile device connections to organizational systems
encryption mechanisms for protecting the confidentiality of CUI on mobile devices
configurations of mobile devices
organization-defined security requirements
security requirements to be satisfied on external systems prior to allowing the use of or access to those systems by authorized individuals are defined.
Prohibit the use of external systems unless the systems are specifically authorized.
Establish the following security requirements to be satisfied on external
systems prior to allowing use of or access to those systems by authorized
individuals:
Permit authorized individuals to use external systems to access the organizational system or to process, store, or transmit CUI only after:
Verifying that the security requirements on the external systems as specified in the organization’s system security plans have been satisfied and
Retaining approved system connection or processing agreements with the organizational entities hosting the external systems.
Restrict the use of organization-controlled portable storage devices by authorized individuals on external systems.
External systems are systems that are used by but are not part of the organization. These systems include personally owned systems, system components, or devices; privately owned computing and communication devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; and systems managed by contractors. Organizations have the option to prohibit the use of any type of external system or specified types of external systems (e.g., prohibit the use of external systems that are not organizationally owned). Terms and conditions are consistent with the trust relationships established with the entities that own, operate, or maintain external systems and include descriptions of shared responsibilities. Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to the organizational system and over whom organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals may vary depending on the trust relationships between organizations. Organizations need assurance that external systems satisfy the necessary security requirements so as not to compromise, damage, or harm the system. This requirement is related to 03.16.03.
the following security requirements to be satisfied on external systems prior to
allowing the use of or access to those systems by authorized individuals are
established:
the use of external systems is prohibited unless the systems are specifically authorized.
authorized individuals are permitted to use external systems to access the organizational system or to process, store, or transmit CUI only after verifying that the security requirements on the external systems as specified in the organization’s system security plans have been satisfied.
the use of organization-controlled portable storage devices by authorized individuals on external systems is restricted.
authorized individuals are permitted to use external systems to access the organizational system or to process, store, or transmit CUI only after retaining approved system connection or processing agreements with the organizational entity hosting the external systems.
access control policy and procedures
procedures for the use of external systems
terms and conditions for the use of external systems
external systems security requirements
list of types of applications accessible from external systems
system configuration settings
system security plan
other relevant documents or records
personnel with responsibilities for defining terms, conditions, and security requirements for the use of external systems
personnel with information security responsibilities
system administrators
mechanisms for implementing or enforcing terms, conditions, and security requirements for the use of external systems
Train authorized individuals to ensure that publicly accessible information does not contain CUI.
Review the content on publicly accessible systems for CUI and remove such information, if discovered.
In accordance with applicable laws, Executive Orders, directives, policies, regulations, standards, and guidelines, the public is not authorized to have access to nonpublic information, including CUI.
authorized individuals are trained to ensure that publicly accessible information does not contain CUI.
the content on publicly accessible systems is reviewed for CUI.
CUI is removed from publicly accessible systems, if discovered.
organization-defined frequency
the frequency at which to provide security literacy training to system users after initial training is defined.
organization-defined events
events that require security literacy training for system users are defined.
organization-defined frequency
the frequency at which to update security literacy training content is defined.
organization-defined events
events that require security literacy training content updates are defined.
Provide security literacy training to system users:
As part of initial training for new users and
When required by system changes or following
On recognizing and reporting indicators of insider threat, social engineering, and social mining.
Update security literacy training content
Organizations provide basic and advanced levels of security literacy training to system users (including managers, senior executives, system administrators, and contractors) and measures to test the knowledge level of users. Organizations determine the content of literacy training based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and the actions required of users to maintain security and respond to incidents. The content also addresses the need for operations security and the handling of CUI. Security awareness techniques include displaying posters, offering supplies inscribed with security reminders, generating email advisories or notices from organizational officials, displaying logon screen messages, and conducting awareness events using podcasts, videos, and webinars. Security literacy training is conducted at a frequency consistent with applicable laws, directives, regulations, and policies. Updating literacy training content on a regular basis ensures that the content remains relevant. Events that may precipitate an update to literacy training content include assessment or audit findings, security incidents or breaches, or changes in applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. Potential indicators and possible precursors of insider threats include behaviors such as inordinate, long-term job dissatisfaction; attempts to gain access to information that is not required for job performance; unexplained access to financial resources; sexual harassment or bullying of fellow employees; workplace violence; and other serious violations of the policies, procedures, rules, directives, or practices of organizations. Organizations may consider tailoring insider threat awareness topics to roles (e.g., training for managers may be focused on specific changes in the behavior of team members, while training for employees may be focused on more general observations). Social engineering is an attempt to deceive an individual into revealing information or taking an action that can be used to breach, compromise, or otherwise adversely impact a system. Social engineering includes phishing, pretexting, impersonation, baiting, quid pro quo, threadjacking, social media exploitation, and tailgating. Social mining is an attempt to gather information about the organization that may be used to support future attacks. Security literacy training includes how to communicate employee and management concerns regarding potential indicators of insider threat and potential and actual instances of social engineering and data mining through appropriate organizational channels in accordance with established policies and procedures.
security literacy training is provided to system users as part of initial training for new users.
security literacy training is provided to system users
security literacy training is provided to system users when required by system
changes or following
security literacy training is provided to system users on recognizing indicators of insider threat.
security literacy training is provided to system users on reporting indicators of insider threat.
security literacy training is provided to system users on recognizing indicators of social engineering.
security literacy training is provided to system users on reporting indicators of social engineering.
security literacy training is provided to system users on recognizing indicators of social mining.
security literacy training is provided to system users on reporting indicators of social mining.
security literacy training content is updated
security literacy training content is updated following
security literacy training and awareness policy and procedures
procedures for security literacy training and awareness implementation
codes of federal regulations
security literacy and awareness training curriculum
security literacy and awareness training materials
training records
system security plan
other relevant documents or records
personnel with responsibilities for security literacy training and awareness
personnel comprising the general system user community
personnel with information security responsibilities
mechanisms for managing information security literacy training and awareness
organization-defined frequency
the frequency at which to provide role-based security training to assigned personnel after initial training is defined.
organization-defined events
events that require role-based security training are defined.
organization-defined frequency
the frequency at which to update role-based security training content is defined.
organization-defined events
events that require role-based security training content updates are defined.
Provide role-based security training to organizational personnel:
Before authorizing access to the system or CUI, before performing
assigned duties, and
When required by system changes or following
Update role-based training content
Organizations determine the content and frequency of security training based on the assigned duties, roles, and responsibilities of individuals and the security requirements of the systems to which personnel have authorized access. In addition, organizations provide system developers, enterprise architects, security architects, software developers, systems integrators, acquisition/procurement officials, system and network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation, security assessors, and personnel with access to system-level software with security-related technical training specifically tailored for their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities that cover physical, personnel, and technical controls. Such training can include policies, procedures, tools, and artifacts for the security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and supply chain security within the context of organizational information security programs.
role-based security training is provided to organizational personnel before authorizing access to the system or CUI.
role-based security training is provided to organizational personnel before performing assigned duties.
role-based security training is provided to organizational personnel
role-based security training is provided to organizational personnel when
required by system changes or following
role-based security training content is updated
role-based security training content is updated following
security awareness and training policy and procedures
procedures for security training implementation
codes of federal regulations
security training curriculum
security training materials
training records
system security plan
other relevant documents or records
personnel with responsibilities for role-based security training
personnel with assigned system security roles and responsibilities
mechanisms for managing role-based security training and awareness
organization-defined event types
event types selected for logging within the system are defined.
organization-defined frequency
the frequency of event types selected for logging are reviewed and updated.
Specify the following event types selected for logging within the system:
Review and update the event types selected for logging
An event is any observable occurrence in a system, including unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed. This includes events that are relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, the execution of privileged functions, failed logons or accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the system monitoring and auditing that are appropriate for each of the security requirements. When defining event types, organizations consider the logging necessary to cover related events, such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloud-based architectures. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access — both successful and unsuccessful — but only activate that capability under specific circumstances due to the potential burden on system performance. The event types that are logged by organizations may change over time. Reviewing and updating the set of logged event types are necessary to ensure that the current set of event types remains relevant.
the following event types are specified for logging within the system:
the event types selected for logging are reviewed
the event types selected for logging are updated
audit and accountability policy and procedures
procedures for auditable events
system design documentation
system configuration settings
system audit records
system auditable events
system security plan
other relevant documents or records
personnel with audit and accountability responsibilities
personnel with information security responsibilities
system administrators
mechanisms for implementing system auditing
Include the following content in audit records:
What type of event occurred
When the event occurred
Where the event occurred
Source of the event
Outcome of the event
Identity of the individuals, subjects, objects, or entities associated with the event
Provide additional information for audit records as needed.
Audit record content that may be necessary to support the auditing function includes time stamps, source and destination addresses, user or process identifiers, event descriptions, file names, and the access control or flow control rules that are invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred). Detailed information that organizations consider in audit records may include a full text recording of privileged commands or the individual identities of group account users.
audit records contain information that establishes what type of event occurred.
audit records contain information that establishes when the event occurred.
audit records contain information that establishes where the event occurred.
audit records contain information that establishes the source of the event.
audit records contain information that establishes the outcome of the event.
audit records contain information that establishes the identity of the individuals, subjects, objects, or entities associated with the event.
additional information for audit records is provided, as needed.
audit and accountability policy and procedures
procedures for the content of audit records
list of organization-defined auditable events
system design documentation
system configuration settings
system audit records
system incident reports
system security plan
other relevant documents or records
personnel with audit and accountability responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing system auditing of auditable events
system audit capability
Generate audit records for the selected event types and audit record content specified in 03.03.01 and 03.03.02.
Retain audit records for a time period consistent with the records retention policy.
Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit logging capability and can facilitate the identification of root causes to problems. The ability to add information generated in audit records is dependent on system functionality to configure the audit record content. Organizations may consider additional information in audit records, including the access control or flow control rules invoked and the individual identities of group account users. Organizations may also consider limiting additional audit record information to only information that is explicitly needed for audit requirements.
audit records for the selected event types and audit record content specified in 03.03.01 and 03.03.02 are generated.
audit records are retained for a time period consistent with the records retention policy.
audit and accountability policy and procedures
procedures for audit record generation
system design documentation
list of auditable events
system audit records
audit record retention policy and procedures
organization-defined retention period for audit records
audit record archives
system configuration settings
system security plan
other relevant documents or records
personnel with audit record generation responsibilities
personnel with audit record retention responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing the audit record generation capability
organization-defined time period
the time period for organizational personnel or roles receiving audit logging process failure alerts is defined.
organization-defined additional actions
additional actions to be taken in the event of an audit logging process failure are defined.
Alert organizational personnel or roles within
Take the following additional actions:
Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Response actions include overwriting the oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel.
organizational personnel or roles are alerted in the event of an audit logging
process failure within
the following additional actions are taken:
audit and accountability policy and procedures
procedures for responding to audit processing failures
system design documentation
system configuration settings
list of personnel to be notified in case of an audit processing failure
system audit records
system security plan
other relevant documents or records
personnel with audit and accountability responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing system response to audit processing failures
organization-defined frequency
the frequency at which system audit records are reviewed and analyzed is defined.
Review and analyze system audit records
Report findings to organizational personnel or roles.
Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.
Audit record review, analysis, and reporting cover information security logging performed by organizations and can include logging that results from the monitoring of account usage, remote access, wireless connectivity, configuration settings, the use of maintenance tools and nonlocal maintenance, system component inventory, mobile device connection, equipment delivery and removal, physical access, temperature and humidity, communications at system interfaces, and the use of mobile code. Findings can be reported to organizational entities, such as the incident response team, help desk, and security or privacy offices. If organizations are prohibited from reviewing and analyzing audit records or unable to conduct such activities, the review or analysis may be carried out by other organizations granted such authority. The scope, frequency, and/or depth of the audit record review, analysis, and reporting may be adjusted to meet organizational needs based on new information received. Correlating audit record review, analysis, and reporting processes helps to ensure that audit records collectively create a more complete view of events.
system audit records are reviewed and analyzed
findings are reported to organizational personnel or roles.
audit records across different repositories are analyzed to gain organization-wide situational awareness.
audit records across different repositories are correlated to gain organization-wide situational awareness.
audit and accountability policy and procedures
procedures for audit record review, analysis, and reporting
reports of audit record findings
records of actions taken in response to reviews and analyses of audit records
system design documentation
system audit records across different repositories
system security plan
system configuration settings
other relevant documents or records
personnel with audit record review, analysis, and reporting responsibilities
personnel with information security responsibilities
mechanisms for supporting the analysis and correlation of audit records
Implement an audit record reduction and report generation capability that supports audit record review, analysis, reporting requirements, and after-the-fact investigations of incidents.
Preserve the original content and time ordering of audit records.
Audit records are generated in 03.03.03. Audit record reduction and report generation occur after audit record generation. Audit record reduction is a process that manipulates collected audit information and organizes it in a summary format that is more meaningful to analysts. Audit record reduction and report generation capabilities do not always come from the same system or organizational entities that conduct auditing activities. An audit record reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the system can help generate customizable reports. The time ordering of audit records can be a significant issue if the granularity of the time stamp in the record is insufficient.
an audit record reduction and report generation capability that supports audit record review is implemented.
an audit record reduction and report generation capability that supports audit record analysis is implemented.
an audit record reduction and report generation capability that supports audit record reporting requirements is implemented.
an audit record reduction and report generation capability that supports after-the-fact investigations of incidents is implemented.
the original content of audit records is preserved.
the original time ordering of audit records is preserved.
audit and accountability policy and procedures
procedures for audit record reduction and report generation
audit record reduction, review, analysis, and reporting tools
system audit records
system design documentation
system configuration settings
system security plan
other relevant documents or records
personnel with audit record reduction and report generation responsibilities
personnel with information security responsibilities
mechanisms for supporting audit record reduction and report generation capability
organization-defined granularity of time measurement
granularity of time measurement for audit record time stamps is defined.
Use internal system clocks to generate time stamps for audit records.
Record time stamps for audit records that meet
Time stamps generated by the system include the date and time. Time is often expressed in Coordinated Universal Time (UTC) — a modern continuation of Greenwich Mean Time (GMT) — or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., clocks synchronizing within hundreds or tens of milliseconds). Organizations may define different time granularities for system components. Time service can be critical to other security capabilities (e.g., access control and identification and authentication), depending on the nature of the mechanisms used to support those capabilities.
internal system clocks are used to generate time stamps for audit records.
time stamps are recorded for audit records that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.
time stamps are recorded for audit records that meet
audit and accountability policy and procedures
procedures for timestamp generation
system design documentation
system configuration settings
system audit records
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing timestamp generation
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
Authorize access to management of audit logging functionality to only a subset of privileged users or roles.
Audit information includes the information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are programs and devices used to conduct audit and logging activities. The protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. The physical protection of audit information is addressed by media and physical protection requirements. Individuals or roles with privileged access to a system and who are also the subject of an audit by that system may affect the reliability of the audit information by inhibiting audit activities or modifying audit records. Requiring privileged access to be further defined between audit-related privileges and other privileges limits the number of users or roles with audit-related privileges.
access to management of audit logging functionality is authorized to only a subset of privileged users or roles.
audit information is protected from unauthorized access, modification, and deletion.
audit logging tools are protected from unauthorized access, modification, and deletion.
audit and accountability policy and procedures
access control policy and procedures
procedures for the protection of audit information
system configuration settings
system audit records
audit tools
system-generated list of privileged users with access to the management of audit functionality
access authorizations
access control list
system design documentation
system security plan
other relevant documents or records
personnel with audit and accountability responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing audit information protection
mechanisms for managing access to audit functionality
organization-defined frequency
the frequency of baseline configuration review and update is defined.
Develop and maintain under configuration control, a current baseline configuration of the system.
Review and update the baseline configuration of the system
Baseline configurations for the system and system components include aspects of connectivity, operation, and communications. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for the system or configuration items within the system. Baseline configurations serve as a basis for future builds, releases, or changes to the system and include information about system components, operational procedures, network topology, and the placement of components in the system architecture. Maintaining baseline configurations requires creating new baselines as the system changes over time. Baseline configurations of the system reflect the current enterprise architecture.
a current baseline configuration of the system is developed.
a current baseline configuration of the system is maintained under configuration control.
the baseline configuration of the system is updated
the baseline configuration of the system is reviewed when system components are installed or modified.
the baseline configuration of the system is updated when system components are installed or modified.
the baseline configuration of the system is reviewed
configuration management policy and procedures
procedures for the baseline system configuration
configuration management plan
enterprise architecture
system design documentation
system architecture
system configuration settings
system component inventory
change control records
system security plan
other relevant documents or records
personnel with configuration management responsibilities
personnel with information security responsibilities
system administrators
processes for managing baseline configurations
mechanisms for supporting configuration control of the baseline configuration
organization-defined configuration settings
configuration settings for the system that reflect the most restrictive mode consistent with operational requirements are defined.
Establish, document, and implement the following configuration settings for
the system that reflect the most restrictive mode consistent with
operational requirements:
Identify, document, and approve any deviations from established configuration settings.
Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system and that affect the security posture or functionality of the system. Security-related configuration settings can be defined for systems (e.g., servers, workstations), input and output devices (e.g., scanners, copiers, printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters that impact the security state of the system, including the parameters required to satisfy other security requirements. Security parameters include registry settings; account, file, and directory permission settings (i.e., privileges); and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for the system. The established settings become part of the system’s configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, and security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors.
the following configuration settings for the system that reflect the most
restrictive mode consistent with operational requirements are established and
documented:
any deviations from established configuration settings are identified and documented.
any deviations from established configuration settings are approved.
the following configuration settings for the system are implemented:
configuration management policy and procedures
procedures for system configuration settings
configuration management plan
system design documentation
system configuration settings
common secure configuration checklists
system component inventory
evidence supporting approved deviations from established configuration settings
change control records
system data processing and retention permissions
system audit records
system security plan
other relevant documents or records
personnel with security configuration management responsibilities
personnel with information security responsibilities
system administrators
processes for managing configuration settings
mechanisms that implement, monitor, or control system configuration settings
mechanisms that identify or document deviations from established configuration settings
Define the types of changes to the system that are configuration-controlled.
Review proposed configuration-controlled changes to the system, and approve or disapprove such changes with explicit consideration for security impacts.
Implement and document approved configuration-controlled changes to the system.
Monitor and review activities associated with configuration-controlled changes to the system.
Configuration change control refers to tracking, reviewing, approving or disapproving, and logging changes to the system. Specifically, it involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the system, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for system components (e.g., operating systems, applications, firewalls, routers, mobile devices) and configuration items of the system, changes to configuration settings, unscheduled and unauthorized changes, and changes to remediate vulnerabilities. This requirement is related to 03.04.04.
the types of changes to the system that are configuration-controlled are defined.
proposed configuration-controlled changes to the system are reviewed with explicit consideration for security impacts.
proposed configuration-controlled changes to the system are approved or disapproved with explicit consideration for security impacts.
activities associated with configuration-controlled changes to the system are monitored.
activities associated with configuration-controlled changes to the system are reviewed.
approved configuration-controlled changes to the system are implemented.
approved configuration-controlled changes to the system are documented.
configuration management policy and procedures
procedures for system configuration change control
configuration management plan
system architecture
configuration settings
change control records
system audit records
change control audit and review reports
agenda, minutes, and documentation from configuration change control oversight meetings
system security plan
other relevant documents or records
personnel with configuration change control responsibilities
personnel with information security responsibilities
members of change control board or similar
system administrators
processes for configuration change control
mechanisms that implement configuration change control
Analyze changes to the system to determine potential security impacts prior to change implementation.
Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented.
Organizational personnel with security responsibilities conduct impact analyses that include reviewing system security plans, policies, and procedures to understand security requirements; reviewing system design documentation and operational procedures to understand how system changes might affect the security state of the system; reviewing the impacts of system changes on supply chain partners with stakeholders; and determining how potential changes to a system create new risks and the ability to mitigate those risks. Impact analyses also include risk assessments to understand the impacts of changes and determine whether additional security requirements are needed. Changes to the system may affect the safeguards and countermeasures previously implemented. This requirement is related to 03.04.03. Not all changes to the system are configuration controlled.
the security requirements for the system continue to be satisfied after the system changes have been implemented.
changes to the system are analyzed to determine potential security impacts prior to change implementation.
configuration management policy and procedures
procedures for security impact analyses for system changes
configuration management plan
security impact analysis documentation
system design documentation
analysis tools and outputs
change control records
system audit records
system security plan
other relevant documents or records
personnel with security impact analysis responsibilities
personnel with information security responsibilities
members of change control board
system developers
system administrators
processes for security impact analyses
Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.
Changes to the hardware, software, or firmware components of the system or the operational procedures related to the system can have potentially significant effects on the security of the system. Therefore, organizations permit only qualified and authorized individuals to access the system for the purpose of initiating changes. Access restrictions include physical and logical access controls, software libraries, workflow automation, media libraries, abstract layers (i.e., changes implemented into external interfaces rather than directly into the system), and change windows (i.e., changes occur only during specified times).
physical access restrictions associated with changes to the system are defined and documented.
physical access restrictions associated with changes to the system are approved.
physical access restrictions associated with changes to the system are enforced.
logical access restrictions associated with changes to the system are defined and documented.
logical access restrictions associated with changes to the system are approved.
logical access restrictions associated with changes to the system are enforced.
configuration management policy and procedures
procedures for access restrictions for system changes
configuration management plan
system design documentation
system architecture
system configuration settings
logical access approvals
physical access approvals
access credentials
change control records
system audit records
system security plan
other relevant documents or records
personnel with logical access control responsibilities
personnel with physical access control responsibilities
personnel with information security responsibilities
system administrators
processes for managing access restrictions for system changes
mechanisms for supporting, implementing, or enforcing access restrictions associated with system changes
organization-defined functions, ports, protocols, connections, and services
functions to be prohibited or restricted are defined.
organization-defined functions, ports, protocols, connections, and services
ports to be prohibited or restricted are defined.
organization-defined functions, ports, protocols, connections, and services
protocols to be prohibited or restricted are defined.
organization-defined functions, ports, protocols, connections, and services
connections to be prohibited or restricted are defined.
organization-defined functions, ports, protocols, connections, and services
services to be prohibited or restricted are defined.
organization-defined frequency
the frequency at which to review the system to identify unnecessary or nonsecure functions, ports, protocols, connections, or services is defined.
Configure the system to provide only mission-essential capabilities.
Prohibit or restrict use of the following functions, ports, protocols,
connections, and services:
Review the system
Disable or remove functions, ports, protocols, connections, and services that are unnecessary or nonsecure.
Systems can provide a variety of functions and services. Some functions and services that are routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. It may be convenient to provide multiple services from single system components. However, doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit functionality to a single function per component. Organizations review the functions and services provided by the system or system components to determine which functions and services are candidates for elimination. Organizations disable unused or unnecessary physical and logical ports and protocols to prevent the unauthorized connection of devices, the transfer of information, and tunneling. Organizations can employ network scanning tools, intrusion detection and prevention systems, and endpoint protection systems (e.g., firewalls and host-based intrusion detection systems) to identify and prevent the use of prohibited functions, ports, protocols, system connections, and services. Bluetooth, File Transfer Protocol (FTP), and peer-to-peer networking are examples of the types of protocols that organizations consider eliminating, restricting, or disabling.
the use of the following functions is prohibited or restricted:
the use of the following ports is prohibited or restricted:
the use of the following protocols is prohibited or restricted:
the use of the following connections is prohibited or restricted:
the use of the following services is prohibited or restricted:
the system is reviewed
unnecessary or nonsecure functions, ports, protocols, connections, and services are disabled or removed.
the system is configured to provide only mission-essential capabilities.
configuration management policy and procedures
procedures for least functionality in the system
configuration management plan
system design documentation
system configuration settings
system component inventory
common secure configuration checklists
documented reviews of functions, ports, protocols, and services
change control records
system audit records
system security plan
other relevant documents or records
personnel with configuration management responsibilities
personnel with responsibilities for reviewing functions, ports, protocols, and services
personnel with information security responsibilities
system developers
system administrators
processes for prohibiting or restricting functions, ports, protocols, and services
processes for reviewing or disabling functions, ports, protocols, and services
mechanisms for implementing the review and disabling of functions, ports, protocols, and services
mechanisms for implementing restrictions on or the prohibition of functions, ports, protocols, and services
organization-defined frequency
the frequency at which to review and update the list of authorized software programs is defined.
Identify software programs authorized to execute on the system.
Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system.
Review and update the list of authorized software programs
If provided with the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved “app stores.” The policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods. Authorized software programs can be limited to specific versions or come from specific sources. To facilitate a comprehensive authorized software process and increase the strength of protection against attacks that bypass application-level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries.
software programs authorized to execute on the system are identified.
a deny-all, allow-by-exception policy for the execution of authorized software programs on the system is implemented.
the list of authorized software programs is reviewed and updated
configuration management policy and procedures
procedures for least functionality in the system
configuration management plan
system design documentation
system configuration settings
list of software programs authorized to execute on the system
system component inventory
records associated with the review and update of the list of authorized software programs
common secure configuration checklists
change control records
system audit records
system security plan
other relevant documents or records
personnel with responsibilities for identifying software authorized to execute on the system
personnel with information security responsibilities
system administrators
processes for identifying, reviewing, and updating programs authorized to execute on the system
processes for implementing authorized software policy
mechanisms for supporting or implementing authorized software policy
organization-defined frequency
the frequency at which to review and update the system component inventory is defined.
Develop and document an inventory of system components.
Review and update the system component inventory
Update the system component inventory as part of installations, removals, and system updates.
System components are discrete, identifiable assets (i.e., hardware, software, and firmware elements) that compose a system. Organizations may implement centralized system component inventories that include components from all systems. In such situations, organizations ensure that the inventories include the system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, software license information, hardware inventory specifications, and — for networked components — the machine names and network addresses for all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include component type, physical location, date of receipt, manufacturer, cost, model, serial number, and supplier information.
an inventory of system components is developed and documented.
the system component inventory is reviewed
the system component inventory is updated
the system component inventory is updated as part of component installations.
the system component inventory is updated as part of component removals.
the system component inventory is updated as part of system updates.
configuration management policy and procedures
procedures for system component inventory
configuration management plan
system design documentation
system component inventory
inventory reviews and update records
component installation records
change control records
component removal records
system change records
system security plan
other relevant documents or records
personnel with component inventory management responsibilities
personnel with information security responsibilities
system administrators
processes for managing the system component inventory
mechanisms for supporting or implementing the system component inventory
processes for updating the system component inventory
mechanisms for supporting or implementing the system component inventory updates
Identify and document the location of CUI and the system components on which the information is processed and stored.
Document changes to the system or system component location where CUI is processed and stored.
Information location addresses the need to understand the specific system components where CUI is being processed and stored and the users who have access to CUI so that appropriate protection mechanisms can be provided, including information flow controls, access controls, and information management.
the location of CUI is identified and documented.
the system components on which CUI is processed are identified and documented.
the system components on which CUI is stored are identified and documented.
changes to the system or system component location where CUI is processed are documented.
changes to the system or system component location where CUI is stored are documented.
configuration management policy and procedures
configuration management plan
procedures for identification and documentation of information location
system audit records
architecture documentation
system design documentation
list of users with system and system component access
change control records
system component inventory
system security plan
other relevant documents or records
personnel with responsibilities for managing information location and user access
personnel with responsibilities for operating, using, or maintaining the system
personnel with information security responsibilities
system developers
system administrators
processes governing information location
mechanisms for enforcing policies and methods for governing information location
organization-defined system configurations
configurations for systems or system components to be issued to individuals traveling to high-risk locations are defined.
organization-defined security requirements
security requirements to be applied to the system or system components when individuals return from travel are defined.
Issue systems or system components with the following configurations to
individuals traveling to high-risk locations:
Apply the following security requirements to the systems or components when
the individuals return from travel:
When it is known that a system or a system component will be in a high-risk area, additional security requirements may be needed to counter the increased threat. Organizations can implement protective measures on the systems or system components used by individuals departing on and returning from travel. Actions include determining whether the locations are of concern, defining the required configurations for the components, ensuring that the components are configured as intended before travel is initiated, and taking additional actions after travel is completed. For example, systems going into high-risk areas can be configured with sanitized hard drives, limited applications, and more stringent configuration settings. Actions applied to mobile devices upon return from travel include examining the device for signs of physical tampering and purging and reimaging the device storage.
systems or system components with the following configurations are issued to
individuals traveling to high-risk locations:
the following security requirements are applied to the system or system
components when the individuals return from travel:
configuration management policy and procedures
configuration management plan
procedures for the baseline configuration of the system
procedures for system component installations and upgrades
system component inventory
system component installations or upgrades and associated records
records of system baseline configuration reviews and updates
system configuration settings
system architecture
change control records
system security plan
other relevant documents or records
personnel with configuration management responsibilities
personnel with information security responsibilities
system administrators
processes for managing baseline configurations
organization-defined circumstances or situations requiring re-authentication
circumstances or situations that require re-authentication are defined.
Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users.
Re-authenticate users when
System users include individuals (or system processes acting on behalf of individuals) who are authorized to access a system. Typically, individual identifiers are the usernames associated with the system accounts assigned to those individuals. Since system processes execute on behalf of groups and roles, organizations may require the unique identification of individuals in group accounts or the accountability of individual activity. The unique identification and authentication of users apply to all system accesses. Organizations use passwords, physical authenticators, biometrics, or some combination thereof to authenticate user identities. Organizations may re-authenticate individuals in certain situations, including when roles, authenticators, or credentials change; when the execution of privileged functions occurs; after a fixed time period; or periodically.
system users are uniquely identified.
system users are authenticated.
processes acting on behalf of users are associated with uniquely identified and authenticated system users.
users are reauthenticated when
identification and authentication policy and procedures
list of circumstances or situations requiring re-authentication
system design documentation
system configuration settings
system audit records
list of system accounts
system security plan
other relevant documents or records
personnel with identification and authentication responsibilities
personnel with system operations responsibilities
personnel with account management responsibilities
system developers
personnel with information security responsibilities
system administrators
processes for uniquely identifying and authenticating users
mechanisms for supporting or implementing identification and authentication capabilities
organization-defined devices or types of devices
devices or types of devices to be uniquely identified and authenticated before establishing a connection are defined.
Uniquely identify and authenticate
Devices that require unique device-to-device identification and authentication are defined by type, device, or a combination of type and device. Organization-defined device types include devices that are not owned by the organization. Systems use shared known information (e.g., Media Access Control .MAC, Transmission Control Protocol/Internet Protocol .TCP/IP addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers .IEEE 802.1x and Extensible Authentication Protocol .EAP, RADIUS server with EAP-Transport Layer Security .TLS authentication, Kerberos) to identify and authenticate devices on local and wide area networks. Public Key Infrastructure (PKI) and certificate revocation checking for the certificates exchanged can be included as part of device authentication.
identification and authentication policy and procedures
procedures for device identification and authentication
system design documentation
list of devices requiring unique identification and authentication
device connection reports
system configuration settings
system security plan
other relevant documents or records
personnel with responsibilities for device identification and authentication
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing device identification and authentication capabilities
Implement multi-factor authentication for access to privileged and non-privileged accounts.
This requirement applies to user accounts. Multi-factor authentication requires the use of two or more different factors to achieve authentication. The authentication factors are defined as follows: something you know (e.g., a personal identification number .PIN), something you have (e.g., a physical authenticator, such as a cryptographic private key), or something you are (e.g., a biometric). Multi-factor authentication solutions that feature physical authenticators include hardware authenticators that provide time-based or challenge-response outputs and smart cards. In addition to authenticating users at the system level, organizations may also employ authentication mechanisms at the application level to provide increased information security.
multi-factor authentication for access to privileged accounts is implemented.
multi-factor authentication for access to non-privileged accounts is implemented.
identification and authentication policy and procedures
system design documentation
list of system accounts
system configuration settings
system audit records
system security plan
other relevant documents or records
personnel with system operations responsibilities
personnel with account management responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing a multi-factor authentication capability
Implement replay-resistant authentication mechanisms for access to privileged and non-privileged accounts.
Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges, such as time synchronous or challenge-response one-time authenticators.
replay-resistant authentication mechanisms for access to privileged accounts are implemented.
replay-resistant authentication mechanisms for access to non-privileged accounts are implemented.
identification and authentication policy and procedures
system design documentation
system audit records
system configuration settings
list of privileged system accounts
system security plan
other relevant documents or records
personnel with system operations responsibilities
personnel with account management responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing identification and authentication capabilities
mechanisms for supporting or implementing replay-resistance
organization-defined time period
the time period for preventing the reuse of identifiers is defined.
organization-defined characteristic identifying individual status
characteristic used to identify individual status are defined.
Receive authorization from organizational personnel or roles to assign an individual, group, role, service, or device identifier.
Select and assign an identifier that identifies an individual, group, role, service, or device.
Prevent the reuse of identifiers for
Manage individual identifiers by uniquely identifying each individual as
Identifiers are provided for users, processes acting on behalf of users, and devices. Prohibiting the reuse of identifiers prevents the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices. Characteristics that identify the status of individuals include contractors, foreign nationals, and non-organizational users. Identifying the status of individuals by these characteristics provides information about the people with whom organizational personnel are communicating. For example, it is useful for an employee to know that one of the individuals on an email message is a contractor.
authorization is received from organizational personnel or roles to assign an individual, group, role, service, or device identifier.
an identifier that identifies an individual, group, role, service, or device is selected.
an identifier that identifies an individual, group, role, service, or device is assigned.
the reuse of identifiers for
individual identifiers are managed by uniquely identifying each individual as
identification and authentication policy and procedures
procedures for identifier management
procedures for account management
system design documentation
list of system accounts
list of characteristics identifying individual status
system configuration settings
list of identifiers generated from physical access control devices
system security plan
other relevant documents or records
personnel with identifier management responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing identifier management
organization-defined frequency
the frequency at which to update the list of commonly used, expected, or compromised passwords is defined.
organization-defined composition and complexity rules
password composition and complexity rules are defined.
Maintain a list of commonly-used, expected, or compromised passwords, and
update the list
Verify that passwords are not found on the list of commonly used, expected, or compromised passwords when users create or update passwords.
Transmit passwords only over cryptographically protected channels.
Store passwords in a cryptographically protected form.
Select a new password upon first use after account recovery.
Enforce the following composition and complexity rules for passwords:
Password-based authentication applies to passwords used in single-factor or multi-factor authentication. Long passwords or passphrases are preferable to shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish and enforce certain rules for password generation (e.g., minimum character length) under certain circumstances. For example, account recovery can occur when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof. Changing temporary passwords to permanent passwords immediately after system logon ensures that the necessary strength of the authentication mechanism is implemented at the earliest opportunity and reduces susceptibility to authenticator compromises. Long passwords and passphrases can be used to increase the complexity of passwords.
a list of commonly used, expected, or compromised passwords is maintained.
a list of commonly used, expected, or compromised passwords is updated
a list of commonly used, expected, or compromised passwords is updated when organizational passwords are suspected to have been compromised.
passwords are verified not to be found on the list of commonly used, expected, or compromised passwords when they are created or updated by users.
passwords are only transmitted over cryptographically protected channels.
passwords are stored in a cryptographically protected form.
a new password is selected upon first use after account recovery.
the following composition and complexity rules for passwords are enforced:
identification and authentication policy and procedures
password policy
procedures for authenticator management
system design documentation
system configuration settings
password configurations
system security plan
other relevant documents or records
personnel with authenticator management responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing a password-based authenticator management capability
Obscure feedback of authentication information during the authentication process.
Authentication feedback does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For example, for desktop or notebook systems with relatively large monitors, the threat may be significant (commonly referred to as shoulder surfing). For mobile devices with small displays, this threat may be less significant and is balanced against the increased likelihood of input errors due to small keyboards. Therefore, the means of obscuring authenticator feedback is selected accordingly. Obscuring feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a limited time before fully obscuring it.
feedback of authentication information during the authentication process is obscured.
identification and authentication policy and procedures
procedures for authenticator feedback
system design documentation
system configuration settings
system audit records
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing the obscuring of feedback of authentication information during authentication
organization-defined frequency
the frequency for changing or refreshing authenticators is defined.
organization-defined events
events that trigger the change or refreshment of authenticators are defined.
Verify the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution.
Establish initial authenticator content for any authenticators issued by the organization.
Establish and implement administrative procedures for initial authenticator distribution; for lost, compromised, or damaged authenticators; and for revoking authenticators.
Change default authenticators at first use.
Change or refresh authenticators
Protect authenticator content from unauthorized disclosure and modification.
Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. The initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, requirements for authenticator content contain specific characteristics. Authenticator management is supported by organization-defined settings and restrictions for various authenticator characteristics (e.g., password complexity and composition rules, validation time window for time synchronous one-time tokens, and the number of allowed rejections during the verification stage of biometric authentication). The requirement to protect individual authenticators may be implemented by 03.15.03 for authenticators in the possession of individuals and by 03.01.01, 03.01.02, 03.01.05, and 03.13.08 for authenticators stored in organizational systems. This includes passwords stored in hashed or encrypted formats or files that contain hashed or encrypted passwords that are accessible with administrator privileges. Actions can be taken to protect authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Developers may deliver system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well-known, easily discoverable, and present a significant risk. Authenticator management includes issuing and revoking authenticators for temporary access when they are no longer needed. The use of long passwords or passphrases may obviate the need to periodically change authenticators.
the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution is verified.
initial authenticator content for any authenticators issued by the organization is established.
administrative procedures for initial authenticator distribution are established.
administrative procedures for lost, compromised, or damaged authenticators are established.
administrative procedures for revoking authenticators are established.
administrative procedures for initial authenticator distribution are implemented.
administrative procedures for lost, compromised, or damaged authenticators are implemented.
administrative procedures for revoking authenticators are implemented.
default authenticators are changed at first use.
authenticators are changed or refreshed
authenticator content is protected from unauthorized disclosure.
authenticator content is protected from unauthorized modification.
identification and authentication policy and procedures
procedures for authenticator management
system configuration settings
list of system authenticator types
system design documentation
system audit records
change control records associated with managing system authenticators
system security plan
other relevant documents or records
personnel with authenticator management responsibilities
personnel with information security responsibilities
system administrators
mechanisms for supporting or implementing the authenticator management capability
Implement an incident-handling capability that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery.
Incident-related information can be obtained from a variety of sources, including audit monitoring, network monitoring, physical access monitoring, user and administrator reports, and reported supply chain events. An effective incident handling capability involves coordination among many organizational entities, including mission and business owners, system owners, human resources offices, physical and personnel security offices, legal departments, operations personnel, and procurement offices.
an incident-handling capability that is consistent with the incident response plan is implemented.
the incident handling capability includes preparation.
the incident handling capability includes detection and analysis.
the incident handling capability includes containment.
the incident handling capability includes eradication.
the incident handling capability includes recovery.
incident response policy and procedures
contingency planning policy and procedures
procedures for incident handling
procedures for incident response planning
incident response plan
contingency plan
records of incident response plan reviews and approvals
system security plan
other relevant documents or records
personnel with incident handling responsibilities
personnel with incident response planning responsibilities
personnel with contingency planning responsibilities
personnel with information security responsibilities
incident handling capability for the organization
incident response plan
organization-defined time period
the time period to report suspected incidents to the organizational incident response capability is defined.
organization-defined authorities
authorities to whom incident information is to be reported are defined.
Track and document system security incidents.
Report suspected incidents to the organizational incident response capability
within
Report incident information to
Provide an incident response support resource that offers advice and assistance to system users on handling and reporting incidents.
Documenting incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics as well as evaluating incident details, trends, and handling. Incident information can be obtained from many sources, including network monitoring, incident reports, incident response teams, user complaints, supply chain partners, audit monitoring, physical access monitoring, and user and administrator reports. 03.06.01 provides information on the types of incidents that are appropriate for monitoring. The types of incidents reported, the content and timeliness of the reports, and the reporting authorities reflect applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. Incident information informs risk assessments, the effectiveness of security assessments, the security requirements for acquisitions, and the selection criteria for technology products. Incident response support resources provided by organizations include help desks, assistance groups, automated ticketing systems to open and track incident response tickets, and access to forensic services or consumer redress services, when required.
system security incidents are tracked.
system security incidents are documented.
suspected incidents are reported to the organizational incident response
capability within
incident information is reported to
an incident response support resource that offers advice and assistance to system users on handling and reporting incidents is provided.
incident response policy and procedures
procedures for incident monitoring
procedures for incident response assistance
incident response records and documentation
incident response plan
system security plan
other relevant documents or records
personnel with incident monitoring responsibilities
personnel with incident response assistance and support responsibilities
personnel with information security responsibilities
processes for incident reporting
incident monitoring capability
mechanisms for supporting or implementing the tracking and documenting of system security incidents
mechanisms for supporting or implementing incident reporting
mechanisms for supporting or implementing incident response assistance
processes for incident response assistance
organization-defined frequency
the frequency at which to test the effectiveness of the incident response capability for the system is defined.
Test the effectiveness of the incident response capability
Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Incident response testing includes the use of checklists, walk-through or tabletop exercises, and simulations. Incident response testing can include a determination of the effects of incident response on organizational operations, organizational assets, and individuals. Qualitative and quantitative data can help determine the effectiveness of incident response processes.
the effectiveness of the incident response capability is tested
incident response policy and procedures
contingency planning policy and procedures
procedures for incident response testing
procedures for contingency plan testing
incident response testing material
incident response test results
incident response test plan
incident response plan
contingency plan
system security plan
other relevant documents or records
personnel with incident response testing responsibilities
personnel with information security responsibilities
organization-defined time period
the time period within which incident response training is to be provided to system users is defined.
organization-defined frequency
the frequency at which to provide incident response training to users after initial training is defined.
organization-defined events
events that initiate a review of the incident response training content are defined.
organization-defined frequency
the frequency at which to review and update incident response training content is defined.
Provide incident response training to system users consistent with assigned roles and responsibilities:
Within
When required by system changes, and
Review and update incident response training content
Incident response training is associated with the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail are included in such training. For example, users may only need to know how to recognize an incident or whom to call; system administrators may require additional training on how to handle incidents; and incident responders may receive specific training on data collection techniques, forensics, reporting, system recovery, and system restoration. Incident response training includes user training in identifying and reporting suspicious activities from external and internal sources. Incident response training for users may be provided as part of 03.02.02. Events that may cause an update to incident response training content include incident response plan testing, response to an actual incident, audit or assessment findings, or changes in applicable laws, Executive Orders, policies, directives, regulations, standards, and guidelines.
incident response training for system users consistent with assigned roles and
responsibilities is provided within
incident response training for system users consistent with assigned roles and responsibilities is provided when required by system changes.
incident response training for system users consistent with assigned roles and
responsibilities is provided
incident response training content is updated following
incident response training content is updated
incident response training content is reviewed following
incident response training content is reviewed
incident response policy and procedures
procedures for incident response training
incident response training curriculum
incident response training materials
incident response plan
incident response training records
system security plan
other relevant documents or records
personnel with incident response training and operational responsibilities
personnel with information security responsibilities
Develop an incident response plan that:
Provides the organization with a roadmap for implementing its incident response capability,
Describes the structure and organization of the incident response capability,
Provides a high-level approach for how the incident response capability fits into the overall organization,
Defines reportable incidents,
Addresses the sharing of incident information, and
Designates responsibilities to organizational entities, personnel, or roles.
Distribute copies of the incident response plan to designated incident response personnel (identified by name and/or by role) and organizational elements.
Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing.
Protect the incident response plan from unauthorized disclosure.
It is important that organizations develop and implement a coordinated approach to incident response. Organizational mission and business functions determine the structure of incident response capabilities. As part of the incident response capabilities, organizations consider the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain.
an incident response plan is developed that provides the organization with a roadmap for implementing its incident response capability.
an incident response plan is developed that describes the structure and organization of the incident response capability.
an incident response plan is developed that provides a high-level approach for how the incident response capability fits into the overall organization.
an incident response plan is developed that defines reportable incidents.
an incident response plan is developed that addresses the sharing of incident information.
an incident response plan is developed that designates responsibilities to organizational entities, personnel, or roles.
copies of the incident response plan are distributed to designated incident response personnel (identified by name or by role).
copies of the incident response plan are distributed to organizational elements.
the incident response plan is protected from unauthorized disclosure.
the incident response plan is updated to address system and organizational changes or problems encountered during plan implementation, execution, or testing.
incident response policy
procedures addressing incident response planning
incident response plan
system security plan
records of incident response plan reviews and approvals
other relevant documents or records
personnel with incident response planning responsibilities
personnel with information security responsibilities
incident response plan and related processes
Approve, control, and monitor the use of system maintenance tools.
Check media with diagnostic and test programs for malicious code before it is used in the system.
Prevent the removal of system maintenance equipment containing CUI by verifying that there is no CUI on the equipment, sanitizing or destroying the equipment, or retaining the equipment within the facility.
Approving, controlling, monitoring, and reviewing maintenance tools address security-related issues associated with the tools that are used for diagnostic and repair actions on the system. Maintenance tools can include hardware and software diagnostic and test equipment as well as packet sniffers. The tools may be pre-installed, brought in with maintenance personnel on media, cloud-based, or downloaded from a website. Diagnostic and test programs are potential vehicles for transporting malicious code into the system, either intentionally or unintentionally. Examples of media inspection include checking the cryptographic hash or digital signatures of diagnostic and test programs and media. If organizations inspect media that contain diagnostic and test programs and determine that the media also contain malicious code, the incident is handled consistent with incident handling policies and procedures. A periodic review of system maintenance tools can result in the withdrawal of approval for outdated, unsupported, irrelevant, or no-longer-used tools. Maintenance tools do not address the hardware and software components that support maintenance and are considered a part of the system.
the use of system maintenance tools is approved.
the use of system maintenance tools is controlled.
the use of system maintenance tools is monitored.
media with diagnostic and test programs are checked for malicious code before the media are used in the system.
the removal of system maintenance equipment containing CUI is prevented by verifying that there is no CUI on the equipment, sanitizing or destroying the equipment, or retaining the equipment within the facility.
maintenance policy and procedures
procedures for system maintenance tools
system maintenance tools
maintenance tool inspection records
equipment sanitization records
media sanitization records
system security plan
other relevant documents or records
personnel with system maintenance responsibilities
personnel responsible for media sanitization
personnel with information security responsibilities
processes for approving, controlling, and monitoring maintenance tools
mechanisms for supporting or implementing the approval, control, or monitoring of maintenance tools
processes for preventing the unauthorized removal of information
processes for inspecting media for malicious code
mechanisms for supporting media sanitization or the destruction of equipment
mechanisms for supporting the verification of media sanitization
processes for inspecting maintenance tools
mechanisms for supporting or implementing the inspection of maintenance tools
mechanisms for supporting or implementing the inspection of media used for maintenance
Approve and monitor nonlocal maintenance and diagnostic activities.
Implement multi-factor authentication and replay resistance in the establishment of nonlocal maintenance and diagnostic sessions.
Terminate session and network connections when nonlocal maintenance is completed.
Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through an external or internal network. Local maintenance and diagnostic activities are carried out by individuals who are physically present at the location of the system and not communicating across a network connection. Authentication techniques used to establish nonlocal maintenance and diagnostic sessions reflect the requirements in 03.05.01.
nonlocal maintenance and diagnostic activities are approved.
nonlocal maintenance and diagnostic activities are monitored.
session connections are terminated when nonlocal maintenance is completed.
network connections are terminated when nonlocal maintenance is completed.
multi-factor authentication is implemented in the establishment of nonlocal maintenance and diagnostic sessions.
replay resistance is implemented in the establishment of nonlocal maintenance and diagnostic sessions.
maintenance policy and procedures
remote access policy and procedures
procedures for nonlocal system maintenance
records of remote access
maintenance records
diagnostic records
system design documentation
system configuration settings
system security plan
other relevant documents or records
personnel with system maintenance responsibilities
personnel with information security responsibilities
system administrators
processes for managing nonlocal maintenance
mechanisms for implementing, supporting, or managing nonlocal maintenance
mechanisms for implementing multi-factor authentication and replay resistance
mechanisms for terminating nonlocal maintenance sessions and network connections
Establish a process for maintenance personnel authorization.
Maintain a list of authorized maintenance organizations or personnel.
Verify that non-escorted personnel who perform maintenance on the system possess the required access authorizations.
Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.
Maintenance personnel refers to individuals who perform hardware or software maintenance on the system, while 03.10.01 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the system. The technical competence of supervising individuals relates to the maintenance performed on the system, while having required access authorizations refers to maintenance on and near the system. Individuals who have not been previously identified as authorized maintenance personnel (e.g., manufacturers, consultants, systems integrators, and vendors) may require privileged access to the system, such as when they are required to conduct maintenance with little or no notice. Organizations may choose to issue temporary credentials to these individuals based on their risk assessments. Temporary credentials may be for one-time use or for very limited time periods.
a process for maintenance personnel authorization is established.
a list of authorized maintenance organizations or personnel is maintained.
organizational personnel with required access authorizations are designated to supervise the maintenance activities of personnel who do not possess the required access authorizations.
organizational personnel with required technical competence are designated to supervise the maintenance activities of personnel who do not possess the required access authorizations.
non-escorted personnel who perform maintenance on the system possess the required access authorizations.
maintenance policy and procedures
service provider contracts
service-level agreements
list of authorized personnel
maintenance records
access control records
system security plan
other relevant documents or records
personnel with system maintenance responsibilities
personnel with information security responsibilities
processes for authorizing and managing maintenance personnel
mechanisms for supporting or implementing the authorization of maintenance personnel
Physically control and securely store system media that contain CUI.
System media include digital and non-digital media. Digital media include diskettes, flash drives, magnetic tapes, external or removable solid state or magnetic drives, compact discs, and digital versatile discs. Non-digital media include paper and microfilm. Physically controlling stored media includes conducting inventories, establishing procedures to allow individuals to check out and return media to libraries, and maintaining accountability for stored media. Secure storage includes a locked drawer, desk, or cabinet or a controlled media library. Controlled areas provide physical and procedural controls to meet the requirements established for protecting information and systems. Sanitization techniques (e.g., destroying, cryptographically erasing, clearing, and purging) prevent the disclosure of CUI to unauthorized individuals. The sanitization process removes CUI from media such that the information cannot be retrieved or reconstructed.
system media that contain CUI are physically controlled.
system media that contain CUI are securely stored.
physical protection policy and procedures
media protection policy and procedures
procedures for media storage
access control policy and procedures
system media
system security plan
other relevant documents or records
personnel with system media protection and storage responsibilities
personnel with information security responsibilities
processes for storing information media
mechanisms for supporting or implementing secure media storage/media protection
Restrict access to CUI on system media to authorized personnel or roles.
System media include digital and non-digital media. Access to CUI on system media can be restricted by physically controlling such media. This includes conducting inventories, ensuring that procedures are in place to allow individuals to check out and return media to the media library, and maintaining accountability for stored media. For digital media, access to CUI can be restricted by using cryptographic means. Encrypting data in storage or at rest is addressed in 03.13.08.
access to CUI on system media is restricted to authorized personnel or roles.
physical protection policy and procedures
media protection policy and procedures
procedures for media access restrictions
access control policy and procedures
media storage facilities
access control records
system security plan
other relevant documents or records
personnel with system media protection responsibilities
personnel with information security responsibilities
system administrators
processes for restricting information on media
mechanisms for supporting or implementing media access restrictions
Sanitize system media that contain CUI prior to disposal, release out of organizational control, or release for reuse.
Media sanitization applies to digital and non-digital media that are subject to disposal or reuse, whether or not the media are considered removable. Examples include digital media in scanners, copiers, printers, notebook computers, mobile devices, workstations, network components, and non-digital media. The sanitization process removes CUI from media such that the information cannot be retrieved or reconstructed. Sanitization techniques (e.g., cryptographically erasing, clearing, purging, and destroying) prevent the disclosure of CUI to unauthorized individuals when such media are reused or released for disposal. NARA policies control the sanitization process for media that contain CUI and may require destruction when other methods cannot be applied to the media.
system media that contain CUI are sanitized prior to disposal, release out of organizational control, or release for reuse.
media protection policy and procedures
procedures for media sanitization and disposal
applicable standards and policies that address media sanitization policy
system audit records
media sanitization records
system design documentation
system configuration settings
records retention and disposition policy
records retention and disposition procedures
system security plan
other relevant documents or records
personnel with media sanitization responsibilities
personnel with records retention and disposition responsibilities
personnel with information security responsibilities
system administrators
processes for media sanitization
mechanisms for supporting or implementing media sanitization
Mark system media that contain CUI to indicate distribution limitations, handling caveats, and applicable CUI markings.
System media include digital and non-digital media. Marking refers to the use or application of human-readable security attributes. Labeling refers to the use of security attributes for internal system data structures. Digital media include diskettes, magnetic tapes, external or removable solid state or magnetic drives, flash drives, compact discs, and digital versatile discs. Non-digital media include paper and microfilm. CUI is defined by NARA along with marking, safeguarding, and dissemination requirements for such information.
system media that contain CUI are marked to indicate distribution limitations.
system media that contain CUI are marked to indicate handling caveats.
system media that contain CUI are marked to indicate applicable CUI markings.
physical protection policy and procedures
media protection policy and procedures
procedures for media marking
list of system media marking security attributes
system security plan
other relevant documents or records
personnel with system media protection and marking responsibilities
personnel with information security responsibilities
processes for marking information media
mechanisms for supporting or implementing media marking
Protect and control system media that contain CUI during transport outside of controlled areas.
Maintain accountability of system media that contain CUI during transport outside of controlled areas.
Document activities associated with the transport of system media that contain CUI.
System media include digital and non-digital media. Digital media include flash drives, diskettes, magnetic tapes, external or removable solid state or magnetic drives, compact discs, and digital versatile discs. Non-digital media include microfilm and paper. Controlled areas are spaces for which organizations provide physical or procedural measures to meet the requirements established for protecting CUI and systems. Media protection during transport can include cryptography and/or locked containers. Activities associated with media transport include releasing media for transport, ensuring that media enter the appropriate transport processes, and the actual transport. Authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability of media during transport includes restricting transport activities to authorized personnel and tracking or obtaining the records of transport activities as the media move through the transportation system to prevent and detect loss, destruction, or tampering. This requirement is related to 03.13.08 and 03.13.11.
system media that contain CUI are protected during transport outside of controlled areas.
system media that contain CUI are controlled during transport outside of controlled areas.
activities associated with the transport of system media that contain CUI are documented.
accountability for system media that contain CUI is maintained during transport outside of controlled areas.
physical protection policy and procedures
media protection policy and procedures
procedures for media storage
access control policy and procedures
authorized personnel list
system media
designated controlled areas
system and communications protection policy and procedures
cryptographic mechanisms and configuration documentation
procedures for the protection of information at rest
system design documentation
system configuration settings
list of information at rest requiring confidentiality protections
system audit records
system security plan
other relevant documents or records
personnel with system media protection and storage responsibilities
personnel with information security responsibilities
system developers
system administrators
processes for storing information media
mechanisms for supporting or implementing media storage/media protection
mechanisms for supporting or implementing confidentiality protections for information at rest
organization-defined types of system media
types of system media with usage restrictions or that are prohibited from use are defined.
Restrict or prohibit the use of
Prohibit the use of removable system media without an identifiable owner.
In contrast to requirement 03.08.01, which restricts user access to media, this requirement restricts or prohibits the use of certain types of media, such as external hard drives, flash drives, or smart displays. Organizations can use technical and non-technical measures (e.g., policies, procedures, and rules of behavior) to control the use of system media. For example, organizations may control the use of portable storage devices by using physical cages on workstations to prohibit access to external ports or disabling or removing the ability to insert, read, or write to devices. Organizations may limit the use of portable storage devices to only approved devices, including devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Organizations may also control the use of portable storage devices based on the type of device — prohibiting the use of writeable, portable devices — and implement this restriction by disabling or removing the capability to write to such devices. Limits on the use of organization-controlled system media in external systems include restrictions on how the media may be used and under what conditions. Requiring identifiable owners (e.g., individuals, organizations, or projects) for removable system media reduces the risk of using such technologies by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the media (e.g., insertion of malicious code).
the use of the following types of system media is restricted or prohibited:
the use of removable system media without an identifiable owner is prohibited.
system media protection policy and procedures
system use policy
procedures for media usage restrictions
rules of behavior
system audit records
system design documentation
system configuration settings
system security plan
other relevant documents or records
personnel with system media use responsibilities
personnel with information security responsibilities
system administrators
processes for media use
mechanisms for restricting or prohibiting the use of system media on systems or system components
Protect the confidentiality of backup information.
Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI at backup storage locations.
The selection of cryptographic mechanisms is based on the need to protect the confidentiality of backup information. Hardware security module (HSM) devices safeguard and manage cryptographic keys and provide cryptographic processing. Cryptographic operations (e.g., encryption, decryption, and signature generation and verification) are typically hosted on the HSM device, and many implementations provide hardware-accelerated mechanisms for cryptographic operations. This requirement is related to 03.13.11.
cryptographic mechanisms are implemented to prevent the unauthorized disclosure of CUI at backup storage locations.
the confidentiality of backup information is protected.
contingency planning policy and procedures
procedures for system backup
contingency plan
system design documentation
system configuration settings
system security plan
other relevant documents or records
personnel with system backup responsibilities
personnel with information security responsibilities
mechanisms for supporting or implementing the cryptographic protection of backup information
organization-defined conditions requiring rescreening
conditions that require the rescreening of individuals are defined.
Screen individuals prior to authorizing access to the system.
Rescreen individuals in accordance with
Personnel security screening activities involve the assessment of the conduct, integrity, judgment, loyalty, reliability, and stability of an individual (i.e., the individual’s trustworthiness) prior to authorizing access to the system or when elevating system access. The screening and rescreening activities reflect applicable federal laws, Executive Orders, directives, policies, regulations, and criteria established for the level of access required for the assigned position.
individuals are screened prior to authorizing access to the system.
individuals are rescreened in accordance with the following conditions:
personnel security policy and procedures
procedures for personnel screening and rescreening
records of screened personnel
system security plan
other relevant documents or records
personnel with personnel security responsibilities
personnel with information security responsibilities
processes for personnel screening and rescreening
organization-defined time period
the time period within which to disable system access is defined.
When individual employment is terminated:
Disable system access within
Terminate or revoke authenticators and credentials associated with the individual, and
Retrieve security-related system property.
When individuals are reassigned or transferred to other positions in the organization:
Review and confirm the ongoing operational need for current logical and physical access authorizations to the system and facility, and
Modify access authorization to correspond with any changes in operational need.
Security-related system property includes hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that accountability is achieved for the organizational property. Security topics at exit interviews include reminding individuals of potential limitations on future employment and non-disclosure agreements. Exit interviews may not always be possible for some individuals, including in cases related to the unavailability of supervisors, illnesses, or job abandonment. The timely execution of termination actions is essential for individuals who have been terminated for cause. Organizations may consider disabling the accounts of individuals who are being terminated prior to the individuals being notified. This requirement applies to the reassignment or transfer of individuals when the personnel action is permanent or of such extended duration as to require protection. Protections that may be required for transfers or reassignments to other positions within organizations include returning old and issuing new identification cards, keys, and building passes; changing system access authorizations (i.e., privileges); closing system accounts and establishing new accounts; and providing access to official records to which individuals had access at previous work locations in previous system accounts.
upon termination of individual employment, system access is disabled within
upon termination of individual employment, authenticators associated with the individual are terminated or revoked.
upon termination of individual employment, credentials associated with the individual are terminated or revoked.
upon termination of individual employment, security-related system property is retrieved.
upon individual reassignment or transfer to other positions in the organization, access authorization is modified to correspond with any changes in operational need.
upon individual reassignment or transfer to other positions in the organization, the ongoing operational need for current logical and physical access authorizations to the system and facility is reviewed.
upon individual reassignment or transfer to other positions in the organization, the ongoing operational need for current logical and physical access authorizations to the system and facility is confirmed.
personnel security policy and procedures
procedures for personnel termination
records of personnel transfer actions
procedures for personnel transfer
list of system and facility access authorizations
records of personnel termination actions
records of terminated or revoked authenticators or credentials
list of system accounts
records of exit interviews
system security plan
other relevant documents or records
personnel with personnel security responsibilities
personnel with account management responsibilities
personnel with information security responsibilities
system administrators
processes for personnel termination
processes for personnel transfer
mechanisms for supporting or implementing personnel transfer notifications
mechanisms for supporting or implementing personnel termination notifications
mechanisms for disabling system access and revoking authenticators
organization-defined frequency
the frequency at which to review the access list detailing authorized facility access by individuals is defined.
Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides.
Issue authorization credentials for facility access.
Review the facility access list
Remove individuals from the facility access list when access is no longer required.
A facility can include one or more physical locations containing systems or system components that process, store, or transmit CUI. Physical access authorizations apply to employees and visitors. Individuals with permanent physical access authorization credentials are not considered visitors. Authorization credentials include identification badges, identification cards, and smart cards. Organizations determine the strength of the authorization credentials consistent with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. Physical access authorizations may not be necessary to access certain areas within facilities that are designated as publicly accessible.
a list of individuals with authorized access to the facility where the system resides is developed.
a list of individuals with authorized access to the facility where the system resides is approved.
a list of individuals with authorized access to the facility where the system resides is maintained.
the facility access list is reviewed
individuals from the facility access list are removed when access is no longer required.
authorization credentials for facility access are issued.
physical protection policy and procedures
procedures for physical access authorizations
authorized personnel access list
physical access list reviews
physical access termination records
authorization credentials
system security plan
other relevant documents or records
personnel with physical access authorization responsibilities
personnel with physical access to the facility where the system resides
personnel with information security responsibilities
processes for physical access authorizations
mechanisms for supporting or implementing physical access authorizations
organization-defined frequency
the frequency at which to review physical access logs is defined.
organization-defined events or potential indications of events
events or potential indications of events requiring physical access logs to be reviewed are defined.
Monitor physical access to the facility where the system resides to detect and respond to physical security incidents.
Review physical access logs
A facility can include one or more physical locations containing systems or system components that process, store, or transmit CUI. Physical access monitoring includes publicly accessible areas within organizational facilities. Examples of physical access monitoring include guards, video surveillance equipment (i.e., cameras), and sensor devices. Reviewing physical access logs can help to identify suspicious activities, anomalous events, or potential threats. The reviews can be supported by audit logging controls if the access logs are part of an automated system. Incident response capabilities include investigations of physical security incidents and responses to those incidents. Incidents include security violations or suspicious physical access activities, such as access outside of normal work hours, repeated access to areas not normally accessed, access for unusual lengths of time, and out-of-sequence access.
physical access to the facility where the system resides is monitored to detect physical security incidents.
physical security incidents are responded to.
physical access logs are reviewed
physical access logs are reviewed upon occurrence of
physical protection policy and procedures
procedures for physical access monitoring
physical access logs or records
physical access monitoring records
physical access log reviews
system security plan
other relevant documents or records
personnel with physical access monitoring responsibilities
personnel with incident response responsibilities
personnel with information security responsibilities
processes for monitoring physical access
mechanisms for supporting or implementing physical access monitoring
mechanisms for supporting or implementing the review of physical access logs
organization-defined security requirements
security requirements to be employed at alternate work sites are defined.
Determine alternate work sites allowed for use by employees.
Employ the following security requirements at alternate work sites:
Alternate work sites include the private residences of employees or other facilities designated by the organization. Alternate work sites can provide readily available alternate locations during contingency operations. Organizations can define different security requirements for specific alternate work sites or types of sites, depending on the work-related activities conducted at the sites. Assessing the effectiveness of the requirements and providing a means to communicate incidents at alternate work sites supports the contingency planning activities of organizations.
alternate work sites allowed for use by employees are determined.
the following security requirements are employed at alternate work sites:
physical protection policy and procedures
procedures for alternate work sites for personnel
list of security requirements for alternate work sites
assessments of security requirements at alternate work sites
system security plan
other relevant documents or records
personnel approving the use of alternate work sites
personnel using alternate work sites
personnel assessing security requirements at alternate work sites
personnel with information security responsibilities
processes for security at alternate work sites
mechanisms for supporting alternate work sites
security requirements employed at alternate work sites
means of communication between personnel at alternate work sites and security personnel
Enforce physical access authorizations at entry and exit points to the facility where the system resides by:
Verifying individual physical access authorizations before granting access to the facility and
Controlling ingress and egress with physical access control systems, devices, or guards.
Maintain physical access audit logs for entry or exit points.
Escort visitors, and control visitor activity.
Secure keys, combinations, and other physical access devices.
Control physical access to output devices to prevent unauthorized individuals from obtaining access to CUI.
This requirement addresses physical locations containing systems or system components that process, store, or transmit CUI. Organizations determine the types of guards needed, including professional security staff or administrative staff. Physical access devices include keys, locks, combinations, biometric readers, and card readers. Physical access control systems comply with applicable laws, Executive Orders, directives, policies, regulations, standards, and guidelines. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural, automated, or some combination thereof. Physical access points can include exterior access points, interior access points to systems that require supplemental access controls, or both. Physical access control applies to employees and visitors. Individuals with permanent physical access authorizations are not considered visitors. Controlling physical access to output devices includes placing output devices in locked rooms or other secured areas with keypad or card reader access controls and only allowing access to authorized individuals, placing output devices in locations that can be monitored by personnel, installing monitor or screen filters, and using headphones. Examples of output devices include monitors, printers, scanners, facsimile machines, audio devices, and copiers.
physical access authorizations are enforced at entry and exit points to the facility where the system resides by verifying individual physical access authorizations before granting access.
physical access authorizations are enforced at entry and exit points to the facility where the system resides by controlling ingress and egress with physical access control systems, devices, or guards.
physical access audit logs for entry or exit points are maintained.
visitors are escorted.
visitor activity is controlled.
physical access to output devices is controlled to prevent unauthorized individuals from obtaining access to CUI.
keys, combinations, and other physical access devices are secured.
physical protection policy and procedures
procedures for physical access control
physical access control logs or records
inventory records of physical access control devices
system entry and exit points
records of key and lock combination changes
storage locations for physical access control devices
physical access control devices
list of security safeguards controlling access to designated publicly accessible areas within facility
system security plan
other relevant documents or records
personnel with physical access control responsibilities
personnel with information security responsibilities
processes for physical access control
mechanisms for supporting or implementing physical access control
physical access control devices
Control physical access to system distribution and transmission lines within organizational facilities.
Safeguarding measures applied to system distribution and transmission lines prevent accidental damage, disruption, and physical tampering. Such measures may also be necessary to prevent eavesdropping or the modification of unencrypted transmissions. Safeguarding measures used to control physical access to system distribution and transmission lines include disconnected or locked spare jacks, locked wiring closets, cabling protection with conduit or cable trays, and wiretapping sensors.
physical access to system distribution and transmission lines within organizational facilities is controlled.
physical protection policy and procedures
procedures for access control for transmission mediums
system design documentation
facility communications and wiring diagrams
list of physical security safeguards applied to system distribution and transmission lines
procedures for access control for display medium
facility layout of system components
list of output devices and associated outputs that require physical access controls
actual displays from system components
physical access control logs or records for areas containing output devices and related outputs
system security plan
other relevant documents or records
personnel with physical access control responsibilities
personnel with information security responsibilities
processes for access control for distribution and transmission lines
mechanisms for supporting or implementing access control for distribution and transmission lines
processes for access control to output devices
mechanisms for supporting or implementing access control for output devices
organization-defined frequency
the frequency at which to update the risk assessment is defined.
Assess the risk (including supply chain risk) of unauthorized disclosure resulting from the processing, storage, or transmission of CUI.
Update risk assessments
Establishing the system boundary is a prerequisite to assessing the risk of the unauthorized disclosure of CUI. Risk assessments consider threats, vulnerabilities, likelihood, and adverse impacts to organizational operations and assets based on the operation and use of the system and the unauthorized disclosure of CUI. Risk assessments also consider risks from external parties (e.g., contractors operating systems on behalf of the organization, service providers, individuals accessing systems, and outsourcing entities). Risk assessments can be conducted at the organization level, the mission or business process level, or the system level and at any phase in the system development life cycle. Risk assessments include supply chain-related risks associated with suppliers or contractors and the system, system component, or system service that they provide.
the risk (including supply chain risk) of unauthorized disclosure resulting from the processing, storage, or transmission of CUI is assessed.
risk assessments are updated
risk assessment policy and procedures
security planning policy and procedures
procedures for organizational assessments of risk
risk assessment
risk assessment results
risk assessment reviews
risk assessment updates
SCRM policy and procedures
inventory of critical systems, system components, and system services
procedures for organizational assessments of supply chain risk
acquisition policy
SCRM plan
system security plan
other relevant documents or records
personnel with risk assessment responsibilities
personnel with SCRM responsibilities
personnel with security responsibilities
processes for organizational risk assessments
mechanisms for supporting or conducting, documenting, reviewing, disseminating, and updating risk assessments
mechanisms for supporting or conducting, documenting, reviewing, disseminating, and updating supply chain risk assessments
organization-defined frequency
the frequency at which the system is monitored for vulnerabilities is defined.
organization-defined frequency
the frequency at which the system is scanned for vulnerabilities is defined.
organization-defined response times
response times to remediate system vulnerabilities are defined.
organization-defined frequency
the frequency at which to update system vulnerabilities to be scanned is defined.
Monitor and scan the system for vulnerabilities
Remediate system vulnerabilities within
Update system vulnerabilities to be scanned
Organizations determine the required vulnerability scanning for system components and ensure that potential sources of vulnerabilities (e.g., networked printers, scanners, and copiers) are not overlooked. Vulnerability analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, or binary analysis. Organizations can use these approaches in source code reviews and tools (e.g., static analysis tools, web-based application scanners, binary analyzers). Vulnerability scanning includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for improperly configured or incorrectly operating flow control mechanisms. To facilitate interoperability, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention. Sources for vulnerability information also include the Common Weakness Enumeration (CWE) listing, the National Vulnerability Database (NVD), and the Common Vulnerability Scoring System (CVSS).
the system is monitored for vulnerabilities
the system is scanned for vulnerabilities
system vulnerabilities are remediated within
the system is monitored for vulnerabilities when new vulnerabilities that affect the system are identified.
the system is scanned for vulnerabilities when new vulnerabilities that affect the system are identified.
system vulnerabilities to be scanned are updated
system vulnerabilities to be scanned are updated when new vulnerabilities are identified and reported.
risk assessment policy and procedures
procedures for vulnerability scanning
patch and vulnerability management records
vulnerability scanning tools and configuration documentation
vulnerability scanning results
risk assessment
risk assessment report
system security plan
other relevant documents or records
personnel with risk assessment and vulnerability scanning responsibilities
personnel with vulnerability scan analysis responsibilities
personnel with vulnerability remediation responsibilities
personnel with information security responsibilities
system administrators
processes for vulnerability monitoring, scanning, analysis, and remediation
mechanisms for supporting or implementing vulnerability monitoring, scanning, analysis, and remediation
Respond to findings from security assessments, monitoring, and audits.
This requirement addresses the need to determine an appropriate response to risk before generating a plan of action and milestones (POAM) entry. It may be possible to mitigate the risk immediately so that a POAM entry is not needed. However, a POAM entry is generated if the risk response is to mitigate the identified risk and the mitigation cannot be completed immediately.
findings from security assessments are responded to.
findings from security monitoring are responded to.
findings from security audits are responded to.
risk assessment policy
assessment reports
system audit records
event logs
system security plan
other relevant documents or records
personnel with assessment and auditing responsibilities
system administrators
personnel with security responsibilities
processes for assessments and audits
mechanisms and tools supporting or implementing assessments and auditing
organization-defined frequency
the frequency at which to assess the security requirements for the system and its environment of operation is defined.
Assess the security requirements for the system and its environment of operation
By assessing the security requirements, organizations determine whether the necessary safeguards and countermeasures are implemented correctly, operating as intended, and producing the desired outcome. Security assessments identify weaknesses in the system and provide the essential information needed to make risk-based decisions. Security assessment reports document assessment results in sufficient detail as deemed necessary by the organization to determine the accuracy and completeness of the reports. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted.
the security requirements for the system and its environment of operation are
assessed
security assessment and monitoring policy and procedures
procedures for security assessment planning
security assessment plan
security assessment report
system security plan
other relevant documents or records
personnel with security assessment responsibilities
personnel with information security responsibilities
mechanisms for supporting security assessments, processes for security assessment plan development, or security assessment reporting
Develop a plan of action and milestones for the system:
To document the planned remediation actions to correct weaknesses or deficiencies noted during security assessments and
To reduce or eliminate known system vulnerabilities.
Update the existing plan of action and milestones based on the findings from:
Security assessments,
Audits or reviews, and
Continuous monitoring activities.
Plans of action and milestones (POAMs) are important documents in organizational security programs. Organizations use POAMs to describe how unsatisfied security requirements will be met and how planned mitigations will be implemented. Organizations can document system security plans and POAMs as separate or combined documents in any format. Federal agencies may consider system security plans and POAMs as inputs to risk-based decisions on whether to process, store, or transmit CUI on a system hosted by a nonfederal organization.
a plan of action and milestones for the system is developed to document the planned remediation actions for correcting weaknesses or deficiencies noted during security assessments.
a plan of action and milestones for the system is developed to reduce or eliminate known system vulnerabilities.
the existing plan of action and milestones is updated based on the findings from security assessments.
the existing plan of action and milestones is updated based on the findings from continuous monitoring activities.
the existing plan of action and milestones is updated based on the findings from audits or reviews.
security assessment and monitoring policy and procedures
procedures for plans of action and milestones
security assessment plan
security assessment report
security assessment evidence
plan of action and milestones
system security plan
other relevant documents or records
personnel with plans of action and milestones development and implementation responsibilities
personnel with information security responsibilities
mechanisms for developing, implementing, and maintaining plans of action and milestones
Develop and implement a system-level continuous monitoring strategy that includes ongoing monitoring and security assessments.
Continuous monitoring at the system level facilitates ongoing awareness of the system security posture to support risk management decisions. The terms continuous and ongoing imply that organizations assess and monitor their systems at a frequency that is sufficient to support risk-based decisions. Different types of security requirements may require different monitoring frequencies.
a system-level continuous monitoring strategy is developed.
a system-level continuous monitoring strategy is implemented.
ongoing monitoring is included in the continuous monitoring strategy.
security assessments are included in the continuous monitoring strategy.
security assessment and monitoring policy and procedures
organizational continuous monitoring strategy
system-level continuous monitoring strategy
procedures for continuous monitoring of the system
procedures for configuration management
security assessment report
plan of action and milestones
system monitoring records
configuration management records
impact analyses
status reports
system security plan
other relevant documents or records
personnel with continuous monitoring responsibilities
personnel with information security responsibilities
system administrators
mechanisms for implementing continuous monitoring
mechanisms for supporting response actions for assessment and monitoring results
mechanisms for supporting security status reporting
organization-defined frequency
the frequency at which to review and update agreements is defined.
Approve and manage the exchange of CUI between the system and other systems
using
Document interface characteristics, security requirements, and responsibilities for each system as part of the exchange agreements.
Review and update the exchange agreements
Information exchange applies to information exchanges between two or more systems, both internal and external to the organization. Organizations consider the risks related to new or increased threats that may be introduced when systems exchange information with other systems that may have different security requirements or policies. The types of agreements selected are based on factors such as the relationship between the organizations exchanging information (e.g., government to government, business to business, government to business, government or business, or government or business to individual) and the level of access to the organizational system by users of the other system. The types of agreements can include information exchange security agreements, interconnection security agreements, memoranda of understanding or agreement, service-level agreements, or other types of agreements. Organizations may incorporate agreement information into formal contracts, especially for information exchanges established between federal agencies and nonfederal organizations (e.g., service providers, contractors, system developers, and system integrators). The types of information contained in exchange agreements include the interface characteristics, security requirements, controls, and responsibilities for each system.
the exchange of CUI between the system and other systems is approved using
the exchange of CUI between the system and other systems is managed using
interface characteristics for each system are documented as part of the exchange agreements.
security requirements for each system are documented as part of the exchange agreements.
responsibilities for each system are documented as part of the exchange agreements.
exchange agreements are reviewed
exchange agreements are updated
access control policy and procedures
procedures for system connections
system and communications protection policy and procedures
system interconnection security agreements
information exchange security agreements
service-level agreements
memoranda of understanding or agreements
non-disclosure agreements
system design documentation
enterprise architecture
security architecture
system configuration settings
system security plan
other relevant documents or records
personnel with development, implementation, and approval responsibilities for system interconnection agreements
personnel who manage systems to which the exchange agreements apply
personnel with information security responsibilities
Monitor and control communications at external managed interfaces to the system and key internal managed interfaces within the system.
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
Connect to external systems only through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.
Managed interfaces include gateways, routers, firewalls, network-based malicious code analysis, virtualization systems, and encrypted tunnels implemented within a security architecture. Subnetworks that are either physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses.
communications at external managed interfaces to the system are monitored.
communications at external managed interfaces to the system are controlled.
communications at key internal managed interfaces within the system are monitored.
communications at key internal managed interfaces within the system are controlled.
subnetworks are implemented for publicly accessible system components that are physically or logically separated from internal networks.
external system connections are only made through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.
system and communications protection policy and procedures
procedures for boundary protection
list of key internal boundaries within the system
boundary protection hardware and software
system configuration settings
security architecture
system audit records
system design documentation
system security plan
other relevant documents or records
personnel with boundary protection responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing boundary protection capabilities
Prevent unauthorized and unintended information transfer via shared system resources.
Preventing unauthorized and unintended information transfer via shared system resources stops information produced by the actions of prior users or roles (or actions of processes acting on behalf of prior users or roles) from being available to current users or roles (or current processes acting on behalf of current users or roles) that obtain access to shared system resources after those resources have been released back to the system. Information in shared system resources also applies to encrypted representations of information. In other contexts, the control of information in shared system resources is referred to as object reuse and residual information protection. Information in shared system resources does not address information remanence, which refers to the residual representation of data that has been nominally deleted, covert channels (including storage and timing channels) in which shared system resources are manipulated to violate information flow restrictions, or components within systems for which there are only single users or roles.
unauthorized information transfer via shared system resources is prevented.
unintended information transfer via shared system resources is prevented.
system and communications protection policy and procedures
procedures for information protection in shared system resources
system configuration settings
system audit records
system design documentation
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for preventing the unauthorized and unintended transfer of information via shared system resources
Deny network communications traffic by default, and allow network communications traffic by exception.
This requirement applies to inbound and outbound network communications traffic at the system boundary and at identified points within the system. A deny-all, allow-by-exception network communications traffic policy ensures that only essential and approved connections are allowed.
network communications traffic is denied by default.
network communications traffic is allowed by exception.
system and communications protection policy and procedures
procedures for boundary protection
system design documentation
system configuration settings
system audit records
system security plan
other relevant documents or records
personnel with boundary protection responsibilities
personnel with information security responsibilities
system developers
system administrators
mechanisms for implementing traffic management at managed interfaces
Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI during transmission and while in storage.
This requirement applies to internal and external networks and any system components that can transmit CUI, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are susceptible to interception and modification. Encryption protects CUI from unauthorized disclosure during transmission and while in storage. Cryptographic mechanisms that protect the confidentiality of CUI during transmission include TLS and IPsec. Information in storage (i.e., information at rest) refers to the state of CUI when it is not in process or in transit and resides on internal or external storage devices, storage area network devices, and databases. Protecting CUI in storage does not focus on the type of storage device or the frequency of access to that device but rather on the state of the information. This requirement relates to 03.13.11.
cryptographic mechanisms are implemented to prevent the unauthorized disclosure of CUI during transmission.
cryptographic mechanisms are implemented to prevent the unauthorized disclosure of CUI while in storage.
system and communications protection policy and procedures
procedures for transmission confidentiality
procedures for the protection of information at rest
system design documentation
system configuration settings
cryptographic mechanisms and associated configuration documentation
information in storage requiring confidentiality protection
system audit records
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing transmission confidentiality
cryptographic mechanisms for supporting or implementing transmission confidentiality
mechanisms for supporting or implementing confidentiality protection for information in storage
cryptographic mechanisms for implementing confidentiality protections for information in storage
organization-defined time period
the time period of inactivity after which the system terminates a network connection associated with a communications session is defined.
Terminate the network connection associated with a communications session at the
end of the session or after
This requirement applies to internal and external networks. Terminating network connections associated with communications sessions includes deallocating TCP/IP addresses or port pairs at the operating system level or deallocating networking assignments at the application level if multiple application sessions are using a single network connection. Time periods of inactivity may be established by organizations and include time periods by type of network access or for specific network accesses.
the network connection associated with a communications session is terminated at
the end of the session or after
system and communications protection policy and procedures
procedures for network disconnect
system design documentation
system configuration settings
system audit records
system security plan
other relevant documents or records
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing a network disconnect capability
organization-defined requirements for key generation, distribution, storage, access, and destruction
requirements for key generation, distribution, storage, access, and destruction are defined.
Establish and manage cryptographic keys in the system in accordance with the
following key management requirements:
Cryptographic keys can be established and managed using either manual procedures or automated mechanisms supported by manual procedures. Organizations satisfy key establishment and management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards that specify appropriate options, levels, and parameters. This requirement is related to 03.13.11.
cryptographic keys are established in the system in accordance with the following
key management requirements:
cryptographic keys are managed in the system in accordance with the following key
management requirements:
system and communications protection policy and procedures
procedures for cryptographic key establishment and management
system design documentation
system configuration settings
cryptographic mechanisms
system audit records
system security plan
other relevant documents or records
personnel with responsibilities for cryptographic key establishment or management
personnel with information security responsibilities
system administrators
mechanisms for supporting or implementing cryptographic key establishment and management
organization-defined types of cryptography
the types of cryptography for protecting the confidentiality of CUI are defined.
Implement the following types of cryptography to protect the confidentiality of
CUI:
Cryptography is implemented in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines. FIPS-validated cryptography is recommended for the protection of CUI.
the following types of cryptography are implemented to protect the
confidentiality of CUI:
system and communications protection policy and procedures
procedures for cryptographic protection
system design documentation
system configuration settings
cryptographic module validation certificates
list of FIPS-validated cryptographic modules
system audit records
system security plan
other relevant documents or records
personnel with responsibilities for cryptographic protection
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing cryptographic protection
organization-defined exceptions where remote activation is to be allowed
exceptions where remote activation is to be allowed are defined.
Prohibit the remote activation of collaborative computing devices and
applications with the following exceptions:
Provide an explicit indication of use to users physically present at the devices.
Collaborative computing devices include white boards, microphones, and cameras. Notebook computers, smartphones, display monitors, and tablets containing cameras and microphones are considered part of collaborative computing devices when conferencing software is in use. Indication of use includes notifying users (e.g., a pop-up menu stating that recording is in progress or that the microphone has been turned on) when collaborative computing devices are activated. Dedicated video conferencing systems, which typically rely on one of the participants calling or connecting to the other party to activate the video conference, are excluded. Solutions to prevent device usage include webcam covers and buttons to disable microphones.
the remote activation of collaborative computing devices and applications is
prohibited with the following exceptions:
an explicit indication of use is provided to users who are physically present at the devices.
system and communications protection policy and procedures
procedures for collaborative computing
access control policy and procedures
system configuration settings
system design documentation
system audit records
system security plan
other relevant documents or records
personnel with responsibilities for managing collaborative computing devices
personnel with information security responsibilities
system developers
system administrators
mechanisms for supporting or implementing the management of remote activation of collaborative computing devices
mechanisms for providing an indication of use of collaborative computing devices
Define acceptable mobile code and mobile code technologies.
Authorize, monitor, and control the use of mobile code.
Mobile code includes software programs or parts of programs that are obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient. Decisions regarding the use of mobile code are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include Java applets, JavaScript, HTML5, VBScript, and WebGL. Usage restrictions and implementation guidelines apply to the selection and use of mobile code installed on servers and downloaded and executed on individual workstations and devices, including notebook computers, smart phones, and smart devices. Mobile code policies and procedures address the actions taken to prevent the development, acquisition, and use of unacceptable mobile code within the system, including requiring mobile code to be digitally signed by a trusted source.
the use of mobile code is authorized.
the use of mobile code is monitored.
the use of mobile code is controlled.
acceptable mobile code is defined.
acceptable mobile code technologies are defined.
system and communications protection policy and procedures
procedures for mobile code
mobile code implementation policy and procedures
list of acceptable mobile code and mobile code technologies
authorization records
system monitoring records
system audit records
system security plan
other relevant documents or records
personnel with responsibilities for managing mobile code
personnel with information security responsibilities
system administrators
processes for authorizing, monitoring, and controlling mobile code
mechanisms for supporting or implementing the management of mobile code
mechanisms for supporting or implementing mobile code monitoring
Protect the authenticity of communications sessions.
Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of the communications sessions in the ongoing identities of other parties and the validity of the transmitted information. Authenticity protection includes protecting against adversary-in-the-middle attacks, session hijacking, and the insertion of false information into sessions.
the authenticity of communications sessions is protected.
system and communications protection policy and procedures
procedures for session authenticity
system design documentation
system configuration settings
system audit records
system security plan
other relevant documents or records
personnel with information security responsibilities
system administrators
mechanisms for supporting or implementing session authenticity
organization-defined time period
the time period within which to install security-relevant software updates after the release of the updates is defined.
organization-defined time period
the time period within which to install security-relevant firmware updates after the release of the updates is defined.
Identify, report, and correct system flaws.
Install security-relevant software and firmware updates within
Organizations identify systems that are affected by announced software and firmware flaws, including potential vulnerabilities that result from those flaws, and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address the flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources (e.g., CWE or CVE databases) when remediating system flaws. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors, including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types.
system flaws are identified.
system flaws are reported.
system flaws are corrected.
security-relevant software updates are installed within
security-relevant firmware updates are installed within
system and information integrity policy and procedures
procedures for flaw remediation
procedures for configuration management
list of recent security flaw remediation actions performed on the system
list of flaws and vulnerabilities that may potentially affect the system
test results from the installation of software and firmware updates to correct system flaws
installation and change control records for security-relevant software and firmware updates
system security plan
other relevant documents or records
personnel responsible for installing, configuring, or maintaining the system
personnel responsible for flaw remediation
personnel with configuration management responsibilities
personnel with information security responsibilities
system administrators
processes for identifying, reporting, and correcting system flaws
processes for installing software and firmware updates
mechanisms for supporting or implementing the reporting and correction of system flaws
mechanisms for supporting or implementing the testing software and firmware updates
organization-defined frequency
the frequency at which malicious code protection mechanisms perform scans is defined.
Implement malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code.
Update malicious code protection mechanisms as new releases are available in accordance with configuration management policies and procedures.
Configure malicious code protection mechanisms to:
Perform scans of the system
Block malicious code, quarantine malicious code, or take other mitigation actions in response to malicious code detection.
Malicious code insertions occur through the exploitation of system vulnerabilities. Malicious code can be inserted into the system in a variety of ways, including email, the internet, and portable storage devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can be encoded in various formats, contained in compressed or hidden files, or hidden in files using techniques such as steganography. Malicious code may be present in commercial off-the-shelf software and custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions. Periodic scans of the system and real-time scans of files from external sources as files are downloaded, opened, or executed can detect malicious code. Malicious code protection mechanisms can also monitor systems for anomalous or unexpected behaviors and take appropriate actions. Malicious code protection mechanisms include signature- and non-signature-based technologies. Non-signature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Non-signature-based mechanisms include reputation-based technologies. Pervasive configuration management, anti-exploitation software, and software integrity controls may also be effective in preventing unauthorized code execution. If malicious code cannot be detected by detection methods or technologies, organizations can rely on secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to help ensure that the software only performs intended functions. Organizations may determine that different actions are warranted in response to the detection of malicious code. For example, organizations can define actions to be taken in response to the detection of malicious code during scans, malicious downloads, or malicious activity when attempting to open or execute files.
malicious code protection mechanisms are implemented at system entry and exit points to detect malicious code.
malicious code protection mechanisms are implemented at system entry and exit points to eradicate malicious code.
malicious code protection mechanisms are updated as new releases are available in accordance with configuration management policy and procedures.
malicious code protection mechanisms are configured to perform scans of the
system
malicious code protection mechanisms are configured to block malicious code, quarantine malicious code, or take other actions in response to malicious code detection.
malicious code protection mechanisms are configured to perform real-time scans of files from external sources at endpoints or system entry and exit points as the files are downloaded, opened, or executed.
system and information integrity policy and procedures
configuration management policy and procedures
procedures for malicious code protection
records of malicious code protection updates
system design documentation
system configuration settings
scan results from malicious code protection mechanisms
record of actions initiated by malicious code protection mechanisms in response to malicious code detection
system audit records
system security plan
other relevant documents or records
personnel responsible for malicious code protection
personnel with system installation, configuration, or maintenance responsibilities
personnel with information security responsibilities
system administrators
processes for employing, updating, and configuring malicious code protection mechanisms
processes for addressing the detection of false positives and resulting potential impacts
mechanisms for supporting or implementing, employing, updating, and configuring malicious code protection mechanisms
mechanisms for supporting or implementing malicious code scanning and the execution of subsequent actions
Receive system security alerts, advisories, and directives from external organizations on an ongoing basis.
Generate and disseminate internal system security alerts, advisories, and directives, as necessary.
There are many publicly available sources of system security alerts and advisories. The Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) generate security alerts and advisories to maintain situational awareness across the Federal Government and in nonfederal organizations. Software vendors, subscription services, and industry Information Sharing and Analysis Centers (ISACs) may also provide security alerts and advisories. Compliance with security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner.
system security alerts, advisories, and directives from external organizations are received on an ongoing basis.
internal security alerts, advisories, and directives are generated, as necessary.
internal security alerts, advisories, and directives are disseminated, as necessary.
Monitor the system to detect:
Attacks and indicators of potential attacks and
Unauthorized connections.
Identify unauthorized use of the system.
Monitor inbound and outbound communications traffic to detect unusual or unauthorized activities or conditions.
System monitoring involves external and internal monitoring. Internal monitoring includes the observation of events that occur within the system. External monitoring includes the observation of events that occur at the system boundary. Organizations can monitor the system by observing audit record activities in real time or by observing other system aspects, such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. A system monitoring capability is achieved through a variety of tools and techniques (e.g., audit record monitoring software, intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, network monitoring software). Strategic locations for monitoring devices include selected perimeter locations and near server farms that support critical applications with such devices being employed at managed system interfaces. The granularity of monitoring the information collected is based on organizational monitoring objectives and the capability of the system to support such objectives. Systems connections can be network, remote, or local. A network connection is any connection with a device that communicates through a network (e.g., local area network, the internet). A remote connection is any connection with a device that communicates through an external network (e.g., the internet). Network, remote, and local connections can be either wired or wireless. Unusual or unauthorized activities or conditions related to inbound and outbound communications traffic include internal traffic that indicates the presence of malicious code in the system or propagating among system components, the unauthorized export of information, or signaling to external systems. Evidence of malicious code is used to identify a potentially compromised system. System monitoring requirements, including the need for types of system monitoring, may be referenced in other requirements.
the system is monitored to detect attacks.
the system is monitored to detect indicators of potential attacks.
the system is monitored to detect unauthorized connections.
unauthorized use of the system is identified.
inbound communications traffic is monitored to detect unusual or unauthorized activities or conditions.
outbound communications traffic is monitored to detect unusual or unauthorized activities or conditions.
system and information integrity policy and procedures
procedures for system monitoring tools and techniques
continuous monitoring strategy
facility diagram or layout
system design documentation
locations within the system where monitoring devices are deployed
system configuration settings
system protocols
system audit records
system security plan
other relevant documents or records
personnel with responsibilities for installing, configuring, or maintaining the system
personnel with system monitoring responsibilities
personnel with intrusion detection responsibilities
personnel with information security responsibilities
system administrators
processes for intrusion detection and system monitoring
mechanisms for supporting or implementing system monitoring capabilities
mechanisms for supporting or implementing intrusion detection and system monitoring capabilities
mechanisms for supporting or implementing the monitoring of inbound and outbound communications traffic
Manage and retain CUI within the system and CUI output from the system in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
Federal agencies consider data retention requirements for nonfederal organizations. Retaining CUI on nonfederal systems after contracts or agreements have concluded increases the attack surface for those systems and the risk of the information being compromised. NARA provides federal policy and guidance on records retention and schedules.
CUI within the system is managed in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
CUI within the system is retained in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
CUI output from the system is managed in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
CUI output from the system is retained in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements.
system and information integrity policy and procedures
laws, Executive Orders, directives, policies, regulations, standards, and operational requirements applicable to information management and retention
records retention and disposition policy
records retention and disposition procedures
media protection policy
media protection procedures
audit findings
system security plan
other relevant documents or records
personnel with information and records management, retention, and disposition responsibilities
personnel with information security responsibilities
system administrators
processes for information management, retention, and disposition
mechanisms for supporting or implementing information management, retention, and disposition
organization-defined frequency
the frequency at which the policies and procedures for satisfying security requirements are reviewed and updated is defined.
Develop, document, and disseminate to organizational personnel or roles the policies and procedures needed to satisfy the security requirements for the protection of CUI.
Review and update policies and procedures
This requirement addresses policies and procedures for the protection of CUI. Policies and procedures contribute to security assurance and should address each family of the CUI security requirements. Policies can be included as part of the organizational security policy or be represented by separate policies that address each family of security requirements. Procedures describe how policies are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security plans or in one or more separate documents.
policies needed to satisfy the security requirements for the protection of CUI are developed and documented.
policies needed to satisfy the security requirements for the protection of CUI are disseminated to organizational personnel or roles.
procedures needed to satisfy the security requirements for the protection of CUI are developed and documented.
procedures needed to satisfy the security requirements for the protection of CUI are disseminated to organizational personnel or roles.
policies and procedures are reviewed
policies and procedures are updated
security policies and procedures associated with the protection of CUI
audit findings
system security plan
other relevant documents or records
personnel with information security responsibilities
organization-defined frequency
the frequency at which the system security plan is reviewed and updated is defined.
Develop a system security plan that:
Defines the constituent system components;
Identifies the information types processed, stored, and transmitted by the system;
Describes specific threats to the system that are of concern to the organization;
Describes the operational environment for the system and any dependencies on or connections to other systems or system components;
Provides an overview of the security requirements for the system;
Describes the safeguards in place or planned for meeting the security requirements;
Identifies individuals that fulfill system roles and responsibilities; and
Includes other relevant information necessary for the protection of CUI.
Review and update the system security plan
Protect the system security plan from unauthorized disclosure.
System security plans provide key characteristics of the system that is processing, storing, and transmitting CUI and how the system and information are protected. System security plans contain sufficient information to enable a design and implementation that are unambiguously compliant with the intent of the plans and the subsequent determinations of risk if the plan is implemented as intended. System security plans can be a collection of documents, including documents that already exist. Effective system security plans reference policies, procedures, and documents (e.g., design specifications) that provide additional detailed information. This reduces the documentation requirements associated with security programs and maintains security information in other established management or operational areas related to enterprise architecture, the system development life cycle, systems engineering, and acquisition.
a system security plan that defines the constituent system components is developed.
a system security plan that identifies the information types processed, stored, and transmitted by the system is developed.
a system security plan that describes specific threats to the system that are of concern to the organization is developed.
a system security plan that describes the operational environment for the system and any dependencies on or connections to other systems or system components is developed.
a system security plan that provides an overview of the security requirements for the system is developed.
a system security plan that describes the safeguards in place or planned for meeting the security requirements is developed.
a system security plan that identifies individuals that fulfill system roles and responsibilities is developed.
a system security plan that includes other relevant information necessary for the protection of CUI is developed.
the system security plan is reviewed
the system security plan is updated
the system security plan is protected from unauthorized disclosure.
security planning policy and procedures
procedures for system security plan development and implementation
procedures for system security plan reviews and updates
enterprise architecture
system security plan
records of system security plan reviews and updates
risk assessments
risk assessment results
security architecture and design documentation
other relevant documents or records
personnel with system security planning and plan implementation responsibilities
system developers
personnel with information security responsibilities
processes for system security plan development, review, update, and approval
organization-defined frequency
the frequency at which the rules of behavior are reviewed and updated is defined.
Establish rules that describe the responsibilities and expected behavior for system usage and protecting CUI.
Provide rules to individuals who require access to the system.
Receive a documented acknowledgement from individuals indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to CUI and the system.
Review and update the rules of behavior
Rules of behavior represent a type of access agreement for system users. Organizations consider rules of behavior for the handling of CUI based on individual user roles and responsibilities and differentiate between rules that apply to privileged users and rules that apply to general users.
rules that describe responsibilities and expected behavior for system usage and protecting CUI are established.
rules are provided to individuals who require access to the system.
a documented acknowledgement from individuals indicating that they have read, understand, and agree to abide by the rules of behavior is received before authorizing access to CUI and the system.
the rules of behavior are updated
the rules of behavior are reviewed
security planning policy and procedures
rules of behavior for system users
signed acknowledgements of rules of behavior
records for rules of behavior reviews and updates
system security plan
other relevant documents or records
personnel with rules of behavior establishment, review, and update responsibilities
personnel with literacy training and awareness responsibilities
personnel with role-based training responsibilities
authorized users of the system who have signed rules of behavior
personnel with information security responsibilities
processes for establishing, reviewing, disseminating, and updating rules of behavior
mechanisms for supporting or implementing the establishment, dissemination, review, and update of rules of behavior
organization-defined systems security engineering principles
systems security engineering principles to be applied to the development or modification of the system and system components are defined.
Apply the following systems security engineering principles to the development or
modification of the system and system components:
Organizations apply systems security engineering principles to new development systems. For legacy systems, organizations apply systems security engineering principles to system modifications to the extent feasible, given the current state of hardware, software, and firmware components. The application of systems security engineering principles helps to develop trustworthy, secure, and resilient systems and reduce the susceptibility of organizations to disruptions, hazards, and threats. Examples include developing layered protections; establishing security policies, architectures, and controls as the foundation for system design; incorporating security requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build trustworthy secure software; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk. Organizations that apply security engineering principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risks to acceptable levels; and make informed risk-management decisions.
system and services acquisition policy
system and services acquisition procedures
procedures addressing security engineering principles used in the development and modification of the system
system design documentation
security requirements and specifications for the system
system security plan
other relevant documents or records
personnel with acquisition/contracting responsibilities
personnel with information security responsibilities
personnel with system development and modification responsibilities
system developers
processes for applying security engineering principles in system development and modification
mechanisms supporting the application of security engineering principles in system development and modification
Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer.
Provide options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced.
Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in opportunities for adversaries to exploit weaknesses or deficiencies in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities when newer technologies are unavailable or when the systems are so isolated that installing replacement components is not an option. Alternative sources of support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational missions and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or obtain the services of external service providers who provide ongoing support for unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated by prohibiting the connection of such components to public or uncontrolled networks or implementing other forms of isolation.
options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced are provided.
system components are replaced when support for the components is no longer available from the developer, vendor, or manufacturer.
system and services acquisition policy and procedures
procedures for the replacement or continued use of unsupported system components
documented evidence of replacing unsupported system components
documented approvals (including justification) for the continued use of unsupported system components
SCRM plan
system security plan
other relevant documents or records
personnel with system and service acquisition responsibilities
personnel responsible for component replacement
personnel with system development life cycle responsibilities
personnel with information security responsibilities
processes for replacing unsupported system components
mechanisms for supporting or implementing the replacement of unsupported system components
organization-defined security requirements
security requirements to be satisfied by external system service providers are defined.
Require the providers of external system services used for the processing,
storage, or transmission of CUI to comply with the following security
requirements:
Define and document user roles and responsibilities with regard to external system services, including shared responsibilities with external service providers.
Implement processes, methods, and techniques to monitor security requirement compliance by external service providers on an ongoing basis.
External system services are provided by external service providers. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with the organization charged with protecting CUI. Service-level agreements define expectations of performance, describe measurable outcomes, and identify remedies, mitigations, and response requirements for instances of noncompliance. Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be useful when there is a need to understand the trade-offs involved in restricting certain functions and services or blocking certain ports and protocols. This requirement is related to 03.01.20.
the providers of external system services used for the processing, storage, or
transmission of CUI comply with the following security requirements:
processes, methods, and techniques to monitor security requirement compliance by external service providers on an ongoing basis are implemented.
user roles and responsibilities with regard to external system services, including shared responsibilities with external service providers, are defined and documented.
system and services acquisition policy and procedures
procedures for monitoring security requirement compliance by external service providers
acquisition documentation
contracts
service-level agreements
interagency agreements
licensing agreements
list of security requirements for external provider services
assessment results or reports from external service providers
SCRM plan
system security plan
other relevant documents or records
personnel with acquisition responsibilities
external providers of system services
personnel with SCRM responsibilities
personnel with information security responsibilities
organizational processes for monitoring security and privacy control compliance by external service providers on an ongoing basis
mechanisms for monitoring security and privacy control compliance by external service providers on an ongoing basis
organization-defined frequency
the frequency at which to review and update the supply chain risk management plan is defined.
Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of the system, system components, or system services.
Review and update the supply chain risk management plan
Protect the supply chain risk management plan from unauthorized disclosure.
Dependence on the products, systems, and services of external providers and the nature of the relationships with those providers present an increasing level of risk to an organization. Threat actions that may increase security risks include unauthorized production, the insertion or use of counterfeits, tampering, poor manufacturing and development practices in the supply chain, theft, and the insertion of malicious software, firmware, and hardware. Supply chain risks can be endemic or systemic within a system, component, or service. Managing supply chain risks is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders. Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against the plans. The system-level SCRM plan is implementation-specific and provides constraints, policy implementation, requirements, and implications. It can either be stand-alone or incorporated into system security plans. The SCRM plan addresses the management, implementation, and monitoring of SCRM requirements and the development or sustainment of systems across the system development life cycle to support mission and business functions. Because supply chains can differ significantly across and within organizations, SCRM plans are tailored to individual program, organizational, and operational contexts.
a plan for managing supply chain risks is developed.
the SCRM plan addresses risks associated with the research and development of the system, system components, or system services.
the SCRM plan addresses risks associated with the design of the system, system components, or system services.
the SCRM plan addresses risks associated with the manufacturing of the system, system components, or system services.
the SCRM plan addresses risks associated with the acquisition of the system, system components, or system services.
the SCRM plan addresses risks associated with the delivery of the system, system components, or system services.
the SCRM plan addresses risks associated with the integration of the system, system components, or system services.
the SCRM plan addresses risks associated with the operation of the system, system components, or system services.
the SCRM plan addresses risks associated with the maintenance of the system, system components, or system services.
the SCRM plan addresses risks associated with the disposal of the system, system components, or system services.
the SCRM plan is reviewed
the SCRM plan is updated
the SCRM plan is protected from unauthorized disclosure.
SCRM policy and procedures
SCRM plan
system and services acquisition policy and procedures
system and services acquisition procedures
procedures for supply chain protection
procedures for protecting the SCRM plan from unauthorized disclosure
system development life cycle procedures
procedures for the integration of information security requirements into the acquisition process
acquisition documentation
service-level agreements
acquisition contracts for the system, system components, or system services
list of supply chain threats
list of safeguards for supply chain threats
system life cycle documentation, including research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal
inter-organizational agreements and procedures
system security plan
other relevant documents or records
personnel with acquisition responsibilities
personnel with SCRM responsibilities
personnel with information security responsibilities
organizational processes for defining and documenting the system development life cycle (SDLC)
organizational processes for identifying SDLC roles and responsibilities
organizational processes for integrating SCRM into the SDLC
mechanisms for supporting or implementing the SDLC
Develop and implement acquisition strategies, contract tools, and procurement methods to identify, protect against, and mitigate supply chain risks.
The acquisition process provides an important vehicle for protecting the supply chain. There are many useful tools and techniques available, including obscuring the end use of a system or system component, using blind purchases, requiring tamperevident packaging, or using trusted or controlled distribution. The results from a supply chain risk assessment can inform the strategies, tools, and methods that are most applicable to the situation. Tools and techniques may provide protections against unauthorized production, theft, tampering, the insertion of counterfeits, the insertion of malicious software or backdoors, and poor development practices throughout the system life cycle. Organizations also consider providing incentives for suppliers to implement safeguards, promote transparency in their processes and security practices, provide contract language that addresses the prohibition of tainted or counterfeit components, and restrict purchases from untrustworthy suppliers. Organizations consider providing training, education, and awareness programs for personnel regarding supply chain risks, available mitigation strategies, and when the programs should be employed. Methods for reviewing and protecting development plans, documentation, and evidence are commensurate with the security requirements of the organization. Contracts may specify documentation protection requirements.
acquisition strategies, contract tools, and procurement methods are developed to identify supply chain risks.
acquisition strategies, contract tools, and procurement methods are developed to protect against supply chain risks.
acquisition strategies, contract tools, and procurement methods are developed to mitigate supply chain risks.
acquisition strategies, contract tools, and procurement methods are implemented to identify supply chain risks.
acquisition strategies, contract tools, and procurement methods are implemented to protect against supply chain risks.
acquisition strategies, contract tools, and procurement methods are implemented to mitigate supply chain risks.
SCRM policy and procedures
SCRM plan
system and services acquisition policy and procedures
procedures for supply chain protection
procedures for the integration of information security requirements into the acquisition process
solicitation documentation
acquisition documentation (including purchase orders)
service-level agreements
acquisition contracts for the system, system components, or services
documentation of identified supply chain risks
mitigation plans for supply chain risks
documentation of training, education, and awareness programs for personnel regarding supply chain risk
system security plan
other relevant documents or records
personnel with acquisition responsibilities
personnel with SCRM responsibilities
personnel with information security responsibilities
processes for defining and employing tailored acquisition strategies, contract tools, and procurement methods
mechanisms for implementing tailored acquisition strategies, contract tools, and procurement methods
organization-defined security requirements
security requirements to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences from supply chain-related events are defined.
Establish a process for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes.
Enforce the following security requirements to protect against supply chain
risks to the system, system components, or system services and to limit the
harm or consequences from supply chain-related events:
Supply chain elements include organizations, entities, or tools that are employed for the research, development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, firmware, and systems development processes; shipping and handling procedures; physical security programs; personnel security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance, and disposal of systems and system components. Supply chain elements and processes are provided by organizations, system integrators, or external service providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to harm the organization and affect its ability to carry out its core missions or business functions.
a process for identifying weaknesses or deficiencies in the supply chain elements and processes is established.
a process for addressing weaknesses or deficiencies in the supply chain elements and processes is established.
the following security requirements are enforced to protect against supply chain
risks to the system, system components, or system services and to limit the harm
or consequences of supply chain-related events:
SCRM policy and procedures
SCRM strategy
SCRM plan
systems and critical system components inventory documentation
system and services acquisition policy and procedures
procedures for the integration of security requirements into the acquisition process
solicitation documentation
acquisition documentation (including purchase orders)
shipping and handling procedures
configuration management documentation and records
acquisition contracts for systems or services
service-level agreements
risk register documentation
system security plan
other relevant documents or records
personnel with acquisition responsibilities
personnel with information security responsibilities
personnel with SCRM responsibilities
processes for identifying and addressing supply chain element and process deficiencies