Getting Started with Cloud Guard
Review Oracle Cloud Guard concepts, ensure you meet prerequisites, enable Cloud Guard initially, and then access Cloud Guard routinely.
Planning for Cloud Guard
Spending some time planning how Cloud Guard functionality is mapped onto your environment, before you enable and configure Cloud Guard, might save you some time later.
You can enable Cloud Guard and begin monitoring your environment immediately. All you need to do is specify a single target that maps to the top-level compartment in the branch of your Oracle Cloud Infrastructure that you want to monitor. Then, over time, you can customize the Cloud Guard configuration, based on your experience with processing the problems that Cloud Guard detects. You can continually customize the Cloud Guard configuration to optimize performance toward a two-part goal:
- Not letting anything that represents a potential security risk go undetected.
- Not detecting "too many" false positives - problems that do not actually represent potential security risks.
If you do some planning, you might be able to get a head start on this two-part goal. All you need to do is survey how the resources in your Oracle Cloud Infrastructure tenancy are organized into compartments.
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.
Enabling Cloud Guard
Perform this task to enable Oracle Cloud Guard from the OCI Console.
Prerequisite: Complete the tasks in Prerequisites and Planning for Cloud Guard.
You can use either of two basic approaches for enabling Cloud Guard:
- Start with Default Configuration: You want Cloud Guard to start reporting problems as soon as possible
after completing the enablement process.
Don't skip any optional selections during the enablement process.
Note
If you skip any of the optional selections during enablement process, Cloud Guard does not automatically start reporting problems after completing the enablement process. If you skip optional settings during enablement, Cloud Guard can't start reporting problems until you add detector recipes to the specified target. See Editing an OCI Target and Its Attached Recipes. - Customize Configuration First: You want to customize Cloud Guard's configuration before Cloud Guard starts reporting problems.
You can skip any or all optional selections during the enablement process.
Whichever approach you take to enable Cloud Guard, you can refine the Cloud Guard configuration as needed after enablement.
What's Next
Whichever approach you followed in the enablement process, Cloud Guard disables two OCI Configuration Detector rules by default in new tenancies. Disabling these rules initially is necessary to prevent Cloud Guard from generating an excessive number of problems that you would consider false positives. For more information about these rules, see:
Some of the detector rules that are enabled by default might produce an excessive number of problems in your particular environment. To be able to disable detector rules, you must clone the Oracle-managed detector recipe to create a user-managed version, See Cloning an OCI Detector Recipe.
- Determine the rule settings to change so that the rule no longer generates those false positives.
See the reference information for the rule in Detector Recipe Reference.
- Modify the rule settings so that the rule no longer generates those false positives.
- Disable the rule.
- Re-enable the rule.
- If you followed the "Start with Default Configuration" approach in the enablement process, information on problems soon starts to appear in Cloud Guard. How soon the problem information starts to appear depends on your environment, your configuration of targets and detectors, and the number of problems that are occurring for Cloud Guard to detect. Note
- If you followed the "Customize Configuration First" approach in the enablement process, no information on problems appears until you complete all of the configuration tasks that you skipped during enablement:
- Define one or more targets. See Creating an OCI Target.
- Optional: Clone Oracle-managed detector recipes. See Cloning an OCI Detector Recipe.
- Optional: Customize detector recipes for your environment. See Editing a User-Managed OCI Detector Recipe.
- Add detector recipes to each target. See Editing an OCI Target and Its Attached Recipes.
- After Cloud Guard has started reporting problems:
- To fine-tune your Cloud Guard configuration to better serve the specific needs of your environment. see Customizing Cloud Guard's Base OCI Configuration.
- To interpret the summary information on detected problems, drill down into the details, and resolve specific problems, see Processing Reported Problems.
- To ensure that Cloud Guard is fully integrated with other OCI services, see Integrating Cloud Guard with Other Services.
Integrating Cloud Guard with Other Services
Ensure that configuration details necessary to support Cloud Guard integration with other services are in place.
After you have finished performing the tasks in Enabling Cloud Guard, plus some follow-up tasks if you use the Customize Configuration First strategy, all integrations with other services should be functioning smoothly.
When new services that support integration with Cloud Guard later become available, you need to ensure that your Cloud Guard configuration details correctly support the new service:
- Cloud Guard targets must contain all the compartments where resources from the new service that Cloud Guard is to monitor are located.
- The Cloud Guard detector recipes that contain the rules that are specific to the new service must be attached to those Cloud Guard targets.
Expand one of the following service names to see the steps to follow to ensure that your Cloud Guard configuration details correctly support the service.
Prerequisite: Ensure that the Certificates service is already enabled and operating properly.
Prerequisite: Ensure that the Data Safe service is already enabled and operating properly. If you perform the following steps before the Data Safe service is enabled, Cloud Guard alerts you that you need to enable Data Safe, whenever it finds a database.
Prerequisite: Ensure that both Cloud Guard and Threat Intelligence services are enabled. Cloud Guard begins reporting problems, based on information from Threat Intelligence Service, without any further configuration.
To allow users to click a link from Problem Details, on the Cloud Guard Problems page and view detailed information in Threat Intelligence, ensure that a policy is in place that grants the user permission:
... to read threat-intel-family in tenancy
Logging Service
Instance Security uses the OCI Logging service to record activity.
You must enable end to end logging for the target where you attached the Instance Security recipe otherwise you won't see anything detected.
Logging can have a heavy impact on resources such as CPU and memory so only enable logging for the regions you want to monitor.
Setting Up Logging
- Open the navigation menu and click Identity & Security. Under Cloud Guard, click Configuration.
- On the Configuration page, click Targets. Look for targets where the entry in the Type isTenant.
- On the Targets page, click the link for the target which has the Instance Security recipe.
- Under Configuration choose the Instance Security tab click Enable/Edit next to Logging configuration details.
- On the Logging configuration details page, you can enable Instance Security raw logging for a region.
- For the region you want, select Enable Log.
- On the Enable log panel, choose the Compartment.
- Choose an existing log group, or create a new one by clicking Create new group. See Log Group Management.
- Choose how long the log to keep the log, for values between 30 days and 180 days, or set a custom log retention value.
- Click Enable log.
Managing Logging Details
- See the logs and search for them by region.
- Change the compartment.
- Change the name of the log.
- Change the log retention period.
- Enable a log.
- Open the navigation menu and click Identity & Security. Under Cloud Guard, click Configuration.
- On the Configuration page, click Targets. Look for targets where the entry in the Type isTenant.
- On the Targets page, click the link for the target which has the Instance Security recipe.
- Under Configuration choose the Instance Security tab and click Enable/Edit next to Logging configuration details.