Access Control (AC)¶

AC.L2-3.1.1 – Authorized Access Control [CUI Data]¶

Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).

Assessment Objectives¶

Source: NIST SP 800-171A, p. 9.

Determine if:

• [a] authorized users are identified;
• [b] processes acting on behalf of authorized users are identified;
• [c] devices (and other systems) authorized to connect to the system are identified;
• [d] system access is limited to authorized users;
• [e] system access is limited to processes acting on behalf of authorized users; and
• [f] system access is limited to authorized devices (including other systems).

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 9.

Examine: [SELECT FROM: Access control policy; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of active system accounts and the name of the individual associated with each account; notifications or records of recently transferred, separated, or terminated employees; list of conditions for group and role membership; list of recently disabled system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; system monitoring records; system audit logs and records; list of devices and systems authorized to connect to organizational systems; other relevant documents or records].

Interview: [SELECT FROM: Personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Organizational processes for managing system accounts; mechanisms for implementing account management].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 10.

Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses [sic] non-privileged) are addressed in requirement 3.1.2 (AC.L2-3.1.2).

Further Discussion¶

Identify users, processes, and devices that are allowed to use company computers and can log on to the company network. Automated updates and other automatic processes should be associated with the user who initiated (authorized) the process. Limit the devices (e.g., printers) that can be accessed by company computers. Set up your system so that only authorized users, processes, and devices can access the company network. This requirement, AC.L2-3.1.1, controls system access based on user, process, or device identity. AC.L2-3.1.1 leverages IA.L2-3.5.1 which provides a vetted and trusted identity for access control.

Examples¶

• Your company maintains a list of all personnel authorized to use company information systems, including those that store, process, and transmit CUI [a]. This list is used to support identification and authentication activities conducted by IT when authorizing access to systems [a,d].

• A coworker wants to buy a new multi-function printer/scanner/fax device and make it available on the company network within the CUI enclave. You explain that the company controls system and device access to the network and will prevent network access by unauthorized systems and devices [c]. You help the coworker submit a ticket that asks for the printer to be granted access to the network, and appropriate leadership approves the device [f].

Potential Assessment Considerations¶

• Is a list of authorized users maintained that defines their identities and roles [a]?
• Are account requests authorized before system access is granted [d,e,f]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.1
• FAR Clause 52.204-21 b.1.i

AC.L2-3.1.2 – Transaction & Function Control¶

Limit system access to the types of transactions and functions that authorized users are permitted to execute.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 9.

Determine if:

• [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
• [b] system access is limited to the defined types of transactions and functions for authorized users.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 9.

Examine: [SELECT FROM: Access control policy; procedures addressing access enforcement; system security plan; system design documentation; list of approved authorizations including remote access authorizations; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel with access enforcement responsibilities; system or network administrators; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Mechanisms implementing access control policy].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 10-11.

Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements).

Further Discussion¶

Limit users to only the information systems, roles, or applications they are permitted to use and are needed for their roles and responsibilities. Limit access to applications and data based on the authorized users’ roles and responsibilities. Common types of functions a user can be assigned are create, read, update, and delete.

Examples¶

• Your team manages DoD contracts for your company. Members of your team need to access the contract information to perform their work properly. Because some of that data contains CUI, you work with IT to set up your group’s systems so that users can be assigned access based on their specific roles [a]. Each role limits whether an employee has read-access or create/read/delete/update -access [b]. Implementing this access control restricts access to CUI information unless specifically authorized.

Potential Assessment Considerations¶

• Are access control lists used to limit access to applications and data based on role and/or identity [a]?
• Is access for authorized users restricted to those parts of the system they are explicitly permitted to use (e.g., a person who only performs word-processing cannot access developer tools) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.2
• FAR Clause 52.204-21 b.1.ii

AC.L2-3.1.3 – Control CUI Flow¶

Control the flow of CUI in accordance with approved authorizations.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 10.

Determine if:

