Managing Detector Recipes

View, clone, and modify detector recipes to fit the specific security needs of your environment.

Note

The information in this section applies specifically to detector recipes with Type = Activity or Type = Configuration. For information on other target types, see:

About Detector Recipes

Cloud Guard detectors follow rules, combined into recipes, to identify problems.

A detector is a Cloud Guard component that identifies potential security problems, based on resource configuration or activity. Each detector uses a detector recipe that defines what the detector should identify as a problem.

Each detector recipe consists of a set of detector rules, that provide a specific definition of a class of resources, with specific actions or configurations, that cause a detector to report a problem.

Cloud Guard provides several sets of detectors with default rules. You can:

  • Use these detectors as is.
  • Clone any of the default detectors and modify the rules to meet specific needs.
  • Enable and disable detectors rules individually.
  • Limit the scope for applying individual rules by specifying conditions that must be met.

Cloud Guard supports two types of detector recipes:

  • Oracle-Managed recipes are provided by Oracle and you can't modify them.
  • User-Managed recipes are created by cloning an Oracle-managed recipe. You can modify user-managed recipes as needed.

For more information on the following topics, see Overview of Recipes:

  • Differences between Oracle-managed and user-managed recipes
  • How user-managed recipes work
  • What settings can be changed at the recipe and target levels

Viewing Details for a Detector Recipe

Open the Detector Recipes page, sort and filter the list, and view details for a specific detector recipe.

  1. From the Cloud Guard options panel on the left, select Detector Recipes.

    The column headers provide summary information for the detector recipes:

    • Recipe Name - the name of the detector recipe.
    • Oracle Managed - shows a check mark if the detector recipe is Oracle-managed.
    • Type - indicates that the detector recipe is an Activity, Threat, or Configuration recipe.
  2. To filter the list, you can:
    • Under Scope at lower left:
      • Select a different Compartment.
      • Change Status.
      • Select a specific Resource type.
    • To right of Tag Filters at lower left:
      1. Click the add link.
      2. In the Apply tag filter dialog box, select a Tag Namespace.

        Select None (free-form tag) if you want to manually enter the Tag Key.

      3. Select a Tag Key.

        Manually enter the Tag Key if you selected None (free-form tag) for the Tag Namespace.

      4. For Value:
        • Select Match any value if you want any tag value to count as a match.
        • Select Match any of the following and manually enter values, separated by commas, if you want only the values you enter to count as a match.
        • To add more values for this tag, click the plus sign (+) at the lower right.
      5. Click Apply Filter.
  3. To view the details for a particular detector recipe, click its link in the Recipe Name column.
  4. In the Details tab, OCID row:
    • Click the Show link to show the full OCID.
    • Click the Copy link to copy the full OCID to the clipboard.

      You can use OCIDs in lists, or directly in some detector configurations to include or exclude resources from the detector.

  5. If the detector recipe you're viewing is user-managed, you can view tags that have been assigned:

    Tagging isn't supported in Oracle-managed detector recipes.

    1. Click the Tags tab.
    2. View the tags that have been assigned.
      If no tags have been assigned, you see "There are no Tags associated with this resource."
  6. In the Detector Rules section, use the column headers to identify the information shown:
    • Detector Rules - the name of each detector rule in the recipe.
    • Risk Level - the severity of the risk posed if the rule is triggered.
    • Status - each rule can be Enabled or Disabled independently.
    • Settings Configured - are settings configured? Yes or No.
    • Conditional Group - are conditions configured for the rule? Yes or No.
  7. In the Detector Rules section,
    • To show summary information for a detector rule, click the Expand icon Image of Expand icon at the right end of its row.
    • To show configuration information for a detector rule, open the Actions menu Image of Action menu, and select Edit.
      For information on rule parameters, and best practice recommendations for changes from default settings, see the reference for the detector recipe type:

What's Next

Cloning a Detector Recipe

Clone detector recipes to fine-tune the set of detector recipes available to use in your environment.

You can use Oracle-managed detector recipes as is, but you can't change many of their settings. Also, you might want to create another detector recipe that's similar to a user-managed detector recipe that you cloned previously.

Whenever you want to create a detector recipe, you can clone the existing (Oracle-managed or user-managed) recipe with the settings that are most similar to what you want in the new recipe.

  1. From the Cloud Guard options panel on the left, select Detector Recipes.
  2. (Optional) In the Scope section at lower left, set parameters to filter what appears in the list:
    • Set Compartment to display only detector recipes attached to a specific compartment.
    • If you also want detector recipes attached to compartments below the selected compartment to appear in the list, select Include Child Compartments.
  3. Click Clone, then in the Clone Detector Recipe dialog box:
    1. If you want to choose a recipe from a particular compartment, click Change Compartment and select a specific compartment to list only recipes from that compartment.
      Note

      From the Detector Recipes page, all detector recipes in the root compartment and all of its sub-compartments are available for cloning.
    2. From the Cloning list, select the detector recipe you want to clone.
      Note

      The recipe must be in the same tenancy where you are logged in.

    3. Enter a Name for the new detector recipe.
      Avoid entering confidential information.
    4. (Optional) Enter a Description for the new detector recipe.
      Avoid entering confidential information.
    5. Specify a Compartment Assignment by selecting from the list.
    6. Click Clone.

      The new detector recipe appears in the Detector Recipes list.

What's Next

Modifying a Detector Recipe

You can modify a few recipe settings in an Oracle-managed detector recipe, and more settings in a user-managed (cloned) detector recipe.

When you modify detector recipes, you change settings for detector rules:

  • Oracle-managed detector recipes only allow you to change the scope of resources to which a rule is applied, by specifying Conditional Group statements.

  • User-managed (cloned) detector recipes add the capability to set Status (enabled or disabled) and Risk Level, and add Labels.

For complete information on what you can modify in Oracle-managed and user-managed (cloned) detector recipes, see Modifying Recipes at Recipe and Target Levels.

  1. From the Cloud Guard options panel on the left, select Detector Recipes.
  2. Locate the detector recipe you want to modify.
    Oracle-managed detector recipes have "Yes" in the Oracle-Managed column.
  3. Click the recipe's link in the Recipe Name column.
    The details page for the detector recipe opens. Here you can modify settings for the detector recipe's individual rules.
  4. If the detector recipe is user-managed (cloned):
    • To change the detector recipe's name or description:
      1. Click Edit below the detector recipe's name on the details page.
      2. In the Edit Detector Recipe dialog box, edit the Name or Description entries.

        Avoid entering confidential information.

      3. Click Save.
    • To attach the detector recipe to a different compartment:
      1. Click Move Resource below the detector recipe's name on the details page.
      2. In the Move Resource to a Different Compartment dialog box, select the new compartment from the Choose New Compartment list, then click Move Resource.
    • To see tags that have been added to the detector recipe, click the Tags tab below the detector recipe's name on the details page.
    • To enable or disable groups of rules:
      1. Select check boxes to the left of the rule names (current Status for all must be the same).
      2. Click Enable or Disable at the top of the list.
    • To delete the detector recipe:
      1. Click Delete below the detector recipe's name on the details page.
      2. In the Delete Detector Recipe dialog box, click Yes.

Next Steps

Ensure that you:

Modifying Rule Settings in a Detector Recipe

You can modify a few rule settings in an Oracle-managed detector recipe, and more settings in a user-managed (cloned) detector recipe.

Note

From the recipe level, for Oracle-managed detector recipes, you can only change the Conditional Group specification, and (where applicable) Input Settings. For user-managed (cloned) detector recipes, you can change any configurable rule settings, including enabling or disabling a rule.

For complete information on what you can modify in Oracle-managed and user-managed (cloned) detector and responder recipes, from the recipe or target level, see Modifying Recipes at Recipe and Target Levels.

  1. Navigate to the detail page for the detector recipe in which you want to modify rule settings.
  2. Locate a detector rule that you want to modify, open the Actions menu Image of Action menu, and select Edit.
    For information on rule parameters, and best practice recommendations for changes from default settings, see the reference for the detector recipe type:
  3. If the detector recipe is user-managed (cloned), in the top part of the Edit Detector Rule dialog box, you can:
    • Change the rule's Status (Enabled vs. Disabled).
      Note

      When you disable a detector recipe rule, any problems that the rule has already triggered remain active on the Problems page. If you are certain that these problems pose no security risk, you can clear them all in one action. See Problem Lifecycle, especially the "Problem Reconciliation Process" section.
    • Set a different Risk Level.
    • Edit the Labels entry.

      Separate multiple labels with a semicolon (";").

  4. If the rule supports configuring a threshold at which the rule triggers a problem a problem, you can change the threshold value by entering a different Input Setting.
    For example, by default the "Password is too old" detector rule triggers a problem if a password has not been changed for more than 90. You can change this value to 60 if your organization policy is to change passwords every 60 days.
  5. In the Conditional Group section at the bottom:
    • To set a condition on a parameter other than tags:
      1. In the Parameter list, select a parameter other than Tags.
      2. Select an Operator.
      3. Select a Value.
      4. To add another condition, click Add Condition and repeat the last three steps.
        Note

        Specifying multiple conditions acts as an AND operator. The rule is enforced only if all the conditions are met.
      5. To delete a condition, click the "X" at the right end of the row for the condition.
    • To set a condition on tags:
      1. In the Parameter list, select Tags.

        A Value box appears below the Parameter box.

      2. Select an Operator (In or Not In).
      3. Click Select Tags, to right of Value box.
      4. In the Select Tags dialog box:
        • To set a condition for defined tags:
          1. Select a Tag Namespace other than None (add a free-form tag).
          2. Select a Tag Key.
          3. Select or enter the Value.
        • To set a condition for free-form tags:
          1. For Tag Namespace, select None (add a free-form tag).
          2. Enter a Tag Key.
          3. Optional: Enter a Value.
        • To add another tag:
          1. Click Additional Tag.
          2. Repeat the preceding substeps for either defined or free-form tags.
            Note

            When you specify multiple tags, the rule is enforced only if all the conditions are met.
        • To delete a tag, click the "X" at the right end of the row for the tag.
        • To save your tag selections, click Select at the bottom of the Select Tags dialog box.
    For more information on Conditional Groups, see Using Conditional Groups with Recipe Rules.
  6. When you are finished modifying the detector rule, click Save.
  7. To change settings for another detector rule, repeat the previous steps, beginning with step 2.

