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.

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 must 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 summarize 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: Change rule Status (enable or disable, user-managed only); change Risk Level and Labels (user-managed only); specify Conditional Group settings.
      • Responders: Change Risk Level and Labels (user-managed only); specify Conditional Group settings.
      Note

      Conditional Group settings can be changed from both the recipe level and the target level. The recipe level supplies global default settings, which can then be modified to better fit needs at the target level, when the recipe is added to a target.
    • Scope: Changes made for detector and responder rules at the recipe level:
      • Changes for enabling and disabling rules and for setting risk levels:
        • Can only be made for user-managed (cloned) recipes.
        • Apply globally to all targets where the detector or responder has already been added or is added later.
      • Changes for 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.
    • Access: You must access the detector and responder rules from the recipe pages, Detector Recipes or Responder Recipes, to change these settings.
  • 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 only change at the target level:
      • Detectors: Specify Conditional Group settings,
      • Responders:
        • Change Rule Trigger between Execute Automatically and Ask me before....
        • Specify Conditional Group settings.
        • Change other settings (for example, enable or disable Required Policy Statements and Remediation Notification).
      Note

      Conditional Group settings can be changed from both the recipe level and the target level. Changes made after a recipe is added to a target modify the base settings to better fit specific needs for that target,
    • Scope: Changes made for detector and responder rules at the recipe level apply to:
      • Generally, changes apply to the current target, and supply the default values for all targets where the detector or responder is added later. Changes do not affect settings in targets where the detector or responder has already been added. After recipes are added to a target, any further changes in settings for that target must be made from the same 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 detector or responder is added later.
    • Access: You must access the detector and responder rules from the Targets page to change these settings.

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

Detector Recipes Responder Recipes
Oracle-Managed User-Managed (Cloned) Oracle-Managed User-Managed (Cloned)

Made From ->

Changes (below)

From Recipes Page From Targets Page From Recipes Page From Targets Page From Recipes Level From Targets Page From Recipes Page From Targets Page
Enable and Disable Rules No No Yes No No No Yes No
Create and Manage Conditional Groups Yes Yes Yes Yes No Yes No Yes
Change Settings, Risk Levels, Labels No No Yes No - - - -
Set Manual vs. Automatic Execution - - - - No Yes No Yes
Enable Required Policy Statements - - - - No Yes No Yes
Enable and Disable Remediation Notification - - - - No Yes No Yes
For Instructions, see: Modifying a Detector Recipe Modifying Recipes Added to a Target Modifying a Detector Recipe Modifying Recipes Added to a Target Modifying a Responder Recipe Modifying Recipes Added to a Target Modifying a Responder Recipe Modifying Recipes Added to a Target
Detector Recipes

The following table summarizes what can be changed for detector recipe rules, when accessed from either the Targets page ("target level") or the Detector Recipes page ("recipe level").

Changes Oracle-Managed Detector Recipes User-Managed (Cloned) Detector Recipes
Recipe Level Target Level Recipe Level Target Level
Enable and Disable Rules No No Yes No
Create and Manage Conditional Groups Yes Yes Yes Yes
Change Risk Levels and Labels No No Yes No
For Instructions, see: Modifying a Detector Recipe Modifying Recipes Added to a Target Modifying a Detector Recipe Modifying Recipes Added to a Target
Responder Recipes

The following table summarizes what can be changed for responder recipe rules, when accessed from either the Targets page ("target level") or the Responder Recipes page ("recipe level").

Changes Oracle-Managed Responder Recipes User-Managed (Cloned) Responder Recipes
Recipe Level Target Level Recipe Level Target Level
Enable and Disable Rules No No Yes No
Create and Manage Conditional Groups Yes Yes Yes Yes
Other Settings No Yes No Yes
For Instructions, see: Modifying a Responder Recipe Modifying Recipes Added to a Target Modifying a Responder Recipe Modifying Recipes Added to a Target

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.
  • 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 Modifying a 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 the 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 Modifying a 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 the 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 Modifying a 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 Modifying a 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.