last sync: 2024-Oct-04 17:51:30 UTC

Guest accounts with read permissions on Azure resources should be removed

Azure BuiltIn Policy definition

Source Azure Portal
Display name Guest accounts with read permissions on Azure resources should be removed
Id e9ac8f8e-ce22-4355-8f04-99b911d6be52
Version 1.0.0
Details on versioning
Versioning Versions supported for Versioning: 1
1.0.0
Built-in Versioning [Preview]
Category Security Center
Microsoft Learn
Description External accounts with read privileges should be removed from your subscription in order to prevent unmonitored access.
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 Path PathIsDefault DefaultPath Modifiable
Microsoft.Security/assessments/status.code Microsoft.Security assessments properties.status.code True False
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 51 compliance controls are associated with this Policy definition 'Guest accounts with read permissions on Azure resources should be removed' (e9ac8f8e-ce22-4355-8f04-99b911d6be52)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v1.0 3.10 Azure_Security_Benchmark_v1.0_3.10 Azure Security Benchmark 3.10 Identity and Access Control Regularly review and reconcile user access Customer Microsoft Entra ID provides logs to help discover stale accounts. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. User access can be reviewed on a regular basis to make sure only the right Users have continued access. Understand Microsoft Entra reporting: https://docs.microsoft.com/azure/active-directory/reports-monitoring/ How to use Azure Identity Access Reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview n/a link 5
Azure_Security_Benchmark_v2.0 PA-3 Azure_Security_Benchmark_v2.0_PA-3 Azure Security Benchmark PA-3 Privileged Access Review and reconcile user access regularly Customer Review user accounts and access assignment regularly to ensure the accounts and their level of access are valid. You can use Microsoft Entra access reviews to review group memberships, access to enterprise applications, and role assignments. Microsoft Entra reporting can provide logs to help discover stale accounts. You can also use Microsoft Entra Privileged Identity Management to create an access review report workflow that facilitates the review process. In addition, Azure Privileged Identity Management can be configured to alert when an excessive number of administrator accounts are created, and to identify administrator accounts that are stale or improperly configured. Note: Some Azure services support local users and roles that aren't managed through Microsoft Entra ID. You must manage these users separately. Create an access review of Azure resource roles in Privileged Identity Management(PIM): https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-resource-roles-start-access-review How to use Microsoft Entra identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview n/a link 5
Azure_Security_Benchmark_v3.0 PA-4 Azure_Security_Benchmark_v3.0_PA-4 Microsoft cloud security benchmark PA-4 Privileged Access Review and reconcile user access regularly Shared **Security Principle:** Conduct regular review of privileged account entitlements. Ensure the access granted to the accounts are valid for administration of control plane, management plane, and workloads. **Azure Guidance:** Review all privileged accounts and the access entitlements in Azure including such as Azure tenant, Azure services, VM/IaaS, CI/CD processes, and enterprise management and security tools. Use Microsoft Entra access reviews to review Microsoft Entra roles and Azure resource access roles, group memberships, access to enterprise applications. Microsoft Entra reporting can also provide logs to help discover stale accounts, accounts not being used for certain amount of time. In addition, Microsoft Entra Privileged Identity Management can be configured to alert when an excessive number of administrator accounts are created for a specific role, and to identify administrator accounts that are stale or improperly configured. **Implementation and additional context:** Create an access review of Azure resource roles in Privileged Identity Management (PIM): https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-resource-roles-start-access-review How to use Microsoft Entra identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview n/a link 5
CCCS AC-2 CCCS_AC-2 CCCS AC-2 Access Control Account Management n/a (A) The organization identifies and selects which types of information system accounts support organizational missions/business functions. (B) The organization assigns account managers for information system accounts. (C) The organization establishes conditions for group and role membership. (D) The organization 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) The organization requires approvals by responsible managers for requests to create information system accounts. (F) The organization creates, enables, modifies, disables, and removes information system accounts in accordance with information system account management procedures. (G) The organization monitors the use of information system accounts. (H) The organization notifies account managers: (a) When accounts are no longer required; (b) When users are terminated or transferred; and (c) When individual information system usage or need-to-know changes. (I) The organization authorizes access to the information system based on: (a) A valid access authorization; (b) Intended system usage; and (c) Other attributes as required by the organization or associated missions/business functions. (J) The organization reviews accounts for compliance with account management requirements at least annually. (K) The organization establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. link 5
CIS_Azure_1.1.0 1.3 CIS_Azure_1.1.0_1.3 CIS Microsoft Azure Foundations Benchmark recommendation 1.3 1 Identity and Access Management Ensure that there are no guest users Shared The customer is responsible for implementing this recommendation. Do not add guest users if not needed. link 8
CIS_Azure_1.3.0 1.3 CIS_Azure_1.3.0_1.3 CIS Microsoft Azure Foundations Benchmark recommendation 1.3 1 Identity and Access Management Ensure guest users are reviewed on a monthly basis Shared The customer is responsible for implementing this recommendation. Azure AD is extended to include Azure AD B2B collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account and sign in with their own work, school, or social identities. Guest users allow you to share your company's applications and services with users from any other organization, while maintaining control over your own corporate data. Work with external partners, large or small, even if they don't have Azure AD or an IT department. A simple invitation and redemption process lets partners use their own credentials to access your company's resources a a guest user. link 8
CIS_Azure_1.4.0 1.3 CIS_Azure_1.4.0_1.3 CIS Microsoft Azure Foundations Benchmark recommendation 1.3 1 Identity and Access Management Ensure guest users are reviewed on a monthly basis Shared The customer is responsible for implementing this recommendation. Azure AD is extended to include Azure AD B2B collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account and sign in with their own work, school, or social identities. Guest users allow you to share your company's applications and services with users from any other organization, while maintaining control over your own corporate data. Work with external partners, large or small, even if they don't have Azure AD or an IT department. A simple invitation and redemption process lets partners use their own credentials to access your company's resources a a guest user. link 8
CIS_Azure_2.0.0 1.5 CIS_Azure_2.0.0_1.5 CIS Microsoft Azure Foundations Benchmark recommendation 1.5 1 Ensure Guest Users Are Reviewed on a Regular Basis Shared Before removing guest users, determine their use and scope. Like removing any user, there may be unforeseen consequences to systems if it is deleted. Azure AD is extended to include Azure AD B2B collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account and sign in with their own work, school, or social identities. Guest users allow you to share your company's applications and services with users from any other organization, while maintaining control over your own corporate data. Work with external partners, large or small, even if they don't have Azure AD or an IT department. A simple invitation and redemption process lets partners use their own credentials to access your company's resources as a guest user. Guest users in every subscription should be review on a regular basis to ensure that inactive and unneeded accounts are removed. Guest users in the Azure AD are generally required for collaboration purposes in Office 365, and may also be required for Azure functions in enterprises with multiple Azure tenants. Guest users are typically added outside your employee on-boarding/off-boarding process and could potentially be overlooked indefinitely, leading to a potential vulnerability. To prevent this, guest users should be reviewed on a regular basis. During this audit, guest users should also be determined to not have administrative privileges. link 8
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_L3 AC.1.001 CMMC_L3_AC.1.001 CMMC L3 AC.1.001 Access Control Limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information 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 AC.1.002. link 31
CMMC_L3 AC.2.007 CMMC_L3_AC.2.007 CMMC L3 AC.2.007 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 4
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_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
IRS_1075_9.3 .1.2 IRS_1075_9.3.1.2 IRS 1075 9.3.1.2 Access Control Account Management (AC-2) n/a The agency must: a. Identify and select the accounts with access to FTI to support agency missions/business functions b. Assign account managers for information system accounts; c. Establish conditions for group and role membership d. Specify 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. Require approval for requests to create information system accounts f. Create, enable, modify, disable, and remove information system accounts in accordance with documented agency account management procedures g. Monitor the use of information system accounts h. Notify account managers when accounts are no longer required, when users are terminated or transferred, or when individual information system usage or need- to-know permission changes i. Authorize access to information systems that receive, process, store, or transmit FTI based on a valid access authorization, need-to-know permission, and under the authority to re-disclosed FTI under the provisions of IRC 6103 j. Review accounts for compliance with account management requirements at a k. minimum of annually for user accounts and semi-annually for privileged accounts l. Establish a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. The information system must automatically disable inactive accounts after 120 days of inactivity. (CE3) link 9
New_Zealand_ISM 16.4.30.C.01 New_Zealand_ISM_16.4.30.C.01 New_Zealand_ISM_16.4.30.C.01 16. Access Control and Passwords Privileged Access Management - Policy Creation and Implementation n/a The requirement for an agency security policy is discussed and described in Chapter 5 Information Security Documentation.  A fundamental part of any security policy is the inclusion of requirements for the treatment of Privileged Accounts.  This is most conveniently contained in a Privileged Access Management (PAM) section within the agency s security policy.  A PAM policy is a fundamental component of an agency s IT Governance. 6
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-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_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
NZ_ISM_v3.5 AC-11 NZ_ISM_v3.5_AC-11 NZISM Security Benchmark AC-11 Access Control and Passwords 16.4.30 Privileged Access Management Customer n/a A fundamental part of any security policy is the inclusion of requirements for the treatment of Privileged Accounts. This is most conveniently contained in a Privileged Access Management (PAM) section within the agency???s security policy. A PAM policy is a fundamental component of an agency???s IT Governance. link 7
PCI_DSS_V3.2.1 3.2 PCI_DSS_v3.2.1_3.2 PCI DSS v3.2.1 3.2 Requirement 3 PCI DSS requirement 3.2 customer n/a n/a link 7
PCI_DSS_V3.2.1 7.2.1 PCI_DSS_v3.2.1_7.2.1 PCI DSS v3.2.1 7.2.1 Requirement 7 PCI DSS requirement 7.2.1 customer n/a n/a link 7
PCI_DSS_V3.2.1 8.1.2 PCI_DSS_v3.2.1_8.1.2 PCI DSS v3.2.1 8.1.2 Requirement 8 PCI DSS requirement 8.1.2 customer n/a n/a link 5
PCI_DSS_V3.2.1 8.1.5 PCI_DSS_v3.2.1_8.1.5 PCI DSS v3.2.1 8.1.5 Requirement 8 PCI DSS requirement 8.1.5 shared n/a n/a link 5
PCI_DSS_V3.2.1 8.3.1 PCI_DSS_v3.2.1_8.3.1 PCI DSS v3.2.1 8.3.1 Requirement 8 PCI DSS requirement 8.3.1 shared n/a n/a link 7
PCI_DSS_v4.0 3.3.3 PCI_DSS_v4.0_3.3.3 PCI DSS v4.0 3.3.3 Requirement 03: Protect Stored Account Data Sensitive authentication data (SAD) is not stored after authorization Shared n/a Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured. • Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. link 13
PCI_DSS_v4.0 7.3.1 PCI_DSS_v4.0_7.3.1 PCI DSS v4.0 7.3.1 Requirement 07: Restrict Access to System Components and Cardholder Data by Business Need to Know Access to system components and data is managed via an access control system(s) Shared n/a An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. link 17
PCI_DSS_v4.0 8.2.4 PCI_DSS_v4.0_8.2.4 PCI DSS v4.0 8.2.4 Requirement 08: Identify Users and Authenticate Access to System Components User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle Shared n/a Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: • Authorized with the appropriate approval. • Implemented with only the privileges specified on the documented approval. link 7
PCI_DSS_v4.0 8.2.7 PCI_DSS_v4.0_8.2.7 PCI DSS v4.0 8.2.7 Requirement 08: Identify Users and Authenticate Access to System Components User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle Shared n/a Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows: • Enabled only during the time period needed and disabled when not in use. • Use is monitored for unexpected activity. link 6
PCI_DSS_v4.0 8.4.1 PCI_DSS_v4.0_8.4.1 PCI DSS v4.0 8.4.1 Requirement 08: Identify Users and Authenticate Access to System Components Multi-factor authentication (MFA) is implemented to secure access into the CDE Shared n/a MFA is implemented for all non-console access into the CDE for personnel with administrative access. link 8
RBI_CSF_Banks_v2016 8.1 RBI_CSF_Banks_v2016_8.1 User Access Control / Management User Access Control / Management-8.1 n/a Provide secure access to the bank???s assets/services from within/outside bank???s network by protecting data/information at rest (e.g. using encryption, if supported by the device) and in-transit (e.g. using technologies such as VPN or other secure web protocols, etc.) 10
RBI_CSF_Banks_v2016 8.2 RBI_CSF_Banks_v2016_8.2 User Access Control / Management User Access Control / Management-8.2 n/a Carefully protect customer access credentials such as logon userid, authentication information and tokens, access profiles, etc. against leakage/attacks 7
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_CSF_Banks_v2016 9.3 RBI_CSF_Banks_v2016_9.3 Authentication Framework For Customers Authentication Framework For Customers-9.3 n/a Banks should act as the identity provider for identification and authentication of customers for access to partner systems using secure authentication technologies 7
RBI_ITF_NBFC_v2017 3.1.a RBI_ITF_NBFC_v2017_3.1.a RBI IT Framework 3.1.a Information and Cyber Security Identification and Classification of Information Assets-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Identification and Classification of Information Assets. NBFCs shall maintain detailed inventory of Information Asset with distinct and clear identification of the asset. link 7
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 23
RMiT_v1.0 10.54 RMiT_v1.0_10.54 RMiT 10.54 Access Control Access Control - 10.54 Shared n/a A financial institution must implement an appropriate access controls policy for the identification, authentication and authorisation of users (internal and external users such as third party service providers). This must address both logical and physical technology access controls which are commensurate with the level of risk of unauthorised access to its technology systems. link 17
SOC_2 CC6.2 SOC_2_CC6.2 SOC 2 Type 2 CC6.2 Logical and Physical Access Controls Access provisioning and removal Shared The customer is responsible for implementing this recommendation. Controls Access Credentials to Protected Assets — Information asset access credentials are created based on an authorization from the system's asset owner or authorized custodian. • Removes Access to Protected Assets When Appropriate — Processes are in place to remove credential access when an individual no longer requires such access. • Reviews Appropriateness of Access Credentials — The appropriateness of access credentials is reviewed on a periodic basis for unnecessary and inappropriate indIviduals with credentials. 11
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
U.07.3 - Management features U.07.3 - Management features 404 not found n/a n/a 19
U.10.2 - Users U.10.2 - Users 404 not found n/a n/a 25
U.10.3 - Users U.10.3 - Users 404 not found n/a n/a 26
U.10.5 - Competent U.10.5 - Competent 404 not found n/a n/a 24
UK_NCSC_CSP 10 UK_NCSC_CSP_10 UK NCSC CSP 10 Identity and authentication Identity and authentication Shared n/a All access to service interfaces should be constrained to authenticated and authorised individuals. link 25
UK_NCSC_CSP 9.1 UK_NCSC_CSP_9.1 UK NCSC CSP 9.1 Secure user management Authentication of users to management interfaces and support channels Shared n/a In order to maintain a secure service, users need to be properly authenticated before being allowed to perform management activities, report faults or request changes to the service. link 6
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
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated 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
Canada Federal PBMM 4c4a5f27-de81-430b-b4e5-9cbd50595a87 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e 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
IRS1075 September 2016 105e0327-6175-4eb2-9af4-1fba43bdb39d Regulatory Compliance GA BuiltIn
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
New Zealand ISM 4f5b1359-4f8e-4d7c-9733-ea47fcde891e 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
NL BIO Cloud Theme 6ce73208-883e-490f-a2ac-44aac3b3687f 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
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 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
UK OFFICIAL and UK NHS 3937f550-eedd-4639-9c5e-294358be442e Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-08-09 17:24:03 add e9ac8f8e-ce22-4355-8f04-99b911d6be52
JSON compare n/a
JSON
api-version=2021-06-01
EPAC