Next Steps

Ensure that you:

Deleting a User-Managed (Cloned) Detector Recipe

You can delete any cloned copy of an Oracle-managed detector.

  1. From the Cloud Guard options panel on the left, select Detector Recipes.
  2. Locate the cloned detector recipe you want to delete.
    Cloned detector recipes have "No" in the Oracle Managed column.
  3. Open the Actions menu Image of Action menu and select Delete.
  4. Click Yes to confirm the deletion.

Detector Recipe Reference

Review summary information for detectors in the Oracle-managed detector recipes.

Note

The following sections include best practice recommendations for modifying detector recipe rules. Oracle-managed recipes allow different types of rule changes, compared with user-managed (cloned) recipes. Accessing a detector recipe from the Detector Recipes page allows different types of rule changes, compared with accessing from the Targets page. See Modifying Recipes at Recipe and Target Levels.
OCI Configuration Detector Rules

Reference material for the Oracle-managed configuration detector recipes that Cloud Guard provides is grouped below by resource type. Expand a Rule Display Name to view the details.

Certificates Resources

Certificate Authority (CA) has no revocation list

Description: Alert when a certifying authority (CA) is found with no certificate revocation list (CRL) configured.

Recommendation: Ensure that CAs have a CRL configured. Create object storage, edit the CA, and add a CRL.

Background: When a client makes a TLS connection and downloads your certificate, the certificate contains a link to the CRL. The client should check the CRL to ensure that the downloaded certificate should be trusted. If they can't find the CRL, most clients trust certificates. Maintaining a CRL is the best way to ensure that a revoked certificate is not trusted.

Rule Parameters:

  • Service Type: Certificates
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: Certificates
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.

Compute Resources

Instance has a public IP address

Description: Alert when a Compute instance has a public IP address.

Recommendation: Carefully consider allowing internet access to any instances. For example, you do not want to accidentally allow internet access to sensitive database instances.

Background: For an instance to be publicly addressable, it must:

  • Have a public IP address
  • Exist in a public virtual computer network (VCN) subnet
  • Be on a VCN that has an internet gateway enabled that is configured for outbound traffic
  • Be on a subnet where the security list is configured for all IP addresses and all ports (0.0.0.0/0)

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: HIGH
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.3 - Prohibit direct public access between the Internet and any system component in the cardholder data environment.
  • CIS 1.1:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

  • CIS 1.0:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

Best Practice for Rule Modifications:
  • Conditional Groups: Filter out OCIDs for any instance that should have a public IP address.

    Filter on CIDR blocks if specific OCIDs are not known. For example, an automated process might be creating new instances within a CIDR range.

Instance is not running an Oracle public image

Description: Alert when a Compute instance is not built from an Oracle public image.

Recommendation: Ensure that your instances are all running sanctioned images from trusted sources.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: LOW
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 2.2 - Develop configuration standards for all system components. Ensure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

    Sources of industry-accepted system hardening standards might include, but are not limited to:

    • Center for Internet Security (CIS)
    • International Organization for Standardization (ISO)
    • SysAdmin Audit Network Security (SANS) Institute
    • National Institute of Standards Technology (NIST)
  • CIS 1.1: Not Covered by CIS 1.1.
  • CIS 1.0: Not Covered by CIS 1.0.
Best Practice for Rule Modifications:
  • Leave default settings.
Instance is publicly accessible

Description: Alert when an instance is publicly accessible.

Recommendation: Carefully consider allowing internet access to any instances.

Background: For an instance to be publicly addressable, it must:

  • Have a public IP address
  • Exist in a public VCN subnet
  • Be on a VCN that has an internet gateway enabled that is configured for outbound traffic
  • Be on a subnet where the security list is configured for all IP addresses and all ports (0.0.0.0/0)

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: CRITICAL
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.
  • CIS 1.1:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

  • CIS 1.0:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

Best Practice for Rule Modifications:
  • Conditional Groups: Filter out instance OCIDs for any that should have a public IP address.
Instance is running an Oracle public image

Description: Alert when a Compute instance that's running is built from an Oracle public image.

Recommendation: Ensure that your instances are all running sanctioned images from trusted sources.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: LOW
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Instance is running without required Tags

Description: Alert when a Compute instance is running without required configured tags.

Recommendation: Ensure that the instances are using required tags.

Background: Tags are important for auditing and tracking purposes.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, TAGS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Add required tags in the rule's Input Setting section.

    These formats are allowed in the Input Setting box. Separate multiple entries with commas.

    • <namespace>.<definedkey>=<definedValue>
    • <namespace>.<definedKey>
    • <freeformkey>=<freeformValue>
    • <freeformkey>

    Examples:

    • <namespace>.<definedkey>=<definedValue>
      • Operations.Environment=Production - If resource has a tag set to Operations namespace, defined key of Environment, and defined value of Production, rule doesn't trigger a problem.
      • Operations.*=* - If resource has a tag set Operations namespace, with any defined key and any defined value, rule doesn't trigger a problem.
    • <namespace>.<definedkey>
      • Operations.Environment - If resource has a tag set to Operations namespace, with a defined key of Environment, and any defined value, rule doesn't trigger a problem.
    • <freeformKey>
    • <freeformKey>=freeformValue
      • Project=APPROVED - If resource has a tag set to freeform key Project with a value of APPROVED, rule doesn't trigger a problem.

Database Resources

Data Safe is not enabled

Description: Alert when a database is detected for which Data Safe is not enabled.

Recommendation: Ensure that Data Safe is enabled for all compartments that Cloud Guard is monitoring, which contain databases. See Enable Oracle Data Safe.

Background: Data Safe helps ensure that your databases are securely configured. This service should be activated to help monitor, secure, and mitigate risks inside your Oracle cloud databases.

Rule Parameters:

  • Service Type: Data Safe
  • Resource Type: Tenancy
  • Risk Level: HIGH
  • Labels: Database Security
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Database is not backed up automatically

Description: Alert when automatic backup isn't enabled for a database.

Recommendation: Ensure that automatic backup is enabled.

Background: Enabling automatic backup ensures that if a catastrophic hardware failure occurs, you are able to restore the database with minimal data loss,

Rule Parameters:

  • Service Type: Database
  • Resource Type: DB System
  • Risk Level: HIGH
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out database OCIDs for any that do not need to be backed up automatically, for example, OCIDs in developer test environments.
Database is not registered in Data Safe

Description: Alert when a database instance is detected which is not registered in Data Safe.

Recommendation: Register this database instance with Data Safe and configure assessments to evaluate and monitor configuration, check user activities, and mitigate risks. See Target Database Registration.

Background: Data Safe helps ensure that your databases are securely configured. All cloud databases This service should be activated to help monitor, secure, and mitigate risks inside your Oracle cloud databases.

Rule Parameters:

  • Service Type: Data Safe
  • Resource Type: Tenancy
  • Risk Level: MEDIUM
  • Labels: Database Security
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Database patch is not applied

Description: Alert when an available database patch has not been applied within your specified number of days.

Recommendation: Apply released patches to the database when they are available.

Background: Database patches address functionality, security, and performance issues. Most security breaches can be prevented by applying available patches.

Rule Parameters:

  • Service Type: Database
  • Resource Type: DB System
  • Risk Level: MEDIUM
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Set Number of days to apply patch in the rule's Input Setting section.
  • Conditional Groups: Filter out database OCIDs for any that do not need to have latest patch applied, for example, OCIDs in developer test environments.
Database System has public IP address

Description: Alert when a database system has a public IP address assigned.

Recommendation: Ensure that the database system does not have a public IP address.

Background: Use of a public IP address to access a database increases your exposure to potential security and business continuity risks.

Rule Parameters:

  • Service Type: Database
  • Resource Type: DB System
  • Risk Level: HIGH
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out database OCIDs for any that are supposed to be public.
Database System is publicly accessible

Description: Alert when a database is publicly accessible.

Recommendation: Carefully consider allowing internet access to any database system.

Background: For a database to be publicly accessible, it must:

  • Have a public IP address.
  • Be in a public VCN subnet.
  • Be on a subnet that has an internet gateway enabled that is configured for outbound traffic.
  • Be on:
    • A subnet where the security list allows traffic from any source CIDR range and "All protocols," or...
    • Be on network security group which allows traffic from any source CIDR range and "All protocols."

Rule Parameters:

  • Service Type: Database
  • Resource Type: ExadataBareMetalVM
  • Risk Level: CRITICAL
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out database OCIDs for any that are supposed to be public.
Database system patch is not applied

