last sync: 2023-Jan-27 18:40:07 UTC

Azure Policy definition

A maximum of 3 owners should be designated for your subscription

Name A maximum of 3 owners should be designated for your subscription
Azure Portal
Id 4f11b553-d42e-4e3a-89be-32ca364cad4c
Version 3.0.0
details on versioning
Category Security Center
Microsoft docs
Description It is recommended to designate up to 3 subscription owners in order to reduce the potential for breach by a compromised owner.
Mode All
Type BuiltIn
Preview FALSE
Deprecated FALSE
Effect Default
AuditIfNotExists
Allowed
AuditIfNotExists, Disabled
RBAC
Role(s)
none
Rule
Aliases
THEN-ExistenceCondition (1)
Alias Namespace ResourceType DefaultPath Modifiable
Microsoft.Security/assessments/status.code Microsoft.Security assessments properties.status.code false
Rule
ResourceTypes
IF (1)
Microsoft.Resources/subscriptions
Compliance The following 50 compliance controls are associated with this Policy definition 'A maximum of 3 owners should be designated for your subscription' (4f11b553-d42e-4e3a-89be-32ca364cad4c)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
AU_ISM 1503 AU_ISM_1503 AU ISM 1503 Guidelines for Personnel Security - Access to systems and their resources Standard access to systems - 1503 n/a Standard access to systems, applications and data repositories is limited to that required for personnel to undertake their duties. link 6
AU_ISM 1508 AU_ISM_1508 AU ISM 1508 Guidelines for Personnel Security - Access to systems and their resources Privileged access to systems - 1508 n/a Privileged access to systems, applications and data repositories is limited to that required for personnel to undertake their duties. link 7
Azure_Security_Benchmark_v1.0 3.1 Azure_Security_Benchmark_v1.0_3.1 Azure Security Benchmark 3.1 Identity and Access Control Maintain an inventory of administrative accounts Customer Azure AD has built-in roles that must be explicitly assigned and are queryable. Use the Azure AD PowerShell module to perform ad hoc queries to discover accounts that are members of administrative groups. How to get a directory role in Azure AD with PowerShell: https://docs.microsoft.com/powershell/module/azuread/get-azureaddirectoryrole?view=azureadps-2.0 How to get members of a directory role in Azure AD with PowerShell: https://docs.microsoft.com/powershell/module/azuread/get-azureaddirectoryrolemember?view=azureadps-2.0 n/a link 4
Azure_Security_Benchmark_v1.0 3.3 Azure_Security_Benchmark_v1.0_3.3 Azure Security Benchmark 3.3 Identity and Access Control Use dedicated administrative accounts Customer Create standard operating procedures around the use of dedicated administrative accounts. Use Azure Security Center Identity and Access Management to monitor the number of administrative accounts. You can also enable a Just-In-Time / Just-Enough-Access by using Azure AD Privileged Identity Management Privileged Roles for Microsoft Services, and Azure Resource Manager. Learn more: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/ n/a link 5
Azure_Security_Benchmark_v2.0 PA-1 Azure_Security_Benchmark_v2.0_PA-1 Azure Security Benchmark PA-1 Privileged Access Protect and limit highly privileged users Customer Limit the number of highly privileged user accounts, and protect these accounts at an elevated level. The most critical built-in roles in Azure AD are Global Administrator and the Privileged Role Administrator, because users assigned to these two roles can delegate administrator roles. With these privileges, users can directly or indirectly read and modify every resource in your Azure environment: - Global Administrator / Company Administrator: Users with this role have access to all administrative features in Azure AD, as well as services that use Azure AD identities. - Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, as well as within Azure AD Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units. Note: You may have other critical roles that need to be governed if you use custom roles with certain privileged permissions assigned. And you may also want to apply similar controls to the administrator account of critical business assets. You can enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD Privileged Identity Management (PIM). JIT grants temporary permissions to perform privileged tasks only when users need it. PIM can also generate security alerts when there is suspicious or unsafe activity in your Azure AD organization. Administrator role permissions in Azure AD: https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-assign-admin-roles Use Azure Privileged Identity Management security alerts: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-how-to-configure-security-alerts Securing privileged access for hybrid and cloud deployments in Azure AD: https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-admin-roles-secure n/a link 4
Azure_Security_Benchmark_v3.0 PA-1 Azure_Security_Benchmark_v3.0_PA-1 Azure Security Benchmark PA-1 Privileged Access Separate and limit highly privileged/administrative users Shared **Security Principle:** Ensure you are identifying all high business impact accounts. Limit the number of privileged/administrative accounts in your cloud's control plane, management plane and data/workload plane. **Azure Guidance:** Azure Active Directory (Azure AD) is Azure's default identity and access management service. The most critical built-in roles in Azure AD are Global Administrator and Privileged Role Administrator, because users assigned to these two roles can delegate administrator roles. With these privileges, users can directly or indirectly read and modify every resource in your Azure environment: - Global Administrator / Company Administrator: Users with this role have access to all administrative features in Azure AD, as well as services that use Azure AD identities. - Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, as well as within Azure AD Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units. Outside of the Azure AD, Azure has built-in roles that can be critical for privileged access at the resource level. - Owner: Grants full access to manage all resources, including the ability to assign roles in Azure RBAC. - Contributor: Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries. - User Access Administrator: Lets you manage user access to Azure resources. Note: You may have other critical roles that need to be governed if you use custom roles in the Azure AD level or resource level with certain privileged permissions assigned. Ensure that you also restrict privileged accounts in other management, identity, and security systems that have administrative access to your business-critical assets, such as Active Directory Domain Controllers (DCs), security tools, and system management tools with agents installed on business critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business critical assets. **Implementation and additional context:** Administrator role permissions in Azure AD: https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-assign-admin-roles Use Azure Privileged Identity Management security alerts: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-how-to-configure-security-alerts Securing privileged access for hybrid and cloud deployments in Azure AD: https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-admin-roles-secure n/a link 6
CCCS AC-5 CCCS_AC-5 CCCS AC-5 Access Control Separation of Duties n/a (A) The organization: (a) Separate organization-defined duties of individuals including at least separation of operational, development, security monitoring, and management functions; (b) Documents separation of duties of individuals; and (c) Defines information system access authorizations to support separation of duties. link 7
CCCS AC-6 CCCS_AC-6 CCCS AC-6 Access Control Least Privilege n/a (A) The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. link 7
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.L2-3.1.5 CMMC_2.0_L2_AC.L2-3.1.5 404 not found n/a n/a 3
CMMC_L3 AC.3.017 CMMC_L3_AC.3.017 CMMC L3 AC.3.017 Access Control Separate the duties of individuals to reduce the risk of malevolent activity without collusion. Shared Microsoft and the customer share responsibilities for implementing this requirement. Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of organizational systems and system components when developing policy on separation of duties. link 4
CMMC_L3 SC.3.181 CMMC_L3_SC.3.181 CMMC L3 SC.3.181 System and Communications Protection Separate user functionality from system management functionality. Shared Microsoft and the customer share responsibilities for implementing this requirement. System management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from system management functionality is physical or logical. Organizations can implement separation of system management functionality from user functionality by using different computers, different central processing units, different instances of operating systems, or different network addresses; virtualization techniques; or combinations of these or other methods, as appropriate. This type of separation includes web administrative interfaces that use separate authentication methods for users of any other system resources. Separation of system and user functionality may include isolating administrative interfaces on different domains and with additional access controls. link 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-6 FedRAMP_High_R4_AC-6 FedRAMP High AC-6 Access Control Least Privilege Shared n/a The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Supplemental Guidance: Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2. References: None. link 4
FedRAMP_High_R4 AC-6(7) FedRAMP_High_R4_AC-6(7) FedRAMP High AC-6 (7) Access Control Review Of User Privileges Shared n/a The organization: (a) Reviews [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) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs. Supplemental Guidance: The need for certain assigned user privileges may change over time reflecting changes in organizational missions/business function, environments of operation, technologies, or threat. 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. Related control: CA-7. link 4
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-6 FedRAMP_Moderate_R4_AC-6 FedRAMP Moderate AC-6 Access Control Least Privilege Shared n/a The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Supplemental Guidance: Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2. References: None. link 4
hipaa 11112.01q2Organizational.67-01.q hipaa-11112.01q2Organizational.67-01.q 11112.01q2Organizational.67-01.q 11 Access Control 11112.01q2Organizational.67-01.q 01.05 Operating System Access Control Shared n/a The information system employs replay-resistant authentication mechanisms such as nonce, one-time passwords, or time stamps to secure network access for privileged accounts. 3
hipaa 1144.01c1System.4-01.c hipaa-1144.01c1System.4-01.c 1144.01c1System.4-01.c 11 Access Control 1144.01c1System.4-01.c 01.02 Authorized Access to Information Systems Shared n/a The organization explicitly authorizes access to specific security relevant functions (deployed in hardware, software, and firmware) and security-relevant information. 6
hipaa 1151.01c3System.1-01.c hipaa-1151.01c3System.1-01.c 1151.01c3System.1-01.c 11 Access Control 1151.01c3System.1-01.c 01.02 Authorized Access to Information Systems Shared n/a The organization limits authorization to privileged accounts on information systems to a pre-defined subset of users. 7
hipaa 1154.01c3System.4-01.c hipaa-1154.01c3System.4-01.c 1154.01c3System.4 - 01.c Privilege Management Contractors are provided with minimal system and physical access only after the organization assesses the contractor's ability to comply with its security requirements and the contractor agrees to comply. Customer n/a Master Supplier Service Agreement (MSSA)
Supplier Data Protection Requirements (DPR)
Sample of TVRA reports
1
IRS_1075_9.3 .1.5 IRS_1075_9.3.1.5 IRS 1075 9.3.1.5 Access Control Separation of Duties (AC-5) n/a The agency must: a. Separate duties of individuals to prevent harmful activity without collusion b. Document separation of duties of individuals c. Define information system access authorizations to support separation of duties link 7
IRS_1075_9.3 .1.6 IRS_1075_9.3.1.6 IRS 1075 9.3.1.6 Access Control Least Privilege (AC-6) n/a The agency must: a. 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 tasks in accordance with agency missions and business functions b. Explicitly authorize access to FTI (CE1) c. Require that users of information system accounts, or roles, with access to FTI, use non-privileged accounts or roles when accessing non-security functions (CE2) d. Restrict privileged accounts on the information system to a limited number of individuals with a need to perform administrative duties (CE5) The information system must: a. Audit the execution of privileged functions (CE9) b. Prevent non-privileged users from executing privileged functions; including disabling, circumventing, or altering implemented security safeguards/countermeasures (CE10) link 7
ISO27001-2013 A.6.1.2 ISO27001-2013_A.6.1.2 ISO 27001:2013 A.6.1.2 Organization of Information Security Segregation of Duties Shared n/a Conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization's assets. link 5
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.5 NIST_SP_800-171_R2_3.1.5 NIST SP 800-171 R2 3.1.5 Access Control Employ the principle of least privilege, including for specific security functions and privileged accounts. Shared Microsoft and the customer share responsibilities for implementing this requirement. Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions. Organizations consider the creation of additional processes, roles, and system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges). Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate in the application of this requirement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. link 8
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-6 NIST_SP_800-53_R4_AC-6 NIST SP 800-53 Rev. 4 AC-6 Access Control Least Privilege Shared n/a The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Supplemental Guidance: Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2. References: None. link 4
NIST_SP_800-53_R4 AC-6(7) NIST_SP_800-53_R4_AC-6(7) NIST SP 800-53 Rev. 4 AC-6 (7) Access Control Review Of User Privileges Shared n/a The organization: (a) Reviews [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) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs. Supplemental Guidance: The need for certain assigned user privileges may change over time reflecting changes in organizational missions/business function, environments of operation, technologies, or threat. 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. Related control: CA-7. link 4
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-6 NIST_SP_800-53_R5_AC-6 NIST SP 800-53 Rev. 5 AC-6 Access Control Least Privilege Shared n/a 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. link 4
NIST_SP_800-53_R5 AC-6(7) NIST_SP_800-53_R5_AC-6(7) NIST SP 800-53 Rev. 5 AC-6 (7) Access Control Review of User Privileges Shared n/a (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. link 4
NZ_ISM_v3.5 AC-9 NZ_ISM_v3.5_AC-9 NZISM Security Benchmark AC-9 Access Control and Passwords 16.3.5 Use of Privileged Accounts Customer n/a Inappropriate use of any feature or facility of a system that enables a privileged user to override system or application controls can be a major contributory factor to failures, information security incidents, or system breaches. link 1
NZISM_Security_Benchmark_v1.1 AC-9 NZISM_Security_Benchmark_v1.1_AC-9 NZISM Security Benchmark AC-9 Access Control and Passwords 16.3.5 Use of Privileged Accounts Customer Agencies SHOULD: - ensure strong change management practices are implemented; - ensure that the use of privileged accounts is controlled and accountable; - ensure that system administrators are assigned an individual account for the performance of their administration tasks; -keep privileged accounts to a minimum; and allow the use of privileged accounts for administrative work only. Inappropriate use of any feature or facility of a system that enables a privileged user to override system or application controls can be a major contributory factor to failures, information security incidents, or system breaches. link 1
PCI_DSS_V3.2.1 7.1.1 PCI_DSS_v3.2.1_7.1.1 PCI DSS v3.2.1 7.1.1 Requirement 7 PCI DSS requirement 7.1.1 customer n/a n/a link 2
PCI_DSS_V3.2.1 7.1.2 PCI_DSS_v3.2.1_7.1.2 PCI DSS v3.2.1 7.1.2 Requirement 7 PCI DSS requirement 7.1.2 shared n/a n/a link 2
PCI_DSS_V3.2.1 7.1.3 PCI_DSS_v3.2.1_7.1.3 PCI DSS v3.2.1 7.1.3 Requirement 7 PCI DSS requirement 7.1.3 customer n/a n/a link 2
PCI_DSS_v4.0 7.2.1 PCI_DSS_v4.0_7.2.1 PCI DSS v4.0 7.2.1 Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know Access to system components and data is appropriately defined and assigned Shared n/a An access control model is defined and includes granting access as follows: • Appropriate access depending on the entity’s business and access needs. • Access to system components and data resources that is based on users’ job classification and functions. • The least privileges required (for example, user, administrator) to perform a job function. link 10
PCI_DSS_v4.0 7.2.2 PCI_DSS_v4.0_7.2.2 PCI DSS v4.0 7.2.2 Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know Access to system components and data is appropriately defined and assigned Shared n/a Access is assigned to users, including privileged users, based on: • Job classification and function. • Least privileges necessary to perform job responsibilities. link 7
RBI_CSF_Banks_v2016 8.3 RBI_CSF_Banks_v2016_8.3 User Access Control / Management User Access Control / Management-8.3 n/a Disallow administrative rights on end-user workstations/PCs/laptops and provide access rights on a need to know basis and for specific duration when it is required following an established process. 5
RBI_CSF_Banks_v2016 8.5 RBI_CSF_Banks_v2016_8.5 User Access Control / Management User Access Control / Management-8.5 n/a Implement appropriate (e.g. centralised) systems and controls to allow, manage, log and monitor privileged/superuser/administrative access to critical systems (Servers/OS/DB, applications, network devices etc.). 12
RBI_ITF_NBFC_v2017 3.1.c RBI_ITF_NBFC_v2017_3.1.c RBI IT Framework 3.1.c Information and Cyber Security Role based Access Control-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Role based Access Control ??? Access to information should be based on well-defined user roles (system administrator, user manager, application owner etc.), NBFCs shall avoid dependence on one or few persons for a particular job. There should be clear delegation of authority for right to upgrade/change user profiles and permissions and also key business parameters (eg. interest rates) which should be documented. link 15
RBI_ITF_NBFC_v2017 3.1.f RBI_ITF_NBFC_v2017_3.1.f RBI IT Framework 3.1.f Information and Cyber Security Maker-checker-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Maker-checker is one of the important principles of authorization in the information systems of financial entities. For each transaction, there must be at least two individuals necessary for its completion as this will reduce the risk of error and will ensure reliability of information. link 24
SOC_2 CC5.2 SOC_2_CC5.2 SOC 2 Type 2 CC5.2 Control Activities COSO Principle 11 Shared The customer is responsible for implementing this recommendation. • Determines Dependency Between the Use of Technology in Business Processes and Technology General Controls — Management understands and determines the dependency and linkage between business processes, automated control activities, and technology general controls. • Establishes Relevant Technology Infrastructure Control Activities — Management selects and develops control activities over the technology infrastructure, which are designed and implemented to help ensure the completeness, accuracy, and availability of technology processing. • Establishes Relevant Security Management Process Controls Activities — Management selects and develops control activities that are designed and implemented to restrict technology access rights to authorized users commensurate with their job responsibilities and to protect the entity’s assets from external threats. • Establishes Relevant Technology Acquisition, Development, and Maintenance Process Control Activities — Management selects and develops control activities over the acquisition, development and maintenance of technology and its infrastructure to achieve management's objectives. 18
SOC_2 CC6.1 SOC_2_CC6.1 SOC 2 Type 2 CC6.1 Logical and Physical Access Controls Logical access security software, infrastructure, and architectures Shared The customer is responsible for implementing this recommendation. The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion: • Identifies and Manages the Inventory of Information Assets — The entity identifies, Page 29 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS inventories, classifies, and manages information assets. • Restricts Logical Access — Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative authorities, mobile devices, output, and offline system components is restricted through the use of access control software and rule sets. • Identifies and Authenticates Users — Persons, infrastructure, and software are identified and authenticated prior to accessing information assets, whether locally or remotely. • Considers Network Segmentation — Network segmentation permits unrelated portions of the entity's information system to be isolated from each other. • Manages Points of Access — Points of access by outside entities and the types of data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified, documented, and managed. • Restricts Access to Information Assets — Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets. • Manages Identification and Authentication — Identification and authentication requirements are established, documented, and managed for individuals and systems accessing entity information, infrastructure, and software. • Manages Credentials for Infrastructure and Software — New internal and external infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point. Credentials are removed and access is disabled when access is no longer required or the infrastructure and software are no longer in use. • Uses Encryption to Protect Data — The entity uses encryption to supplement other measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk. • Protects Encryption Keys — Processes are in place to protect encryption keys during generation, storage, use, and destruction 80
SOC_2 CC6.3 SOC_2_CC6.3 SOC 2 Type 2 CC6.3 Logical and Physical Access Controls Rol based access and least privilege Shared The customer is responsible for implementing this recommendation. • Creates or Modifies Access to Protected Information Assets — Processes are in place to create or modify access to protected information assets based on authorization from the asset’s owner. • Removes Access to Protected Information Assets — Processes are in place to remove access to protected information assets when an individual no longer requires access. • Uses Role-Based Access Controls — Role-based access control is utilized to support segregation of incompatible functions. • Reviews Access Roles and Rules — The appropriateness of access roles and access rules is reviewed on a periodic basis for unnecessary and inappropriate individuals with access and access rules are modified as appropriate 20
SWIFT_CSCF_v2021 1.2 SWIFT_CSCF_v2021_1.2 SWIFT CSCF v2021 1.2 SWIFT Environment Protection Operating System Privileged Account Control n/a Restrict and control the allocation and usage of administrator-level operating system accounts. link 12
SWIFT_CSCF_v2021 5.1 SWIFT_CSCF_v2021_5.1 SWIFT CSCF v2021 5.1 Manage Identities and Segregate Privileges Logical Access Control n/a Enforce the security principles of need-to-know access, least privilege, and segregation of duties for operator accounts. link 7
SWIFT_CSCF_v2022 1.2 SWIFT_CSCF_v2022_1.2 SWIFT CSCF v2022 1.2 1. Restrict Internet Access & Protect Critical Systems from General IT Environment Restrict and control the allocation and usage of administrator-level operating system accounts. Shared n/a Access to administrator-level operating system accounts is restricted to the maximum extent possible. Usage is controlled, monitored, and only permitted for relevant activities such as software installation and configuration, maintenance, and emergency activities. At all other times, an account with the least privilege access is used. link 22
SWIFT_CSCF_v2022 5.1 SWIFT_CSCF_v2022_5.1 SWIFT CSCF v2022 5.1 5. Manage Identities and Segregate Privileges Enforce the security principles of need-to-know access, least privilege, and separation of duties for operator accounts. Shared n/a Accounts are defined according to the security principles of need-to-know access, least privilege, and separation of duties. link 35
History
Date/Time (UTC ymd) (i) Change type Change detail
2021-01-05 16:06:49 change Major (2.0.0 > 3.0.0)
Initiatives
usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: Azure Security Benchmark v1 42a694ed-f65e-42b2-aa9e-8052e9740a92 Regulatory Compliance Deprecated BuiltIn
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn
[Deprecated]: DoD Impact Level 4 8d792a84-723c-4d92-a3c3-e4ed16a2d133 Regulatory Compliance Deprecated BuiltIn
[Preview]: Australian Government ISM PROTECTED 27272c0b-c225-4cc3-b8b0-f2534b093077 Regulatory Compliance Preview BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for NBFC 7f89f09c-48c1-f28d-1bd5-84f3fb22f86c Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2020 3e0c67fc-8c7c-406c-89bd-6b6bdc986a22 Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2021 abf84fac-f817-a70c-14b5-47eec767458a Regulatory Compliance Preview BuiltIn
Azure Security Benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
Canada Federal PBMM 4c4a5f27-de81-430b-b4e5-9cbd50595a87 Regulatory Compliance GA BuiltIn
CMMC Level 3 b5629c75-5c77-4422-87b9-2509e680f8de Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
IRS1075 September 2016 105e0327-6175-4eb2-9af4-1fba43bdb39d Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted d1a462af-7e6d-4901-98ac-61570b4ed22a Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
PCI DSS v4 c676748e-3af9-4e22-bc28-50feed564afb Regulatory Compliance GA BuiltIn
PCI v3.2.1:2018 496eeda9-8f2f-4d5e-8dfd-204f0a92ed41 Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
JSON
changes

JSON