Skip to main content

🛡️ Oracle IAM User MFA is disabled🟢

Logic​

Similar Policies​

  • Internal: dec-x-b92b08f4

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-b92b08f41

Description​

Open File

Description​

This policy identifies Oracle IAM Users that do not have multifactor authentication (MFA) activated.

Rationale​

MFA adds a second authentication factor to the standard username and password sign-in flow. Requiring MFA for OCI IAM users reduces the likelihood that stolen, guessed, or reused passwords can be used to access the OCI Console.

Impact​

Users without MFA are more exposed to credential theft, phishing, password spraying, and credential stuffing attacks. A compromised OCI IAM user can be used to view or change cloud resources according to the user's assigned policies, so interactive accounts should require an additional verification factor.

Audit​

This policy flags an Oracle IAM User as INCOMPLIANT if the Lifecycle State field is set to ACTIVE and the MFA Status field is set to Deactivated.

Users whose Lifecycle State field is not set to ACTIVE are marked as INAPPLICABLE. Users with an empty or unexpected MFA Status value are marked as UNDETERMINED.

Remediation​

Open File

Remediation​

Enforce MFA from Oracle Cloud Console​

  1. Sign in to the OCI Console.
  2. Open the navigation menu and select Identity & Security.
  3. Under Identity, select Domains.
  4. Select the identity domain that contains the affected users.
  5. Open Security, then select Sign-on policies.
  6. If Security Policy for OCI Console exists, open it and confirm that:
    • The policy is activated.
    • The OCI Console application is assigned to the policy.
    • The MFA for all users rule is active.
    • The rule allows access, prompts for an additional factor, and sets MFA enrollment to Required.
  7. If the Security Policy for OCI Console policy does not exist or cannot be used, create a sign-on policy for OCI Console access:
    • Select Create sign-on policy.
    • Add a sign-on rule for the users or groups that require OCI Console access.
    • Set the rule action to allow access.
    • Enable Prompt for an additional factor.
    • Set MFA enrollment to Required.
    • Add the OCI Console application to the policy.

... see more

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 4 Regulated entities would typically put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes.88no data
💼 APRA CPG 234 → 💼 5 The strength of identification and authentication would typically be commensurate with the impact should an identity be falsified. Common techniques for increasing the strength of identification and authentication include the use of strong password techniques (i.e. length, complexity, re-use limitations and frequency of change), utilisation of cryptographic techniques and increasing the number and type of authentication factors used. Authentication factors include something an individual: a. knows - for example, user IDs and passwords; b. has - for example, a security token or other devices in the person’s possession used for the generation of one-time passwords; c. is - for example, retinal scans, hand scans, signature scans, digital signature, voice scans or other biometrics.33no data
💼 APRA CPG 234 → 💼 6 The following are examples where increased authentication strength is typically required, given the impact should an identity be falsified: a. administration or other privileged access to sensitive or critical information assets; b. remote access (i.e. via public networks) to sensitive or critical information assets; c. high-risk activities (e.g. third-party fund transfers, creation of new payees)22no data
💼 APRA CPG 234 → 💼 44a malicious acts by an insider with highly-privileged access, potentially involving collusion with internal or external parties;11no data
💼 APRA CPG 234 → 💼 45 An understanding of plausible worst case scenarios can help regulated entities identify and implement additional controls to prevent or reduce the impact of such scenarios. One example is malware that infects computers and encrypts data, both on the infected computer and any connected storage, including (corporate) networks and cloud storage. Such attacks reinforce the importance of protecting the backup environment in the event that the production environment is compromised. Common techniques to achieve this include network segmentation, highly restricted and segregated access controls and network traffic flow restrictions.4042no data
💼 APRA CPG 234 → 💼 j. multi-factor authentication for privileged access, remote access and other high-risk activities;22no data
💼 CIS Oracle v3.1.0 → 💼 1.7 Ensure MFA is enabled for all users with a console password - Level 1 (Automated)11no data
💼 Cloudaware Framework → 💼 Multi-Factor Authentication (MFA) Implementation19no data
💼 ISO/IEC 27001:2013 → 💼 A.9.3.1 Use of secret authentication information33no data
💼 ISO/IEC 27001:2022 → 💼 5.15 Access control1532no data
💼 ISO/IEC 27001:2022 → 💼 8.2 Privileged access rights710no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1934no data
💼 NIST CSF v1.1 → 💼 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)2024no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization47no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated54no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties144no data
💼 PCI DSS v3.2.1 → 💼 8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components.6121no data
💼 PCI DSS v3.2.1 → 💼 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.3no data
💼 PCI DSS v3.2.1 → 💼 8.3.2 Incorporate multi-factor authentication for all remote network access originating from outside the entity's network.1no data
💼 PCI DSS v3.2.1 → 💼 8.6 Where other authentication mechanisms are used, use of these mechanisms must be assigned.1no data
💼 PCI DSS v4.0.1 → 💼 8.3.1 All user access to system components for users and administrators is authenticated.1no data
💼 PCI DSS v4.0.1 → 💼 8.3.10.1 If passwords/passphrases are used as the only authentication factor for customer user access then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed.1no data
💼 PCI DSS v4.0.1 → 💼 8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used factors are assigned to an individual user and not shared among multiple users, and physical and/or logical controls ensure only the intended user can use that factor to gain access.1no data
💼 PCI DSS v4.0.1 → 💼 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.3no data
💼 PCI DSS v4.0.1 → 💼 8.4.2 MFA is implemented for all non-console access into the CDE.4no data
💼 PCI DSS v4.0.1 → 💼 8.4.3 MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE.1no data
💼 PCI DSS v4.0 → 💼 8.3.1 All user access to system components for users and administrators is authenticated.11no data
💼 PCI DSS v4.0 → 💼 8.3.10.1 If passwords/passphrases are used as the only authentication factor for customer user access then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed.1no data
💼 PCI DSS v4.0 → 💼 8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used factors are assigned to an individual user and not shared among multiple users, and physical and/or logical controls ensure only the intended user can use that factor to gain access.11no data
💼 PCI DSS v4.0 → 💼 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.13no data
💼 PCI DSS v4.0 → 💼 8.4.2 MFA is implemented for all access into the CDE.14no data
💼 PCI DSS v4.0 → 💼 8.4.3 MFA is implemented for all remote network access originating from outside the entity's network that could access or impact the CDE.11no data