Description: Alert when an available database system patch has not been applied.

Recommendation: Apply released patches to the database system when they are available.

Background: Database system patches often include updates that eliminate known security vulnerabilities.

Rule Parameters:

  • Service Type: Database
  • Resource Type: DB System
  • Risk Level: MEDIUM
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Set Number of days to apply patch in the rule's Input Setting section.
  • Conditional Groups: Filter out database system OCIDs for any that do not need to have latest patch applied, for example, OCIDs in developer test environments.
Database System version is not sanctioned

Description: Alert when a database system is running with a version that's not sanctioned.

Recommendation: Ensure that the deployed database system version is approved and tested.

Background: Running unsanctioned versions of database systems might increase your chances of a security breach, putting your data confidentiality, integrity, and availability at risk.

Rule Parameters:

  • Service Type: Database
  • Resource Type: DB System
  • Risk Level: CRITICAL
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out database system OCIDs for any that do not need to have a sanctioned version, for example, OCIDs in developer test environments.
Database version is not sanctioned

Description: Alert when a database is running with a version that's not sanctioned.

Recommendation: Ensure that the deployed database version is approved and tested.

Background: The sanctioned version of a database has the most recent security features and vulnerability patches. Running unsanctioned versions of a database might increase your chances of a security breach, putting your data confidentiality, integrity, and availability at risk.

Rule Parameters:

  • Service Type: Database
  • Resource Type: DB System
  • Risk Level: CRITICAL
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out database OCIDs for any that do not need to have a sanctioned version, for example, OCIDs in developer test environments.

IAM Resources

API key is too old

Description: Alert when an IAM private/public key pair assigned to a user is too old.

Recommendation: Rotate API keys regularly, at least every 90 days.

Background: Changing IAM API keys at least every 90 days is a security best practice. The longer that IAM credentials remain unchanged, the greater the risk that they can become compromised.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: IAMKey
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_IAM, CIS_OCI_V1.1_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.2.4 - Credentials must be rotated at least every 90 days.
  • CIS 1.1: 1.8 - Ensure that user API keys rotate within 90 days or less.
  • CIS 1.0: Doesn't cover.
Best Practice for Rule Modifications:
  • Configuration: (Optional) You can change the default value of 90 days in the rule's Input Setting section.
IAM Auth Token is too old

Description: Alert when IAM Auth Tokens are older than your specified maximum number of days.

Recommendation: Rotate IAM Auth Tokens regularly, at least every 90 days.

Background: Changing IAM Auth Tokens at least every 90 days is a security best practice. The longer that IAM Auth Tokens remain unchanged, the greater the risk that they can become compromised.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.1_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.2.4 - Credentials must be rotated at least every 90 days.
  • CIS 1.1: 1.9 Ensure user Auth tokens rotate within 90 days or less.
  • CIS 1.0: None
Best Practice for Rule Modifications:
  • Configuration: Set the maximum number of days for IAM Auth Tokens (default is 90) in the rule's Input Setting section.
IAM Customer Secret Key is too old

Description: Alert when IAM Customer Secret Keys are older than your specified maximum number of days.

Recommendation: Rotate IAM Customer Secret Keys regularly, at least every 90 days.

Background: Changing IAM Customer Secret Keys at least every 90 days is a security best practice. The longer that IAM Customer Secret Keys remain unchanged, the greater the risk that they can become compromised.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.1_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.2.4 - Credentials must be rotated at least every 90 days.
  • CIS 1.1: 1.9 Ensure user customer secret keys rotate within 90 days or less.
  • CIS 1.0: None
Best Practice for Rule Modifications:
  • Configuration: Set the maximum number of days for IAM Customer Secret Keys (default is 90) in the rule's Input Setting section.
IAM group has too few members

Description: Alert when an IAM group has fewer than your specified minimum number of members.

Recommendation: Increase the number of group members to be fewer than your specified minimum number of members.

Background: IAM group membership frequently grants access to resources and features. Group memberships that have too few members might represent excess privileges being "orphaned" (no longer available to any users).

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Group
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
IAM group has too many members

Description: Alert when an IAM group has more than your specified maximum number of members.

Recommendation: Reduce number of group members to be less than your specified maximum number of members.

Background: IAM group membership frequently grants access to resources and features. Group memberships that have too many members might represent overly permissive privileges being given to too many users.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Group
  • Risk Level: MEDIUM
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Password is too old

Description: Alert when an IAM password is older than your specified maximum number of days.

Recommendation: Rotate IAM passwords regularly, at least every 90 days.

Background: Changing IAM passwords at least every 90 days is a security best practice. The longer that IAM credentials remain unchanged, the greater the risk that they can become compromised.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_IAM, CIS_OCI_V1.1_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.2.4 - Credentials must be rotated at least every 90 days.
  • CIS 1.1: 1.5 - Ensure that IAM password policy expires passwords within 365 days.
  • CIS 1.0: 1.9 Ensure that IAM password policy expires passwords within 365 days.
Best Practice for Rule Modifications:
  • Configuration: Set the maximum number of days for passwords (default is 90) in the rule's Input Setting section.
Password policy does not meet complexity requirements

Description: Password policy does not meet complexity requirements.

Recommendation: Oracle recommends that a strong password policy include at least one lower case letter.

Background: Complex passwords are harder to guess and can decrease the chances of unauthorized access or compromised data.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Policy
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.1_IAM, CIS_OCI_V1.0_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.2.3 - Passwords/passphrases must meet the following:
    • Require a minimum length of at least seven characters.
    • Contain both numeric and alphabetic characters.

    Alternatively, the passwords or passphrases must have complexity and strength at least equivalent to the parameters specified above.

  • CIS 1.1: 1.4 - Ensure that IAM password policy requires minimum length of 14 or greater.
  • CIS 1.0:

    1.4 - Ensure that IAM password policy requires minimum length of 14 or greater.

    1.5 - Ensure that IAM password policy requires at least one uppercase letter.

    1.6 - Ensure that IAM password policy requires at least one lowercase letter.

    1.7 - Ensure that IAM password policy requires at least one symbol.

    1.8 - Ensure that IAM password policy requires at least one number.

Best Practice for Rule Modifications:
  • Leave default settings.
Policy gives too many privileges

Description: Alert when an IAM policy grants any administrator role access to a user who is not member of the Administrators group.

Recommendation: Ensure that the policy is restricted to allow only specific users to access the resources required to accomplish their job functions.

Background: A policy is a document that specifies who can access which OCI resources that your company has, and how. A policy simply allows a group to work in certain ways with specific types of resources in a particular compartment.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Policy
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.1_IAM, CIS_OCI_V1.0_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 7.1.2 - Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
  • CIS 1.1: - 1.2 Ensure that permissions on all resources are given only to the tenancy administrator group.
  • CIS 1.0: - 1.2 Ensure that permissions on all resources are given only to the tenancy administrator group.
Best Practice for Rule Modifications:
  • Configuration: Add OCIDs for any groups that should be allowed these privileges in the rule's Input Setting section.
Tenancy admin privilege granted to group

Description: Alert when the tenancy administrator privilege is granted to an extra IAM group.

Recommendation: Verify with the OCI administrator that this entitlement grant was sanctioned, and that the membership of the group remains valid after the grant of the administrator privilege.

Background: Default tenancy administrator group members can perform any action on all resources in that tenancy. This high-privilege entitlement must be controlled and restricted to only those users who need it to perform their job functions.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Policy
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.1_IAM, CIS_OCI_V1.0_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 7.1.2 - Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
  • CIS 1.1: 1.3 Ensure that IAM administrators cannot update tenancy Administrators group.
  • CIS 1.0: 1.3 - Ensure that IAM administrators cannot update tenancy Administrators group.
Best Practice for Rule Modifications:
  • Configuration: Add OCIDs of groups that should have admin privilege in the rule's Input Setting section.
User does not have MFA enabled

Description: Alert when a user doesn't have multifactor authentication (MFA) enabled.

Recommendation: Enable MFA for all users, using the Oracle Mobile Authenticator (OMA) application on each user's mobile device and the one-time passcode (OTP) sent to the user's registered email address.

Background: MFA provides an extra layer of security, on top of user name and password. A second verification factor is required each time a user logs in. During the authentication process, users can enable a single device as a trusted device for a maximum period of one day. The email passcode must not be valid for more than 10 minutes. These features combine to provide a degree of protection from password spraying, credential stuffing, and account takeover attacks.
Note

Only applicable to local users. Not applicable to IDCS users, unless they are mapped to local users.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_IAM, CIS_OCI_V1.1_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.3 - Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.
  • CIS 1.1: 1.7 - Ensure that MFA is enabled for all users with a console password.
  • CIS 1.0: 1.11 - Ensure that MFA is enabled for all users with a console password.
Best Practice for Rule Modifications:
  • Leave default settings.
User has API keys

Description: Alert when a user has API keys enabled.

Recommendation: Ensure that OCI access by administrators through API keys is performed as an exception. Do not hard-code IAM credentials directly in software or documents to a wide audience.

