| Compliance |
The following 36 compliance controls are associated with this Policy definition 'Cognitive Services accounts should have local authentication methods disabled' (71ef260a-8f18-47b7-abcb-62d0673d94dc)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| CMMC_2.0_L2 |
AC.L1-3.1.1 |
CMMC_2.0_L2_AC.L1-3.1.1 |
404 not found |
|
|
|
n/a |
n/a |
|
57 |
| CMMC_2.0_L2 |
AC.L1-3.1.2 |
CMMC_2.0_L2_AC.L1-3.1.2 |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
| CMMC_2.0_L2 |
IA.L1-3.5.1 |
CMMC_2.0_L2_IA.L1-3.5.1 |
404 not found |
|
|
|
n/a |
n/a |
|
5 |
| CMMC_2.0_L2 |
IA.L1-3.5.2 |
CMMC_2.0_L2_IA.L1-3.5.2 |
404 not found |
|
|
|
n/a |
n/a |
|
18 |
| CMMC_2.0_L2 |
IA.L2-3.5.5 |
CMMC_2.0_L2_IA.L2-3.5.5 |
404 not found |
|
|
|
n/a |
n/a |
|
5 |
| CMMC_2.0_L2 |
IA.L2-3.5.6 |
CMMC_2.0_L2_IA.L2-3.5.6 |
404 not found |
|
|
|
n/a |
n/a |
|
6 |
| FedRAMP_High_R4 |
AC-2 |
FedRAMP_High_R4_AC-2 |
FedRAMP High AC-2 |
Access Control |
Account Management |
Shared |
n/a |
The organization:
a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
b. Assigns account managers for information system accounts;
c. Establishes conditions for group and role membership;
d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
g. Monitors the use of, information system accounts;
h. Notifies account managers:
1. When accounts are no longer required;
2. When users are terminated or transferred; and
3. When individual information system usage or need-to-know changes;
i. Authorizes access to the information system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the organization or associated missions/business functions;
j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a 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 (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.
References: None. |
link |
25 |
| FedRAMP_High_R4 |
AC-2(1) |
FedRAMP_High_R4_AC-2(1) |
FedRAMP High AC-2 (1) |
Access Control |
Automated System Account Management |
Shared |
n/a |
The organization employs automated mechanisms to support the management of information system accounts.
Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. |
link |
7 |
| FedRAMP_High_R4 |
AC-2(7) |
FedRAMP_High_R4_AC-2(7) |
FedRAMP High AC-2 (7) |
Access Control |
Role-Based Schemes |
Shared |
n/a |
The organization:
(a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;
(b) Monitors privileged role assignments; and
(c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.
Supplemental Guidance: 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. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. |
link |
10 |
| FedRAMP_High_R4 |
AC-3 |
FedRAMP_High_R4_AC-3 |
FedRAMP High AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, 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, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None. |
link |
21 |
| FedRAMP_High_R4 |
IA-2 |
FedRAMP_High_R4_IA-2 |
FedRAMP High IA-2 |
Identification And Authentication |
Identification And Authentication
(Organizational Users) |
Shared |
n/a |
The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).
Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is
obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network.
Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g.,
cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level
(i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8.
References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. |
link |
10 |
| FedRAMP_High_R4 |
IA-4 |
FedRAMP_High_R4_IA-4 |
FedRAMP High IA-4 |
Identification And Authentication |
Identifier Management |
Shared |
n/a |
The organization manages information system identifiers by:
a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier;
b. Selecting an identifier that identifies an individual, group, role, or device;
c. Assigning the identifier to the intended individual, group, role, or device;
d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and
e. Disabling the identifier after [Assignment: organization-defined time period of inactivity].
Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37.
References: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78. |
link |
7 |
| FedRAMP_Moderate_R4 |
AC-2 |
FedRAMP_Moderate_R4_AC-2 |
FedRAMP Moderate AC-2 |
Access Control |
Account Management |
Shared |
n/a |
The organization:
a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
b. Assigns account managers for information system accounts;
c. Establishes conditions for group and role membership;
d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
g. Monitors the use of, information system accounts;
h. Notifies account managers:
1. When accounts are no longer required;
2. When users are terminated or transferred; and
3. When individual information system usage or need-to-know changes;
i. Authorizes access to the information system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the organization or associated missions/business functions;
j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a 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 (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.
References: None. |
link |
25 |
| FedRAMP_Moderate_R4 |
AC-2(1) |
FedRAMP_Moderate_R4_AC-2(1) |
FedRAMP Moderate AC-2 (1) |
Access Control |
Automated System Account Management |
Shared |
n/a |
The organization employs automated mechanisms to support the management of information system accounts.
Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. |
link |
7 |
| FedRAMP_Moderate_R4 |
AC-2(7) |
FedRAMP_Moderate_R4_AC-2(7) |
FedRAMP Moderate AC-2 (7) |
Access Control |
Role-Based Schemes |
Shared |
n/a |
The organization:
(a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;
(b) Monitors privileged role assignments; and
(c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.
Supplemental Guidance: 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. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. |
link |
10 |
| FedRAMP_Moderate_R4 |
AC-3 |
FedRAMP_Moderate_R4_AC-3 |
FedRAMP Moderate AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, 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, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None. |
link |
21 |
| FedRAMP_Moderate_R4 |
IA-2 |
FedRAMP_Moderate_R4_IA-2 |
FedRAMP Moderate IA-2 |
Identification And Authentication |
Identification And Authentication (Organizational Users) |
Shared |
n/a |
The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).
Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is
obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network.
Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g.,
cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level
(i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8.
References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. |
link |
10 |
| FedRAMP_Moderate_R4 |
IA-4 |
FedRAMP_Moderate_R4_IA-4 |
FedRAMP Moderate IA-4 |
Identification And Authentication |
Identifier Management |
Shared |
n/a |
The organization manages information system identifiers by:
a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier;
b. Selecting an identifier that identifies an individual, group, role, or device;
c. Assigning the identifier to the intended individual, group, role, or device;
d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and
e. Disabling the identifier after [Assignment: organization-defined time period of inactivity].
Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37.
References: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78. |
link |
7 |
| NIST_SP_800-171_R2_3 |
.1.1 |
NIST_SP_800-171_R2_3.1.1 |
NIST SP 800-171 R2 3.1.1 |
Access Control |
Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
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 non-privileged) are addressed in requirement 3.1.2. |
link |
55 |
| NIST_SP_800-171_R2_3 |
.1.2 |
NIST_SP_800-171_R2_3.1.2 |
NIST SP 800-171 R2 3.1.2 |
Access Control |
Limit system access to the types of transactions and functions that authorized users are permitted to execute. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
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). |
link |
31 |
| NIST_SP_800-171_R2_3 |
.5.1 |
NIST_SP_800-171_R2_3.5.1 |
NIST SP 800-171 R2 3.5.1 |
Identification and Authentication |
Identify system users, processes acting on behalf of users, and devices. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Common device identifiers include Media Access Control (MAC), Internet Protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the user names associated with the system accounts assigned to those individuals. Organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. In addition, this requirement addresses individual identifiers that are not necessarily associated with system accounts. Organizational devices requiring identification may be defined by type, by device, or by a combination of type/device. [SP 800-63-3] provides guidance on digital identities. |
link |
9 |
| NIST_SP_800-171_R2_3 |
.5.2 |
NIST_SP_800-171_R2_3.5.2 |
NIST SP 800-171 R2 3.5.2 |
Identification and Authentication |
Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. [SP 800-63-3] provides guidance on digital identities. |
link |
24 |
| NIST_SP_800-171_R2_3 |
.5.5 |
NIST_SP_800-171_R2_3.5.5 |
NIST SP 800-171 R2 3.5.5 |
Identification and Authentication |
Prevent reuse of identifiers for a defined period. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Identifiers are provided for users, processes acting on behalf of users, or devices (3.5.1). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. |
link |
6 |
| NIST_SP_800-171_R2_3 |
.5.6 |
NIST_SP_800-171_R2_3.5.6 |
NIST SP 800-171 R2 3.5.6 |
Identification and Authentication |
Disable identifiers after a defined period of inactivity. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Inactive identifiers pose a risk to organizational information because attackers may exploit an inactive identifier to gain undetected access to organizational devices. The owners of the inactive accounts may not notice if unauthorized access to the account has been obtained. |
link |
6 |
| NIST_SP_800-53_R4 |
AC-2 |
NIST_SP_800-53_R4_AC-2 |
NIST SP 800-53 Rev. 4 AC-2 |
Access Control |
Account Management |
Shared |
n/a |
The organization:
a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
b. Assigns account managers for information system accounts;
c. Establishes conditions for group and role membership;
d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
g. Monitors the use of, information system accounts;
h. Notifies account managers:
1. When accounts are no longer required;
2. When users are terminated or transferred; and
3. When individual information system usage or need-to-know changes;
i. Authorizes access to the information system based on:
1. A valid access authorization;
2. Intended system usage; and
3. Other attributes as required by the organization or associated missions/business functions;
j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
Supplemental Guidance: Information system account types include individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a 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 (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.
References: None. |
link |
25 |
| NIST_SP_800-53_R4 |
AC-2(1) |
NIST_SP_800-53_R4_AC-2(1) |
NIST SP 800-53 Rev. 4 AC-2 (1) |
Access Control |
Automated System Account Management |
Shared |
n/a |
The organization employs automated mechanisms to support the management of information system accounts.
Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. |
link |
7 |
| NIST_SP_800-53_R4 |
AC-2(7) |
NIST_SP_800-53_R4_AC-2(7) |
NIST SP 800-53 Rev. 4 AC-2 (7) |
Access Control |
Role-Based Schemes |
Shared |
n/a |
The organization:
(a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;
(b) Monitors privileged role assignments; and
(c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.
Supplemental Guidance: 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. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. |
link |
10 |
| NIST_SP_800-53_R4 |
AC-3 |
NIST_SP_800-53_R4_AC-3 |
NIST SP 800-53 Rev. 4 AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, 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, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.
References: None. |
link |
21 |
| NIST_SP_800-53_R4 |
IA-2 |
NIST_SP_800-53_R4_IA-2 |
NIST SP 800-53 Rev. 4 IA-2 |
Identification And Authentication |
Identification And Authentication (Organizational Users) |
Shared |
n/a |
The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).
Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is
obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network.
Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g.,
cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level
(i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8.
References: HSPD-12; OMB Memoranda 04-04, 06-16, 11-11; FIPS Publication 201; NIST Special Publications 800-63, 800-73, 800-76, 800-78; FICAM Roadmap and Implementation Guidance; Web: http://idmanagement.gov. |
link |
10 |
| NIST_SP_800-53_R4 |
IA-4 |
NIST_SP_800-53_R4_IA-4 |
NIST SP 800-53 Rev. 4 IA-4 |
Identification And Authentication |
Identifier Management |
Shared |
n/a |
The organization manages information system identifiers by:
a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier;
b. Selecting an identifier that identifies an individual, group, role, or device;
c. Assigning the identifier to the intended individual, group, role, or device;
d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and
e. Disabling the identifier after [Assignment: organization-defined time period of inactivity].
Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37.
References: FIPS Publication 201; NIST Special Publications 800-73, 800-76, 800-78. |
link |
7 |
| NIST_SP_800-53_R5 |
AC-2 |
NIST_SP_800-53_R5_AC-2 |
NIST SP 800-53 Rev. 5 AC-2 |
Access Control |
Account Management |
Shared |
n/a |
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. |
link |
25 |
| NIST_SP_800-53_R5 |
AC-2(1) |
NIST_SP_800-53_R5_AC-2(1) |
NIST SP 800-53 Rev. 5 AC-2 (1) |
Access Control |
Automated System Account Management |
Shared |
n/a |
Support the management of system accounts using [Assignment: organization-defined automated mechanisms]. |
link |
7 |
| NIST_SP_800-53_R5 |
AC-2(7) |
NIST_SP_800-53_R5_AC-2(7) |
NIST SP 800-53 Rev. 5 AC-2 (7) |
Access Control |
Privileged User Accounts |
Shared |
n/a |
(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. |
link |
10 |
| NIST_SP_800-53_R5 |
AC-3 |
NIST_SP_800-53_R5_AC-3 |
NIST SP 800-53 Rev. 5 AC-3 |
Access Control |
Access Enforcement |
Shared |
n/a |
Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. |
link |
21 |
| NIST_SP_800-53_R5 |
IA-2 |
NIST_SP_800-53_R5_IA-2 |
NIST SP 800-53 Rev. 5 IA-2 |
Identification and Authentication |
Identification and Authentication (organizational Users) |
Shared |
n/a |
Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users. |
link |
10 |
| NIST_SP_800-53_R5 |
IA-4 |
NIST_SP_800-53_R5_IA-4 |
NIST SP 800-53 Rev. 5 IA-4 |
Identification and Authentication |
Identifier Management |
Shared |
n/a |
Manage system identifiers by:
a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, service, or device identifier;
b. Selecting an identifier that identifies an individual, group, role, service, or device;
c. Assigning the identifier to the intended individual, group, role, service, or device; and
d. Preventing reuse of identifiers for [Assignment: organization-defined time period]. |
link |
7 |
|