Oracle Cloud Infrastructure Documentation

Some Common Features

As you prepare to customize Oracle Cloud Guard, there are several features that are common across more than one area.

You can preview these features in the following sections before you start customizing Cloud Guard, or you can follow links from specific tasks where the information is helpful.

Overview of Recipes

Understand the differences between Oracle-managed and user-managed recipes, how user-managed recipes work, and what settings can be changed at the recipe and target levels.

The three sections below also appear in About OCI Responder Recipes and About OCI Detector Recipes.

Oracle-Managed vs. User-Managed Recipes

Understand differences between these two categories of recipes.

For both detectors and responders, Cloud Guard provides a rich set of Oracle-managed recipes for:

  • OCI Configuration detectors
  • OCI Activity detectors
  • OCI Threat detectors
  • Responders

Although you can use the Oracle-managed recipes as is, you'll probably want to make changes to adapt them to the specific needs of your environment. In particular, you might want to change the risk level associated with some rules, and you might want to disable other rules altogether. To make these types of changes, first clone the recipe to make a user-managed copy, and then you make changes to the copy.

If new detector rules are added to an Oracle-managed recipe, the rules are automatically added to all user-managed (cloned) copies of that recipe, with the default values from the Oracle-managed source. You can then modify the new rule's configuration in the user-managed copies of the recipe.

The following table shows an example of three detector rules from the Oracle-managed recipe and how a user-manged copy might be modified. Changes for the user-managed rules are shown in bold:

Oracle-Managed Recipe User-Managed Recipe
Rule Status Risk Level Status Risk Level
Bucket is public ENABLED HIGH DISABLED HIGH
KMS Key not rotated ENABLED MEDIUM ENABLED HIGH
Instance has public IP address ENABLED CRITICAL ENABLED CRITICAL

You can clone the same Oracle-managed recipe as many times as you need, to create user-managed copies that are fine-tuned for special purposes. Some reasons for having different recipes might include:

  • Different treatment of non-production versus production workloads.
  • Separate operations or notification processes for resources in different compartments.
  • Regional requirements for resources in some compartments.
  • Different types of resources requiring different rules for configuration or activity.
How User-Managed (Cloned) Detectors and Responders Work

Understand how a user-managed recipe retains ties to the Oracle-managed recipe from which it was cloned.

  • When you clone an Oracle-managed recipe, it creates a user-managed copy. The user-managed copy is exactly like the Oracle-managed original, but you can customize it.

    Changes you make in the cloned copy, including changes to rule settings, do not affect the original detector or responder recipe.

  • You can't change everything in your user-managed recipes. For individual rules, you can change the risk level and you can enable and disable the rule and change its risk level. You can't delete rules or add new rules.
  • To use a user-managed recipe, you must add it to a target. A target can only have one recipe of each type added to it: configuration detectors, activity detectors, and responders. If a target already has a recipe of the type you want to add, you have to remove that recipe before you can add another of the same type. See Editing an OCI Target and Its Attached Recipes.
  • Cloud Guard keeps your user-managed recipes in sync with the original Oracle-managed recipes. Any new rules added to the original Oracle-managed recipe are automatically added to your cloned copies. And any improvements made to rules in the original Oracle-managed recipe are automatically reflected in the same rules in your cloned copies.
  • Watch for new rules being added to your user-managed recipes. Any new rules that are added are disabled by default. Examine new rules closely to see if you want to enable them. Monitor Cloud Guard Release Notes for these updates.
  • Monitor the list of rules that you disable in a user-managed recipe to see if any need to be enabled. As time passes, you might find that you want to start using some of the recipes that you disabled earlier. Monitor Cloud Guard Release Notes for these updates.
Modifying Recipes at Recipe and Target Levels

Understand how Oracle Cloud Guard separates recipe settings into two levels, and how to update different settings for Oracle-managed or user-managed (cloned), detector and responder recipes at those two levels.

Cloud Guard separates the settings that you can configure for detector and responder rules into two groups, recipe level and target level. You access these levels from different pages.

If you don't understand the details, managing detector and responder recipes in Oracle Cloud Guard can become confusing. The Detector Recipe Reference section at the end of this section summarizes the information for all types of recipes, when accessed from either the Targets page or the respective recipes pages.

Note