Background: IAM API keys are credentials used to grant programmatic access to resources. Actual human users should not use API keys.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_IAM, CIS_OCI_V1.1_IAM, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.6 - Where other authentication mechanisms are used, such as physical or logical security tokens, smart cards, or certificates, use of these mechanisms must be assigned as follows:
    • Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
    • Physical or logical controls, or both, must be in place to ensure that only the intended account can use that mechanism to gain access.
  • CIS 1.1: 1.11 - Ensure that API keys are not created for tenancy administrator users.
  • CIS 1.0: 1.13 - Ensure that API keys are not created for tenancy administrator users.
Best Practice for Rule Modifications:
  • Leave default settings.

KMS Resources

Key has not been rotated

Description: Alert when a KMS key has not been rotated within your specified time period.

Recommendation: Ensure that you rotate the KMS keys regularly.

Background: For information security, you should periodically change or rotate, passwords, keys, and cryptographic materials. Rotating your keys in KMS reduces the impact and probability of key compromise. Set the minimum. You can change the default time for rotating keys from 180 days in the rule's Input Setting section.

Rule Parameters:

  • Service Type: KMS
  • Resource Type: KMS Key
  • Risk Level: CRITICAL
  • Labels: CIS_OCI_V1.1_MONITORING, KMS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 8.2.4 - Credentials must be rotated at least every 90 days.
  • CIS 1.1: 3.16 - Ensure that customer created Customer Managed Key (CMK) is rotated at least annually.
  • CIS 1.0: Not Covered by CIS 1.0
Best Practice for Rule Modifications:
  • Configuration: Set the default time for rotating keys in the rule's Input Setting section.

Multiple Resources

Resource is not tagged appropriately

Description: Alert when a resource is not tagged in compliance with the tagging requirements you've specified.

Recommendation: Verify that the configured tags are in use for compute images, compute instances, database systems, VCNs, object storage, and storage block volumes.

Background: Verify that the configured tags are in use for compute images, compute instances, database systems, VCNs, object storage, and storage block volumes.

Rule Parameters:

  • Service Type: Multiple
  • Resource Type: Multiple
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, TAGS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 2.4 - Maintain an inventory of system components that are in scope for PCI DSS.
  • CIS 1.1: 3.2 - Ensure that default tags are used on resources.
  • CIS 1.0: 4.2 - Ensure that default tags are used on resources.
Best Practice for Rule Modifications:
  • Configuration: Add appropriate tags in the rule's Input Setting section.

Networking Resources

Load balancer allows weak cipher suites

Description: Alert when a load balancer has a cipher suite configured that is oci-wider-compatible-ssl-cipher-suite-v1. This cipher suite includes algorithms like DES and RC4 that are considered weak and prone to attacks. Only applicable for predefined cipher suites and not the custom cipher suite values.

Recommendation: Use default, modern cipher suites that support stronger encryption.

Background: Certain versions of cipher suites with algorithms like DES are not recommended.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Load Balancer
  • Risk Level: MEDIUM
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Load balancer allows weak SSL communication

Description: Alert when a load balancer has a protocol configured as part its SSL policy that includes any version less than Transport Layer Security (TLS) 1.2.

Recommendation: Ensure that the SSL policy version configured is at least TLS 1.2.

Background: Older versions of are risky and vulnerable to many types of attacks. Several standards, such as PCI-DSS and NIST, strongly encourage the use of TLS 1.2.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Load Balancer
  • Risk Level: HIGH
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Load balancer has no backend set

Description: Alert when a load balancer has no associated backend sets.

Recommendation: Ensure that you configure load balancers with backend sets to control the health and access to a load balancer by defined instances.

Background: A backend set is a logical entity defined by a load balancing policy, a health check policy, and a list of backend servers.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Load Balancer
  • Risk Level: CRITICAL
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Load balancer has no inbound rules or listeners

Description: Alert when a security list of a load balancer has ingress rules that accept traffic from an open source (0.0.0.0/0).

Recommendation: Ensure that your OCI load balancers use inbound rules or listeners to only allow access from known resources.

Background: OCI load balancers enable end-to-end TLS connections between a client's applications and your VCN. A listener is a logical entity that checks for incoming traffic on the load balancer's IP address. To handle TCP, HTTP, and HTTPS traffic, you must configure at least one listener per traffic type.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Load Balancer
  • Risk Level: MINOR
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Load Balancer has public IP address

Description: Alert when a load balancer is running with a public IP address.

Recommendation: Ensure that all load balancers not required to be publicly accessible are running with private IP addresses.

Background: A public IP address on a load balancer that is not intended to be used for publicly available content creates an unnecessary security vulnerability.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Load Balancer
  • Risk Level: High
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out OCIDs for any load balancer that should have a public IP address.
Load balancer SSL certificate expiring soon

Description: Alert when the SSL certificate in a load balancer is set to expire within your specified time period.

Note

Cloud Guard monitors for expiring certificates for:
  • Listeners and backend-sets in the load balancer.
  • Load balancer-managed certificates only.

    Service-managed certificates are not monitored.

Recommendation: Ensure that certificates are rotated on a timely basis.

Background: To ensure continuous security and usability, SSL certificates must be rotated in OCI.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Load Balancer
  • Risk Level: CRITICAL
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Set Days before expiring (default is 48) in the rule's Input Setting section.
NSG egress rule contains disallowed IP/port

Description: Alert when the egress rule for a network security group (NSG) contains a disallowed destination IP address and port number.

Recommendation: Ensure that the egress rules for communication with the IP/port are permitted for this NSG.

Background: NSGs act as a virtual firewall for compute instances and other kinds of resources. NSG's outbound (egress) security rules apply to a set of virtual NICs in a VCN to allow access to specific ports and IP addresses.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Network Security Group
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.3.4 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
  • CIS 1.1:

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

  • CIS 1.0:

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow that ingress from 0.0.0.0/0 to port 3389.

Best Practice for Rule Modifications:
  • Configuration: Add disallowed ports in the rule's Input Setting section.
NSG ingress rule contains disallowed IP/port

Description: Alert when the ingress rule for a network security group contains a disallowed destination IP address and port number.

Recommendation: Ensure that the ingress rules for communication with the IP/port are permitted for this NSG.

Background: NSGs act as a virtual firewall for compute instances and other kinds of resources. NSGs inbound (ingress) security rules apply to a set of virtual NICs in a VCN to allow access to specific ports and IP addresses.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Network Security Group
  • Risk Level: HIGH
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.2.1 - Restrict inbound and outbound traffic to what's necessary for the cardholder data environment, and specifically deny all other traffic.
  • CIS 1.1:

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

  • CIS 1.0:

    2.3 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 22.

    2.4 - Ensure that no network security groups allow ingress from 0.0.0.0/0 to port 3389.

Best Practice for Rule Modifications:
  • Configuration: Add disallowed ports in the rule's Input Setting section.
VCN has Internet Gateway attached

Description: Alert when a VCN is attached to an internet gateway.

Recommendation: Ensure that internet gateways are authorized to be attached to a VCN, and that this attachment doesn’t expose resources to the internet. Ensure that security lists with ingress / inbound rules and those security lists are not configured to allow access from all IP addresses 0.0.0.0/0.

Background: Gateways provide external connectivity to hosts in a VCN. They include internet gateway (IGW) for internet connectivity.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.3.4 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
  • CIS 1.1:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389

    2.5 - Ensure that the default security list of every VCN restricts all traffic except ICMP

    3.13 - Ensure that a notification is configured for changes to network gateways

  • CIS 1.0:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389

    2.7 - Ensure that the default security list of every VCN restricts all traffic except ICMP

Best Practice for Rule Modifications:
  • Leave default settings.
VCN has Local Peering Gateway attached

Description: Alert when a VCN is attached to a local peering gateway.

Recommendation: Ensure that local peering gateways are authorized to be attached to a VCN, and that this attachment doesn’t expose resources to the internet.

Background: Gateways provide external connectivity to hosts in a VCN. They include local peering gateway (LPG) for connectivity to peered VCN.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
  • CIS 1.1:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

    2.5 - Ensure that the default security list of every VCN restricts all traffic except ICMP.

    3.13 - Ensure that a notification is configured for changes to network gateways.

  • CIS 1.0:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

    2.5 - Ensure that the default security list of every VCN restricts all traffic except ICMP.

Best Practice for Rule Modifications:
  • Leave default settings.
VCN has no inbound Security List

Description: Alert when a VCN has no inbound security list.

Recommendation: Ensure that your OCI VCN's use security lists with ingress or inbound rules to only allow access from known resources.

Background: Security lists provide stateful and stateless firewall capability to control network access to your instances. A security list is configured at the subnet level and enforced at the instance level. You can apply multiple security lists to a subnet where a network packet is allowed, if it matches any rule in the security lists.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: MEDIUM
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Security list allows traffic to non-public port from all sources (0.0.0.0/0)

Description: Alert when a VCN security list allows unrestricted traffic to a non-public port from an open source (0.0.0.0/0).

Recommendation: Use VCN security lists to restrict network access to instances in a subnet. To prevent unauthorized access or attacks on compute instances, Oracle recommends that you:

  • Use a VCN security list to allow SSH or RDP access only from authorized CIDR blocks
  • Do not leave compute instances open to the internet (0.0.0.0/0)

Background: A VCN has a collection of features for enforcing network access control and securing VCN traffic. Security lists provide stateful and stateless firewall capability to control network access to your instances. A security list is configured at the subnet level and enforced at the instance level. You can apply multiple security lists to a subnet where a network packet is allowed, if it matches any rule in the security lists.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: CRITICAL
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.3 - Prohibit direct public access between the Internet and any system component in the cardholder data environment.
  • CIS 1.1:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

  • CIS 1.0:

    2.1 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 22.

    2.2 - Ensure that no security lists allow ingress from 0.0.0.0/0 to port 3389.