• [a] information flow control policies are defined;
• [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
• [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
• [d] authorizations for controlling the flow of CUI are defined; and
• [e] approved authorizations for controlling the flow of CUI are enforced.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 10.

Examine: [SELECT FROM: Access control policy; information flow control policies; procedures addressing information flow enforcement; system security plan; system design documentation; system configuration settings and associated documentation; list of information flow authorizations; system baseline configuration; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Mechanisms implementing information flow enforcement policy].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 11.

Information flow control regulates where information can travel within a system and between systems (versus who can access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include the following: keeping export-controlled information from being transmitted in the clear to the internet; blocking outside traffic that claims to be from within the organization; restricting requests to the internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content.

Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of information 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., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or 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. Transferring information between systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. Organizations consider the shared nature of commercial telecommunications services in the implementation of security requirements associated with the use of such services. Commercial telecommunications services are commonly based on network components and consolidated management systems shared by all attached commercial customers and may also include third party-provided access lines and other service elements. Such transmission services may represent sources of increased risk despite contract security provisions. NIST SP 800-41 provides guidance on firewalls and firewall policy. SP 800-125B provides guidance on security for virtualization technologies. 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 information transfers between interconnected systems (i.e., allowing access only); employing hardware mechanisms to enforce one-way information flows; and implementing trustworthy regrading mechanisms to reassign security attributes and security labels.

Further Discussion¶

Typically, companies will have a firewall between the internal network and the internet. Often multiple firewalls or routing switches are used inside a network to create zones to separate sensitive data, business units, or user groups. Proxy servers can be used to break the connection between multiple networks. All traffic entering or leaving a network is intercepted by the proxy, preventing direct access between networks. Companies should also ensure by policy and enforcement mechanisms that all CUI allowed to flow across the internet is encrypted.

Examples¶

• You configure a proxy device on your company’s network. CUI is stored within this environment. Your goal is to better mask and protect the devices inside the network while enforcing information flow policies. After the device is configured, information does not flow directly from the internal network to the internet. The proxy device intercepts the traffic and analyzes it to determine if the traffic conforms to organization information flow control policies. If it does, the device allows the information to pass to its destination [b]. The proxy blocks traffic that does not meet policy requirements [e].

• As a subcontractor on a DoD contract, your organization sometimes needs to transmit CUI to the prime contractor. You create a policy document that specifies who is allowed to transmit CUI and that such transmission requires manager approval [a,c,d]. The policy instructs users to encrypt any CUI transmitted via email or to use a designated secure file sharing utility [b,d]. The policy states that users who do not follow appropriate procedures may be subject to disciplinary action [e].

Potential Assessment Considerations¶

• Are designated sources of regulated data identified within the system (e.g., internal network and IP address) and between interconnected systems (e.g., external networks, IP addresses, ports, and protocols) [c]?
• Are designated destinations of regulated data identified within the system (e.g., internal network and IP address) and between interconnected systems (external networks and IP addresses) [c]?
• Are authorizations defined for each source and destination within the system and between interconnected systems (e.g., allow or deny rules for each combination of source and destination) [d]?
• Are approved authorizations for controlling the flow of regulated data enforced within the system and between interconnected systems (e.g., traffic between authorized sources and destinations is allowed and traffic between unauthorized sources and destinations is denied) [e]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.3

AC.L2-3.1.4 – Separation of Duties¶

Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 10.

Determine if:

• [a] the duties of individuals requiring separation are defined;
• [b] responsibilities for duties that require separation are assigned to separate individuals; and
• [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 10.

Examine: [SELECT FROM: Access control policy; procedures addressing divisions of responsibility and separation of duties; system security plan; system configuration settings and associated documentation; list of divisions of responsibility and separation of duties; system access authorizations; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for defining divisions of responsibility and separation of duties; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms implementing separation of duties policy].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 11.

Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering 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 organizational systems and system components when developing policy on separation of duties.

Further Discussion¶

No one person should be in charge of an entire critical task from beginning to end. Documenting and dividing elements of important duties and tasks between employees reduces intentional or unintentional execution of malicious activities.

Examples¶

• You are responsible for the management of several key systems within your organization including some that process CUI. You assign the task of reviewing the system logs to two different people. This way, no one person is solely responsible for the execution of this critical security function [c].

• You are a system administrator. Human Resources notifies you of a new hire, and you create an account with general privileges, but you are not allowed to grant access to systems that contain CUI [a,b]. The program manager contacts the team in your organization that has system administration authority over the CUI systems and informs them which CUI the new hire will need to access. Subsequently, a second system administrator grants access privileges to the new hire [c].

Potential Assessment Considerations¶

• Does system documentation identify the system functions or processes that require separation of duties (e.g., function combinations that represent a conflict of interest or an over-allocation of security privilege for one individual) [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.4

AC.L2-3.1.5 – Least Privilege¶

Employ the principle of least privilege, including for specific security functions and privileged accounts.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 11.

Determine if:

• [a] privileged accounts are identified;
• [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
• [c] security functions are identified; and
• [d] access to security functions is authorized in accordance with the principle of least privilege.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 11.

Examine: [SELECT FROM: Access control policy; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of active system accounts and the name of the individual associated with each account; list of conditions for group and role membership; notifications or records of recently transferred, separated, or terminated employees; list of recently disabled system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; system monitoring/audit records; procedures addressing least privilege; list of security functions (deployed in hardware, software, and firmware) and security-relevant information for which access is to be explicitly authorized; list of system-generated privileged accounts; list of system administration personnel; other relevant documents or records].

Interview: [SELECT FROM: Personnel with account management responsibilities; system or network administrators; personnel with information security responsibilities; personnel with responsibilities for defining least privileges necessary to accomplish specified tasks].

Test: [SELECT FROM: Organizational processes for managing system accounts; mechanisms for implementing account management; mechanisms implementing least privilege functions; mechanisms prohibiting privileged access to the system].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 12.

Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions. Organizations consider the creation of additional processes, roles, and system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges). Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate in the application of this requirement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk.

Further Discussion¶

The principle of least privilege applies to all users and processes on all systems, but it is critical to systems containing or accessing CUI. Least privilege:

• restricts user access to only the machines and information needed to fulfill job responsibilities; and
• limits what system configuration settings users can change, only allowing individuals with a business need to change them.

Examples¶

• You create accounts for an organization that processes CUI. By default, everyone is assigned a basic user role, which prevents a user from modifying system configurations. Privileged access is only assigned to users and processes that require it to carry out job functions, such as IT staff, and is very selectively granted [b,d].

Potential Assessment Considerations¶

• Are privileged accounts documented and is when they may be used defined [a]?
• Are users assigned privileged accounts to perform their job functions only when it is necessary [b]?
• Are necessary security functions identified (e.g., access control configuration, system configuration settings, or privileged account lists) that must be managed through the use of privileged accounts [c]?
• Is access to privileged functions and security information restricted to authorized employees [d]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.5

AC.L2-3.1.6 – Non-Privileged Account Use¶

Use non-privileged accounts or roles when accessing nonsecurity functions.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 11.

Determine if:

• [a] nonsecurity functions are identified; and
• [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 11.

Examine: [SELECT FROM: Access control policy; procedures addressing least privilege; system security plan; list of system-generated security functions assigned to system accounts or roles; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for defining least privileges necessary to accomplish specified organizational tasks; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms implementing least privilege functions].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 12.

This requirement limits exposure when operating from within privileged accounts or roles. The inclusion of roles addresses situations where organizations implement access control policies such as role-based access control and where a change of role provides the same degree of assurance in the change of access authorizations for the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account.

Further Discussion¶

A user with a privileged account can perform more tasks and access more information than a person with a non-privileged account. Tasks (including unauthorized tasks orchestrated by attackers) performed when using the privileged account can have a greater impact on the system. System administrators and users with privileged accounts must be trained not to use their privileged accounts for everyday tasks, such as browsing the internet or connecting unnecessarily to other systems or services.

Examples¶

• You are logged in using your privileged account and you need to look up how to reset a non-functioning application which processes CUI. You should log on to another computer with your non-privileged account before you connect to the web and start searching for the reset information [b]. That way, if your account is compromised during the search, it will be your regular user account rather than an account with elevated privileges.

Potential Assessment Considerations¶

• Are nonsecurity functions and non-privileged roles defined [a,b]?
• Is it required that nonsecurity functions only be accessed with the use of non-privileged accounts? How is this verified [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.6

AC.L2-3.1.7 – Privileged Functions¶

Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 12.

Determine if:

• [a] privileged functions are defined;
• [b] non-privileged users are defined;
• [c] non-privileged users are prevented from executing privileged functions; and
• [d] the execution of privileged functions is captured in audit logs.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 12.

Examine: [SELECT FROM: Privacy and security policies, procedures addressing system use notification; documented approval of system use notification messages or banners; system audit logs and records; system design documentation; user acknowledgements of notification message or banner; system security plan; system use notification messages; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for defining least privileges necessary to accomplish specified tasks; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Mechanisms implementing least privilege functions for non-privileged users; mechanisms auditing the execution of privileged functions].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 12.

Privileged functions include establishing system accounts, performing system integrity checks, conducting patching operations, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. Note that this requirement represents a condition to be achieved by the definition of authorized privileges in 3.1.2 (AC.L2-3.1.2). Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Logging the use of privileged functions is one way to detect such misuse, and in doing so, help mitigate the risk from insider threats and the advanced persistent threat.

Further Discussion¶

Non-privileged users should receive only those permissions required to perform their basic job functions. Privileged users are granted additional permissions because their jobs require them. Privileged functions typically involve the control, monitoring, or administration of the system and its security measures. When these special privileged functions are performed, the activity must be captured in an audit log, which can be used to identify abuse. Non-privileged employees must not be granted permission to perform any of the functions of a privileged user. This requirement, AC.L2-3.1.7, manages non-privileged users by logging any attempts to execute privileged functions. AC.L2-3.1.7 leverages AU.L2-3.3.2, which ensures logging and traceability of user actions. AC.L2-3.1.7 also extends AC.L2-3.1.2, which defines a requirement to limit types of transactions and functions to those that authorized users are permitted to execute.

Examples¶

• Your organization handles CUI and has put security controls in place that prevent non-privileged users from performing privileged activities [a,b,c]. However, a standard user was accidentally given elevated system administrator privileges. The organization has implemented an endpoint detection and response solution that provides visibility into the use of privileged activities. The monitoring system logs a security misconfiguration because the use of administrative privileges was performed by a user who was not known to have that ability. This allows you to correct the error [d].

Potential Assessment Considerations¶

• Is it possible to identify who enabled privileges at any particular time [d]?
• Are the privileged system functions documented (e.g., functions that involve the control, monitoring or administration of the system, including security functions and log management) [a]?
• Do documented procedures describe the configuration of the system to ensure system roles do not grant non-privileged users the ability to execute privileged functions [c]?
• Do procedures describe the configuration of system settings to capture the execution of all privileged functions in audit logs [d]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.7

AC.L2-3.1.8 – Unsuccessful Logon Attempts¶

Limit unsuccessful logon attempts.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 12.

Determine if:

• [a] the means of limiting unsuccessful logon attempts is defined; and
• [b] the defined means of limiting unsuccessful logon attempts is implemented.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 12.

Examine: [SELECT FROM: Access control policy; procedures addressing unsuccessful logon attempts; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with information security responsibilities; system developers; system or network administrators].

Test: [SELECT FROM: Mechanisms implementing access control policy for unsuccessful logon attempts].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 12-13.

This requirement applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are, in most cases, temporary and automatically release after a predetermined period established by the organization (i.e., a delay algorithm). If a delay algorithm is selected, organizations may employ different algorithms for different system components based on the capabilities of the respective components. Responses to unsuccessful logon attempts may be implemented at the operating system and application levels.

Further Discussion¶

Consecutive unsuccessful logon attempts may indicate malicious activity. OSAs can mitigate these attacks by limiting the number of unsuccessful logon attempts, typically by locking the account. A defined number of consecutive unsuccessful logon attempts is a common configuration setting. OSAs are expected to set this number at a level that fits their risk profile with the knowledge that fewer unsuccessful attempts provide higher security. After an unsuccessful login attempt threshold is exceeded and the system locks an account, the account may either remain locked until an administrator takes action to unlock it, or it may be locked for a predefined time after which it unlocks automatically.

Examples¶

• You attempt to log on to your work computer, which stores CUI. You mistype your password three times in a row, and an error message is generated telling you the account is locked [b]. You call your IT help desk or system administrator to request assistance. The system administrator explains that the account is locked as a result of three unsuccessful logon attempts [a]. The administrator offers to unlock the account and notes that you can wait 30 minutes for the account to unlock automatically.

Potential Assessment Considerations¶

• Is there a defined threshold for the number of unsuccessful logon attempts for which the system takes action to prevent additional attempts [a]?
• Is a mechanism for limiting the number of unsuccessful logon attempts implemented and does it use the defined threshold [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.8

AC.L2-3.1.9 – Privacy & Security Notices¶

Provide privacy and security notices consistent with applicable CUI rules.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 12-13.

Determine if:

• [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
• [b] privacy and security notices are displayed.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 12-13.

Examine: [SELECT FROM: Privacy and security policies, procedures addressing system use notification; documented approval of system use notification messages or banners; system audit logs and records; system design documentation; user acknowledgements of notification message or banner; system security plan; system use notification messages; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; personnel with responsibility for providing legal advice; system developers].

Test: [SELECT FROM: Mechanisms implementing system use notification].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 13.

System use notifications can be implemented using messages or warning banners displayed before individuals log in to organizational systems. System use notifications are used only for access via logon interfaces with human users and are not required when such human interfaces do not exist. Based on a risk assessment, organizations consider whether a secondary system use notification is needed to access applications or other system resources after the initial network logon. Where necessary, posters or other printed materials may be used in lieu of an automated system banner. Organizations consult with the Office of General Counsel for legal review and approval of warning banner content.

Further Discussion¶

Every system containing or providing access to CUI has legal requirements concerning user privacy and security notices. One method of addressing this requirement is the use of a system-use notification banner that displays the legal requirements of using the system. Users may be required to click to agree to the displayed requirements of using the system each time they log on to the machine. This agreement can be used in the civil and/or criminal prosecution of an attacker that violates the terms. The legal notification should meet all applicable requirements. At a minimum, the notice should inform the user that:

• information system usage may be monitored or recorded, and is subject to audit;
• unauthorized use of the information systems is prohibited;
• unauthorized use is subject to criminal and civil penalties;
• use of the information system affirms consent to monitoring and recording;
• the information system contains CUI with specific requirements imposed by the Department of Defense; and
• use of the information system may be subject to other specified requirements associated with certain types of CUI such as Export Controlled information.

Examples¶

• You are setting up IT equipment including a database server that will contain CUI. You have worked with legal counsel to draft a notification. It contains both general and specific CUI security and privacy requirements [a]. The system displays the required security and privacy information before anyone logs on to your organization’s computers that contain or provide access to CUI [b].

Potential Assessment Considerations¶

• Are objectives identified for privacy and security notices, and does the implementation satisfy the required objectives [a,b]? Discrepancies may indicate a deficient process and/or an incomplete objective for the overall requirement.
• Are there any special requirements associated with the specific CUI category [a]?
• Are appropriate notices displayed in areas where paper-based CUI is stored and processed [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.9

AC.L2-3.1.10 – Session Lock¶

Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 13.

Determine if:

• [a] the period of inactivity after which the system initiates a session lock is defined;
• [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
• [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 13.

Examine: [SELECT FROM: Access control policy; procedures addressing session lock; procedures addressing identification and authentication; system design documentation; system configuration settings and associated documentation; system security plan; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Mechanisms implementing access control policy for session lock].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 13.

Session locks are temporary actions taken when users stop work and move away from the immediate vicinity of the system but do not want to log out because of the temporary nature of their absences. Session locks are implemented where session activities can be determined, typically at the operating system level (but can also be at the application level). Session locks are not an acceptable substitute for logging out of the system, for example, if organizations require users to log out at the end of the workday. Pattern-hiding displays can include static or dynamic images, for example, patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen, with the additional caveat that none of the images convey controlled unclassified information.

Further Discussion¶

Session locks can be initiated by the user or, more fundamentally, enabled automatically when the system has been idle for a period of time, for example, five minutes. Session locks are a quick way to prevent unauthorized use of the systems without having a user log off. Minimum configuration requirements are left up to the organization to define. A locked session shows pattern-hiding information on the screen to mask the data on the display.

Examples¶

• You manage systems for an organization that stores, processes, and transmits CUI. You notice that employees leave their offices without locking their computers. Sometimes their screens display sensitive company information. You configure all machines to lock after five minutes of inactivity [a,b]. You also remind your coworkers to lock their systems when they walk away [a].

Potential Assessment Considerations¶

• Does the session lock hide previously visible information (e.g., replacing what was visible with a lock screen or screensaver that does not include sensitive information) [c]?
• If session locks are not managed centrally, how are all computer users made aware of the requirements and how to configure them [a,b,c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.10

AC.L2-3.1.11 – Session Termination¶

Terminate (automatically) a user session after a defined condition.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 13-14.

Determine if:

• [a] conditions requiring a user session to terminate are defined; and
• [b] a user session is automatically terminated after any of the defined conditions occur.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 13-14.

Examine: [SELECT FROM: Access control policy; procedures addressing session termination; system design documentation; system security plan; system configuration settings and associated documentation; list of conditions or trigger events requiring session disconnect; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Mechanisms implementing user session termination].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 13.

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). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on system use.

Further Discussion¶

Configure the system to terminate user sessions based on the organization’s policy. Session termination policies can be simple or sophisticated. Examples are inactivity (end the session after a specified duration (e.g., one hour 33) of inactivity), day/time (all sessions are terminated at the end of the established workday), misbehavior (end the session due to an attempted policy violation), and maintenance (terminate sessions to prevent issues with an upgrade or service outage). If there is no automatic control of user sessions, an attacker can take advantage of an unattended session.

Examples¶

• You manage systems containing CUI for your organization and configure the system to terminate all user sessions after 1 hour of inactivity [a]. As the session timeout approaches, the system prompts users with a warning banner asking if they want to continue the session. When the session timeout does occur, the login page pops up, and the users must log in to start a new session [b].

• A user is logged into a corporate database containing CUI but is not authorized to view CUI. The user has submitted a series of queries that unintentionally violate policy, as they attempt to extract CUI that the user is not authorized to view [a]. The session terminates with a warning as a result of a violation of corporate policy [b]. The user must reestablish the session before being able to submit additional legitimate queries.

Potential Assessment Considerations¶

• Are the conditions in which a user session must be terminated described (e.g., after a period of inactivity or after a defined time limit) [a]?
• Are procedures documented that describe how to configure the system to enable automatic termination of user sessions after any of the defined conditions occur [b]?
• Are user sessions terminated based on organization-defined conditions [a,b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.11

33 Review DoD Cybersecurity FAQ Q53.2 for information on minimum values.

AC.L2-3.1.12 – Control Remote Access¶

Monitor and control remote access sessions.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 14.

Determine if:

• [a] remote access sessions are permitted;
• [b] the types of permitted remote access are identified;
• [c] remote access sessions are controlled; and
• [d] remote access sessions are monitored.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 14.

Examine: [SELECT FROM: Access control policy; procedures addressing remote access implementation and usage (including restrictions); configuration management plan; system security plan; system design documentation; system configuration settings and associated documentation; remote access authorizations; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for managing remote access connections; system or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Remote access management capability for the system].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 13-14.

Remote access is access to organizational systems by users (or processes acting on behalf of users) communicating through external networks (e.g., the internet). Remote access methods include dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality over remote connections. The use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate control (e.g., employing encryption techniques for confidentiality protection), may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks. VPNs with encrypted tunnels can affect the capability to adequately monitor network communications traffic for malicious code.

Automated monitoring and control of remote access sessions allows organizations to detect cyber-attacks and help to ensure ongoing compliance with remote access policies by auditing connection activities of remote users on a variety of system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). NIST SP 800-46, SP 800-77, and SP 800-113 provide guidance on secure remote access and virtual private networks.

Further Discussion¶

Remote access connections pass through untrusted networks and therefore require proper security controls such as encryption to ensure data confidentiality. Initialization of all remote sessions should ensure that only authorized users and devices are connecting. After the remote session is established, the connection is monitored to track who is accessing the network remotely and what files are being accessed during the session. Remote access sessions can encompass more than just remote connections back to a headquarters network. Access to cloud-based email providers or server infrastructures also are relevant to this requirement if those environments contain CUI. This requirement, AC.L2-3.1.12, requires the control of remote access sessions and complements five other requirements dealing with remote access (AC.L2-3.1.14, AC.L2-3.1.13, AC.L2-3.1.15, IA.L2-3.5.3, and MA.L2-3.7.5):

• AC.L2-3.1.14 limits remote access to specific access control points.
• AC.L2-3.1.13 requires the use of cryptographic mechanisms when enabling remote sessions.
• AC.L2-3.1.15 requires authorization for privileged commands executed during a remote session.
• IA.L2-3.5.3 requires multifactor authentication for network access to non-privileged accounts.
• Finally, MA.L2-3.7.5 requires the addition of multifactor authentication for remote maintenance sessions.

Examples¶

• You often need to work from remote locations, such as your home or client sites, and you are permitted to access your organization’s internal networks (including a network containing CUI) from those remote locations [a]. A system administrator issues you a company laptop with VPN software installed, which is required to connect to the networks remotely [b]. After the laptop connects to the VPN server, you must accept a privacy notice that states that the company’s security department may monitor the connection. This monitoring is achieved through the analysis of data from sensors on the network notifying IT if issues arise. The security department may also review audit logs to see who is connecting remotely, when, and what information they are accessing [d]. During session establishment, the message “Verifying Compliance” means software like a Device Health Check (DHC) application is checking the remote device to ensure it meets the established requirements to connect [c].

Potential Assessment Considerations¶

• Do policies identify when remote access is permitted and what methods must be used [a,b]?
• Are systems configured to permit only approved remote access sessions (e.g., disallow remote access sessions by default) [c]?
• Are automated or manual mechanisms employed for monitoring remote connections? If the monitoring is manual, does it occur at a frequency commensurate with the level of risk [d]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.12

AC.L2-3.1.13 – Remote Access Confidentiality¶

Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 14.

Determine if:

• [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
• [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 14.

Examine: [SELECT FROM: Access control policy; procedures addressing remote access to the system; system security plan; system design documentation; system configuration settings and associated documentation; cryptographic mechanisms and associated configuration documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Cryptographic mechanisms protecting remote access sessions].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 14.

Cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography.

Further Discussion¶

A remote access session involves logging into the organization’s systems such as its internal network or a cloud service provider from a remote location such as home or an alternate work site. Because the use of cryptography in this requirement is to protect the confidentiality of CUI, the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11. Although not explicitly required to meet AC.L2-3.1.13 requirements, this remote access session must be secured using FIPS-validated cryptography to provide confidentiality and prevent anyone from deciphering session information exchanges.

This requirement, AC.L2-3.1.13, requires the use of cryptographic mechanisms when enabling remote sessions and complements five other requirements dealing with remote access (AC.L2-3.1.12, AC.L2-3.1.14, AC.L2-3.1.15, IA.L2-3.5.3, and MA.L2-3.7.5):

• AC.L2-3.1.12 requires the control of remote access sessions.
• AC.L2-3.1.14 limits remote access to specific access control points.
• AC.L2-3.1.15 requires authorization for privileged commands executed during a remote session.
• IA.L2-3.5.3 requires multifactor authentication for network access to non-privileged accounts.
• Finally, MA.L2-3.7.5 requires the addition of multifactor authentication for remote maintenance sessions.

Examples¶

• You are responsible for implementing a remote network access capability for users who access CUI remotely. In order to provide session confidentiality, you decide to implement a VPN mechanism and select a product that has completed FIPS 140 validation [a,b].

Potential Assessment Considerations¶

• Are cryptographic mechanisms used for remote access sessions (e.g., Transport Layer Security (TLS) and Internet Protocol Security (IPSec) using FIPS-validated encryption algorithms) defined and implemented [a,b]? Note that simply using an approved algorithm is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140.

Key References¶

• NIST SP 800-171 Rev. 2 3.1.13

AC.L2-3.1.14 – Remote Access Routing¶

Route remote access via managed access control points.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 15.

Determine if:

• [a] managed access control points are identified and implemented; and
• [b] remote access is routed through managed network access control points.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 15.

Examine: [SELECT FROM: Access control policy; procedures addressing remote access to the system; system security plan; system design documentation; list of all managed network access control points; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms routing all remote accesses through managed network access control points].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 14.

Routing remote access through managed access control points enhances explicit, organizational control over such connections, reducing the susceptibility to unauthorized access to organizational systems resulting in the unauthorized disclosure of CUI.

Further Discussion¶

The OSA can route all remote access through a limited number of remote access control points to reduce the attack surface and simplify network management. This allows for better monitoring and control of the remote connections. This requirement, AC.L2-3.1.14, limits remote access to specific access control points and complements five other requirements dealing with remote access (AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.15, IA.L2-3.5.3, and MA.L2-3.7.5):

• AC.L2-3.1.12 requires the control of remote access sessions.
• AC.L2-3.1.13 requires the use of cryptographic mechanisms when enabling remote sessions.
• AC.L2-3.1.15 requires authorization for privileged commands executed during a remote session.
• IA.L2-3.5.3 requires multifactor authentication for network access to non-privileged accounts.
• Finally, MA.L2-3.7.5 requires the addition of multifactor authentication for remote maintenance sessions.

Examples¶

• You manage systems for a company that processes CUI at multiple locations, and several employees at different locations need to connect to the organization’s networks while working remotely. Because each company location has a direct connection to headquarters, you decide to route all remote access through the headquarters location [a]. All remote traffic is routed through a single location to simplify monitoring [b].

Potential Assessment Considerations¶

• How many managed access control points are implemented [a]?
• Is all remote access routed through the managed access control points [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.14

AC.L2-3.1.15 – Privileged Remote Access¶

Authorize remote execution of privileged commands and remote access to security-relevant information.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 15.

Determine if:

• [a] privileged commands authorized for remote execution are identified;
• [b] security-relevant information authorized to be accessed remotely is identified;
• [c] the execution of the identified privileged commands via remote access is authorized; and
• [d] access to the identified security-relevant information via remote access is authorized.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 15.

Examine: [SELECT FROM: Access control policy; procedures addressing remote access to the system; system configuration settings and associated documentation; system security plan; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms implementing remote access management].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 14.

A privileged command is a human-initiated (interactively or via a process operating on behalf of the human) command executed on a system involving the control, monitoring, or administration of the system including security functions and associated security-relevant information. Security-relevant information is any information within the system 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. Controlling such access from remote locations helps to ensure that unauthorized individuals are not able to execute such commands freely with the potential to do serious or catastrophic damage to organizational systems. Note that the ability to affect the integrity of the system is considered security-relevant as that could enable the means to by-pass security functions although not directly impacting the function itself.

Further Discussion¶

Privileged users are not necessarily allowed to perform their job functions from a remote location. Likewise, not all privileged commands may be executed remotely. Allowing remote execution of privileged commands or remote access to security-relevant information should be avoided if possible. If absolutely necessary, the privileged commands authorized for remote execution should be identified and documented. Document which user roles have permissions to remotely execute privileged commands to make changes and to access security relevant information. Documentation must be used to establish security mechanisms that enforce the policy. This requirement, AC.L2-3.1.15, requires authorization for privileged commands executed during a remote session and complements five other requirements dealing with remote access (AC.L2-3.1.12, AC.L2-3.1.14, AC.L2-3.1.13, IA.L2-3.5.3, and MA.L2-3.7.5):

• AC.L2-3.1.12 requires the control of remote access sessions.
• AC.L2-3.1.14 limits remote access to specific access control points.
• AC.L2-3.1.13 requires the use of cryptographic mechanisms when enabling remote sessions.
• IA.L2-3.5.3 requires multifactor authentication for network access to non-privileged accounts.
• Finally, MA.L2-3.7.5 requires the addition of multifactor authentication for remote maintenance sessions.

This requirement, AC.L2-3.1.15, also extends AC.L2-3.1.2, which limits the types of transactions and functions that authorized users are permitted to execute.

Examples¶

• Your company’s Access Control Policy permits certain work roles to remotely perform a limited set of privileged commands from company-owned computers [a]. You implement controls to enforce who can remotely execute a privileged command, which privileged commands they can execute, and who is allowed access to security relevant information such as audit log configuration settings [a,c,d].

Potential Assessment Considerations¶

• Does system documentation identify system administration or security functions that can be executed remotely [a]?
• Is execution of the identified privileged commands via remote access only authorized for documented operational needs [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.15

AC.L2-3.1.16 – Wireless Access Authorization¶

Authorize wireless access prior to allowing such connections.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 15-16.

Determine if:

• [a] wireless access points are identified; and
• [b] wireless access is authorized prior to allowing such connections.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 15-16.

Examine: [SELECT FROM: Access control policy; configuration management plan; procedures addressing wireless access implementation and usage (including restrictions); system security plan; system design documentation; system configuration settings and associated documentation; wireless access authorizations; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for managing wireless access connections; personnel with information security responsibilities].

Test: [SELECT FROM: Wireless access management capability for the system].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 14.

Establishing usage restrictions and configuration/connection requirements for wireless access to the system provides criteria for organizations to support wireless access authorization decisions. Such restrictions and requirements reduce the susceptibility to unauthorized access to the system through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication.

Further Discussion¶

Guidelines from management form the basis for the requirements that must be met prior to authorizing a wireless connection. These guidelines may include the following:

• types of devices, such as corporate or privately owned equipment;
• configuration requirements of the devices; and
• authorization requirements before granting such connections.

AC.L2-3.1.16, AC.L2-3.1.17, and AC.L2-3.1.18 are complementary requirements in that they all establish control for the connection of mobile devices and wireless devices through the use of authentication, authorization, and encryption mechanisms.

Examples¶

• Your company is implementing a wireless network at its headquarters. CUI may be transmitted on this network. You work with management to draft a policy about the use of the wireless network. The policy states that only company-approved devices that contain verified security configuration settings are allowed to connect. The policy also includes usage restrictions that must be followed for anyone who wants to use the wireless network. Authorization is required before devices are allowed to connect to the wireless network [b].

Potential Assessment Considerations¶

• Is an updated list of approved network devices providing wireless access to the system maintained [a]?
• Are network devices providing wireless access configured to require users or devices be authorized prior to permitting a wireless connection [b]?
• Is wireless access to the system authorized and managed [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.16

AC.L2-3.1.17 – Wireless Access Protection¶

Protect wireless access using authentication and encryption.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 16.

Determine if:

• [a] wireless access to the system is protected using authentication; and
• [b] wireless access to the system is protected using encryption.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 16.

Examine: [SELECT FROM: Access control policy; system design documentation; procedures addressing wireless implementation and usage (including restrictions); system security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: System or network administrators; personnel with information security responsibilities; system developers].

Test: [SELECT FROM: Mechanisms implementing wireless access protections to the system].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 14-15.

Organizations authenticate individuals and devices to help protect wireless access to the system. Special attention is given to the wide variety of devices that are part of the Internet of Things with potential wireless access to organizational systems.

Further Discussion¶

Use a combination of authentication and encryption methods to protect the access to wireless networks. Authenticating users to a wireless access point can be achieved in multiple ways. The most common authentication and encryption methods used include:

• WPA2-PSK (WiFi Protected Access-Pre-shared Key) – This method uses a password or passphrase known by the wireless access point and the client (user device). It is common in small companies that have little turnover because the key must be changed each time an employee leaves in order to prevent the terminated employee from connecting to the

network without authorization. WPA2 is typically configured to use Advanced Encryption Standard (AES) encryption.

• WPA2 Enterprise – This method may be better for larger companies and enterprise networks because authentication is based on the identity of the individual user or device rather than a shared password or passphrase. It typically requires a Remote Authentication Dial-in User Service (RADIUS) server for authentication and can provide higher security than WPA2-PSK.

Open authentication must not be used because it authenticates any user and lacks security capabilities. Because the use of cryptography in this requirement is to protect the confidentiality of CUI, the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11. AC.L2-3.1.16, AC.L2-3.1.17, and AC.L2-3.1.18 are complementary requirements in that they all establish control for the connection of mobile devices and wireless devices through the use of authentication, authorization, and encryption mechanisms.

Examples¶

• You manage the wireless network at a small company and are installing a new wireless solution that may transmit CUI. You start by selecting a product that employs encryption validated against the FIPS 140 standard. You configure the wireless solution to use WPA2, requiring users to enter a pre-shared key to connect to the wireless network [a,b].

• You manage the wireless network at a large company and are installing a new wireless solution that may transmit CUI. You start by selecting a product that employs encryption that is validated against the FIPS 140 standard. Because of the size of your workforce, you configure the wireless system to authenticate users with a RADIUS server. Users must provide the wireless system with their domain usernames and passwords to be able to connect, and the RADIUS server verifies those credentials. Users unable to authenticate are denied access [a,b].

Potential Assessment Considerations¶

• Is wireless access limited only to authenticated and authorized users (e.g., required to supply a username and password) [a]?
• If the organization is securing its wireless network with a pre-shared key, is access to that key restricted to only authorized users [a]?
• Is wireless access encrypted using FIPS-validated cryptography? Note that simply using an approved algorithm is not sufficient; the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140 [b].

Key References¶

• NIST SP 800-171 Rev. 2 3.1.17

AC.L2-3.1.18 – Mobile Device Connection¶

Control connection of mobile devices.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 16.

Determine if:

• [a] mobile devices that process, store, or transmit CUI are identified;
• [b] mobile device connections are authorized; and
• [c] mobile device connections are monitored and logged.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 16.

Examine: [SELECT FROM: Access control policy; authorizations for mobile device connections to organizational systems; procedures addressing access control for mobile device usage (including restrictions); system design documentation; configuration management plan; system security plan; system audit logs and records; system configuration settings and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel using mobile devices to access organizational systems; system or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Access control capability authorizing mobile device connections to organizational systems].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 15.

A mobile device is a computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture information, or built-in features for synchronizing local data with remote locations. Examples of mobile devices include smart phones, e-readers, and tablets. Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for the different types of devices. Usage restrictions and implementation guidance for mobile devices include: device identification and authentication; configuration management; implementation of mandatory protective software (e.g., malicious code detection, firewall); scanning devices for malicious code; updating virus protection software; scanning for critical software updates and patches; conducting primary operating system (and possibly other resident software) integrity checks; and disabling unnecessary hardware (e.g., wireless, infrared). The need to provide adequate security for mobile devices goes beyond this requirement. Many controls for mobile devices are reflected in other CUI security requirements. NIST SP 800-124 provides guidance on mobile device security.

Further Discussion¶

Establish guidelines and acceptable requirements for proper configuration, use, and management of mobile devices. Devices that process, store, or transmit CUI must be identified with a device-specific identifier. There are many different types of identifiers, and it is important to select one that can accommodate all devices and be used in a consistent manner. These identifiers are important for facilitating the required monitoring and logging function. In addition to smartphones, consider the security of other portable devices such as e-readers and tablets. AC.L2-3.1.16, AC.L2-3.1.17, and AC.L2-3.1.18 are complementary requirements in that they all establish control for the connection of mobile devices and wireless devices through the use of authentication, authorization, and encryption mechanisms.

Examples¶

• Your organization has a policy stating that all mobile devices, including iPads, tablets, mobile phones, and Personal Digital Assistants (PDAs), must be approved and registered with the IT department before connecting to the network that contains CUI. The IT department uses a Mobile Device Management solution to monitor mobile devices and enforce policies across the enterprise [b,c].

Potential Assessment Considerations¶

• Is a list of mobile devices that are permitted to process, store, or transmit CUI maintained [a,b]?
• Is the system configured to only permit connections from identified, authorized mobile devices [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.18

AC.L2-3.1.19 – Encrypt CUI on Mobile¶

Encrypt CUI on mobile devices and mobile computing platforms.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 17.

Determine if:

• [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
• [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 17.

Examine: [SELECT FROM: Access control policy; procedures addressing access control for mobile devices; system design documentation; system configuration settings and associated documentation; encryption mechanisms and associated configuration documentation; system security plan; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with access control responsibilities for mobile devices; system or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Encryption mechanisms protecting confidentiality of information on mobile devices].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 15.

Organizations can employ full-device encryption or container-based encryption to protect the confidentiality of CUI on mobile devices and computing platforms. Container-based encryption provides a more fine-grained approach to the encryption of data and information including encrypting selected data structures such as files, records, or fields.

Further Discussion¶

Ensure CUI is encrypted on all mobile devices and mobile computing platforms that process, store, or transmit CUI including smartphones, tablets, and e-readers.

Because the use of cryptography in this requirement is to protect the confidentiality of CUI, the cryptography used must meet the criteria specified in requirement SC.L2-3.13.11. This requirement, AC.L2-3.1.19, specifies that CUI be encrypted on mobile devices and extends three other CUI protection requirements (MP.L2-3.8.1, MP.L2-3.8.2, and SC.L2-3.13.16):

• MP.L2-3.8.1 requires that media containing CUI be protected.
• MP.L2-3.8.2 limits access to CUI to authorized users.
• Finally, SC.L2-3.13.16 requires confidentiality of CUI at rest.

This requirement, AC.L2-3.1.19, also leverages SC.L2-3.13.11, which specifies that the algorithms used must be FIPS-validated cryptography, and SC.L2-3.13.10, which specifies that any cryptographic keys in use must be protected.

Examples¶

• You are in charge of mobile device security for a company that processes CUI. You configure all laptops to use the full-disk encryption technology built into the operating system. This approach is FIPS-validated and encrypts all files, folders, and volumes. Phones and tablets pose a greater technical challenge with their wide range of manufacturers and operating systems. You select a proprietary mobile device management (MDM) solution to enforce FIPS-validated encryption on those devices [a,b].

Potential Assessment Considerations¶

• Is a list maintained of mobile devices and mobile computing platforms that are permitted to process, store, or transmit CUI [a]?
• Is CUI encrypted on mobile devices using FIPS-validated algorithms [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.19

AC.L2-3.1.20 – External Connections [CUI Data]¶

Verify and control/limit connections to and use of external systems.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 17.

Determine if:

• [a] connections to external systems are identified;
• [b] the use of external systems is identified;
• [c] connections to external systems are verified;
• [d] the use of external systems is verified;
• [e] connections to external systems are controlled/limited; and
• [f] the use of external systems is controlled/limited.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 17.

Examine: [SELECT FROM: Access control policy; procedures addressing the use of external systems; terms and conditions for external systems; system security plan; list of applications accessible from external systems; system configuration settings and associated documentation; system connection or processing agreements; account management documents; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for defining terms and conditions for use of external systems to access organizational systems; system or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms implementing terms and conditions on use of external systems].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 15-16.

External systems are systems or components of systems for which organizations typically have no direct supervision and authority over the application of security requirements and controls or the determination of the effectiveness of implemented controls on those systems. External systems include personally owned systems, components, or devices and privately-owned computing and communications devices resident in commercial or public facilities.

This requirement also addresses the use of external systems for the processing, storage, or transmission of CUI, including accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational systems. Organizations establish terms and conditions for the use of external systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum, the types of applications that can be accessed on organizational systems from external systems. If terms and conditions with the owners of external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems. This requirement recognizes that there are circumstances where individuals using external systems (e.g., contractors, coalition partners) need to access organizational systems. In those situations, organizations need confidence that the external systems contain the necessary controls so as not to compromise, damage, or otherwise harm organizational systems. Verification that the required controls have been effectively implemented can be achieved by third-party, independent assessments, attestations, or other means, depending on the assurance or confidence level required by organizations. Note that while “external” typically refers to outside of the organization’s direct supervision and authority, that is not always the case. Regarding the protection of CUI across an organization, the organization may have systems that process CUI and others that do not. And among the systems that process CUI there are likely access restrictions for CUI that apply between systems. Therefore, from the perspective of a given system, other systems within the organization may be considered “external" to that system.

Further Discussion¶

Control and manage connections between your company network and outside networks. Outside networks could include the public internet, one of your own company’s networks that falls outside of your CMMC Assessment Scope (e.g., an isolated lab), or a network that does not belong to your company. Tools to accomplish include firewalls and connection allow/deny lists. External systems not controlled by your company could be running applications that are prohibited or blocked. Control and limit access to corporate networks from personally owned devices such as laptops, tablets, and phones. You may choose to limit how and when your network is connected to outside systems or only allow certain employees to connect to outside systems from network resources.

Examples¶

• Your company has a project that contains CUI. You remind your coworkers of the policy requirement to use their company laptops, not personal laptops or tablets, when working remotely on the project [b,f]. You also remind everyone to work from the cloud environment that is approved for processing and storing CUI rather than the other collaborative tools that may be used for other projects [b,f].

Potential Assessment Considerations¶

• Are all connections to external systems outside of the assessment scope identified [a]?
• Are external systems (e.g., systems managed by OSAs, partners, or vendors; personal devices) that are permitted to connect to or make use of organizational systems identified [b]?
• Are methods employed to ensure that only authorized connections are being made to external systems (e.g., requiring log-ins or certificates, access from a specific IP address, or access via Virtual Private Network (VPN)) [c,e]?
• Are methods employed to confirm that only authorized external systems are connecting (e.g., if employees are receiving company email on personal cell phones, is the OSA checking to verify that only known/expected devices are connecting) [d]?
• Is the use of external systems limited, including by policy or physical control [f]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.20
• FAR Clause 52.204-21 b.1.iii

AC.L2-3.1.21 – Portable Storage Use¶

Limit use of portable storage devices on external systems.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 18.

Determine if:

• [a] the use of portable storage devices containing CUI on external systems is identified and documented;
• [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
• [c] the use of portable storage devices containing CUI on external systems is limited as defined.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 18.

Examine: [SELECT FROM: Access control policy; procedures addressing the use of external systems; system security plan; system configuration settings and associated documentation; system connection or processing agreements; account management documents; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for restricting or prohibiting use of organization-controlled storage devices on external systems; system or network administrators; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms implementing restrictions on use of portable storage devices].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 16.

Limits on the use of organization-controlled portable storage devices in external systems include complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used. Note that while “external” typically refers to outside of the organization’s direct supervision and authority that is not always the case. Regarding the protection of CUI across an organization, the organization may have systems that process CUI and others that do not. Among the systems that process CUI there are likely access restrictions for CUI that apply between systems. Therefore, from the perspective of a given system, other systems within the organization may be considered “external" to that system.

Further Discussion¶

A portable storage device is a system component that can be inserted or attached and easily removed from a system. It is used to store data or information. Examples of portable storage devices include:

• compact/digital video disks (CDs/DVDs);
• Universal Serial Bus (USB) drives;
• external hard disk drives;
• flash memory cards/drives; and
• floppy disks.

This requirement can be implemented in two ways:

• identifying the portable storage device usage restrictions, identifying portable storage devices that may be used on external systems, identifying associated external systems on which a portable storage device may be used, and administratively (through the use of a written policy) limiting the usage of the devices to those systems; or
• configuring devices to work only when connected to a system to which the portable storage device can authenticate, limiting the devices’ use on external systems to those that the OSA has the ability to manage.

Examples¶

• Your organization, which stores and processes CUI, has a written portable device usage restriction policy. It states that users can only use external storage devices such as thumb dives or external hard disks that belong to the company. When needed for a specific business function, a user checks the device out from IT and returns it to IT when no longer needed [a,b].

Potential Assessment Considerations¶

• Are the portable storage devices authorized for external use identified and documented [a]?
• Are the circumstances defined in which portable storage devices containing CUI may be used on external systems (e.g., with management approval) [b]?
• Are limitations stipulated for the use of portable storage devices containing CUI on external systems (e.g., authorized personnel only, encrypted drives required) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.21

AC.L2-3.1.22 – Control Public Information [CUI Data]¶

Control CUI posted or processed on publicly accessible systems.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 18.

Determine if:

• [a] individuals authorized to post or process information on publicly accessible systems are identified;
• [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
• [c] a review process is in place prior to posting of any content to publicly accessible systems;
• [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
• [e] mechanisms are in place to remove and address improper posting of CUI.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 18.

Examine: [SELECT FROM: Access control policy; procedures addressing publicly accessible content; system security plan; list of users authorized to post publicly accessible content on organizational systems; training materials and/or records; records of publicly accessible information reviews; records of response to nonpublic information on public websites; system audit logs and records; security awareness training records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with responsibilities for managing publicly accessible information posted on organizational systems; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms implementing management of publicly accessible content].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 16.

In accordance with laws, Executive Orders, directives, policies, regulations, or standards, the public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act, CUI, and proprietary information). This requirement addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Individuals authorized to post CUI onto publicly accessible systems are designated. The content of information is reviewed prior to posting onto publicly accessible systems to ensure that nonpublic information is not included.

Further Discussion¶

Only government officials can be authorized to release CUI to the public. Do not allow CUI to become public – always safeguard the confidentiality of CUI by controlling the posting of CUI on company-controlled websites or public forums, and the exposure of CUI in public presentations or on public displays. It is important to know which users are allowed to publish information on publicly accessible systems, like your company website, and implement a review process before posting such information. If CUI is discovered on a publicly accessible system, procedures should be in place to remove that information and alert the appropriate parties.

Examples¶

• Your company decides to start issuing press releases about its projects in an effort to reach more potential customers. Your company receives CUI from the government as part of its DoD contract. Because you recognize the need to manage controlled information, including CUI, you meet with the employees who write the releases and post information to establish a review process [c]. It is decided that you will review press releases for CUI before posting it on the company website [a,d]. Only certain employees will be authorized to post to the website [a].

Potential Assessment Considerations¶

• Does information on externally facing systems (i.e., publicly accessible) have a documented approval chain for public release [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.1.22
• FAR Clause 52.204-21 b.1.iv