Note:

Configure Oracle Cloud Guard detector rules to detect problems based on conditions

Introduction

Oracle Cloud Guard is a free cloud native service that scans targets - which are Oracle Cloud Infrastructure (OCI) compartments and detects problems based on rules defined in the policies called detector policies. Once a rule is satisfied, it creates a problem which you can review from the console. Cloud Guard acts on the problems using rules defined in the responder policies. Cloud Guard comes with various out-of-the-box detector recipes. For example, configuration detector recipes, activity detector recipes, and so on. Detector recipes have several detector rules, when these rules are triggered, Cloud Guard creates a problem.

Image of the Cloud Guard overview screen

Once you have configured Cloud Guard, it starts detecting problems based on the out-of-the-box detector policies. When you review the problems detected by Cloud Guard, you may find some problems are false positives based on your use case. For example, Cloud Guard “Instance is publicly accessible” and “Instance has a public IP” detector rules detect instances in your targets (compartment) that are accessible from the internet and have a public IP. However, you want to allow a demo/training compute instance to have a public IP and have it accessible from the internet.

You can achieve this by configuring conditional groups in Cloud Guard detector rules and you can do it for almost all types of detector rules.

Objectives

Prerequisites

Task 1: Identify the detector rule that should run based on a condition

Before you start configuring detector rule conditional group, you must know which detector rules you need to work on. In this tutorial, we are demonstrating using a configuration detector rule “Instance has a public IP address”. This detector rule scans the compute instances in a target and if instance has a public IP assigned, Cloud Guard creates a problem and if corresponding responder rule is set to automatically delete the

Image of the Cloud Guard Instance has a public IP address detector rule

Similarly, you can identify other detector rules that you may want to set the scope for detector rules. For example, “Bucket is public” detector rule that detects if bucket is public and Cloud Guard will make it private upon detection by responder rule. However, you may have a public bucket hosting public documents and you do want Cloud Guard to create problem for this bucket.

Image of the Cloud Guard Bucket is public detector rule

Cloud Guard has responders that can trigger automatically (configurable, default off) when a detector rule detects a problem. In such cases, you will come to know about the detector rules that need conditional access by the users that cannot access the resource because of the Cloud Guard responder rule execution. For example, if a user needs a public IP for a compute instance for genuine reason but Cloud Guard responder activity has removed the public IP from the instance upon detection.

Note Consider following when adding a condition to a recipe, conditions defined in recipe at the target level are scoped to that specific target and does not impact other recipes in other targets. Condition defined at recipe level will impact all the targets where the recipe is attached. Read more on this here.

Following tables shows some of the supported parameter available for recipes. You will notice from the table that activity recipe parameters are targeted to actor and configuration recipe parameters are targeted to the resource.

Recipe Conditional Parameters
Activity Recipe Region – region from where actor is coming from.
Location(City, State, Province, Country) - Location of the actor.
Tags - Applied to the Actor.
IPv6/IPv4 Address - Actor’s IP address.
User Names - User name of the actor.
Configuration Recipe Tags - Tags applied to the resource.
OCID - OCID of the resource. Example: OCID of the compute Instance, DB System, Load balancer, User, Group, Policy, VNIC, VCN, and so on.
Bucket Namespace/Name
CIDR/IPv6/IPv4 Address - IP of the resource, where applicable (Example - Database System has public IP address, Instance has a public IP address).

Task 2: Create a condition group in the detector rule

  1. Navigate to Cloud Guard, Targets, (target-name), Target details, Detector recipe, OCI Configuration Detector Recipe (Oracle managed).

    Note: If you have cloned the out-of-the-box detector recipe then navigate to that. In our example, we are going to add a condition to the detector rule “Instance has a public IP address”.

  2. Under detector rule, search for Instance and you will see instance related detector rules

    Image of the Search instance has public IP detector rule

  3. Edit the detector rule by clicking on the three dots on right. Under conditional group:

    • Select compartment where to apply this rule, in our example iam-demo.

    • Select the parameter from the list, in our example, instance OCID.

    • Select the operator, in our example “not in” because we do want Cloud Guard to detect one of the instance with public IP.

    • Select custom list from the list, you will see managed list also we will cover that in the next step.

    • If you have more than one compute instance with public IP that you want to exclude, add another condition.

    • Enter OCID of the instance and save.

      Note: The parameter list is specific to the detector rules. Each rule will have common parameters and some specific to the rules. Multiple conditions in one conditional group use logical AND.

    Image of the edit instance has public IP detector rule

  4. View the resolved problem. Once changes are saved, after a short while, Cloud Guard will detect the change and automatically resolve existing problems for the compute instance by marking the problem as resolved. You can view this in the list of resolved problems.

    Image of the resolved instance has public IP detector rule

We saw how we can statically add a single or multiple condition in a detector rule by editing the detector rule. What if you need to add multiple conditions of the same type with just different value. One option is to keep editing the detector rule but there is a better way to do it by using managed list that we will see in the next step.

Task 3: Use managed list in the detector rules

  1. Create a managed list.

    Note: In our example, we have a few compute instances that are allowed to have public IP. Therefore we have created a managed list called “PublicInstances” of type Resource OCID and added OCID of all the compute instances that can have public IP. See this document on how to create a managed list.

    Image of the create managed list

  2. Use the managed list in the detector rules instead of statically adding the values.

    Note: In our example, we have edited the “Instance has public IP” detector rule changed list from custom list to managed list and specified the list name as “PublicInstance”. Managed list makes it easy to add/delete instance OCID from one place instead of editing the detector rule.

    Image of the use managed list in detector rule

Next Steps

Review problems generated by Cloud Guard to find out where you can add conditions to the detector rules so that Cloud Guard does not generate problems based on your business logic and removes false positives.

Acknowledgments

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.