Best Practice for Rule Modifications:
  • Leave default settings.
VCN Security list allows traffic to restricted port

Description: Alert when a VCN security list allows certain restricted ports (see Input Settings, Restricted Protocol:Ports List) as part of the Security list ingress rule.

Recommendation: If "Restricted Protocol:Ports List" includes port values that are identified or allowed for your workloads, then modify the list of ports in Input Settings accordingly. Additional details section of the problem provides a list of open Restricted ports that triggered this problem. Ensure that your OCI VCNs use security lists with ingress or inbound rules to only allow traffic access to identified ports. Review if detected ports should be open on this security list Ingress rule and close them if they are not required to be open. Oracle also recommends checking the "Restricted Protocol:Ports List" in the Input setting of this detector rule and modify it to allow certain required ports and thus notifying Cloud Guard to not detect a problem for those ports.

Background: Security lists provide stateful and stateless firewall capability to control network access to your instances. A security list is configured at the subnet level and enforced at the instance level. You can apply multiple security lists to a subnet where a network packet is allowed, if it matches any rule in the security lists.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: MINOR
  • Labels: CIS_OCI_V1.0_NETWORK, CIS_OCI_V1.1_NETWORK, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.2 - Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
  • CIS 1.1: 2.5 - Ensure that the default security list of every VCN restricts all traffic except ICMP.
  • CIS 1.0: 2.7 - Ensure that the default security list of every VCN restricts all traffic except ICMP.
Best Practice for Rule Modifications:
  • Configuration:
    • Add Allowed Protocol:Ports List, in the rule's Input Setting section.
    • Modify Restricted Protocol:Ports List as needed, in the rule's Input Setting section.

    You can enter ports lists manually, or you can enter names of one or more security lists that you've defined. See Security Lists.

    Note

    Choosing between use of Allowed... List and Restricted... List:
    • If you leave both lists empty, accesses to all ports generate problems. Specify one or both lists to avoid this problem.
    • If you specify allowed ports, accesses to all other ports generate problems.
    • If you specify only restricted ports, accesses to only those ports generate problems.
    • If you specify the same port number in both lists, you aren't allowed to save your changes.
VNIC without associated network security group

Description: Alert when a virtual network interface card (VNIC) has no associated (NSG).

Recommendation: Ensure that all VNICs have an associated NSG.

Background: A VNIC is a networking component that enables a resource such as a compute instance to connect to a VCN. The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each VNIC resides in a subnet in a VCN. A VNIC without an NSG might trigger a connectivity issue.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: MINOR
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Modify Restricted Protocol:Ports List as needed, in the rule's Input Setting section.

Scanning Resources

Scanned container image has vulnerabilities

Description: Alert when Oracle Vulnerability Scanning Service (VSS) scans containers and identifies known cybersecurity vulnerabilities. To use this rule, you must create a Host Scan Recipe and a Host Scan Target in the Scanning service. See Scanning: Getting Started in the Scanning documentation.

Recommendation: Perform the recommended actions that are documented for each vulnerability, such as applying an OS patch.

Background: The Scanning service identifies vulnerabilities for applications, libraries, operating systems, and services. Each vulnerability in the database has a distinct identifier or CVE.

Rule Parameters:

  • Service Type: Scanning, Compute
  • Resource Type: Container
  • Risk Level: CRITICAL
  • Labels: VSS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave the default settings (all CVEs are detected)
Scanned host has open ports

Description: Alert when Oracle Vulnerability Scanning Service (VSS) scans Compute instances (hosts) and identifies open ports. To use this rule, you must create a Host Scan Recipe and a Host Scan Target in the Scanning service. See Scanning: Getting Started in the Scanning documentation.

Recommendation: Review the identified ports and close them if you determine that they should not be open on this host.

Background: Certain ports are required for operation and delivery of services, but any open ports beyond the intended list can potentially be used to exploit the services.

Rule Parameters:

  • Service Type: Scanning, Compute
  • Resource Type: Compute
  • Risk Level: CRITICAL
  • Labels: VSS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Add any Allowed Ports that should be ignored in the rule's Input Setting section.
Scanned host has vulnerabilities

Description: Alert when Oracle Vulnerability Scanning Service (VSS) scans Compute instances (hosts) and identifies known cybersecurity vulnerabilities. To use this rule, you must create a Host Scan Recipe and a Host Scan Target in the Scanning service. See Scanning: Getting Started in the Scanning documentation.

Recommendation: Perform the recommended actions that are documented for each vulnerability, such as applying an OS patch.

Background: The Scanning service identifies vulnerabilities for applications, libraries, operating systems, and services. Each vulnerability in the database has a distinct identifier or CVE.

Rule Parameters:

  • Service Type: Scanning, Compute
  • Resource Type: Compute
  • Risk Level: CRITICAL
  • Labels: VSS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave the default settings (all CVEs are detected)

Storage Resources

Block Volume is encrypted with Oracle-managed key

Description: Alert when a block volume is encrypted with Oracle-managed keys.

Recommendation: Assign a KMS key to this volume.

Background: Encryption of volumes provides an extra level of security on your data. Management of encryption keys is critical to protecting and accessing protected data. Some customers want to identify block volumes encrypted Oracle-managed keys vs the user-managed keys.

Rule Parameters:

  • Service Type: Storage
  • Resource Type: Block Volume
  • Risk Level: MINOR
  • Labels: KMS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Oracle-Managed Keys: Recommended to secure block volumes.
  • User-Managed Keys:
    • Use KMS wherever possible.
    • Implement Oracle Security Zones on compartments to ensure that practice is followed.
  • Conditional Groups: Avoid using, because of the large number of volumes.
Block Volume is not attached

Description: Alert when a block volume is not attached to its associated instance.

Recommendation: Ensure that the volume is attached.

Background: Detaching a block volume decouples the volume from its associated instance and could affect data availability, from business-critical data to point-in-time copies of volumes as backups.

Rule Parameters:

  • Service Type: Storage
  • Resource Type: Block Volume
  • Risk Level: MEDIUM
  • Labels: Storage
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Avoid using, because of large number of volumes.
Bucket is public

Description: Alert when a bucket is public.

Recommendation: Ensure that the bucket is sanctioned for public access, and if not, direct the OCI administrator to restrict the bucket policy to allow only specific users access to the resources required to accomplish their job functions.

Background: Object Storage supports anonymous, unauthenticated access to a bucket. A public bucket that has read access enabled for anonymous users allows anyone to obtain object metadata, download bucket objects, and optionally list bucket contents.

Rule Parameters:

  • Service Type: Storage
  • Resource Type: Bucket
  • Risk Level: CRITICAL
  • Labels: CIS_OCI_V1.1_ObjectStorage, ObjectStorage
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.2.1 - Restrict inbound and outbound traffic to what's necessary for the cardholder data environment, and specifically deny all other traffic.
  • CIS 1.1: 4.1 - Ensure that no Object Storage buckets are publicly visible.
  • CIS 1.0: Not Covered by CIS 1.0.
Best Practice for Rule Modifications:
  • Conditional Groups: Filter out bucket names (<namespace>/<name>) for any that are supposed to be public.
Object Storage bucket is encrypted with Oracle-managed key

Description: Alert when an Object Storage bucket is encrypted with an Oracle-managed key.

Recommendation: Assign a KMS key to this bucket.

Background: Encryption of storage buckets provides an extra level of security on your data. Management of encryption keys is critical to protecting and accessing protected data. Some customers want to identify storage buckets encrypted Oracle-managed keys.

Rule Parameters:

  • Service Type: Storage
  • Resource Type: Bucket
  • Risk Level: MINOR
  • Labels: CIS_OCI_V1.1_ObjectStorage, ObjectStorage, KMS
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not an issue for PCI.
  • CIS 1.1: 4.2 -Ensure Object Storage Buckets are encrypted with a Customer Managed Key (CMK).
  • CIS 1.0: Not Covered by CIS 1.0.
Best Practice for Rule Modifications:
  • Configuration: If you require strict key control using user-managed keys through KMS, create an Oracle Security Zone compartment and create resources in that compartment.
Read Log access disabled for bucket

Description: Alert when the read access logs are not enabled for an Object Storage bucket.

Recommendation: Ensure that read logs are enabled for the bucket and that the logs are being continuously monitored by the security tools.

Background: Access logs help you secure your sensitive objects by providing visibility into the activities around read and write operations on the objects within the Object storage bucket.

Rule Parameters:

  • Service Type: Storage
  • Resource Type: Bucket
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.1_ObjectStorage, ObjectStorage
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.2.1 - Restrict inbound and outbound traffic to what's necessary for the cardholder data environment, and specifically deny all other traffic.
  • CIS 1.1: 4.1 - Ensure that no Object Storage buckets are publicly visible.
  • CIS 1.0: Not Covered by CIS 1.0.
Best Practice for Rule Modifications:
Write Log access disabled for bucket

Description: Alert when the write access logs are not enabled for an Object Storage bucket.

Recommendation: Ensure that write logs are enabled for the bucket and that the logs are being continuously monitored by the security tools.

Background: Access logs help you secure your sensitive objects by providing visibility into the activities around read and write operations on the objects within the Object storage bucket.

