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.
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.
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 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.
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.
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.
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.
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.
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.