Cloud Guard

Oracle Cloud Guard is an Oracle Cloud Infrastructure service that helps customers monitor, identify, achieve, and maintain a strong security posture on Oracle Cloud.

Use the service to examine your Oracle Cloud Infrastructure resources for security weakness related to configuration, and your operators and users for risky activities. Upon detection, Cloud Guard can suggest, assist, or take corrective actions, based on your configuration.

Oracle Security Zones is another Oracle Cloud Infrastructure service that supplements Cloud Guard functionality. Security Zones lets you define policy compliance requirements for groups of resources. Security Zones can then enforce those policies and automatically correct and log any violations. For more information, see Security Zones.

Cloud Guard Concepts

Understand Cloud Guard components and terminology.

The following diagram provides a high-level overview of Cloud Guard system flow. You can refer to this diagram as you review the Cloud Guard concepts whose definitions follow.

Image of high-level system flow in Cloud Guard

These terms are important for you to understand as you work with Cloud Guard:

Defines the scope of what Cloud Guard is to check. For Oracle Cloud Infrastructure, this scope is tied to the compartment where the target is defined and all the child compartments from that point until another target is encountered. The other target that's encountered takes over from that point into any descending compartments.
  • A target can consist of your entire OCI tenancy (target at the root compartment).
  • To monitor IAM policies , the root compartment must be a target.
  • You must specify at least one target when you enable Cloud Guard. You can modify that target and define more targets later.
  • Targets can't overlap, and only a single target at a time is applied to a compartment and its resources.
  • A compartment (and its children) can be exempted from checks by being declared a target, but not having detector recipes applied to that target.
Performs checks and identifies potential security problems based on their type and configuration.
Detector recipe
Provides the baselines for examining the resources and activities in the target.
Oracle-managed detector recipe
  • Provided by Cloud Guard.
  • Allows setting only the scope of resources for which a rule triggers a problem.
  • Doesn't allow you to disable rules or change a rule's risk level.
  • May be updated to include new defaults and settings at any time.

    Monitor Cloud Guard Release Notes for these updates.

User-managed detector recipe
  • Created by cloning an Oracle-managed recipe.
  • Allows setting the scope of resources for which a rule triggers a problem.
  • Also allows you to disable individual rules and change a rule's risk level.
OCI Configuration Detector recipe
Set of rules designed specifically to detect resource configuration settings that could pose a security problem.
OCI Activity Detector recipe
Set of rules designed specifically to detect actions on resources that could pose a security problem.
Detector rule
Provides 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. Each rule in a detector recipe can be configured individually.
Any action or setting on a resource that could potentially cause a security problem. Cloud Guard monitors your Oracle Cloud Infrastructure tenancy’s network activity to identify and resolve problems. Problems:
  • Are created when Cloud Guard discovers a deviation from a detector rule.
  • Are defined by the type of detector that creates them: activity or configuration,
  • Contain data about the specific type of issue that was found.
  • Can be resolved, dismissed, or remediated.
An action that Cloud Guard can take when a detector has identified a problem. The available actions are resource-specific. Responders are structured similar to detectors:
Responder recipe
Defines the action or set of actions to take in response to a problem that a detector has identified.
Oracle-managed responder recipe
  • Provided by Cloud Guard.
  • Doesn't allow you to disable rules.
  • May be updated to include new defaults and settings at any time.

    Monitor Cloud Guard Release Notes for these updates.

User-managed responder recipe
  • Created by cloning the Oracle-managed recipe.
  • Allows you to disable individual rules and change a rule's risk level.
Responder rule
Defines the specific actions to take. If any one responder rule is triggered, it triggers the responder. Each rule in a detector recipe can be configured individually.
Cloud Guard provides a set of responders with default rules. You can use these responders as is. You can clone any of the default responders and modify the rules to meet specific needs. You can enable and disable responder rules individually. You can limit the scope for applying individual rules by specifying conditions to limit the scope.
Managed list
A reusable list of parameters that makes it easier to set the scope for detector and responder rules. For example, a predefined "Trusted Oracle IP address space" list contains all the Oracle IP addresses that you want to regard as trusted when you define rules for detectors and responders.
Regions in Cloud Guard
Activity that Cloud Guard monitors can occur it two types of regions:
Reporting Region
The default region for your Cloud Guard tenancy. The first region defined when your Cloud Guard tenancy was enabled.

Integration with Notifications and Events services to send notification happens only in the reporting region. Selecting a particular region  from the Regions list at the top of the console has no effect on information displayed. To filter information by region, use the Filters on the Cloud Guard page.

Monitored Region
Other regions that your Cloud Guard tenancy monitors.
Oracle-Managed vs. User-Managed Recipes

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

  • OCI Configuration detectors
  • OCI Activity 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

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

  • 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.
  • 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 Modifying Recipes Added to a Target.
  • 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've disabled 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.