Introduction

Since the launch of Oracle Cloud Guard, we have had many customers who have enabled it seeking information on how to operate the service more effectively. So, in this post, I would like to walk you through tuning the Cloud Guard service to tailor the results of problem detection and response to provide better visibility into insecure cloud configurations and activities.

Oracle Cloud Guard is a free cloud-native security service for monitoring the security posture of an OCI tenancy and providing notification or remediation of the problem. There are four primary components of Cloud Guard; a target to be inspected, a detector function used to inspect the target, a problem as the output of a detected event within a target, and a responder function to act on the problem. While we will briefly review these concepts of Cloud Guard below, you may find more detail on the configuration and operation of Cloud Guard by reading previous blog posts, How Oracle is helping you maintain a strong security posture in the cloud, Discovering and fixing weak cloud security posture with Oracle Cloud Guard, Quick Tip #4 - Setting up notifications for Oracle Cloud Guard in 3 easy steps, Integrate Oracle Cloud Guard with External Systems Using OCI Events and Functions, and Push Cloud Guard Problems to Splunk HEC with OCI SDK, or by referencing the Cloud Guard documentation.
 

Target

The first main component of a Cloud Guard instance is a “Target”, which is the logical object inspected by Cloud Guard. Targets are bound to a selected compartment in a tenancy and inherit any of its sub compartments.
 

Detectors

The second main component of a Cloud Guard instance is a Detector. A detector is composed of  Detector Rules collected into a Detector Recipe.


 

Detector Rules

Detector Rules are the individual definition of a resource and the actions or configurations associated with a specific cloud security problem.

Once a Detector Recipe is cloned the rule enabled status, risk level, and their conditions, can be modified. This can be helpful if you are receiving many false positive problems. Be careful before doing this however as the assumption for disabling a rule is that it is completely irrelevant to the Cloud Guard target both now and in the future.

Detector Recipes

The Detector Recipe is set of detector rules created by Oracle to monitor the different aspects of security within Oracle Cloud.

There are two types of recipes, Oracle Managed and User Managed. The Oracle Managed Detector Recipes set is automatically updated and modified by Oracle Cloud and cannot be modified, while a User Managed Detector Recipe is a user customized set of detector rules. So, you will need to clone the Oracle Managed Detector Recipe that cannot be modified into a User Managed one so that it can be.
 

Detector Conditions

Now that we can customize our set of rules, let’s go over using detector conditions to exclude any resources that would trigger a false positive problem detection.

Lists

Managed List

A managed list is an independently configured list of parameters that can be reused within Cloud Guard detector conditions to tailor which resources are included or excluded from detector rules. This is useful for grouping a long or evolving list of similar resources.
 

A custom list is a list of resources added inline to the rule conditions that is more useful for quick addition of short lists of parameters.

Configuration Conditions

In the case below, we examine the conditions for exclusion from a configuration problem detector. Here our tenancy has both public and private web services with object storage for web content. You may want a detector rule to monitor your tenancy to ensure that none of your private web and object services are turned public. However, you will also receive problem alerts for the public object storage buckets which service the public website as a completely valid use. To solve this, you should add all the public services to a list group and exclude them from detection.
 

Activity Conditions

Another type of problem detector is an activity detector, which finds problems when different users or resources take high risk activities within the tenancy. Below we have an example of an activity detector for monitoring when security policy is changed. This is a good rule to have so that we can audit when security policy has been changed and by which user. At the same time, this rule may give you many false positive alerts of security policy changes made by valid security engineers and administrators. In this case you would use either a managed or custom list of valid uses that would be excluded from detection.
 

Problems

Problems are the output of a detector triggering. They consist of a name, associated risk, type, resource, target, etc. No tuning is required here as this is a result of the detector rule and conditions.

Responders

Responders are the component that acts based on the detection of a problem. Like Detectors, responders are a set of rules collected into a recipe. They provide two types of response actions; notification and remediation.

Responder Rules

Once you have cloned the Responder Recipe into a User Managed set, you may enable or disable individual rules, before modifying the notification or remediation responses or conditions. It is best to keep all rules enabled for future coverage unless the rule is creating severe challenges based on your configuration and cannot be properly tuned.

Responder Recipes

Much like the above Detector Recipes, Oracle Cloud Guard employs the concept of Oracle Managed and User Managed Responder Recipes. The difference between the two being that the Oracle Managed Recipe does not need to be maintained but rules cannot be modified, and vice-versa for User Managed Recipes.

Notification

A notification responder will connect to the Oracle Event service and dispatch the configured event type for that responder. For traditional notifications, the events service will then connect to the Notifications service and dispatch the configured notification. In some instanced these events may also execute code within the Oracle Functions service to extend the range of actions that will be taken on the event. For more information about using events and notifications see our other blog posts Integrate Oracle Cloud Guard with External Systems Using OCI Events and Functions and Push Cloud Guard Problems to Splunk HEC with OCI SDK.

Remediation

Remediation responders are pre-configured sets of one or more actions developed by Oracle that automatically reconfigure cloud settings to remediate the detected security issue. At present these cannot be tuned or modified.

Conclusion

Today we demonstrated some simple but powerful ways to customize Cloud Guard in order to ensure the highest fidelity of problem events are surfaced. For more detail on Cloud Guard see our previous blog posts, How Oracle is helping you maintain a strong security posture in the cloud, Discovering and fixing weak cloud security posture with Oracle Cloud Guard, Quick Tip #4 - Setting up notifications for Oracle Cloud Guard in 3 easy steps, Integrate Oracle Cloud Guard with External Systems Using OCI Events and Functions, and Push Cloud Guard Problems to Splunk HEC with OCI SDK, and check out the documentation.