Detect vs prevent
| Cloud Guard | Security Zones | |
|---|---|---|
| When | After the fact (configuration, activity, threat detectors) | At create/update time: blocks violating actions |
| Scope | Targets (compartment trees) | Security zone compartments |
| Output | Problems with risk levels, optional automatic responders | Denied requests with the violated policy |
Use both: Security Zones for non-negotiable rules in production, Cloud Guard to find everything else.
1. Targets and recipes
- Target at the root compartment (or per top-level compartment) so nothing is missed.
- Clone Oracle-managed detector and responder recipes (don't edit them; you can't) and attach clones to targets:
| Recipe clone | Applied to | Tuning |
|---|---|---|
detector-prod | Production compartments | Strict risk levels, more detectors enabled |
detector-nonprod | Dev/test/sandbox | Lower risk levels for noisy rules, some detectors off |
responder-prod | Production | Notify only, except a few safe automatic actions |
2. Tune detectors
- Start with all configuration and activity detectors on; review the first two weeks of problems.
- Adjust risk levels per rule for your context (e.g. public bucket = CRITICAL in prod, MEDIUM in a website-assets compartment with an approved public bucket).
- Use conditions in detector rules to exclude known, approved resources (tags or OCIDs), documenting each exclusion.
- Enable threat detectors / instance security features where licensed and useful.
3. Route problems to owners
Cloud Guard problem detected (Events: com.oraclecloud.cloudguard.problemdetected)
─► Events rule filtered by risk level ─► Notifications topic per severity
─► CRITICAL/HIGH: on-call security channel + ticket for the compartment owner
─► MEDIUM/LOW: weekly digest to owners
Use owner defined tags on compartments to route tickets automatically (a Function can look up the compartment's tag and create the ticket).
4. Responders: automate carefully
Responder actions (e.g. make bucket private, stop instance, disable user) can run automatically or on approval.
| Action | Automatic? |
|---|---|
| Make a public bucket private (non-website compartments) | Often yes |
| Disable a user with suspicious activity | Usually needs human approval |
| Stop or terminate instances | Only with approval in production |
Test automatic responders in non-prod and document what they do. Surprise remediation causes outages.
5. Security Zones for production
Security zone recipes enforce policies such as: no public buckets, no public IPs on instances (where required), encryption with customer-managed keys, databases with backups, resources only from approved services. Apply them to production compartments that hold sensitive data:
- Start with the Oracle-managed maximum security recipe, then a custom recipe if you need fewer constraints.
- Test deployments (Terraform) against a zone in a non-prod copy first. Some services or configurations aren't allowed in security zones.
6. Measure the programme
| Metric | Target example |
|---|---|
| Open CRITICAL/HIGH problems | Trending to zero; none older than 7 days |
| Mean time to resolve by risk level | Agreed SLA |
| Exclusions with owner and expiry | 100% |
| Security zone violations attempted | Visible and explained |
Tip
Fix problems in the Terraform modules that create resources, not just in the console. Otherwise the same problem reappears with the next deployment.
Checklist
- Targets covering the whole tenancy
- Cloned detector/responder recipes per environment
- Detector risk levels and conditions tuned, exclusions documented
- Problems routed by severity to owners
- Automatic responders limited and tested
- Security Zones on sensitive production compartments
- Metrics reviewed monthly