Rule Parameters:

  • Service Type: Storage
  • Resource Type: Bucket
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.1_MONITORING, CIS_OCI_V1.1_ObjectStorage, ObjectStorage
Compliance Control Mapping:
  • PCI-DSS 3.2.1: 1.2.1 - Restrict inbound and outbound traffic to what's necessary for the cardholder data environment, and specifically deny all other traffic.
  • CIS 1.1: 4.1 - Ensure that no Object Storage buckets are publicly visible.
  • CIS 1.0: Not Covered by CIS 1.0.
Best Practice for Rule Modifications:
OCI Activity Detector Rules

Reference material for the Oracle-managed activity detector recipe that Cloud Guard provides is grouped below by resource type. Expand a Rule Display Name to view the details.

Bastion Resources

Bastion created

Description: Alert when a new Bastion instance is created.

Recommendation: Ensure that only authorized users create Bastion instances.

Background: Bastions provide users with secure and seamless SSH access to target hosts in private subnets, while still restricting direct public access.

Rule Parameters:

  • Service Type: Bastion
  • Resource Type: Instance
  • Risk Level: LOW
  • Labels: Bastion
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Bastion session created

Description: Alert when a new Bastion session is created.

Recommendation: Ensure that only authorized users create Bastion sessions.

Background: A Bastion Session provides time-bound, secure, and seamless SSH access to a target host in private subnets, while still restricting direct public access.

Rule Parameters:

  • Service Type: Bastion
  • Resource Type: Instance
  • Risk Level: LOW
  • Labels: Bastion
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.

Certificates Resources

CA bundle updated

Description: Alert when a CA bundle is updated.

Recommendation: Ensure that only authorized users update CA bundles. If user is not authorized, reverse the update.

Background: A CA bundle is a file that contains root and intermediate certificates. The CA in the bundle vouches for the users' intermediate certificates. When a CA bundle is updated, a user who is associated with a deleted intermediate certificate is no longer able to access resources vouched for by the CA. Similarly, a user who is associated with an intermediate certificate that is added is now able to access those resources.

Rule Parameters:

  • Service Type: Certificates
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: Certificates
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Certificate Authority (CA) deleted

Description: Alert when a certifying authority (CA) bundle is deleted.

Recommendation: Ensure that only authorized users delete CA bundles are only deleted by authorized users. If user is not authorized, cancel the deletion.

Background: A CA bundle is a file that contains root and intermediate certificates. The CA in the bundle vouches for the users' intermediate certificate. When a CA bundle is deleted, the users who are associated with the intermediate certificates are no longer able to access resources that require the CA's vouching.

Rule Parameters:

  • Service Type: Certificates
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: Certificates
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Certificate Authority (CA) has no revocation list

Description: Alert when a certifying authority (CA) has no certificate revocation list (CRL).

Recommendation: Create object storage, edit the CA, and add a CRL.

Background: When a client makes a TLS connection and downloads your certificate, the certificate contains a link to the CRL. The client can then check the CRL to ensure the certificate it downloaded can be trusted. Most clients automatically trust the certificate when they can't find the CRL.

Rule Parameters:

  • Service Type: Certificates
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: Certificates
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Intermediate Certificate Authority (CA) revoked

Description: Alert when an intermediate certificate in a certifying authority (CA) bundle is revoked.

Recommendation: Ensure that only authorized users revoke intermediate certificates in CA bundles. If user is not authorized, cancel the revocation.

Background: When an intermediate certificate in a CA bundle is revoked, the associated user is no longer able to access resources that require the user's intermediate certificate to be vouched for by an approved CA.

Rule Parameters:

  • Service Type: Certificates
  • Resource Type: User
  • Risk Level: MEDIUM
  • Labels: Certificates
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.

Compute Resources

Export Image

Description: Alert when a Compute image is exported.

Recommendation: Images that contain anything proprietary should be tagged accordingly with export privileges allowed only to suitable OCI administrators.

Background: Compute images might be equivalent to "data drives" and contain sensitive information. Images that might contain anything proprietary should be identified accordingly with export privileges permitted only to suitable OCI administrators.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: MINOR
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Import Image

Description: Alert when a Compute image is exported.

Recommendation: Ensure that a person expected to bring new images into your environment imports the compute image from trusted sources, such as Oracle or a trusted Compute administrator.

Background: Compute images are the foundations for compute instances. A new image impacts every future compute instance launched from that image and imported images should come from known and trusted sources.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: MINOR
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Instance terminated

Description: Alert when a Compute instance is terminated.

Recommendation: Use IAM policies to restrict instance termination operations.

Background: Compute instances might deliver critical functions.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: HIGH
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Update Image

Description: Alert when a Compute image is updated.

Recommendation:

Ensure that:

  • A person expected to bring new images into your environment imports the image.
  • The image is imported from trusted sources, such as Oracle or a trusted Compute administrator.

Background: Compute images are the foundations for compute instances. A modification to images impacts every future compute instance launched from that image. Images and any changes related to them should come from known and trusted sources.

Rule Parameters:

  • Service Type: Compute
  • Resource Type: Instance
  • Risk Level: LOW
  • Labels: Compute
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.

Database Resources

Database System terminated

Description: Alert when a database system is terminated.

Recommendation: Ensure that a permitted administrator sanctions and performs the termination of the database system and related databases.

Background: Database systems might hold sensitive data and provide critical functionality. Termination of a database system permanently deletes the system, any databases running on it, and any storage volumes attached to it.

Rule Parameters:

  • Service Type: DB System
  • Resource Type: System
  • Risk Level: HIGH
  • Labels: Database
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.

IAM Resources

IAM API keys Created

Description: Alert when IAM API keys are created for a user.

Recommendation: Ensure that API keys are created only by users who are authorized to create API keys, for themselves or for other users.

Background: API keys are needed to use one of Oracle SDKs or other developer tools. Use of these developer tools by persons whose job function doesn't require it is a security vulnerability.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to create API keys for users.
IAM API keys Deleted

Description: Alert when a user's IAM API key is deleted.

Recommendation: Ensure that API keys are deleted only by users who are authorized to create and delete API keys.

Background: API keys are needed to use one of Oracle SDKs or other developer tools. Deletion of API keys for a user who is working with Oracle developer tools can seriously impact productivity.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to delete users' API keys.
IAM Auth Token Created

Description: Alert when an IAM Auth Token is created for a user.

Recommendation: Ensure that IAM Auth Tokens are created by and for authorized users.

Background: Auth Tokens can be used to authenticate with third-party APIs. Availability of Auth Tokens to people whose job function doesn't require them creates a security vulnerability. See User Credentials.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to create IAM Auth Tokens.
IAM Auth Token Deleted

Description: Alert when an IAM Auth Token is deleted for a user.

Recommendation: Ensure that IAM Auth Tokens are deleted by authorized users.

Background: Auth Tokens can be used to authenticate with third-party APIs. Availability of Auth Tokens to people whose job function doesn't require them creates a security vulnerability. See User Credentials.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to delete IAM Auth Tokens.
IAM Customer Keys created

Description: Alert when IAM customer keys are created.

Recommendation: Ensure that these keys are created only for authorized users.

Background: Customer secret keys are created for Amazon S3 Compatibility API use with Object Storage.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to create IAM customer keys.
IAM Customer Keys Deleted

Description: Alert when IAM customer keys are deleted.

Recommendation: Ensure that deletion of these keys is expected.

Background: Customer secret keys are created for Amazon S3 Compatibility API use with Object Storage.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to delete IAM customer keys.
IAM Group created

Description: Alert when an IAM group is created.

Recommendation: Ensure that only authorized users create IAM groups.

Background: Groups control access to resources and privileges.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Group
  • Risk Level: MINOR
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
IAM Group deleted

Description: Alert when an IAM group is deleted.

Recommendation: Ensure that only authorized users perform IAM group deletions.

Background: Groups control access to resources and privileges.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: GROUP
  • Risk Level: MINOR
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
IAM OAuth 2.0 credentials created

Description: Alert when IAM OAuth 2.0 credentials are created.

Recommendation: Ensure that these credentials are created only for authorized users.

Background: IAM OAuth 2.0 credentials are for interacting with the APIs of those services that use OAuth 2.0 authorization. See User Credentials.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to create IAM OAuth 2.0 credentials.
IAM OAuth 2.0 credentials Deleted

Description: Alert when IAM OAuth 2.0 credentials are deleted.

Recommendation: Ensure that deletion of these credentials is expected.

Background: IAM OAuth 2.0 credentials are for interacting with the APIs of those services that use OAuth 2.0 authorization. See User Credentials.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to delete IAM OAuth 2.0 credentials.
IAM User capabilities modified

Description: Alert when an IAM user's capabilities are edited.

Recommendation: Ensure that only authorized users change an IAM user's capabilities.

Background: To access Oracle Cloud Infrastructure, a user must have the required credentials like API keys, auth tokens, and, other credentials.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Leave default settings.
IAM User created

Description: Alert when a local or federated user is created in OCI IAM.

Recommendation: Ensure that only authorized users create IAM users.

Background: An IAM user can be an individual employee or system that needs to manage or use your company's Oracle Cloud Infrastructure resources.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: MINOR
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
IAM User UI password created or reset

Description: Alert when a user's Console password is create or reset.

Recommendation: Ensure that a user's password is reset by the user, or by an admin user who is authorized to reset passwords.

