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 diagram below provides a high level overview of Cloud Guard system flow. You can refer to this diagram as you review the Cloud Guard concepts defined below.
These terms are important for you to understand as you work with Cloud Guard:
- 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.
- 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.
- 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.
- An action that Cloud Guard can take when a detector has
identified a problem. The available actions are
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 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
- Additional regions that your Cloud Guard tenancy monitors.
For both detectors and responders, Cloud Guard provides a rich set of Oracle managed recipes for:
- Configuration detectors
- Activity detectors
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.
- 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 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. 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.