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.

Cloud Guard Concepts

Understand Cloud Guard components and terminology.

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

Target
Defines the scope of what Cloud Guard will check. For Oracle Cloud Infrastructure, this is tied to the compartment where the target is defined and all of the child compartments from that point until another target is encountered, which 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 additional targets later.
  • Targets may not overlap, and only a single target is applied to a compartment and its resources at a time.
  • A compartment (and its children) can be exempted from checks by being declared a target, but not having detector recipes applied to that target.
Detector
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.
User managed detector recipe
  • Must be 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.
Configuration detector recipe
Set of rules designed specifically to detect resource configuration settings that could pose a security problem.
Activity detector recipe
Set of rules designed specifically to detect actions on resources that could pose a security problem.
Detector rule
Provides a very specific definition of a class of resources, with specific actions or configurations, that should 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 may be configured individually.
Problem
Any action or setting on a resource that could potentially cause a security problem. Problems are created when Cloud Guard discovers a deviation from a detector rule. Problems are defined by the type of detector that creates them (activity or configuration), and contain data about the specific type of issue that was found. Problems may be resolved, dismissed, or remediated. Cloud Guard monitors your Oracle Cloud Infrastructure tenancy’s network activity to identify and resolve problems.
Responder
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.
User managed responder recipe
  • Must be 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 may 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 define detectors. 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 (Home) 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.
Monitored Region
Additional 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:

  • Configuration detectors
  • 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 may want to change the risk level associated with some rules, and you may want to disable other rules altogether. To do this, you must first clone the recipe to make a user managed copy, and then you make changes the copy. If new detector rules are added to an Oracle managed recipe, all clones of that recipe will also have the rule added, with the default values from the Oracle managed source. The new rule's configuration in the cloned recipe can then be modified.

The table below shows an example of three detector rules from the Oracle managed recipe and how a cloned 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, in order to create recipes 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 Cloned Detectors and Responders Work

  • When you clone an Oracle managed recipe, it creates a user managed copy. The cloned 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 (configuration detectors, activity detectors, responders) added to it; if a target already has a recipe of the type you want to add, you'll have to remove that recipe before you can another of the same type. See Modifying 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. You should examine new rules closely to see if you want to enable them.
  • Monitor the list of rules that you've disabled in a user managed recipe to if any should be enabled. As time passes, you may find that you want to start using some of the recipes that you disabled earlier.