Background: Resetting a user's password multiple times, or resetting by a user who is not authorized to reset user passwords, might indicate a security risk.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: IAM
  • Resource Type: User
  • Risk Level: LOW
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to reset user passwords.
Security policy modified

Description: Alert when a security policy is modified.

Recommendation:

Ensure that:
  • The policy is restricted to allow only specific users to access the resources required to accomplish their job functions
  • The modification is sanctioned

Background: Changing policies impact the all users in the group and might give privileges to users who do not need them.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Policy
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.1_MONITORING, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.7 - Ensure that a notification is configured for IAM policy changes.
Best Practice for Rule Modifications:
  • Leave default settings.
User added to group

Description: Alert when a user is added to a group.

Recommendation: Ensure that the user is entitled to be a member of the group.

Background: Groups control access to resources and privileges. Sensitive groups should be closely monitored for membership changes.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: Group
  • Risk Level: MINOR
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.6 - Ensure that a notification isthat configured for IAM group changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
User removed from group

Description: Alert when a user is removed from a group.

Recommendation: Ensure that the user is entitled to be a member of the group.

Background: Groups control access to resources and privileges. Sensitive groups should be closely monitored for membership changes.

Rule Parameters:

  • Service Type: IAM
  • Resource Type: User
  • Risk Level: MINOR
  • Labels: IAM
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to remove users from this group.

Networking Resources

DRG attached to a VCN

Description: Alert when a dynamic routing gateway (DRG) is attached to a VCN.

Recommendation: Ensure that the attaching of this DRG to the VCN is permitted and expected in this compartment by the resource (user).

Background: DRGs are used to connect existing on-premises networks to a virtual cloud network (VCN) with IPSec VPN or FastConnect.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: Networking
  • Resource Type: DRG
  • Risk Level: MINOR
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to attach DRGs to VCNs.
DRG created

Description: Alert when a dynamic routing gateway (DRG) is created.

Recommendation: Ensure that the creation of this DRG is permitted and expected in this compartment by the resource (user).

Background: DRGs are used to connect existing on-premises networks to a virtual cloud network (VCN) with IPSEC VPN or FastConnect.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: Networking
  • Resource Type: DRG
  • Risk Level: MINOR
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to create DRGs.
DRG deleted

Description: Alert when a dynamic routing gateway (DRG) is deleted.

Recommendation: Ensure that deletion of this DRG is permitted and expected by the resource (user).

Background: DRGs are used to connect existing on-premises networks to a virtual cloud network (VCN) with IPSec VPN or FastConnect.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: Networking
  • Resource Type: DRG
  • Risk Level: MINOR
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to delete DRGs.
DRG detached from a VCN

Description: Alert when a dynamic routing gateway (DRG) is detached from a VCN.

Recommendation: Ensure that the detaching of this DRG from the VCN is permitted and expected in this compartment by the resource (user).

Background: DRGs are used to connect existing on-premises networks to a virtual cloud network (VCN) with IPSec VPN or FastConnect.

Rule Parameters:

  • (Status: Disabled)
  • Service Type: Networking
  • Resource Type: DRG
  • Risk Level: MINOR
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Enable rule if you want to see which users are doing group-related operations.
  • Conditional Groups: Trigger a problem only if user is not in an admin group with permission to detach DRGs from VCNs.
Subnet Changed

Description: Alert when a subnet is changed.

Recommendation: Ensure that the change to the VCN is permitted and expected in this compartment.

Background: Subnets are subdivisions of a VCN. Compute instances that are connected in the same subnet use the same route table, security lists, and DHCP options.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Subnet
  • Risk Level: LOW
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Subnet deleted

Description: Alert when a subnet is deleted.

Recommendation: Enable multi-factor authentication (MFA) to ensure that the user is a genuinely logged in user and the credentials are not compromised.

Background: Subnets are subdivisions of a VCN. Compute instances that are connected in the same subnet use the same route table, security lists, and DHCP options.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Subnet
  • Risk Level: LOW
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Leave default settings.
Suspicious Ip Activity

Description: Alert when a user logs in, or an API invocation is made, from a suspicious IP address. If the proper policy is in place, provide a link from the Cloud Guard problem to detailed information on the suspicious IP address in the Threat Intelligence Service. For details on the required policy, see Threat Intelligence IAM Policies.

Recommendation: Enable multi-factor authentication (MFA) to ensure that the user is a genuinely logged in user and the credentials are not compromised.

Background: A user logging in from a suspicious IP address is a potential threat.

Rule Parameters:

  • Service Type: Cloud Guard
  • Resource Type: Security
  • Risk Level: CRITICAL
  • Labels: Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
Best Practice for Rule Modifications:
  • Configuration: Blocklist or allowlist CIDR blocks or specific IP addresses in the rule's Input Setting section.
VCN created

Description: Alert when a VCN is created.

Recommendation: Ensure that the creation of a new VCN is permitted and expected in this compartment.

Background: A VCN is a virtual, private network that you set up in Oracle data centers. Like a traditional network, it might contain firewall rules and specific types of communication gateways.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.9 - Ensure that a notification is configured for VCN changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN deleted

Description: Alert when a VCN is created.

Recommendation: Ensure that the deletion of a VCN is permitted and expected in this compartment.

Background: A VCN is a virtual, private network that you set up in Oracle data centers. Like a traditional network, it might contain firewall rules and specific types of communication gateways. VCN deletion can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: VCN
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.9 - Ensure that a notification is configured for VCN changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN DHCP Option changed

Description: Alert when a VCN DHCP option is changed.

Recommendation: Ensure that the change to DHCP and DNS information is permitted for this VCN and related resources.

Background: DHCP options control certain types of configuration on the instances in a VCN, including specification of search domains and DNS resolvers that can direct communications within VCNs across to Internet resources. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: DHCP
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.9 - Ensure that a notification is configured for VCN changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Internet Gateway created

Description: Alert when a VCN internet gateway is created.

Recommendation: Ensure that the creation of an internet gateway is permitted for this VCN and its related resources.

Background: Internet gateways are virtual routers you can add to your VCN to enable direct connectivity (inbound from or outbound) to the internet. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Internet Gateway
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.13 - Ensure that a notification is configured for changes to network gateways.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Internet Gateway terminated

Description: Alert when a VCN internet gateway is terminated.

Recommendation: Ensure that the deletion of an internet gateway is permitted for this VCN and its related resources.

Background: Internet gateways are virtual routers you can add to your VCN to enable direct connectivity (inbound from or outbound) to the internet. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Internet Gateway
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.13 - Ensure that a notification is configured for changes to network gateways.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Local Peering Gateway changed

Description: Alert when a VCN local peering gateway is changed.

Recommendation: Ensure that the changes to the LPG are permitted for this VCN and its related resources.

Background: VCN local peering gateways (LPG) connect two VCNs in the same region without routing traffic over the internet. LPG resources in the VCNs to communicate directly with private IP addresses. Changes to LPGs can impact resource access and cross-VCN communications. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Local Peering Gateway
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.13 - Ensure that a notification is configured for changes to network gateways.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Network Security Group Deleted

Description: Alert when a VCN's NSG is deleted.

Recommendation: Ensure that the removal of the NSG is permitted for this VCN and its related resources.

Background: Network security groups (NSGs) act as a virtual firewall for compute instances and other kinds of resources. NSGs have a set of inbound (ingress) and outbound (egress) security rules applied to a set of virtual NICs in a VCN. Deleting NSGs can remove protections between resources in the VCN, and cause denial of access to resources or data loss.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Network Security Group
  • Risk Level: HIGH
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.12 - Ensure that a notification is configured for network security group changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Network Security Group egress rule changed

Description: Alert when a VCN's NSG egress rule is changed.

Recommendation: Ensure that the new egress rules are permitted for this NSG and its related resources.

Background: Network security groups (NSGs) act as a virtual firewall for compute instances and other kinds of resources. NSGs have a set of inbound (ingress) and outbound (egress) security rules applied to a set of virtual NICs in a VCN. Egress rule changes can cause denial of access to resources.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Network Security Group
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.12 - Ensure that a notification is configured for network security group changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Network Security Group ingress rule changed

Description: Alert when a VCN's NSG ingress rule is changed.

Recommendation: Ensure that the new ingress rules are permitted for this NSG and its related resources.

Background: Network security groups (NSGs) act as a virtual firewall for compute instances and other kinds of resources. NSGs have a set of inbound (ingress) and outbound (egress) security rules applied to a set of virtual NICs in a VCN. Changes to NSGs ingress rules might allow connections and traffic to new resources and VNICs in the VCN.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Network Security Group
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.12 - Ensure that a notification is configured for network security group changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Route Table changed

Description: Alert when a VCN's route table is changed.

Recommendation: Ensure that the change to the route table is permitted and expected in this compartment.

Background: Virtual route tables have rules that look and act like traditional network route rules. Misconfigured route tables might send network traffic to be dropped (blackholed) or sent to an unintended target. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Route Table
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.10 - Ensure that a notification is configured for changes to route tables.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Security List created

Description: Alert when security list is created for a VCN.

Recommendation: Ensure that the creation of this security list is permitted for this VCN and its related resources.

Background: Security lists act as virtual firewalls for compute instances and other resources and consists of sets of ingress and egress rules that apply to all the VNICs in any subnet associated with that security list. Multiple security lists might apply to resources and give access to ports and IP addresses for those resources. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Security List
  • Risk Level: LOW
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.11 - Ensure that a notification is configured for security list changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Security List deleted

