OCI Cloud Guard shows thousands of problems: tune detector recipes without hiding real risks

#The problem with defaults

Cloud Guard is enabled at the root compartment with Oracle-managed detector recipes. A week later there are thousands of open problems: public buckets that are meant to be public, instances without a specific tag, "suspicious" logins from your own VPN. People stop looking, and the one real problem is lost in the noise.

The fix is tuning, not disabling.

#Step 1: measure what's there

oci cloud-guard problem list --compartment-id ocid1.tenancy.oc1..aaaa... \
  --compartment-id-in-subtree true --access-level ACCESSIBLE \
  --lifecycle-detail OPEN --all \
  --query "data.items[].{rule:\"detector-rule-id\", risk:\"risk-level\", res:\"resource-name\", cmp:\"compartment-id\"}" \
  --output json > problems.json

jq -r '.[].rule' problems.json | sort | uniq -c | sort -rn | head -20

Usually 5-10 rules produce 80% of the problems. Work on those first.

#Step 2: clone the recipes

You can't edit Oracle-managed recipes. Clone them, then attach the clones to your targets:

• Configuration detector recipe: checks resource settings (public buckets, open security lists, keys not rotated).
• Activity detector recipe: checks actions in audit logs (policy changes, bucket made public).
• Threat detector recipe: behaviour-based detections.

Clones keep receiving rule updates from the Oracle-managed source, but your overrides stay.

#Step 3: tune per rule

For each noisy rule, decide one of:

Conditions support compartment and resource matching and, for many rules, tag-based matching. A pattern that scales: tag intentionally public buckets security.exception=approved-public with a change number, and exclude that tag in the rule condition. The exception is now visible on the resource itself.

Warning

Never exclude a whole production compartment from a rule to make the problem count drop. Exclude specific resources with a documented reason.

#Step 4: scope targets properly

One target at the root compartment with one recipe treats production and sandboxes the same. Create targets that match your compartment design:

• prod compartments: strict recipes, all detectors.
• nonprod: same recipes with some rules lowered.
• sandbox: minimal recipe, mainly activity and threat detection.

A compartment can only be covered by one target. Child compartments inherit the parent's target unless they have their own.

#Step 5: clear the backlog with reasons

After tuning, existing problems remain open. Resolve them in bulk only where the tuning now excludes them, and use Dismiss (not Resolve) for accepted risks, so the history shows a decision rather than a fix:

oci cloud-guard problem update-problem-status --problem-id ocid1.cloudguardproblem.oc1..aaaa... \
  --status DISMISSED --comment "Approved public bucket, CHG-2211"

Check oci cloud-guard problem --help for the exact subcommand in your CLI version.

#Step 6: responders, carefully

Responder recipes can act automatically (make a bucket private, stop an instance, delete a public IP). Start with notification only via Events and Notifications:

• Event type for new problems -> Notifications topic -> email/Slack/ticketing.
• Turn on automatic remediation only for rules with no legitimate exceptions, and only after a few weeks of clean results.

#A weekly routine

1. Top 10 rules by open problems: tune or fix.
2. All CRITICAL/HIGH problems older than 7 days: owner assigned?
3. New exceptions added this week: reviewed?
4. Problem count trend: should go down, then flat.

#Prevent it next time

• Treat recipes as code: export them, review changes, keep a changelog of tuning decisions.
• Add the security exception tag to your tagging standard so teams can request exceptions the same way every time.
• Related: Cloud Guard and Security Zones operating model.