Getting Started with Cloud Guard

Survey Your Environment 🔗

Examine the types of resources that are stored in different parts of the compartment hierarchy in your Oracle Cloud Infrastructure tenancy. Are there groups of resources in different parts of that compartment hierarchy that need to be monitored for in different ways, in order to detect different types of threats? Would the same problem, if detected in different compartments, represent different risk levels?

Cloud Guard lets you define different areas within your Oracle Cloud Infrastructure tenancy that can be monitored in different ways. The trade-off is that all compartments within a defined area are monitored in the same way.

Familiarize Yourself with Cloud Guard Terminology 🔗

Cloud Guard Concepts defines the terms that you learn as you work with Cloud Guard. To get started, the following list summarizes what you need to know to get started planning for Cloud Guard.

Target

Defines scope of what Cloud Guard checks. All compartments within a target are checked in the same way and you have the same options for processing problems that are detected.

Detector

Performs checks to identify potential security problems based on activities or configurations. Rules followed to identify problems are the same for all compartments in a target.

Responder

Specifies actions that Cloud Guard can take when detectors identify problems. Rules for how to process identified problems are the same for all compartments in a target.

Familiarize Yourself with Cloud Guard Detector Recipes 🔗

Look over the rules described in the sections of Detector Recipe Reference for different detectors. Within your environment:

• Are there any compartments that you do not want Cloud Guard to monitor at all? If so, you have to define one or more targets in a way that excludes these compartments.
• Do you think that you might want to set the risk level differently, or enable and disable rules differently, for resources in different parts of your Oracle Cloud Infrastructure compartment hierarchy? To configure detector rules differently for different compartments, you have to define separate targets for those compartments.

  For example, for the "Bucket is public" configuration rule, the default risk level is "CRITICAL" and the rule is enabled by default. Should these settings be the same for all compartments?

• You can disable responder recipe actions on problems that detectors identify. If you want actions for a particular responder rule to be enabled in some compartments, but disabled in others, you have to define separate targets for those compartments.

  For example, the "Make Bucket Private" responder rule is enabled by default. Do you have some compartments in which all buckets are public by design, and so you can disable this rule?

Plan How Targets Will Map to Compartments 🔗

If at this point you don't think you need to define multiple targets, and you have completed the Prerequisites, you can proceed with Enabling Cloud Guard. You can always change your target configuration later, as the need arises.

If you think you need to set up targets to allow different compartments to be monitored differently, keep these guidelines in mind when mapping targets to compartments:

• All of a target's compartments inherit that target's configuration. The detector and responder rule settings for a target apply to the top-level compartment assigned to that target, and to any subordinate compartments below it in the compartment hierarchy.

  If you want to exclude some compartments from monitoring, create targets below the root level and do not include the root compartment in any target.

• Target defined within an existing target overrides inherited configuration. Within an existing target, you can assign a compartment below the target's top-level compartment to a new target. You can change the detector and responder rule settings for the new target, and those settings now apply to the top-level compartment assigned to that target, and to all the subordinate compartments below it in the compartment hierarchy.

Carefully Choose Your Reporting Region 🔗

When you enable Cloud Guard, you are asked to choose a reporting region. Carefully consider these consequences of your reporting region choice:

• The reporting region you select commits your organization to comply with all legal requirements of the country where the reporting region is hosted.
• After Cloud Guard is enabled, you can't change the reporting region without disabling and re-enabling Cloud Guard.
• All customizations, and existing problems (including their history) are lost when you disable Cloud Guard, so you would have to manually restore those customizations.
• All API calls, except for READs, must be made on the reporting region.

Ensure that you make the best decision for your reporting region, before you begin Steps to Enable Cloud Guard.