Description: Alert when security list for a VCN is deleted.

Recommendation: Ensure that the removal of this security list is permitted for this VCN and its related resources.

Background: Security lists act as virtual firewalls for compute instances and other resources and consists of sets of ingress and egress rules that apply to all the VNICs in any subnet associated with that security list. Multiple security lists might apply to resources and give access to ports and IP addresses for those resources. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Security List
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.11 - Ensure that a notification is configured for security list changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Security List egress rules changed

Description: Alert when a VCN's security list egress rules are changed.

Recommendation: Ensure that the changes to the egress rules are permitted for this security list and its related resources.

Background: Security lists act as virtual firewalls for compute instances and other resources and consists of sets of ingress and egress rules that apply to all the VNICs in any subnet associated with that security list. Multiple security lists might apply to resources and give access to ports and IP addresses for those resources. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Security List
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.11 - Ensure that a notification is configured for security list changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
VCN Security List ingress rules changed

Description: Alert when a VCN's security list ingress rules are changed.

Recommendation: Ensure that the changes to the ingress rules are permitted for this security list and its related resources.

Background: Security lists act as virtual firewalls for compute instances and other resources and consists of sets of ingress and egress rules that apply to all the VNICs in any subnet associated with that security list. Multiple security lists might apply to resources and give access to ports and IP addresses for those resources. VCN changes can change routing, FQDN resolution, and other networking operations.

Rule Parameters:

  • Service Type: Networking
  • Resource Type: Security List
  • Risk Level: MEDIUM
  • Labels: CIS_OCI_V1.0_MONITORING, CIS_OCI_V1.1_MONITORING, Network
Compliance Control Mapping:
  • PCI-DSS 3.2.1: Not applicable.
  • CIS 1.1: 3.11 - Ensure that a notification is configured for security list changes.
  • CIS 1.0: 4.6 Ensure that a notification is configured for IAM group changes.
Best Practice for Rule Modifications:
  • Leave default settings.
OCI Threat Detector Rules

Reference material for the Oracle-managed threat detector recipe that Cloud Guard provides.

Expand a Rule Display Name to view the details. Expand the "Sighting Type Reference" at the end to view technical information about the different sighting types that feed into OCI Threat Detector processing.

Rogue User

Description: Alert when a user has performed activities that generate a risk score that above the problem threshold, which could indicate a compromised account or an insider threat. Adversaries can use brute force techniques to gain access to accounts when passwords are unknown. Users could abuse their assigned privileges and perform tasks well beyond business requirements, which can be detrimental to the organization.

Recommendation: Consider temporarily disabling the account while you investigate the activity, and require a password reset if the user doesn't recognize the activity.

Background: A user's risk score that exceeds the problem threshold could indicate a compromised account or a disgruntled employee.

Rule Parameters: This rule has no parameters that you can modify.

Compliance Control Mapping:
  • Not applicable
Best Practice for Rule Modifications:
  • Leave default settings.
Sighting Type Reference

Review details of how sighting type data is derived and how it enters into calculation of risk score and security score.

Note

For all sighting types, more detailed information can be available from the reported problem, through a link that accesses the Threat Intelligence Service. This link requires a policy to be in place that grants the user permission:

... to read threat-intel-family in tenancy

See Threat Intelligence IAM Policies.

Elevated Access

Description: Adversaries could perform privileged activities that are beyond the users' day-to-day responsibilities or privileges could have been overprovisioned.

MITRE ATT&CK Framework
Data Sources:
  • OCI audit events
  • IP address reputation

Learning Period: Cloud Guard takes 90 days to learn a new user's activity pattern, before starting to identify privilege escalation sightings.

Severity and Confidence: Cloud Guard assigns both the severity and confidence levels, based on factors like these:

  • Is the requested permission the new highest permission for the service in the last few weeks?
  • Did the request originate from a suspicious IP address or a new geographical location?
  • Was a new user-agent used?
  • Was the user dormant for at least seven days before the request?
  • Was the request made through a TOR exit node, a public proxy, or an anonymous VPN?

The more factors such as these are involved, the higher the severity and confidence levels that are assigned.

Elevated Number of Pre-Authenticated Requests (PARs)

Description: Abnormal creation of pre-authenticated requests. Pre-authenticated requests provide a way to let users access a private bucket or an object without having their own credentials, which could help an attacker exfiltrate data instead of going through a command and control channel.

MITRE ATT&CK Framework
Data Sources:
  • OCI audit events

Learning Period: If the PARs are not spaced out in time, Cloud Guard can start detecting PARs within a few hours of the start of this type of attack. The more that PARs are spaced out in time, the longer it takes for Cloud Guard to detect.

Severity: Cloud Guard assigns the severity level based on the duration, quantity, and type of the PARs. The longer the duration and higher the quantity of PARs, the higher the severity level that's assigned.

Confidence: Cloud Guard assigns the confidence level based on the patterns of PAR-related activity detected. The more suspicious the pattern of PAR-related activity, the higher the confidence level that's assigned.

Impair Defenses

Description: Adversaries might exploit acquired privileges to disable defensive mechanisms such as cloud security tools, virtual cloud networks (VCN) security lists, and data backup.

MITRE ATT&CK Framework
Data Sources:
  • OCI audit events

Learning Period: Cloud Guard starts detecting impair-defenses within a few hours of the start of this type of attack.

Severity: Cloud Guard assigns the severity level based on the request status of the impair-defenses-related APIs and the impacted service type. The more security-related services that are impacted, the higher the severity level that's assigned.

Confidence: Cloud Guard assigns the confidence level based on the patterns of impair-defenses activity detected. The more instances of suspicious activity that occurred, and the more suspicious the pattern of impair-defenses-related activity is, the higher the confidence level that's assigned.

Impossible Travel

Description: Adversaries could obtain and abuse credentials for a cloud account, providing access to restricted resources. One way to detect illegitimate use of legitimate credentials is to identify access by the same account from different geographic locations, when the time period between accesses is too short to be physically possible.

MITRE ATT&CK Framework
Data Sources:
  • IP addresses
    Note

    To qualify as impossible travel, the two accesses by the account must be from IP address that are:
    • Originating from different countries.
    • Not listed as trusted.

    A machine learning algorithm ignores obvious false positives that appear to be instances of impossible travel, such as VPNs and locations regularly used by other users in the organization.

Learning Period: Cloud Guard takes seven days to learn a new user's activity pattern, before starting to compare IP addresses in successive accesses.

Severity: Cloud Guard assigns the severity level based on the observed IAM privilege level of the targeted user. The broader the user's privileges within your environment, the higher the severity level that's assigned.

Confidence: Cloud Guard assigns the confidence level based primarily on the patterns detected in the time and distance between sequential accesses. The shorter the time vs. the distance, the higher the confidence level that's assigned. Cloud Guard also factors in differences in patterns of privilege usage: the more the current pattern of privileges used diverges from past patterns, the higher the confidence level that's assigned.

Password Guessing

Description: Brute force attack, against a single user, by adversaries with no prior knowledge of legitimate credentials could guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary can try to systematically guess the password using a repetitive, iterative mechanism, or using a list of common passwords. If the attacker's automated process has a sufficient built-in wait time between failed authentication attempts, it doesn't cause account lockout.

MITRE ATT&CK Framework
Data Sources:
  • Login events
  • IP address reputation
  • Password change logs

Learning Period: Cloud Guard starts detecting password guessing within a few hours of the start of this type of attack.

Severity: Cloud Guard assigns the severity level based on the observed IAM privilege level of the targeted user. The broader the user's privileges within your environment, the higher the severity level that's assigned.

Confidence: Cloud Guard assigns the confidence level based on the patterns of suspicious activity detected. The more instances of suspicious activity that occurred, and the more suspicious the individual instances are, the higher the confidence level that's assigned.

Password Spraying

Description: Brute force attack, against multiple users, by adversaries with no prior knowledge of legitimate credentials could guess passwords to try to get access to accounts. Adversaries could use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials. Logins are attempted against many different accounts to avoid lockouts that would normally occur when brute forcing a single account with many passwords.

MITRE ATT&CK Framework
Data Sources:
  • Login events
  • IP address reputation
  • Password change logs

Learning Period: Cloud Guard starts detecting password spraying within a few hours of the start of this type of attack.

Severity: Cloud Guard assigns the severity level based on the observed IAM privilege level of the targeted user. The broader the user's privileges within your environment, the higher the severity level that's assigned.

Confidence: Cloud Guard assigns the confidence level based on the patterns of suspicious activity detected. The more instances of suspicious activity that occurred, and the more suspicious the individual instances are, the higher the confidence level that's assigned.

Persistence

Description: Adversaries might add an adversary-controlled API key to maintain persistent access to victim accounts and instances.

MITRE ATT&CK Framework
Data Sources:
  • IP Reputation
  • OCI audit events

Learning Period: Cloud Guard starts detecting persistence within a few days of the start of this type of attack.

Severity: Cloud Guard assigns the severity level based on the observed IAM privilege level of the victim user. The broader the user's privileges within your environment, the higher the severity level that's assigned.

Confidence: Cloud Guard assigns the confidence level based on the patterns of persistence activity detected. The more instances of suspicious activity that occurred, and the more suspicious the pattern of persistence-related activity is, the higher the confidence level that's assigned.