Az Policy Advertizer

Azure_Security_Benchmark_v2.0

PA-7

Azure_Security_Benchmark_v2.0_PA-7

Azure Security Benchmark PA-7

Privileged Access

Follow just enough administration (least privilege principle)

Customer

Azure role-based access control (Azure RBAC) allows you to manage Azure resource access through role assignments. You can assign these roles to users, group service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges complement the just in time (JIT) approach of Microsoft Entra Privileged Identity Management (PIM), and those privileges should be reviewed periodically. Use built-in roles to allocate permission and only create custom role when required. What is Azure role-based access control (Azure RBAC): https://docs.microsoft.com/azure/role-based-access-control/overview How to configure Azure RBAC: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal How to use Microsoft Entra identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview

n/a

Azure_Security_Benchmark_v3.0

PA-7

Azure_Security_Benchmark_v3.0_PA-7

Microsoft cloud security benchmark PA-7

Privileged Access

Follow just enough administration (least privilege) principle

Shared

**Security Principle:** Follow the just enough administration (least privilege) principle to manage permissions at fine-grained level. Use features such as role-based access control (RBAC) to manage resource access through role assignments. **Azure Guidance:** Use Azure role-based access control (Azure RBAC) to manage Azure resource access through role assignments. Through RBAC, you can assign roles to users, group service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges will complement the just-in-time (JIT) approach of Microsoft Entra Privileged Identity Management (PIM), and those privileges should be reviewed periodically. If required, you can also use PIM to define the time-length (time-bound-assignment) condition in role assignment where a user can activate or use the role only within start and end dates. Note: Use Azure built-in roles to allocate permissions and only create custom roles when required. **Implementation and additional context:** What is Azure role-based access control (Azure RBAC): https://docs.microsoft.com/azure/role-based-access-control/overview How to configure RBAC in Azure: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal How to use Microsoft Entra identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview Microsoft Entra Privileged Identity Management - Time-bound assignment: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-configure#what-does-it-do

n/a

CIS_Azure_2.0.0

1.23

CIS_Azure_2.0.0_1.23

CIS Microsoft Azure Foundations Benchmark recommendation 1.23

Ensure That No Custom Subscription Administrator Roles Exist

Shared

Subscriptions will need to be handled by Administrators with permissions.

The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. Classic subscription admin roles offer basic access management and include Account Administrator, Service Administrator, and Co-Administrators. It is recommended the least necessary permissions be given initially. Permissions can be added as needed by the account holder. This ensures the account holder cannot perform actions which were not intended.

CMMC_2.0_L2

AC.L1-3.1.1

CMMC_2.0_L2_AC.L1-3.1.1

404 not found

n/a

CMMC_2.0_L2

AC.L1-3.1.2

CMMC_2.0_L2_AC.L1-3.1.2

404 not found

n/a

CMMC_2.0_L2

AC.L2-3.1.5

CMMC_2.0_L2_AC.L2-3.1.5

404 not found

n/a

CMMC_L3

AC.3.018

CMMC_L3_AC.3.018

CMMC L3 AC.3.018

Access Control

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

Shared

Microsoft and the customer share responsibilities for implementing this requirement.

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

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.

AC-2(7)

FedRAMP_High_R4_AC-2(7)

FedRAMP High AC-2 (7)

Access Control

Role-Based Schemes

Shared

n/a

The organization: (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) Monitors privileged role assignments; and (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate. Supplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration.

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.

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.

FedRAMP_Moderate_R4

AC-2

FedRAMP_Moderate_R4_AC-2

FedRAMP Moderate AC-2

Access Control

Account Management

Shared

n/a

FedRAMP_Moderate_R4_AC-2(7)

FedRAMP_Moderate_R4

AC-2(7)

FedRAMP Moderate AC-2 (7)

Access Control

Role-Based Schemes

Shared

n/a

FedRAMP_Moderate_R4

AC-6

FedRAMP_Moderate_R4_AC-6

FedRAMP Moderate AC-6

Access Control

Least Privilege

Shared

n/a

hipaa-1148.01c2System.78-01.c

hipaa

1148.01c2System.78-01.c

1148.01c2System.78-01.c

11 Access Control

1148.01c2System.78-01.c 01.02 Authorized Access to Information Systems

Shared

n/a

The organization restricts access to privileged functions and all security-relevant information.

hipaa

1230.09c2Organizational.1-09.c

hipaa-1230.09c2Organizational.1-09.c

1230.09c2Organizational.1-09.c

12 Audit Logging & Monitoring

1230.09c2Organizational.1-09.c 09.01 Documented Operating Procedures

Shared

n/a

No single person is able to access, modify, or use information systems without authorization or detection.

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)

