Introduction
OCI Cloud Guard is our native Cloud Security Posture Management (CSPM) tool. If you do not have a CSPM tool for Oracle Cloud Infrastructure (OCI) you may consider Cloud Guard. In this post I will be describing some tuning tips that will help you get started.
Cloud Guard, as a CSPM tool, will report ‘Problems’ based on the configured ‘Detector’ recipes. These recipes should be tuned in order to reduce “noise” or ‘false positives’ during the scan of you resources. Below I have provided a list of ordered steps that I recommend customers follow in order to properly tune the recipes.
Configuration and Tuning Steps
Here is a list of steps that I recommend when enabling and tuning Cloud Guard. The first two steps are required to use Cloud Guard (provided for completeness). I will describe each step in more details below.
- Enable Cloud Guard
- Create admin group for IAM policies
- Clone all managed detector recipes and/or responder recipe
- Create baseline recipe configuration
- Attach cloned recipes to ‘root’ compartment
- Evaluate ‘problems’ and tune
- Make changes to recipes
- Repeat last two steps(6/7) until stable baseline
- Add event to notify on specific problems that arise.
Details
Enable Cloud Guard
It goes without saying that you must first enable Cloud Guard. Cloud Guard is a free service and it will not impact the performance of your environment. After enabling and attaching recipes to a target, it may take up to 24 hours to receive data from Cloud Guard.
Create admin group for IAM policies
A user that belongs to the Administrators group will have full access to enable and use Cloud Guard. However, I recommend that you create a cloud guard admin group and add users to evaluate and audit cloud guard ‘problems’. When viewing ‘problems’, keep in mind that there maybe Personal Identifiable Information (PII) so take care in selecting administrators accessing the data. You may also “mask” the data via Data Masking in Cloud Guard.
Clone all managed detector recipes and/or responder recipe
More than likely changes will be made to detector rules to support your environment. The oracle managed recipes cannot be modified so you will need to clone the recipes. Changes to Oracle managed recipes WILL also be reflected in cloned recipes.
Create baseline recipe configuration
Once a recipe is cloned you can modify properties for each rule within a recipe.
You can modify the following:
- Status – You can Enable or Disable a rule
- Risk Level – Critical, High, Medium, Low, Minor
- Label – (String) Labels can be assigned for tracking purposes.
- Conditional Group – A filter to include or exclude resources
Though you can add conditional group to a rule, I recommend that you add conditions only after you attach a recipe to a target. This allows you to create rules specific to a target. If you decide to add conditions to a recipe before attaching it to a target make sure that it is general enough as to not bypass a scan due to the conditional group filter.
From my experiencer, customers do one of three things when creating a baseline recipe:
- Use the Oracle Managed default settings (after cloning)
- Enable all rules
- Enable/Disable selected rules based on environment/tenancy
If you have a mature tenancy I recommend that you enable all rules to find and catch any false positives.
Attach cloned recipes to ‘root’ compartment
Once you cloned the Oracle managed recipes attached it to the root compartment to evaluate all problems. Even after attaching you can still change the settings within the detector recipes as described above. But you will notice that not all attributes can be changed once you attach a recipe to a target.
Notice that the Status, Risk Level and Labels are not modifiable. You still have the ability to go back to Cloud Guard -> Dectoector Recipes and make chantges to these attributes, however, be aware that these changes will be reflected to all targets that use the same reciple.
Evaluate ‘problems’ and tune
After attaching the cloned recipes to the root target you will soon receive data from Cloud Guard. Click ‘Problems’ to see the data.
Within the ‘Problem’ screen you can select ‘Learn More’ at the top description to understand the reasoning behind this issue. The reasoning can come from the CIS Benchmark 1.0/2.0, PCI, Oracle Best Practices and others.
If this is a true problem/issue then you have some options to remediate the problem. If there is a corresponding Responder Rule then the ‘Remediate’ button will also be active.
Make changes to recipes
If the ‘problem’ is not valid or can be ignored (i.e. Dev/Test environment); then this maybe a good case to clone the recipe again and make changes to the rule that reflect the compartment where the resource resides. For example, you may have a Dev/Test compartment where some ‘problems’ can be ignored. This is a good candidate to clone the root recipe and modify the rule (i.e. Disable) and attach to the a new target (compartment). In this same example, you may also modify the rule to use a condition to exclude the compartment altogether without having to clone the recipe.
Cloning the recipe will give you more flexibility and is recommended especially if you have multiple rules to modify.
Repeat last two steps(6/7) until stable baseline
After changes are made to the recipe wait and see if the intended result is what you expect. This is an iterative process. The idea is to remove the “noise” or false positives in Cloud Guard.
Add event to notify on specific problems that arise
For every problem there is a ‘CloudEvent’ that is sent to OCI Events. Some problems need immediate intervention and by using OCI Events to notify administrators is a good way to be proactive instead of reactive.
Summary
To utilize Cloud Guard efficiently it is imparative that customers configure the tool to minimize the “noise” or false positives” that may arise. An iterative approach shoiuld be taken for tuning the detector recipes based on your tenancy and I hope that this post helped. Remember, any security tool is only as good as the connfiguration.