When you update an Oracle-managed recipe, the updates are applied automatically to all user-managed recipes cloned from it. Whichever page you start from when you change a recipe, the changes remain when you access the recipe, starting from the other page.
  • Recipe Level settings are "strategic" in nature. That is, they have the broadest impact, affecting all targets to which the recipe is attached. These settings should require the highest level of permissions to make changes.
    • Security principle: Recipe settings have broad impact in Cloud Guard, and so fewer users should be allowed to change settings at this level.
    • Settings that you can change at the recipe level:
      • Detectors:
        • Status (enable or disable rule, user-managed only).
        • Risk Level (user-managed only).
        • Labels (user-managed only).
        • Input Setting (if applicable for rule).
        • Conditional Group settings.
      • Responders:
        • Status (enable or disable rule, user-managed only).
    • Scope: Changes made for detector and responder rules at the recipe level:
      • Status changes (enable or disable rules):
        • Can only be made for user-managed (cloned) recipes.
        • Apply globally to all targets where the detector or responder has already been attached or is attached later.
      • Conditional Group settings:
        • Supply the default values for all targets where the detector or responder recipe is added later.
        • After a recipe is added to a target, changes in the Conditional Group settings can only be made from that target.
      • Policy Statements (for responder rules, at target level only):
        • Enablement of a policy statement is global, applying to all responder rules that require the policy, at both recipe and target levels.
        • You only need enable a policy once in a tenancy.
    • Access: Access the detector and responder rules from the recipe pages, Detector Recipes or Responder Recipes, to change these settings as described above.
  • Target Level settings are "tactical" in nature. That is, they impact only a single target, and therefore can require a lower level of permissions to make changes.
    • Security principle: Targets tend to have a more narrow impact, affecting only a subset of your compartments, and so more users can be allowed to change settings at this level.
    • Settings that you can change at the target level:
      • Detectors:
        • Conditional Groups (user-managed only).
      • Responders:
        • Status (enable or disable rule, user-managed only).
        • Input Settings, to enable or disable Post Remediation Notification (if applicable for rule).
        • Change Rule Trigger between Execute Automatically and Ask me before....
        • Change other settings (for example, enable or disable Required Policy Statements and Remediation Notification).
    • Scope: Changes made for detector and responder rules at the target level apply to:
      • Generally, changes apply to the current target. Changes do not affect any settings in targets where the detector or responder recipe has already been attached. After recipes are attached to a target, any further changes in settings for that target must be made from the same target. Changes made later at the recipe level automatically update the recipe attached to the target.
      • For enabling required policies and enabling and disabling remediation notifications (both for responder recipes only), changes supply the default values for all targets where the user-managed (cloned) detector or responder recipe is added later.
    • Access: Access the detector and responder rules from the Targets page to change these settings as described above.
  • Summary of Important Limitations - some settings can only be changed at the recipe or target level, or only in Oracle- or user-managed recipes:
    • Detectors:
      • Status (enable or disable rule) - only in user-managed recipes, at recipe level.
      • Risk Level - only in user-managed recipes, at recipe level.
      • Labels – only in user-managed recipe, at recipe level.
    • Responders:
      • Status (Enable or Disable rules) – only in user-managed recipe, at recipe level.
      • Input Settings, to enable or disable Post Remediation Notification (if applicable for rule) – only at target level (for both Oracle- and user-managed recipes).
      • Rule Trigger (between Execute Automatically and Ask me before...) - only at target level (for both Oracle- and user-managed responder recipes).

The following table summarizes which detector and responder rule settings you can change at the recipe level and at the target level, for both Oracle-managed and user-managed recipes.

Types of Changes (below)

 Detector Recipe Changes Made From... Responder Recipe Changes Made From...
Oracle-Managed User-Managed (Cloned) Oracle-Managed User-Managed (Cloned)
Recipes Page Targets Page Recipes Page Targets Page Recipes Page Targets Page Recipes Page Targets Page
Status (Enable and Disable Rules) No No Yes No No No Yes No
Risk Level No No Yes No N/A N/A N.A N/A
Labels No No Yes No N/A N/A N/A N/A
Input Settings Yes No Yes No No Yes No Yes
Conditional Groups Yes Yes Yes Yes No Yes No Yes
Enable Policy Statements N/A N/A N/A N/A No Yes No Yes
Rule Trigger (Manual or Automatic Execution) N/A N/A N/A N/A No Yes No Yes
Remediation Notification (Setting) N/A N/A N/A N/A No Yes No Yes
For Instructions, see: Topic Topic Topic Topic Topic Topic Topic Topic
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. Subcompartments 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)

Using Conditional Groups with Recipe Rules

Conditional groups let you quickly set the scope for which a detector or responder rule should be activated.

Conditional Groups for Detectors

A conditional group sets parameters that you specify, to limit the scope of situations for which the violation of a detector rule actually triggers a problem:

  • For configuration detectors, conditional groups allow for inclusion or exclusion of specific resources from monitoring.
  • For activity detectors, conditional groups allow for limiting activity detectors to certain IP spaces, regions, users, groups, or resources.
  • To implement conditional groups, when you are modifying a detector recipe rule:
    1. Select the Parameter, Operator, and Custom List or a Managed List.
    2. Input one or more entries for the Value to be matched.
    • To set a condition on a parameter other than tags, follow these steps:
      1. In the Parameter list, select a parameter other than Tags.
      2. Select an Operator, a List, and a Value.
      3. To add another condition, click Another condition.
        Note

        Specifying multiple conditions acts as an AND operator. The rule is enforced only if all the conditions are met.
    • To set a condition on tags, follow these steps:
      1. In the Parameter list, select Tags.
      2. Select an Operator (In or Not In).
        • If you select In, the rule affects only items that are tagged with one of the tags that are in the list that you provide.
        • If you select Not In, the rule affects only items that are not tagged with one of the tags that are in the list that you provide.
      3. Click Select tags.
      4. In the Select tags dialog box, set a condition for defined or free-form tags:
        • To set a condition for defined tags, select a Tag namespace other than None, select a Tag key, and then select or enter the Tag value:
        • To set a condition for free-form tags, for Tag namespace, select None for Tag namespace, enter a Tag key, and then optionally enter the Tag value.
        • Add more tags as needed.
          Note

          When you specify multiple tags, the rule is enforced only if all the conditions are met.
  • You can add a condition for a single resource and input at a time using a custom list, or add multiple resources and inputs at once using managed lists.

Example: You have 10 Compute Instances. Two instances (Instance1 and Instance2) should be public, so you don't want the "Instance is publicly accessible" rule to trigger problems on these instances. You can use conditional groups to exclude these two instances, using either custom lists or managed lists.

Valid Values for Conditional Group Parameters

With both detector and responder recipes, some rules have Parameter options that require you to type one or more valid Value entries. The following list provides links to sources that the valid values for each parameter type. Where links are not available, a brief explanation of how to find valid values is provided.

Exclusion of Resources Using Custom Lists

Use custom lists when the number of items to be matched is small, and you don't expect to need to reuse the same list multiple times.

  1. Open the details page for the detector recipe where the "Instance is publicly accessible" rule is enabled.

    See Editing a User-Managed OCI Detector Recipe.

  2. On the detector recipe's detail page, under Detector Rules, locate the row for the "Instance is publicly accessible" rule.
  3. At the right end of that row, open its Actions menu Image of Action menu, and select Edit.
  4. In the Edit Detector Rule dialog box, Conditional Group section:
    1. Set Parameter to Instance OCID.
    2. Set Operator to Not in.
    3. Set List to Custom List.
    4. For Value, enter the OCID for Instance1.
  5. Click Add Condition.
  6. In the new condition row:
    1. Set Parameter to Instance OCID.
    2. Set Operator to Not in.
    3. Set List to Custom List.
    4. For Value, enter the OCID for Instance2.
  7. Click Save.

    The "Instance is publicly accessible" rule now monitors all instances for public configuration, except Instance1 and Instance2.

Exclusion of Resources Using Managed Lists

Use managed lists when the number of items to be matched is large, or you expect to need to reuse the same list multiple times.

  1. First, create a managed list of instance OCIDs that contains the OCIDs for Instance1 and Instance2.

    See Creating a Managed List.

    Let's assume you name that list "Public Compute Instance OCIDs."

  2. Open the details page for the detector recipe where the "Instance is publicly accessible" rule is enabled.

    See Editing a User-Managed OCI Detector Recipe.

  3. On the detector recipe's detail page, under Detector Rules, locate the row for the "Instance is publicly accessible" rule.
  4. At the right end of that row, open its Actions menu Image of Action menu, and select Edit.
  5. In the Edit Detector Rule dialog box, Conditional Group section:
    1. Set Parameter to Instance OCID.
    2. Set Operator to Not in.
    3. Set List to Managed List.
    4. For Value, select the name of the managed list you created ("Public Compute Instance OCIDs" in the example in step 1).
  6. Click Save.

    The "Instance is publicly accessible" rule now monitors all instances for public configuration, except Instance1 and Instance2.

    Note

    Any Compute Instance OCIDs you add to your managed list in the future is also excluded from monitoring.

Using Managed and Custom Lists with Recipe Rules

Managed lists let you quickly set the scope for which a recipe rule should be applied, by including or excluding a predefined list of parameters. Custom lists let you enter a short list of parameters for the same purpose.

Applying a Managed List to a Configuration Detector

Example: If a compute instance has a public IP address, you would like to trigger a problem. But you have some instances that should have public IP addresses and you don't want those instances to trigger problems.

  1. Create a managed list containing all the resource OCIDs of the compute instances that should have public IP addresses.

    See Creating a Managed List.

  2. Assign this managed list as a Conditional Group entry for the "Instance has a public IP" configuration detector rule.

    See Editing a User-Managed OCI Detector Recipe.

Applying a Managed List to an Activity Detector

Example: If activity that's initiated from specific suspicious IP addresses creates a bucket or instance, you would like to trigger a problem.

  1. Create a managed list containing the known suspicious IP addresses.

    See Creating a Managed List.

  2. Assign this managed list as a Conditional Group entry for the "Suspicious IP activity" detector rule.

    See Editing a User-Managed OCI Detector Recipe.

Alternatively, if you knew that buckets or instances should be created only from certain, trusted IP addresses, you could:

  • Create a managed list containing trusted IP addresses.
  • Then use the "Not In" operator in the Conditional Group entry for the "Suspicious IP activity" detector rule.