ISO27001-2013

A.9.2.3

ISO27001-2013_A.9.2.3

ISO 27001:2013 A.9.2.3

Access Control

Management of privileged access rights

Shared

n/a

The allocation and use of privileged access rights shall be restricted and controlled.

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.

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).

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.

AC-2

NIST_SP_800-53_R4_AC-2

NIST SP 800-53 Rev. 4 AC-2

Access Control

Account Management

Shared

n/a

NIST_SP_800-53_R4_AC-2(7)

AC-2(7)

NIST SP 800-53 Rev. 4 AC-2 (7)

Access Control

Role-Based Schemes

Shared

n/a

AC-6

NIST_SP_800-53_R4_AC-6

NIST SP 800-53 Rev. 4 AC-6

Access Control

Least Privilege

Shared

n/a

NIST_SP_800-53_R4_AC-6(7)

AC-6(7)

NIST SP 800-53 Rev. 4 AC-6 (7)

Access Control

Review Of User Privileges

Shared

n/a

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.

NIST_SP_800-53_R5_AC-2(7)

AC-2(7)

NIST SP 800-53 Rev. 5 AC-2 (7)

Access Control

Privileged User Accounts

Shared

n/a

(a) Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme;an attribute-based access scheme] ; (b) Monitor privileged role or attribute assignments; (c) Monitor changes to roles or attributes; and (d) Revoke access when privileged role or attribute assignments are no longer appropriate.

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.

NIST_SP_800-53_R5_AC-6(7)

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.

NZ_ISM_v3.5

AC-18

NZ_ISM_v3.5_AC-18

NZISM Security Benchmark AC-18

Access Control and Passwords

16.6.9 Events to be logged

Customer

n/a

The events to be logged are key elements in the monitoring of the security posture of systems and contributing to reviews, audits, investigations and incident management.

NZISM_Security_Benchmark_v1.1

AC-17

NZISM_Security_Benchmark_v1.1_AC-17

NZISM Security Benchmark AC-17

Access Control and Passwords

16.6.9 Events to be logged

Customer

Agencies MUST log, at minimum, the following events for all software components: logons; failed logon attempts; logoffs; date and time; all privileged operations; failed attempts to elevate privileges; security related system alerts and failures; system user and group additions, deletions and modification to permissions; and unauthorised or failed access attempts to systems and files identified as critical to the agency.

The events to be logged are key elements in the monitoring of the security posture of systems and contributing to reviews, audits, investigations and incident management.

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

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

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

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.

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.

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.

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.)

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.).

RBI_CSF_Banks_v2016

8.8

RBI_CSF_Banks_v2016_8.8

User Access Control / Management

User Access Control / Management-8.8

n/a

Implement measures to control installation of software on PCs/laptops, etc

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.

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.

RMiT_v1.0

10.55

RMiT_v1.0_10.55

RMiT 10.55

Access Control

Access Control - 10.55

Shared

n/a

In observing paragraph 10.54, a financial institution should consider the following principles in its access control policy: (a) adopt a 'deny all' access control policy for users by default unless explicitly authorised; (b) employ 'least privilege' access rights or on a 'need-to-have' basis where only the minimum sufficient permissions are granted to legitimate users to perform their roles; (c) employ time-bound access rights which restrict access to a specific period including access rights granted to service providers; (d) employ segregation of incompatible functions where no single person is responsible for an entire operation that may provide the ability to independently modify, circumvent, and disable system security features. This may include a combination of functions such as: (i) system development and technology operations; (ii) security administration and system administration; and (iii) network operation and network security;" (e) employ dual control functions which require two or more persons to execute an activity; (f) adopt stronger authentication for critical activities including for remote access; (g) limit and control the use of the same user ID for multiple concurrent sessions; (h) limit and control the sharing of user ID and passwords across multiple users; and (i) control the use of generic user ID naming conventions in favour of more personally identifiable IDs.

RMiT_v1.0

10.60

RMiT_v1.0_10.60

RMiT 10.60

Access Control

Access Control - 10.60

Shared

n/a

A financial institution must establish a user access matrix to outline access rights, user roles or profiles, and the authorising and approving authorities. The access matrix must be periodically reviewed and updated.

RMiT_v1.0

10.62

RMiT_v1.0_10.62

RMiT 10.62

Access Control

Access Control - 10.62

Shared

n/a

In fulfilling the requirement under paragraph 10.61, large financial institutions are required to' (a) deploy an identity access management system to effectively manage and monitor user access to enterprise-wide systems; and (b) deploy automated audit tools to flag any anomalies.