10.1 Cloud Guard: Detector Recipes, Problems, Scores & Responders

7.3 Cloud Guard: Managed Detector Recipes, Security Scores & Responder Recipes

OCI Cloud Guard Architecture: Core Entities and Governance Fabric

As enterprise cloud footprints expand across dozens of compartments, regions, and development teams, maintaining continuous security compliance becomes an intractable manual challenge. Misconfigurations—such as accidentally exposed Object Storage buckets, volumes without customer-managed keys, permissive security list rules, or compromised IAM credentials—can emerge and persist undetected for weeks. OCI Cloud Guard is a native, cloud-scale Cloud Security Posture Management (CSPM) service that delivers continuous, automated security surveillance and remediation across your tenancy.

Cloud Guard works through four main concepts:

1. Targets: A Target defines the scope of resources that Cloud Guard monitors. A target can be scoped to the root compartment (encompassing the entire tenancy across all subscribed geographic regions) or granularly restricted to specific departmental compartments (e.g., Finance-Production or DevOps-Sandbox).
2. Detector Recipes: A Detector Recipe contains an inventory of security rules that define what misconfigurations, policy violations, or behavioral anomalies to detect. When a detector rule identifies a violation, Cloud Guard raises an actionable Problem.
3. Problems: A Problem represents an active, identified security issue. Each problem records the offending resource OCID, geographic region, compartment path, detection timestamp, risk severity level (Critical, High, Medium, Low, or Minor), and status, such as open, resolved, or dismissed.
4. Responder Recipes: A Responder Recipe defines the specific remediation action executed when a Problem is identified. Actions range from automated containment (e.g., flipping a public bucket to private) to generating security alerts for human verification.

---

Detector Recipes: Configuration, Activity, Threat & Instance Security Detectors

Cloud Guard provides specialized detector engines to inspect distinct layers of the cloud ecosystem:

1. Configuration Detectors

Configuration detector rules check how resources are set up. Examples from Oracle's detector reference include:

• Bucket is public (Object Storage).
• Instance has a public IP address (risk level High) and Instance is publicly accessible (Compute).
• Instance is not running an Oracle public image.
• VCN has Internet Gateway attached and security rules that allow traffic from 0.0.0.0/0 to restricted ports such as 22 or 3389.
• Policy gives too many privileges and Tenancy admin privilege granted to group (IAM).
• Database is not backed up automatically and Key has not been rotated.

Many rules are labeled with the CIS OCI Foundations Benchmark controls they support.

2. Activity Detectors

Activity detector rules watch actions recorded in OCI Audit that may be risky even when they are legitimate, for example a bastion or bastion session being created, a certificate authority being deleted or revoked, an image being exported, an instance or DB system being terminated, or changes to IAM and networking resources such as security list ingress rules.

3. Threat Detectors

The threat detector looks for patterns of malicious behavior, such as a rogue user whose recent actions combine indicators like impossible travel or password spraying.

Cloud Guard also offers Instance Security detection for compute hosts. OCI provides Oracle-managed recipes for detectors and responders. Oracle maintains and updates them, and you can change only a few settings in their rules. For broader customization, you create a user-managed recipe, usually by cloning an Oracle-managed one.

To tailor Cloud Guard to enterprise requirements, architects employ the Clone-and-Customize pattern:

1. The architect clones the Oracle-Managed Recipe into a custom User-Managed Recipe.
2. In the user-managed recipe, specific rules can be enabled or disabled (e.g., disabling public bucket alerts in a specialized web-hosting compartment while keeping them critical in database compartments).
3. Trigger conditions and risk thresholds can be modified (e.g., elevating SSH port exposure from High to Critical).
4. The custom recipe is bound to the appropriate Target compartment.

---

Security Posture Scoring: Security Score vs. Risk Score

Cloud Guard synthesizes thousands of individual resource evaluations into executive-level posture metrics:

1. Security Score

The Security Score is the percentage of resources that Cloud Guard examined and did not flag as potential problems:

• A higher score is better, and 100 means no problems were detected.
• It reflects monitoring over the past 30 days and is updated continuously.

2. Risk Score

The Risk Score estimates the risk posed by the problems Cloud Guard has detected:

• It reflects the number of problems, the risk level of each, and the sensitivity of the resource types involved.
• The raw value is normalized to a range of 0 to 9,999, where 0 means no problems were detected.
• It covers the past 30 days and is recalculated every 15 minutes.
• Because it grows with the "surface area" of risk, a large tenancy can have an excellent security score and still a high risk score. Fixing high and critical problems on the most sensitive resources reduces it the most.

---

Responder Recipes: Automated vs. User-Approval Remediation

A responder is an action Cloud Guard can take when a detector identifies a problem. Responder recipes group responder rules, and you can use Oracle's defaults, clone them, enable or disable individual rules, and add conditions that limit where a rule applies.

Oracle-Managed Responder Rules

Oracle's responder recipe includes these rules:

Each responder needs an IAM policy that lets the Cloud Guard service act, for example allow service cloudguard to manage buckets in compartment Finance for Make Bucket Private, or manage instance-family for the compute responders. Enabling responders gives Cloud Guard permission to change your environment, so grant only what your security policy allows.

Execution Modes

Responder rules run in one of two modes:

1. User action (default for remediation rules): Cloud Guard shows the problem and the suggested responder, and an authorized engineer reviews it and chooses to remediate. This suits production, where an automatic stop or termination could cause an outage.
2. Automatic action: the responder runs as soon as the problem is detected, without waiting for a person. Use it for high-confidence, high-impact problems such as a public bucket containing sensitive data. The Cloud Event responder already runs this way by default.

---

Integration with OCI Events, Notifications, and SIEM/SOAR Ecosystems

Cloud Guard integrates seamlessly with OCI's event-driven architecture, enabling enterprise-grade alert routing and external tool orchestration:

• OCI Events Service: Cloud Guard automatically emits structured, CloudEvents-compliant JSON events for state changes, including Problem - Detected, Problem - Remediated, and Problem - Dismissed.
• Fan-Out via OCI Notifications (ONS): Events trigger ONS notification topics, broadcasting critical alerts via email, SMS, PagerDuty, or Slack webhooks to on-call incident response engineers.
• Custom Automation via OCI Functions: When complex, multi-system remediation is required (e.g., quarantining an entire VCN, capturing instance memory forensics, or opening a high-priority incident in ServiceNow or Jira), an OCI Events rule routes the problem event to an OCI Function for programmatic execution.
• SIEM/SOAR Ingestion via OCI Streaming: For organizations operating centralized Security Operations Centers (SOC), Cloud Guard events are routed to OCI Streaming (providing a managed Apache Kafka API) to continuously ingest security findings into external platforms like Splunk, Microsoft Sentinel, IBM QRadar, or Datadog.

Architectural Comparison: Cloud Guard Detector Types

The following table contrasts the functional characteristics, telemetry sources, and primary use cases of Cloud Guard detector recipes: