FEDRAMP Moderate.xlsx
XLSX spreadsheet 573 KB Posted
- Attached to
- Human Capital Management
- Solicitation number
- HHM402-24-Q-0001
- Issued by
-
Defense Intelligence Agency
About this file
This document provides details of a solicitation for human capital management services. The Defense Intelligence Agency is seeking proposals for providing services such as training, recruiting, and personnel administration. Offerors should submit proposals by the date listed in the solicitation to be considered for an award, which is expected to be made in the following months. Pricing is to be provided using labor categories and rates defined in the solicitation. The contract has a one year base period and may include option years extending up to a total of five years.
View the file
Other files
Show all 38
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
High Baseline
| (U) | NIST 800-53 Security Controls Catalog Revision 5 | FedRAMP® High Baseline | |||
| SORT ID | Family | ID | Control Name | NIST Control Description | |
| (From NIST SP 800-53r5 12/10/2020) | NIST Discussion | ||||
| (From NIST SP 800-53r5 12/10/2020) | H FedRAMP-Defined Assignment / Selection Parameters | ||||
| (Numbering matches SSP) | H Additional FedRAMP Requirements and Guidance | FedRAMP |
Parameter AC-01 ACCESS CONTROL AC-1 Policy and Procedures a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]:
1. [Selection (one or more): Organization-level; Mission/business process-level; System-level] access control policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the access control policy and the associated access controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the access control policy and procedures; and
c. Review and update the current access control:
1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and
| 2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]. | Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls 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 and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. | AC-1 (c) (1) [at least annually] | |||
| AC-1 (c) (2) [at least annually] [significant changes] | X | ||||
| AC-02 | ACCESS CONTROL | AC-2 | Account Management | a. Define and document the types of accounts allowed and specifically prohibited for use within the system; |
b. Assign account managers;
c. Require [Assignment: organization-defined prerequisites and criteria] for group and role membership;
d. Specify:
1. Authorized users of the system;
2. Group and role membership; and
3. Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes (as required)] for each account;
e. Require approvals by [Assignment: organization-defined personnel or roles] for requests to create accounts;
f. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria];
g. Monitor the use of accounts;
h. Notify account managers and [Assignment: organization-defined personnel or roles] within:
1. [Assignment: organization-defined time period] when accounts are no longer required;
2. [Assignment: organization-defined time period] when users are terminated or transferred; and
3. [Assignment: organization-defined time period] when system usage or need-to-know changes for an individual;
i. Authorize access to the system based on:
1. A valid access authorization;
2. Intended system usage; and
3. [Assignment: organization-defined attributes (as required)];
j. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];
k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and
l. Align account management processes with personnel termination and transfer processes. Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.
Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.
Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training. AC-2 (h) (1) [twenty-four (24) hours] AC-2 (h) (2) [eight (8) hours] AC-2 (h) (3) [eight (8) hours]
| AC-2 (j) [monthly for privileged accessed, every six (6) months for non-privileged access] | X | ||||||
| AC-02 (01) | ACCESS CONTROL | AC-2 (1) | Account Management | Automated System Account Management | Support the management of system accounts using [Assignment: organization-defined automated mechanisms]. | Automated system account management includes using automated mechanisms to create, enable, modify, disable, and remove accounts; notify account managers when an account is created, enabled, modified, disabled, or removed, or when users are terminated or transferred; monitor system account usage; and report atypical system account usage. Automated mechanisms can include internal system functions and email, telephonic, and text messaging notifications. | ||
| AC-02 (02) | ACCESS CONTROL | AC-2 (2) | Account Management | Automated Temporary and Emergency Account Management | Automatically [Selection: remove; disable] temporary and emergency accounts after [Assignment: organization-defined time period for each type of account]. | Management of temporary and emergency accounts includes the removal or disabling of such accounts automatically after a predefined time period rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation. | AC-2 (2) [Selection: disables] | |
| [Assignment: no more than 24 hours from last use] | X | ||||||
| AC-02 (03) | ACCESS CONTROL | AC-2 (3) | Account Management | Disable Accounts | Disable accounts within [Assignment: organization-defined time period] when the accounts: |
(a) Have expired;
(b) Are no longer associated with a user or individual;
(c) Are in violation of organizational policy; or
| (d) Have been inactive for [Assignment: organization-defined time period]. | Disabling expired, inactive, or otherwise anomalous accounts supports the concepts of least privilege and least functionality which reduce the attack surface of the system. | AC-2 (3) [24 hours for user accounts] |
| AC-2 (3) (d) [thirty-five (35) days] (See additional requirements and guidance.) | AC-2 (3) Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices). The time periods are approved and accepted by the JAB/AO. Where user management is a function of the service, reports of activity of consumer users shall be made available. |
AC-2 (3) (d) Requirement: The service provider defines the time period of inactivity for device identifiers.
Guidance: For DoD clouds, see DoD cloud website for specific DoD requirements that go above and beyond FedRAMP https://public.cyber.mil/dccs/.
| X | ||||||||
| AC-02 (04) | ACCESS CONTROL | AC-2 (4) | Account Management | Automated Audit Actions | Automatically audit account creation, modification, enabling, disabling, and removal actions. | Account management audit records are defined in accordance with AU-2 and reviewed, analyzed, and reported in accordance with AU-6. | |||
| AC-02 (05) | ACCESS CONTROL | AC-2 (5) | Account Management | Inactivity Logout | Require that users log out when [Assignment: organization-defined time period of expected inactivity or description of when to log out]. | 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 AC-11. | AC-2 (5) [inactivity is anticipated to exceed Fifteen (15) minutes] | AC-2 (5) Guidance: Should use a shorter timeframe than AC-12. | X |
| AC-02 (07) | ACCESS CONTROL | AC-2 (7) | Account Management | Privileged User Accounts | (a) Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme; an attribute-based access scheme]; |
(b) Monitor privileged role or attribute assignments;
(c) Monitor changes to roles or attributes; and
| (d) Revoke access when privileged role or attribute assignments are no longer appropriate. | Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. Privileged roles include key management, account management, database administration, system and network administration, and web administration. A role-based access scheme organizes permitted system access and privileges into roles. In contrast, an attribute-based access scheme specifies allowed system access and privileges based on attributes. | |||||||
| AC-02 (09) | ACCESS CONTROL | AC-2 (9) | Account Management | Restrictions on Use of Shared and Group Accounts | Only permit the use of shared and group accounts that meet [Assignment: organization-defined conditions for establishing shared and group accounts]. | Before permitting the use of shared or group accounts, organizations consider the increased risk due to the lack of accountability with such accounts. | AC-2 (9) [organization-defined need with justification statement that explains why such accounts are necessary] | AC-2 (9) Requirement: Required if shared/group accounts are deployed | |
| X | ||||||||
| AC-02 (11) | ACCESS CONTROL | AC-2 (11) | Account Management | Usage Conditions | Enforce [Assignment: organization-defined circumstances and/or usage conditions] for [Assignment: organization-defined system accounts]. | Specifying and enforcing usage conditions helps to enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. Account monitoring includes alerts generated if the account is used in violation of organizational parameters. Organizations can describe specific conditions or circumstances under which system accounts can be used, such as by restricting usage to certain days of the week, time of day, or specific durations of time. | |||
| AC-02 (12) | ACCESS CONTROL | AC-2 (12) | Account Management | Account Monitoring for Atypical Usage | (a) Monitor system accounts for [Assignment: organization-defined atypical usage]; and | ||||
| (b) Report atypical usage of system accounts to [Assignment: organization-defined personnel or roles]. | Atypical usage includes accessing systems at certain times of the day or from locations that are not consistent with the normal usage patterns of individuals. Monitoring for atypical usage may reveal rogue behavior by individuals or an attack in progress. Account monitoring may inadvertently create privacy risks since data collected to identify atypical usage may reveal previously unknown information about the behavior of individuals. Organizations assess and document privacy risks from monitoring accounts for atypical usage in their privacy impact assessment and make determinations that are in alignment with their privacy program plan. | AC-2 (12) (b)[at a minimum, the ISSO and/or similar role within the organization] | AC-2 (12) (a) Requirement: Required for privileged accounts. |
AC-2 (12) (b) Requirement: Required for privileged accounts.
| X | |||||||
| AC-02 (13) | ACCESS CONTROL | AC-2 (13) | Account Management | Disable Accounts for High-risk Individuals | Disable accounts of individuals within [Assignment: organization-defined time period] of discovery of [Assignment: organization-defined significant risks]. | Users who pose a significant security and/or privacy risk include individuals for whom reliable evidence indicates either the intention to use authorized access to systems to cause harm or through whom adversaries will cause harm. Such harm includes adverse impacts to organizational operations, organizational assets, individuals, other organizations, or the Nation. Close coordination among system administrators, legal staff, human resource managers, and authorizing officials is essential when disabling system accounts for high-risk individuals. | AC-2 (13)-1 [one (1) hour] | X |
| AC-03 | ACCESS CONTROL | AC-3 | Access Enforcement | Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. | Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection (PE) family. | ||
| AC-04 | ACCESS CONTROL | AC-4 | Information Flow Enforcement | Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies]. | Information flow control regulates where information can travel 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 blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see CA-3). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security or privacy attributes and labels. |
Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ 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. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS).
| AC-04 (04) | ACCESS CONTROL | AC-4 (4) | Information Flow Enforcement | Flow Control of Encrypted Information | Prevent encrypted information from bypassing [Assignment: organization-defined information flow control mechanisms] by [Selection (one or more): decrypting the information; blocking the flow of the encrypted information; terminating communications sessions attempting to pass encrypted information; [Assignment: organization-defined procedure or method]]. | Flow control mechanisms include content checking, security policy filters, and data type identifiers. The term encryption is extended to cover encoded data not recognized by filtering mechanisms. | AC-4 (4)-1 [intrusion detection mechanisms] | AC-4 (4) Requirement: The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf) and M-22-09 (https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf). | X | |
| AC-04 (21) | ACCESS CONTROL | AC-4 (21) | Information Flow Enforcement | Physical or Logical Separation of Information Flows | Separate information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization-defined required separations by types of information]. | Enforcing the separation of information flows associated with defined types of data can enhance protection by ensuring that information is not commingled while in transit and by enabling flow control by transmission paths that are not otherwise achievable. Types of separable information include inbound and outbound communications traffic, service requests and responses, and information of differing security impact or classification levels. | ||||
| AC-05 | ACCESS CONTROL | AC-5 | Separation of Duties | a. Identify and document [Assignment: organization-defined duties of individuals requiring separation]; and | |||||
| b. Define system access authorizations to support separation of duties. | 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 or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security 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 systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in AC-2, access control mechanisms in AC-3, and identity management activities in IA-2, IA-4, and IA-12. | AC-5 Guidance: CSPs have the option to provide a separation of duties matrix as an attachment to the SSP. |
| AC-06 | ACCESS CONTROL | AC-6 | Least Privilege | Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks. | Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems. |
| AC-06 (01) | ACCESS CONTROL | AC-6 (1) | Least Privilege | Authorize Access to Security Functions | Authorize access for [Assignment: organization-defined individuals or roles] to: |
(a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware)]; and
| (b) [Assignment: organization-defined security-relevant information]. | Security functions include establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters. Security-relevant information includes filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, and access control lists. Authorized personnel include security administrators, system administrators, system security officers, system programmers, and other privileged users. | AC-6 (1) (a) [all functions not publicly accessible] | |||||||
| AC-6 (1) (b) [all security-relevant information not publicly available] | X | ||||||||
| AC-06 (02) | ACCESS CONTROL | AC-6 (2) | Least Privilege | Non-privileged Access for Nonsecurity Functions | Require that users of system accounts (or roles) with access to [Assignment: organization-defined security functions or security-relevant information] use non-privileged accounts or roles, when accessing nonsecurity functions. | Requiring the use of non-privileged accounts when accessing nonsecurity functions 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 the processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. | AC-6 (2) [all security functions] | AC-6 (2) Guidance: Examples of security functions include but are not limited to: establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters, system programming, system and security administration, other privileged functions. | ||
| X | |||||||||
| AC-06 (03) | ACCESS CONTROL | AC-6 (3) | Least Privilege | Network Access to Privileged Commands | Authorize network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and document the rationale for such access in the security plan for the system. | Network access is any access across a network connection in lieu of local access (i.e., user being physically present at the device). | AC-6 (3)-1 [all privileged commands] | X | ||
| AC-06 (05) | ACCESS CONTROL | AC-6 (5) | Least Privilege | Privileged Accounts | Restrict privileged accounts on the system to [Assignment: organization-defined personnel or roles]. | 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 accessing privileged information or privileged functions. Organizations may differentiate in the application of restricting privileged accounts between allowed privileges for local accounts and for domain accounts provided that they retain the ability to control system configurations for key parameters and as otherwise necessary to sufficiently mitigate risk. | ||||
| AC-06 (07) | ACCESS CONTROL | AC-6 (7) | Least Privilege | Review of User Privileges | (a) Review [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and | |||||
| (b) Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs. | The need for certain assigned user privileges may change over time to reflect changes in organizational mission and business functions, environments of operation, technologies, or threats. A periodic review of assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, organizations take appropriate corrective actions. | AC-6 (7) (a)-1 [at a minimum, annually] | |||||||
| AC-6 (7) (a)-2 [all users with privileges] | X | ||||||||
| AC-06 (08) | ACCESS CONTROL | AC-6 (8) | Least Privilege | Privilege Levels for Code Execution | Prevent the following software from executing at higher privilege levels than users executing the software: [Assignment: organization-defined software]. | In certain situations, software applications or programs need to execute with elevated privileges to perform required functions. However, depending on the software functionality and configuration, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications or programs, those users may indirectly be provided with greater privileges than assigned. | AC-6 (8) [any software except software explicitly documented] | X | ||
| AC-06 (09) | ACCESS CONTROL | AC-6 (9) | Least Privilege | Log Use of Privileged Functions | Log the execution of privileged functions. | The 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 and analyzing 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. | ||||
| AC-06 (10) | ACCESS CONTROL | AC-6 (10) | Least Privilege | Prohibit Non-privileged Users from Executing Privileged Functions | Prevent non-privileged users from executing privileged functions. | Privileged functions include disabling, circumventing, or altering implemented security or privacy controls, establishing system accounts, performing system integrity checks, and administering cryptographic key management activities. Non-privileged users are individuals who do not possess appropriate authorizations. Privileged functions that require protection from non-privileged users include circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms. Preventing non-privileged users from executing privileged functions is enforced by AC-3. | ||||
| AC-07 | ACCESS CONTROL | AC-7 | Unsuccessful Logon Attempts | a. Enforce a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and | |||||
| b. Automatically [Selection (one or more): lock the account or node for an [Assignment: organization-defined time period]; lock the account or node until released by an administrator; delay next logon prompt per [Assignment: organization-defined delay algorithm]; notify system administrator; take other [Assignment: organization-defined action]] when the maximum number of unsuccessful attempts is exceeded. | The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded 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 usually temporary and automatically release after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded 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 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. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need. | AC-7 Requirement: In alignment with NIST SP 800-63B |
AC-08 ACCESS CONTROL AC-8 System Use Notification a. Display [Assignment: organization-defined system use notification message or banner] to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:
1. Users are accessing a U.S. Government system;
2. System usage may be monitored, recorded, and subject to audit;
3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and
4. Use of the system indicates consent to monitoring and recording;
b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and
c. For publicly accessible systems:
1. Display system use information [Assignment: organization-defined conditions], before granting further access to the publicly accessible system;
2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and
| 3. Include a description of the authorized uses of the system. | System use notifications can be implemented using messages or warning banners displayed before individuals log in to systems. System use notifications are used only for access via logon interfaces with human users. Notifications are not required when human interfaces do not exist. Based on an assessment of risk, organizations consider whether or not a secondary system use notification is needed to access applications or other system resources after the initial network logon. Organizations consider system use notification messages or banners displayed in multiple languages based on organizational needs and the demographics of system users. Organizations consult with the privacy office for input regarding privacy messaging and the Office of the General Counsel or organizational equivalent for legal review and approval of warning banner content. | AC-8 (a) [see additional Requirements and Guidance] |
| AC-8 (c) (1) [see additional Requirements and Guidance] | AC-8 Requirement: The service provider shall determine elements of the cloud environment that require the System Use Notification control. The elements of the cloud environment that require System Use Notification are approved and accepted by the JAB/AO. |
Requirement: The service provider shall determine how System Use Notification is going to be verified and provide appropriate periodicity of the check. The System Use Notification verification and periodicity are approved and accepted by the JAB/AO.
Requirement: If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO.
| Guidance: If performed as part of a Configuration Baseline check, then the % of items requiring setting that are checked and that pass (or fail) check can be provided. | X | |||||||
| AC-10 | ACCESS CONTROL | AC-10 | Concurrent Session Control | Limit the number of concurrent sessions for each [Assignment: organization-defined account and/or account type] to [Assignment: organization-defined number]. | Organizations may define the maximum number of concurrent sessions for system accounts globally, by account type, by account, or any combination thereof. For example, organizations may limit the number of concurrent sessions for system administrators or other individuals working in particularly sensitive domains or mission-critical applications. Concurrent session control addresses concurrent sessions for system accounts. It does not, however, address concurrent sessions by single users via multiple system accounts. | AC-10-2 [three (3) sessions for privileged access and two (2) sessions for non-privileged access] | X | |
| AC-11 | ACCESS CONTROL | AC-11 | Device Lock | a. Prevent further access to the system by [Selection (one or more): initiating a device lock after [Assignment: organization-defined time period] of inactivity; requiring the user to initiate a device lock before leaving the system unattended]; and | ||||
| b. Retain the device lock until the user reestablishes access using established identification and authentication procedures. | Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks can be implemented at the operating system level or at the application level. A proximity lock may be used to initiate the device lock (e.g., via a Bluetooth-enabled device or dongle). User-initiated device locking is behavior or policy-based and, as such, requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of systems, such as when organizations require users to log out at the end of workdays. | AC-11 (a) [fifteen (15) minutes]; requiring the user to initiate a device lock before leaving the system unattended | X | |||||
| AC-11 (01) | ACCESS CONTROL | AC-11 (1) | Device Lock | Pattern-hiding Displays | Conceal, via the device lock, information previously visible on the display with a publicly viewable image. | The pattern-hiding display can include static or dynamic images, such as patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen with the caveat that controlled unclassified information is not displayed. | |||
| AC-12 | ACCESS CONTROL | AC-12 | Session Termination | Automatically terminate a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect]. | Session termination addresses the termination of user-initiated logical sessions (in contrast to SC-10, which addresses the termination of network connections associated with communications sessions (i.e., network disconnect)). 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 without terminating network sessions. Session termination ends all processes associated with a user’s logical session except for those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events that require automatic termination of the session include organization-defined periods of user inactivity, targeted responses to certain types of incidents, or time-of-day restrictions on system use. | |||
| AC-14 | ACCESS CONTROL | AC-14 | Permitted Actions Without Identification or Authentication | a. Identify [Assignment: organization-defined user actions] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and | ||||
| b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication. | Specific user actions may be permitted without identification or authentication if organizations determine that identification and authentication are not required for the specified user actions. Organizations may allow a limited number of user actions without identification or authentication, including when individuals access public websites or other publicly accessible federal systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations identify actions that normally require identification or authentication but may, under certain circumstances, allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. Permitting actions without identification or authentication does not apply to situations where identification and authentication have already occurred and are not repeated but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational systems without identification and authentication, and therefore, the value for the assignment operation can be none. | |||||||
| AC-17 | ACCESS CONTROL | AC-17 | Remote Access | a. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and | ||||
| b. Authorize each type of remote access to the system prior to allowing such connections. | Remote access is access to organizational systems (or processes acting on behalf of users) that communicate through external networks such as the Internet. Types of remote access include dial-up, broadband, and wireless. Organizations use encrypted virtual private networks (VPNs) to enhance confidentiality and integrity for remote connections. The use of encrypted VPNs provides sufficient assurance to the organization that it can effectively treat such connections as internal networks if the cryptographic mechanisms used are implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. VPNs with encrypted tunnels can also affect the ability to adequately monitor network communications traffic for malicious code. Remote access controls apply to systems other than public web servers or systems designed for public access. Authorization of each remote access type addresses authorization prior to allowing remote access without specifying the specific formats for such authorization. While organizations may use information exchange and system connection security agreements to manage remote access connections to other systems, such agreements are addressed as part of CA-3. Enforcing access restrictions for remote access is addressed via AC-3. | |||||||
| AC-17 (01) | ACCESS CONTROL | AC-17 (1) | Remote Access | Monitoring and Control | Employ automated mechanisms to monitor and control remote access methods. | Monitoring and control of remote access methods allows organizations to detect attacks and help ensure compliance with remote access policies by auditing the connection activities of remote users on a variety of system components, including servers, notebook computers, workstations, smart phones, and tablets. Audit logging for remote access is enforced by AU-2. Audit events are defined in AU-2a. | |||
| AC-17 (02) | ACCESS CONTROL | AC-17 (2) | Remote Access | Protection of Confidentiality and Integrity Using Encryption | Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions. | Virtual private networks can be used to protect the confidentiality and integrity of remote access sessions. Transport Layer Security (TLS) is an example of a cryptographic protocol that provides end-to-end communications security over networks and is used for Internet communications and online transactions. | |||
| AC-17 (03) | ACCESS CONTROL | AC-17 (3) | Remote Access | Managed Access Control Points | Route remote accesses through authorized and managed network access control points. | Organizations consider the Trusted Internet Connections (TIC) initiative DHS TIC requirements for external network connections since limiting the number of access control points for remote access reduces attack surfaces. | |||
| AC-17 (04) | ACCESS CONTROL | AC-17 (4) | Remote Access | Privileged Commands and Access | (a) Authorize the execution of privileged commands and access to security-relevant information via remote access only in a format that provides assessable evidence and for the following needs: [Assignment: organization-defined needs]; and | ||||
| (b) Document the rationale for remote access in the security plan for the system. | Remote access to systems represents a significant potential vulnerability that can be exploited by adversaries. As such, restricting the execution of privileged commands and access to security-relevant information via remote access reduces the exposure of the organization and the susceptibility to threats by adversaries to the remote access capability. | |||||||
| AC-18 | ACCESS CONTROL | AC-18 | Wireless Access | a. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and | ||||
| b. Authorize each type of wireless access to the system prior to allowing such connections. | Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. Wireless networks use authentication protocols that provide authenticator protection and mutual authentication. | |||||||
| AC-18 (01) | ACCESS CONTROL | AC-18 (1) | Wireless Access | Authentication and Encryption | Protect wireless access to the system using authentication of [Selection (one or more): users; devices] and encryption. | Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries. To protect systems with wireless access points, strong authentication of users and devices along with strong encryption can reduce susceptibility to threats by adversaries involving wireless technologies. | |||
| AC-18 (03) | ACCESS CONTROL | AC-18 (3) | Wireless Access | Disable Wireless Networking | Disable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment. | Wireless networking capabilities that are embedded within system components represent a significant potential vulnerability that can be exploited by adversaries. Disabling wireless capabilities when not needed for essential organizational missions or functions can reduce susceptibility to threats by adversaries involving wireless technologies. | |||
| AC-18 (04) | ACCESS CONTROL | AC-18 (4) | Wireless Access | Restrict Configurations by Users | Identify and explicitly authorize users allowed to independently configure wireless networking capabilities. | Organizational authorizations to allow selected users to configure wireless networking capabilities are enforced, in part, by the access enforcement mechanisms employed within organizational systems. | |||
| AC-18 (05) | ACCESS CONTROL | AC-18 (5) | Wireless Access | Antennas and Transmission Power Levels | Select radio antennas and calibrate transmission power levels to reduce the probability that signals from wireless access points can be received outside of organization-controlled boundaries. | Actions that may be taken to limit unauthorized use of wireless communications outside of organization-controlled boundaries include reducing the power of wireless transmissions so that the transmissions are less likely to emit a signal that can be captured outside of the physical perimeters of the organization, employing measures such as emissions security to control wireless emanations, and using directional or beamforming antennas that reduce the likelihood that unintended receivers will be able to intercept signals. Prior to taking such mitigating actions, organizations can conduct periodic wireless surveys to understand the radio frequency profile of organizational systems as well as other systems that may be operating in the area. | |||
| AC-19 | ACCESS CONTROL | AC-19 | Access Control for Mobile Devices | a. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and | ||||
| b. Authorize the connection of mobile devices to organizational systems. | 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; possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile device functionality may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of notebook/desktop systems, depending on the nature and intended purpose of the device. Protection and control of mobile devices is behavior or policy-based and requires users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which organizations provide physical or procedural controls to meet the requirements established for protecting information and systems. |
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 and specific implementation guidance for mobile devices include configuration management, device identification and authentication, implementation of mandatory protective software, scanning devices for malicious code, updating virus…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .