Managing Detector Recipes

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

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. A detector recipe consists of multiple detector rules. If any one rule is triggered, it causes the detector to report a problem.

About Detector Recipes

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

Each detector recipe uses multiple detector rules, each of which a specific definition of a class of resources, with specific actions or configurations, that cause a detector to report a problem. If any one rule is triggered, it causes the detector to report a problem.

Cloud Guard provides two types of detector recipes:

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

You apply detector recipes to compartments.

If a compartment has other compartments below it, the detector recipe's rules automatically apply to all lower level compartments in the hierarchy.

When a compartment hierarchy has detector recipes applied to compartments at different levels, whenever the rules conflict, the rules from the detector recipe applied at a lower level override the rules from any detector recipe that is applied at a higher level. This applies to the compartment on which a detector recipe is applied and all compartments below it.

Inheritance Details for Detector Rule Fields

There are four levels at which the fields within a detector recipe and its detector rules can be modified. Each has its own set of restrictions.

Note

The precedence for detector recipe rules applied at these different levels is similar to the precedence for a compartment hierarchy: whenever the rules conflict, the rules at a more specific level (higher number in list below) override rules at a broader level (lower number in list below.
  1. Oracle: When Cloud Guard needs to update or create new Oracle managed recipes, they are available to all tenants.
  2. Tenant: These are changes applicable only to a particular tenant.
    • These fields can be modified at the tenant level for an Oracle managed recipe:
      • Labels (can only be added)
      • Configurations (also called Settings)
      • Conditions
    • These fields can't be modified at the tenant level for an Oracle managed recipe:
      • Status (enabled/disabled)
      • Risk Level
    • These fields can be modified at the tenant level for a non-Oracle managed recipe:
      • Status (enabled/disabled)
      • Risk Level
      • Labels
      • Configurations (also called Settings)
      • Conditions
  3. Target: These are changes applicable only to a particular target.
    • These fields can be modified at the target level for both Oracle managed and non-Oracle managed recipes:
      • Conditions
    • These fields can be modified at the target level for a non-Oracle managed recipe:
      • Status (enabled/disabled)
      • Risk Level
      • Labels
      • Configurations (also called Settings)
  4. Descendant compartments of a target: These are changes applicable only to a compartment selected from the descendant tree of a target.
    • These fields can be modified at the target level for both Oracle managed and non-Oracle managed recipes:
      • Conditions
    • These fields can be modified at the target level for a non-Oracle managed recipe:
      • Status (enabled/disabled)
      • Risk Level
      • Labels
      • Configurations (also called Settings)

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 or a Configuration recipe.
  2. To filter the list of detector recipes, start typing in the Filter by name box.
  3. To view the details for a particular detector recipe, open the Actions menu Image of Action menu, and select View.
    Note

    Tags functionality is temporarily not available for detector recipes. You can't use the Tags tab or the Add Tags button for detector recipes.
  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. 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.
  6. 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.

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. From the Cloning list, select the detector recipe you want to clone.
    2. Enter a Name for the new detector recipe.
    3. (Optional) Enter a Description for the new detector recipe.
    4. Specify a Compartment Assignment by selecting from the list.
    5. 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.
    Note

    Tags functionality is temporarily not available for detector recipes. You can't use the Tags tab or the Add Tags button for detector recipes.
  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, then click Save
    • 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 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 add tags to the detector recipe:
      1. Click Add Tags below the detector recipe's name on the details page.
      2. In the Add One Or More Tags To This Resource dialog box, select a Tag Namespace, then enter a Tag Key and a Value.
      3. To add another tag, click Additional Tag, then repeat the previous step.
      4. When you finish adding tags, click Add Tags.
    • 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.

  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.
  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 Processing and Resolving Problems on the Problems Page.
    • Set a different Risk Level.
    • Edit the Labels entry.
      Separate multiple labels with a semicolon (";").
  4. In the Conditional Groups section at the bottom, you can:
    1. Select a Parameter.
    2. Select an Operator.
    3. Select a Value.
    4. To add another condition, click Add Condition and repeat the last three steps.
      Note

      When you specify multiple conditions, the conditions are ANDed. The rule is enforced only if all the conditions are met. If you need to OR multiple conditions, clone a separate recipe for each condition and specify only one condition for the rule in each recipe.
    5. To delete a condition, click the "X" at the right end of the row for the condition.
    For more information on Conditional Groups, see Using Conditional Groups with Recipe Rules.
  5. To change settings for another detector rule, repeat the previous steps, beginning with step 5.
  6. Click Save.

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 tables 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.
Configuration Detectors

The following table lists summary information for the Oracle-managed configuration detectors that Cloud Guard provides.

Rule Display Name Description, Recommendation, and Background Rule Parameters Best Practice for Rule Modifications
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.

Service Type: IAM

Exadata BareMetal VM: IAMKey

Risk Level: MEDIUM

Labels: IAM

  • Configuration: (Optional) You can change the default value of 90 days in the rule's Settings Input section.
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.

Service Type: Storage

Exadata BareMetal VM: Block Volume

Risk Level: MINOR

Labels: KMS, CIS 3.0

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

Service Type: Storage

Exadata BareMetal VM: Block Volume

Risk Level: MEDIUM

Labels: Storage

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

Service Type: Storage

Exadata BareMetal VM: Bucket

Risk Level: CRITICAL

Labels: CIS 3.0, Object Storage

  • Conditional Groups: Filter out bucket OCIDs for any that are supposed to be public.
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,

Service Type: Database

Exadata BareMetal VM: DB System

Risk Level: HIGH

Labels: Database, CIS 3.0

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

Service Type: Database

Exadata BareMetal VM: DB System

Risk Level: MEDIUM

Labels: Database, CIS 3.2

  • Configuration: Set Number of days to apply patch in the rule's Settings Input 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.

Service Type: Database

Exadata BareMetal VM: Exadata BareMetal VM

Risk Level: HIGH

Labels: Database, CIS 3.1

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

Service Type: Database

Exadata BareMetal VM: DB System

Risk Level: MEDIUM

Labels: Database

  • Configuration: Set Number of days to apply patch in the rule's Settings Input 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.

Service Type: Database

Exadata BareMetal VM: Exadata BareMetal VM

Risk Level: CRITICAL

Labels: Database

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

Service Type: Database

Exadata BareMetal VM: Exadata BareMetal VM

Risk Level: CRITICAL

Labels: Database

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

Service Type: IAM

Exadata BareMetal VM: Group

Risk Level: LOW

Labels: IAM

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

Service Type: IAM

Exadata BareMetal VM: Group

Risk Level: MEDIUM

Labels: IAM

  • Leave default settings.
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 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)

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: HIGH

Labels: Compute, CIS 3.0

  • Conditional Groups: Filter out OCIDs for any instance that should have a public IP address.
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.

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: LOW

Labels: Compute

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

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: CRITICAL

Labels: Compute, CIS 3.0

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

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: LOW

Labels: Compute

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

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: MEDIUM

Labels: Compute, CIS 3.0

  • Configuration: Add required tags in the rule's Settings Input section.
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 Settings Input section.

Service Type: KMS

Exadata BareMetal VM: KMS Key

Risk Level: CRITICAL

Labels: KMS, CIS 3.0

  • Configuration: Set the default time for rotating keys in the rule's Settings Input section.

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.

Service Type: Networking

Risk Level: MEDIUM

Labels: customer defined

  • 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 TLS 1.2.

Recommendation: Ensure that the SSL policy version configured is at least TLS1.2.

Background: Older versions of Transport Layer Security (TLS) 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.

Service Type: Networking

Risk Level: HIGH

Labels: customer defined

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

Service Type: Networking

Exadata BareMetal VM: Load Balancer

Risk Level: CRITICAL

Labels: Network, CIS 3.0

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

Service Type: Networking

Exadata BareMetal VM: Load Balancer

Risk Level: MINOR

Labels: Network, CIS 3.1

  • Leave default settings.
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.

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

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

Service Type: Networking

Exadata BareMetal VM: Load Balancer

Risk Level: CRITICAL

Labels: Network

  • Configuration: Set Days before expiring (default is 48) in the rule's Settings Input 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.

Service Type: Networking

Exadata BareMetal VM: Network Security Group

Risk Level: MEDIUM

Labels: Network

  • Configuration: Add disallowed ports in the rule's Settings Input 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.

Service Type: Networking

Exadata BareMetal VM: Network Security Group

Risk Level: HIGH

Labels: Network

  • Configuration: Add disallowed ports in the rule's Settings Input section.
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.

Service Type: Storage

Exadata BareMetal VM: Bucket

Risk Level: MINOR

Labels: KMS, CIS 3.0

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

Service Type: IAM

Exadata BareMetal VM: User

Risk Level: MEDIUM

Labels: IAM

  • Configuration: Set the maximum number of days for passwords (default is 90) in the rule's Settings Input section.
Password policy does not meet complexity requirements

Description: Alert when an IAM password does not meet your specified 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.

Service Type: IAM

Exadata BareMetal VM: Policy

Risk Level: LOW

Labels: IAM

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

Service Type: IAM

Exadata BareMetal VM: Policy

Risk Level: MEDIUM

Labels: IAM

  • Configuration: Add OCIDs for any groups that should be allowed these privileges in the rule's Settings Input section.
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: Untagged resources in OCI indicate that infrastructure has been created without the use of sanctioned tags. Uncontrolled infrastructure can result in a weakened security posture. Resource types that trigger an alert if untagged: Compute images (IMAGE), Compute instances (INSTANCE), Database systems (DB_SYSTEM), VCNs (VCN), Object Storage (BUCKET), and Block Volume (VOLUME).

Service Type: Multiple

Exadata BareMetal VM: Multiple

Risk Level: LOW

Labels: []

  • Configuration: Add appropriate tags in the rule's Settings Input 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.

Service Type: IAM

Exadata BareMetal VM: Policy

Risk Level: LOW

Labels: []

  • Configuration: Add OCIDs of groups that should have admin privilege in the rule's Settings Input 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.

Service Type: IAM

Exadata BareMetal VM: User

Risk Level: User

Labels: IAM

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

Service Type: IAM

Exadata BareMetal VM: User

Risk Level: LOW

Labels: IAM

  • Leave default settings.
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.

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: LOW

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: LOW

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: CRITICAL

Labels: Network

  • Configuration: Add any restricted_protocol:ports lists in the rule's Settings Input section.
VCN Security list allows traffic to restricted port

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

Recommendation: Ensure that your security lists do not allow the 0.0.0.0/0 IP address range to control access to your instances. While VCNs would require a public facing IP address and an internet facing gateway with an open security list, defense in depth dictates that security lists be limited to known resources. It should be noted that a NAT instance can also provide internet access.

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.

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: CRITICAL

Labels: Network

  • Configuration: Modify restricted_protocol:ports list as needed, in the rule's Settings Input section.
Activity Detectors

The following table lists summary information for the Oracle-managed activity detectors that Cloud Guard provides.

Rule Display Name Description, Recommendation, and Background Rule Parameters Best Practice for Rule Modifications
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.

Service Type: DB System

Exadata BareMetal VM: System

Risk Level: HIGH

Labels: Database

  • Leave default settings.
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.

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: MINOR

Labels: Compute, CIS 3.0

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

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: MINOR

Labels: Compute

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

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: HIGH

Labels: Compute, CIS 3.0

  • Leave default settings.
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.

Service Type: IAM

Exadata BareMetal VM: Policy

Risk Level: LOW

Labels: IAM

  • Leave default settings.
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.

Service Type: Networking

Exadata BareMetal VM: Subnet

Risk Level: LOW

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Subnet

Risk Level: LOW

Labels: Network

  • Leave default settings.
Suspicious Ip Activity

Description: Alert when a user logs in from a suspicious IP address.

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.

Service Type: Cloud Guard

Exadata BareMetal VM: Security

Risk Level: CRITICAL

Labels: Network, CIS 3.0

  • Configuration: Blocklist or allowlist CIDR blocks or specific IP addresses in the rule's Settings Input section.
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 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.

Service Type: Compute

Exadata BareMetal VM: Instance

Risk Level: LOW

Labels: Compute

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

Service Type: IAM

Exadata BareMetal VM: Group

Risk Level: MINOR

Labels: IAM

  • Leave default settings.
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.

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: LOW

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: VCN

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: DHCP

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Internet Gateway

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Internet Gateway

Risk Level: LOW

Labels: Network

  • 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. LPGs 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.

Service Type: Networking

Exadata BareMetal VM: Local Peering Gateway

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Network Security Group

Risk Level: HIGH

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Network Security Group

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Network Security Group

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Route Table

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Security List

Risk Level: LOW

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Security List

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Security List

Risk Level: MEDIUM

Labels: Network

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

Service Type: Networking

Exadata BareMetal VM: Security List

Risk Level: MEDIUM

Labels: Network

  • Leave default settings.