OCI Logging & Detection Hardening

The OCI Audit service records every management-plane API call across the tenancy (write and read, success and failure, with the calling principal, source IP, request body where it does not contain secrets, and the affected resource OCIDs) into a tenancy-wide audit log; this is the OCI equivalent of AWS CloudTrail org-trail and Azure Activity Log centralisation. Set the Audit service retention to its 365-day maximum (CIS OCI v2.0.0 §4.x codifies the 365-day minimum), centralise audit events into a dedicated logging compartment, and archive every audit event to an Object Storage bucket with a LOCKED retention rule of 2 years (730 days) — this is the two-tier pattern that mirrors Phase 6 AWS CloudTrail plus S3 Object Lock Compliance mode and Phase 8 GCP aggregated sinks plus BigQuery audit. Without the archive tier the compliance window is bounded at 365 days; without the LOCKED retention rule the archive itself can be deleted by any principal with OBJECT_DELETE permission, which is the exact attacker profile incident response cares about (Oracle Cloud Infrastructure — Audit Service overview (accessed 2026-05)). The principle traces back to General Logging — log integrity: an audit log an attacker can shorten is not an audit log; immutability and chain-of-custody require write-once retention. CRITICAL because in the absence of tenancy-wide audit the organisation cannot detect, scope, or close out any incident touching the management plane — a Cloud Guard finding, a Vault key deletion, an Identity Domain group mutation, all become unobservable.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: set the Audit service retention to its 365-day maximum.
oci audit configuration update \
  --compartment-id "$TENANCY_OCID" \
  --retention-period-days 365

# Step 2: create the dedicated logging compartment and the audit-archive Object Storage bucket.
oci os bucket create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --name audit-archive-prod \
  --namespace-name "$OS_NAMESPACE" \
  --versioning Enabled \
  --kms-key-id "$VAULT_KEY_OCID"

# Step 3: apply a LOCKED 2-year retention rule on the archive bucket.
# time_amount=730 days; time_rule_locked transitions immutable after 14-day grace.
oci os retention-rule create \
  --bucket-name audit-archive-prod \
  --namespace-name "$OS_NAMESPACE" \
  --display-name compliance-2y \
  --duration '{"timeAmount":730,"timeUnit":"DAYS"}' \
  --time-rule-locked "$(date -u -d '+14 days' +%Y-%m-%dT%H:%M:%SZ)"

# Step 4: configure a Service Connector Hub to ship the tenancy Audit log into the archive bucket.
oci sch service-connector create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --display-name audit-to-archive \
  --source '{"kind":"logging","logSources":[{"compartmentId":"'"$TENANCY_OCID"'","logGroupId":"_Audit","logId":"_Audit"}]}' \
  --target '{"kind":"objectStorage","bucketName":"audit-archive-prod","namespaceName":"'"$OS_NAMESPACE"'"}'

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Cloud docs (accessed 2026-05)
resource "oci_audit_configuration" "tenancy" {
  compartment_id        = var.tenancy_ocid
  retention_period_days = 365
}

resource "oci_objectstorage_bucket" "audit_archive" {
  compartment_id = var.logging_compartment_id
  namespace      = var.os_namespace
  name           = "audit-archive-prod"
  versioning     = "Enabled"
  kms_key_id     = var.vault_key_ocid
  retention_rules {
    display_name     = "compliance-2y"
    duration {
      time_amount = 730
      time_unit   = "DAYS"
    }
    # Lock the rule 14 days after creation: rule becomes immutable, cannot be
    # reduced or deleted even by tenancy-admin (mirrors S3 Object Lock Compliance).
    time_rule_locked = timeadd(timestamp(), "336h")
  }
}

# Service Connector Hub: tenancy Audit log -> archive bucket.
resource "oci_sch_service_connector" "audit_to_archive" {
  compartment_id = var.logging_compartment_id
  display_name   = "audit-to-archive"
  source {
    kind = "logging"
    log_sources {
      compartment_id = var.tenancy_ocid
      log_group_id   = "_Audit"
      log_id         = "_Audit"
    }
  }
  target {
    kind           = "objectStorage"
    bucket         = oci_objectstorage_bucket.audit_archive.name
    namespace      = var.os_namespace
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-01-audit-tenancy" \
  --display-name "oci-log-01-audit-tenancy" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-01-audit-tenancy" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Remediation — Pulumi (TypeScript)

import * as pulumi from "@pulumi/pulumi";
import * as oci from "@pulumi/oci";

// Tenancy-wide Audit retention extension to 365 days (default is 90).
const cfg = new pulumi.Config();
const tenancyOcid = cfg.require("tenancyOcid");

const auditRetention = new oci.audit.Configuration("tenancy-audit-365d", {
  compartmentId: tenancyOcid,
  retentionPeriodDays: 365,  // max-365 at the audit-service tier; archive longer via Logging
});

// Forward Audit events to a tenancy-level Logging service log group for long-term archive.
const auditArchiveGroup = new oci.logging.LogGroup("audit-archive", {
  compartmentId: tenancyOcid,
  displayName: "audit-archive-7yr",
  description: "Long-term Audit event archive — exported via Service Connector to Object Storage",
});

const auditLog = new oci.logging.Log("audit-tenancy-forward", {
  logGroupId: auditArchiveGroup.id,
  displayName: "audit-tenancy",
  logType: "SERVICE",
  isEnabled: true,
  configuration: {
    source: {
      sourceType: "OCISERVICE",
      service: "audit",
      resource: tenancyOcid,
      category: "all",
    },
  },
  retentionDuration: 180,  // 6 mo at the Logging tier; Service Connector exports daily to OSS
});

export const auditLogOcid = auditLog.id;

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' = 'audit'
          and eventName = 'UpdateConfiguration'
          | eval new_retention = data.request.payload.retentionPeriodDays
          | where new_retention < 365
          | stats count by 'User Name', 'Compartment Name', new_retention

Equivalent on: AWS · Azure · GCP

The OCI Audit service records management-plane API calls — bucket create, key rotate, policy update — but it does not record data-plane events (the GetObject and PutObject calls into individual buckets, the Encrypt and Decrypt and GenerateDataKey calls into individual Vault keys, the Function invocations) by default. Data-plane events are equivalent to the AWS CloudTrail "Data Events" tier and the Azure Storage Diagnostic Logs tier — they answer "who read the customer-data bucket between 02:00 and 04:00 UTC the night of the incident" and they are required for any forensic investigation of data exfiltration. Enable service logs explicitly for Object Storage read and write categories, for Vault key use, and for Functions invocations, organised into a per-service Log Group inside the dedicated logging compartment, and ship the resulting logs into Logging Analytics or via Service Connector Hub into Object Storage for long-term retention (OCI — Logging Service overview (accessed 2026-05)). The cost model is per-GB-ingested into the Logging service (with archival economics if you ship to Object Storage), so noisy services like Functions warrant a sampling policy decision rather than blanket 100% capture. HIGH because the absence of data-plane events makes data-exfiltration incidents un-investigable — the management-plane Audit log shows the bucket existed and the IAM policy permitted read, but not who read what and when.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: create the per-service Log Group in the logging compartment.
oci logging log-group create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --display-name service-data-events

# Step 2: enable Object Storage read events for a sensitive bucket.
oci logging log create \
  --log-group-id "$LOG_GROUP_OCID" \
  --display-name objectstorage-customer-data-read \
  --log-type SERVICE \
  --is-enabled true \
  --configuration '{
    "source": {
      "service": "objectstorage",
      "resource": "'"$BUCKET_OCID"'",
      "category": "read",
      "sourceType": "OCISERVICE"
    }
  }'

# Step 3: enable Object Storage write events (PutObject, DeleteObject) for the same bucket.
oci logging log create \
  --log-group-id "$LOG_GROUP_OCID" \
  --display-name objectstorage-customer-data-write \
  --log-type SERVICE \
  --is-enabled true \
  --configuration '{
    "source": {
      "service": "objectstorage",
      "resource": "'"$BUCKET_OCID"'",
      "category": "write",
      "sourceType": "OCISERVICE"
    }
  }'

# Step 4: enable KMS (Vault) key-use events for a regulated Vault key.
oci logging log create \
  --log-group-id "$LOG_GROUP_OCID" \
  --display-name vault-key-use \
  --log-type SERVICE \
  --is-enabled true \
  --configuration '{
    "source": {
      "service": "vaults",
      "resource": "'"$VAULT_KEY_OCID"'",
      "category": "all",
      "sourceType": "OCISERVICE"
    }
  }'

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Cloud docs (accessed 2026-05)
resource "oci_logging_log_group" "service_data_events" {
  compartment_id = var.logging_compartment_id
  display_name   = "service-data-events"
}

# Object Storage read events for customer-data bucket.
resource "oci_logging_log" "objectstorage_read" {
  log_group_id = oci_logging_log_group.service_data_events.id
  display_name = "objectstorage-customer-data-read"
  log_type     = "SERVICE"
  is_enabled   = true
  configuration {
    source {
      service     = "objectstorage"
      resource    = var.customer_data_bucket_ocid
      category    = "read"
      source_type = "OCISERVICE"
    }
  }
}

# Object Storage write events (PutObject, DeleteObject) for the same bucket.
resource "oci_logging_log" "objectstorage_write" {
  log_group_id = oci_logging_log_group.service_data_events.id
  display_name = "objectstorage-customer-data-write"
  log_type     = "SERVICE"
  is_enabled   = true
  configuration {
    source {
      service     = "objectstorage"
      resource    = var.customer_data_bucket_ocid
      category    = "write"
      source_type = "OCISERVICE"
    }
  }
}

# Vault key-use events (Encrypt, Decrypt, GenerateDataKey) for a regulated key.
resource "oci_logging_log" "vault_key_use" {
  log_group_id = oci_logging_log_group.service_data_events.id
  display_name = "vault-key-use"
  log_type     = "SERVICE"
  is_enabled   = true
  configuration {
    source {
      service     = "vaults"
      resource    = var.regulated_vault_key_ocid
      category    = "all"
      source_type = "OCISERVICE"
    }
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-02-data-events" \
  --display-name "oci-log-02-data-events" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-02-data-events" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' = 'logging'
          and eventName in ('UpdateLog', 'DeleteLog')
          | eval is_data_event = if(data.target.log.logType = 'SERVICE' and data.target.log.configuration.source.category in ('read', 'write'), 'YES', 'NO')
          | where is_data_event = 'YES'
          | stats count by 'User Name', data.target.log.displayName, eventName

Equivalent on: AWS · Azure · GCP

Cloud Guard is DETECTIVE at tenancy scope. Cloud Guard is OCI's cross-tenancy detection plane: enable it at the tenancy root with Oracle-managed detector recipes (the Configuration detector evaluates resource configurations against a library of checks — public buckets, weak NSG rules, IAM policies that grant manage all-resources, Vault keys without rotation; the Activity detector evaluates suspicious API call patterns — instance launched in unusual region, IAM policy created from anomalous source IP, MFA bypassed), set the target to the tenancy root compartment so detection covers the entire subtree, and attach the Oracle-managed responder recipe (which integrates with Notifications and Functions; the auto-remediation behaviour is canonically owned by oci-ir-02-cloud-guard-remediation on the OCI IR page). Problems surface in the Cloud Guard problems view with severity Critical / High / Medium / Minor / Low; integrate the problems stream into the organisation's SIEM or ticketing via Notifications topics for triage tracking. Cloud Guard's scope is tenancy posture (CSPM) — it observes unsafe state and surfaces findings; it does not block resource creation (Security Zones at oci-log-05 is the preventive surface) and it does not scan workloads for CVEs (Vulnerability Scanning Service at oci-log-04 is the workload-scope detective surface). The detector pack is certified against CIS OCI v2.0.0; v3.1.0 evaluation requires VSS findings plus manual compartment-policy checks until OCI ships the v3.1.0 detector pack (OCI — Cloud Guard documentation (accessed 2026-05)). The principle traces back to General Logging — SIEM and detection engineering: a posture engine that finds the issues nobody is configured to look for, with managed detector recipes that ship with the platform rather than being authored by the customer.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: enable Cloud Guard at the tenancy root with a reporting region.
# (Reporting region is the region where Cloud Guard stores problems; one per tenancy.)
oci cloud-guard configuration update \
  --compartment-id "$TENANCY_OCID" \
  --status ENABLED \
  --reporting-region us-ashburn-1

# Step 2: create the tenancy-root target so detection covers the entire compartment subtree.
oci cloud-guard target create \
  --compartment-id "$TENANCY_OCID" \
  --display-name tenancy-root \
  --target-resource-type COMPARTMENT \
  --target-resource-id "$TENANCY_OCID"

# Step 3: attach the Oracle-managed detector + responder recipes to the target.
# (Recipe OCIDs are tenancy-specific; query with oci cloud-guard detector-recipe list.)
oci cloud-guard target-detector-recipe create \
  --target-id "$TARGET_OCID" \
  --detector-recipe-id "$ORACLE_MANAGED_CONFIG_DETECTOR_OCID"

oci cloud-guard target-responder-recipe create \
  --target-id "$TARGET_OCID" \
  --responder-recipe-id "$ORACLE_MANAGED_RESPONDER_OCID"

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Cloud Guard docs (accessed 2026-05)
resource "oci_cloud_guard_cloud_guard_configuration" "tenancy" {
  compartment_id   = var.tenancy_ocid
  status           = "ENABLED"
  reporting_region = "us-ashburn-1"
}

# Clone the Oracle-managed Configuration detector recipe so it can be tuned per-tenancy.
resource "oci_cloud_guard_detector_recipe" "config_clone" {
  compartment_id            = var.tenancy_ocid
  display_name              = "tenancy-config-detector"
  source_detector_recipe_id = var.oracle_managed_config_detector_ocid
}

# Clone the Oracle-managed Activity detector recipe.
resource "oci_cloud_guard_detector_recipe" "activity_clone" {
  compartment_id            = var.tenancy_ocid
  display_name              = "tenancy-activity-detector"
  source_detector_recipe_id = var.oracle_managed_activity_detector_ocid
}

# Clone the Oracle-managed responder recipe (responsive pair owned by oci-ir-02).
resource "oci_cloud_guard_responder_recipe" "responder_clone" {
  compartment_id             = var.tenancy_ocid
  display_name               = "tenancy-responder"
  source_responder_recipe_id = var.oracle_managed_responder_ocid
}

# Target = tenancy root compartment subtree; binds detectors + responder.
resource "oci_cloud_guard_target" "tenancy_root" {
  compartment_id        = var.tenancy_ocid
  display_name          = "tenancy-root"
  target_resource_type  = "COMPARTMENT"
  target_resource_id    = var.tenancy_ocid
  target_detector_recipes {
    detector_recipe_id = oci_cloud_guard_detector_recipe.config_clone.id
  }
  target_detector_recipes {
    detector_recipe_id = oci_cloud_guard_detector_recipe.activity_clone.id
  }
  target_responder_recipes {
    responder_recipe_id = oci_cloud_guard_responder_recipe.responder_clone.id
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-03-cloud-guard" \
  --display-name "oci-log-03-cloud-guard" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-03-cloud-guard" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' = 'cloud-guard'
          and eventName = 'UpdateConfiguration'
          | eval cg_status = data.request.payload.status
          | where cg_status = 'DISABLED'
          | stats count by 'User Name', 'Compartment Name'

Equivalent on: AWS · Azure · GCP

Vulnerability Scanning Service (VSS) is DETECTIVE on workloads. The anchor literal oci-log-04-cloud-guard-detectors is preserved for sibling-provider link stability (sibling-anchors.tsv lock from Phase 6 — every AWS, Azure, and GCP logging page emits a graceful-then-STRICT href pointing at this anchor literal); the functional Title for this control on this page is "Vulnerability Scanning Service" because VSS provides the cleanest cross-provider functional analog to AWS GuardDuty / Amazon Inspector, Azure Defender for Servers and Defender for Containers, and GCP Security Command Center Premium threat detection plus Container Analysis. Configure two recipe surfaces: host scan recipes scan the operating system of Compute instances for CVEs and open ports on a schedule (the Cloud Agent must be running on the instance and the Vulnerability Scanning plugin must be enabled); container scan recipes scan Container Registry (OCIR) images on push and on a schedule for CVEs in OS and language packages. Findings surface in the VSS console with severity Critical / High / Medium / Low and also flow into Cloud Guard via the VSS detector, so a tenancy that ships both oci-log-03 and this control gets a single problem-triage view (OCI — Vulnerability Scanning Service (accessed 2026-05)). Remediation feedback flows back to OS Management Hub for patching workflows (oci-work-08-os-management-hub on the OCI Workloads page). VSS is distinct from Cloud Guard — VSS is workload-level CVE detection (the workloads themselves and the images they run); Cloud Guard is tenancy-level misconfiguration detection (the IAM policy, the bucket ACL, the NSG rule). Cross-reference oci-work-04-vulnerability-scanning: the work-level control is the host-scan recipe attached to a specific Compute instance fleet; this log-level control is the umbrella that covers all VSS recipes across the tenancy. CRITICAL because CVE detection in production OS and container images is the same severity as posture detection — an unpatched pre-auth RCE in a workload is the same root attack surface as an over-broad IAM policy, and going without is a CRITICAL gap.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: create a host scan recipe (STANDARD scan level — daily; WEEKLY also supported).
oci vulnerability-scanning host-scan-recipe create \
  --compartment-id "$WORKLOAD_COMPARTMENT_OCID" \
  --display-name prod-host-scan \
  --port-settings '{"scanLevel":"STANDARD"}' \
  --agent-settings '{
    "scanLevel": "STANDARD",
    "vendor": "OCI",
    "agentConfiguration": {"vendor": "OCI", "cisBenchmarkSettings": {"scanLevel": "STANDARD"}}
  }' \
  --schedule '{"type":"DAILY"}'

# Step 2: create a host scan target binding the recipe to a Compute instance compartment.
oci vulnerability-scanning host-scan-target create \
  --compartment-id "$WORKLOAD_COMPARTMENT_OCID" \
  --display-name prod-host-scan-target \
  --host-scan-recipe-id "$RECIPE_OCID" \
  --target-compartment-id "$PROD_COMPUTE_COMPARTMENT_OCID"

# Step 3: create a container scan recipe (scans OCIR images on push + on schedule).
oci vulnerability-scanning container-scan-recipe create \
  --compartment-id "$WORKLOAD_COMPARTMENT_OCID" \
  --display-name prod-container-scan \
  --scan-settings '{"scanLevel":"STANDARD"}'

# Step 4: attach the container scan recipe to a Container Registry repository.
oci vulnerability-scanning container-scan-target create \
  --compartment-id "$WORKLOAD_COMPARTMENT_OCID" \
  --display-name prod-container-scan-target \
  --container-scan-recipe-id "$CONTAINER_RECIPE_OCID" \
  --target-registry '{"registryType":"OCIR","compartmentId":"'"$REGISTRY_COMPARTMENT_OCID"'"}'

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Vulnerability Scanning Service docs (accessed 2026-05)
resource "oci_vulnerability_scans_host_scan_recipe" "prod" {
  compartment_id = var.workload_compartment_id
  display_name   = "prod-host-scan"
  port_settings {
    scan_level = "STANDARD"
  }
  agent_settings {
    scan_level = "STANDARD"
    vendor     = "OCI"
    agent_configuration {
      vendor = "OCI"
      cis_benchmark_settings {
        scan_level = "STANDARD"
      }
    }
  }
  schedule {
    type = "DAILY"
  }
}

resource "oci_vulnerability_scans_host_scan_target" "prod" {
  compartment_id        = var.workload_compartment_id
  display_name          = "prod-host-scan-target"
  host_scan_recipe_id   = oci_vulnerability_scans_host_scan_recipe.prod.id
  target_compartment_id = var.prod_compute_compartment_id
}

resource "oci_vulnerability_scans_container_scan_recipe" "prod" {
  compartment_id = var.workload_compartment_id
  display_name   = "prod-container-scan"
  scan_settings {
    scan_level = "STANDARD"
  }
}

resource "oci_vulnerability_scans_container_scan_target" "prod" {
  compartment_id             = var.workload_compartment_id
  display_name               = "prod-container-scan-target"
  container_scan_recipe_id   = oci_vulnerability_scans_container_scan_recipe.prod.id
  target_registry {
    registry_type  = "OCIR"
    compartment_id = var.registry_compartment_id
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-04-cloud-guard-detectors" \
  --display-name "oci-log-04-cloud-guard-detectors" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-04-cloud-guard-detectors" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Remediation — Pulumi (TypeScript)

import * as pulumi from "@pulumi/pulumi";
import * as oci from "@pulumi/oci";

// Cloud Guard detector recipes — Configuration + Activity detectors enabled.
const cfg = new pulumi.Config();
const tenancyOcid = cfg.require("tenancyOcid");
const reportingRegion = cfg.require("reportingRegion");

const cloudGuardConfig = new oci.cloudguard.CloudGuardConfiguration("cg-enable", {
  compartmentId: tenancyOcid,
  reportingRegion: reportingRegion,
  status: "ENABLED",
  selfManagedResources: false,  // Oracle-managed detector definitions
});

// Clone Oracle-managed Configuration detector recipe + customise.
const configDetectorRecipe = new oci.cloudguard.DetectorRecipe("config-detector", {
  compartmentId: tenancyOcid,
  displayName: "hardening-config-detector",
  detector: "IAAS_CONFIGURATION_DETECTOR",
  sourceDetectorRecipeId: cfg.require("oracleConfigRecipeOcid"),
  description: "Detect mis-configured public buckets, open SGs, unencrypted volumes",
}, { dependsOn: [cloudGuardConfig] });

// Bind detector recipe to a Cloud Guard Target at the tenancy root.
const tenancyTarget = new oci.cloudguard.Target("tenancy-target", {
  compartmentId: tenancyOcid,
  displayName: "tenancy-root-target",
  targetResourceType: "COMPARTMENT",
  targetResourceId: tenancyOcid,
  targetDetectorRecipes: [{ detectorRecipeId: configDetectorRecipe.id }],
});

export const detectorRecipeOcid = configDetectorRecipe.id;

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' = 'cloud-guard'
          and eventName in ('UpdateDetectorRecipe', 'DeleteDetectorRecipe')
          | eval rule = data.request.payload.detectorRules
          | where rule like '%isEnabled":false%' and (rule like '%HIGH%' or rule like '%CRITICAL%')
          | stats count by 'User Name', data.target.detectorRecipe.id

Equivalent on: AWS · Azure · GCP

Security Zones is PREVENTIVE via compartment policy. The anchor literal oci-log-05-cloud-guard is preserved for sibling-provider link stability (sibling-anchors.tsv lock from Phase 6); the functional Title for this control on this page is "Security Zones" — the preventive enforcement surface that is distinct from Cloud Guard's detective scope at oci-log-03. A compartment designated as a Security Zone rejects non-compliant resource-creation API calls at request time using a Security Recipe: the call to create a public-read Object Storage bucket returns a 4xx response, not a Cloud Guard problem after the fact; the call to create a Block Volume without a Vault key reference is rejected; the call to launch a Compute instance with a public IP in the wrong subnet is rejected. The Oracle-managed Maximum Security Recipe is the default starting point (RESEARCH Open Q #5 resolution) — it bundles the canonical hardening rules: buckets must be private, Block Volumes must be CMEK-encrypted with a Vault key, Compute instances must not have public IPs, only approved Vault keys may be used, and so on. For environments where a Maximum Security Recipe rule legitimately conflicts (the canonical example is a static-website public bucket use case where the rule "buckets must be private" cannot hold), clone the Maximum Security Recipe and edit the conflicting rule into a Custom Security Recipe; the recommendation is to scope the custom recipe to one compartment and keep the Maximum Security Recipe on every other production compartment (OCI — Security Zones documentation (accessed 2026-05)). Security Zones blocks unsafe creation at request time; Cloud Guard surfaces unsafe state after the fact — the two surfaces are complementary, and a tenancy that ships both gets both prevention and detection across the same compartment subtree. The principle traces back to General Logging — what to log and to the broader preventive-vs-detective distinction codified in methodology — control-type labelling: a control that rejects unsafe state at the API request boundary is preventive by definition, even when the underlying engine (Cloud Guard) also has a detective surface. HIGH severity because Security Zones is the strongest preventive surface OCI exposes for compartment-scoped policy enforcement; not CRITICAL because the rules it enforces are also enforced by the corresponding individual controls (no-public-bucket lives on oci-data-01-object-storage-private, CMEK on Block Volumes lives on oci-data-03-block-volume-encryption) — Security Zones is the belt-and-braces enforcement layer on top.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: list the Oracle-managed Maximum Security Recipe OCID.
oci cloud-guard security-recipe list \
  --compartment-id "$TENANCY_OCID" \
  --owner ORACLE \
  --query 'data.items[?contains("display-name", `Maximum`)] | [0].id'

# Step 2 (optional): clone the Maximum Security Recipe as the starting point for a Custom Recipe.
# (Skip this step and use the Oracle-managed OCID directly if no rule exceptions are required.)
oci cloud-guard security-recipe create \
  --compartment-id "$SECURITY_COMPARTMENT_OCID" \
  --display-name custom-recipe-static-site \
  --owner USER \
  --security-policies "[\"$MAX_SECURITY_POLICY_1\", \"$MAX_SECURITY_POLICY_2\"]"

# Step 3: designate the production compartment as a Security Zone bound to the recipe.
oci cloud-guard security-zone create \
  --compartment-id "$PROD_COMPARTMENT_OCID" \
  --display-name prod-zone \
  --security-zone-recipe-id "$RECIPE_OCID"

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Security Zones docs (accessed 2026-05)

# Reference the Oracle-managed Maximum Security Recipe via data source.
data "oci_cloud_guard_security_recipes" "managed" {
  compartment_id = var.tenancy_ocid
  display_name   = "OracleSecurityZoneRecipeMaxSecurity"
}

# OPTIONAL: clone the Maximum Security Recipe for a per-compartment exception.
# Most production compartments should use the Oracle-managed recipe OCID directly
# without cloning — only clone when a specific rule legitimately conflicts
# (canonical example: static-website public bucket use case).
resource "oci_cloud_guard_security_recipe" "custom" {
  compartment_id = var.security_compartment_id
  display_name   = "custom-recipe-static-site"
  owner          = "USER"
  security_policies = data.oci_cloud_guard_security_recipes.managed.security_recipe_collection[0].items[0].security_policies
}

# Designate the production compartment as a Security Zone — preventive enforcement.
# Resource-creation API calls into this compartment are evaluated against the recipe
# at request time; non-compliant calls return a 4xx response.
resource "oci_cloud_guard_security_zone" "prod" {
  compartment_id          = var.prod_compartment_id
  display_name            = "prod-zone"
  security_zone_recipe_id = data.oci_cloud_guard_security_recipes.managed.security_recipe_collection[0].items[0].id
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-05-cloud-guard" \
  --display-name "oci-log-05-cloud-guard" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-05-cloud-guard" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' = 'cloud-guard'
          and eventName in ('DeleteTarget', 'UpdateTarget', 'UpdateManagedList')
          | eval scope = data.target.target.targetResourceType
          | where eventName = 'DeleteTarget'
             or scope is null
          | stats count by 'User Name', data.target.target.id, eventName

Equivalent on: AWS · Azure · GCP

VCN Flow Logs capture L3/L4 metadata (5-tuple, action ACCEPT or REJECT, byte and packet counts) for every flow that traverses a VNIC or subnet on which Flow Logs are enabled; they are the OCI equivalent of AWS VPC Flow Logs, Azure NSG Flow Logs, and GCP VPC Flow Logs, and they are the foundational network-detection surface for any anomaly-driven SIEM rule. Enable Flow Logs on every subnet (the subnet-level surface aggregates over every VNIC in the subnet — the right default for breadth) with sampling at 100% for security-critical subnets (database tier, management subnets, anything carrying customer data) and a reduced sampling rate (1% or 0.1%) for high-volume non-sensitive subnets where the cost of 100% sampling is not justified by the detection value; aggregate the resulting logs into a centralised Log Group in the dedicated logging compartment, and export to Object Storage via Service Connector Hub for long-term retention (OCI — VCN Flow Logs (accessed 2026-05)). The principle traces back to General Logging — what to log: the network plane is the second-to-last forensic surface before the workload itself, and the cost of not having Flow Logs is paid only once — during an incident, when there is no time to backfill them. MEDIUM severity (not HIGH) because Flow Logs alone don't prevent or detect specific known-bad behaviours; they are the substrate on which detection rules and forensic queries operate.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: create the central Flow Logs Log Group.
oci logging log-group create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --display-name vcn-flow-logs

# Step 2: enable Flow Logs on a security-critical subnet at 100% sampling.
oci logging log create \
  --log-group-id "$LOG_GROUP_OCID" \
  --display-name flow-logs-db-tier \
  --log-type SERVICE \
  --is-enabled true \
  --configuration '{
    "source": {
      "service": "flowlogs",
      "resource": "'"$DB_SUBNET_OCID"'",
      "category": "all",
      "sourceType": "OCISERVICE"
    }
  }'

# Step 3: ship Flow Logs to Object Storage for long-term retention.
oci sch service-connector create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --display-name flow-logs-to-archive \
  --source '{"kind":"logging","logSources":[{"compartmentId":"'"$LOGGING_COMPARTMENT_OCID"'","logGroupId":"'"$LOG_GROUP_OCID"'"}]}' \
  --target '{"kind":"objectStorage","bucketName":"flow-logs-archive","namespaceName":"'"$OS_NAMESPACE"'"}'

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Cloud docs (accessed 2026-05)
resource "oci_logging_log_group" "vcn_flow_logs" {
  compartment_id = var.logging_compartment_id
  display_name   = "vcn-flow-logs"
}

# Flow Logs at 100% sampling on the database-tier subnet.
resource "oci_logging_log" "db_tier_flow" {
  log_group_id = oci_logging_log_group.vcn_flow_logs.id
  display_name = "flow-logs-db-tier"
  log_type     = "SERVICE"
  is_enabled   = true
  configuration {
    source {
      service     = "flowlogs"
      resource    = var.db_subnet_ocid
      category    = "all"
      source_type = "OCISERVICE"
    }
  }
}

# Flow Logs at reduced sampling on a high-volume workload subnet.
resource "oci_logging_log" "app_tier_flow" {
  log_group_id = oci_logging_log_group.vcn_flow_logs.id
  display_name = "flow-logs-app-tier"
  log_type     = "SERVICE"
  is_enabled   = true
  configuration {
    source {
      service     = "flowlogs"
      resource    = var.app_subnet_ocid
      category    = "all"
      source_type = "OCISERVICE"
    }
  }
}

# Service Connector Hub: Flow Logs Log Group -> Object Storage archive.
resource "oci_sch_service_connector" "flow_archive" {
  compartment_id = var.logging_compartment_id
  display_name   = "flow-logs-to-archive"
  source {
    kind = "logging"
    log_sources {
      compartment_id = var.logging_compartment_id
      log_group_id   = oci_logging_log_group.vcn_flow_logs.id
    }
  }
  target {
    kind      = "objectStorage"
    bucket    = "flow-logs-archive"
    namespace = var.os_namespace
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-06-vcn-flow-logs" \
  --display-name "oci-log-06-vcn-flow-logs" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-06-vcn-flow-logs" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' = 'logging'
          and eventName in ('UpdateLog', 'DeleteLog')
          | eval cat = data.target.log.configuration.source.category
          | where cat in ('flowlogs', 'all') and (eventName = 'DeleteLog' or data.target.log.isEnabled = 'false')
          | stats count by 'User Name', data.target.log.displayName, eventName

Equivalent on: AWS · Azure · GCP

The OCI Notifications service is the topic-and-subscription fan-out primitive (a topic-per-event-class, subscribers via Email, PagerDuty, Slack, HTTPS, or OCI Functions for custom playbooks) and the Events service is the rule-evaluation layer that filters audit events and emits matching events onto Notifications topics. Together they are the wire that turns the canonical tenancy-critical security events — Identity Domain policy create / update / delete, group membership mutations, Vault key delete or rotation, Audit configuration update, Cloud Guard Critical or High problems, federated IdP configuration change — into operator-visible alerts in the channels the SOC actually watches. Without this wire, the events are captured in the Audit log but nobody is paged on them, which means the median time-to-detect-and-respond stretches from minutes to whatever the SOC's batch-log-review cadence is. Configure one topic per event class (so an Email-only subscriber for low-criticality changes does not page the on-call channel that handles Vault-key deletes) and bind Events rules to event types via the Oracle event type schema — for example com.oraclecloud.identitycontrolplane.updatepolicy, com.oraclecloud.keymanagement.deletekey, com.oraclecloud.cloud-guard.problemdetected (OCI — Notifications Service (accessed 2026-05); OCI — Events Service (accessed 2026-05)). The principle traces back to General Logging — alerting: capture-without-alerting is detection theatre; an event nobody is paged on is not detected, only recorded.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: create the security-events Notifications topic.
oci ons topic create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --name security-events-critical \
  --description "Tenancy-critical security events (IAM, Vault, Audit, Cloud Guard)"

# Step 2: subscribe the SOC pager-email to the topic.
oci ons subscription create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --topic-id "$TOPIC_OCID" \
  --protocol EMAIL \
  --subscription-endpoint secops-pager@example.com

# Step 3: bind an Events rule for IAM policy mutations.
oci events rule create \
  --compartment-id "$TENANCY_OCID" \
  --display-name iam-policy-mutations \
  --condition '{
    "eventType": [
      "com.oraclecloud.identitycontrolplane.createpolicy",
      "com.oraclecloud.identitycontrolplane.updatepolicy",
      "com.oraclecloud.identitycontrolplane.deletepolicy"
    ]
  }' \
  --is-enabled true \
  --actions '{"actions":[{"actionType":"ONS","topicId":"'"$TOPIC_OCID"'","isEnabled":true}]}'

# Step 4: bind an Events rule for Vault key deletes (canonical irreversible event).
oci events rule create \
  --compartment-id "$TENANCY_OCID" \
  --display-name vault-key-deletes \
  --condition '{"eventType":["com.oraclecloud.keymanagement.deletekey","com.oraclecloud.keymanagement.scheduledeletion"]}' \
  --is-enabled true \
  --actions '{"actions":[{"actionType":"ONS","topicId":"'"$TOPIC_OCID"'","isEnabled":true}]}'

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Notifications + Events docs (accessed 2026-05)
resource "oci_ons_notification_topic" "security_critical" {
  compartment_id = var.logging_compartment_id
  name           = "security-events-critical"
  description    = "Tenancy-critical security events (IAM, Vault, Audit, Cloud Guard)"
}

resource "oci_ons_subscription" "soc_pager" {
  compartment_id = var.logging_compartment_id
  topic_id       = oci_ons_notification_topic.security_critical.id
  protocol       = "EMAIL"
  endpoint       = "secops-pager@example.com"
}

# IAM (Identity Domains) policy mutations -> Notifications.
resource "oci_events_rule" "iam_policy_mutations" {
  compartment_id = var.tenancy_ocid
  display_name   = "iam-policy-mutations"
  is_enabled     = true
  condition = jsonencode({
    eventType = [
      "com.oraclecloud.identitycontrolplane.createpolicy",
      "com.oraclecloud.identitycontrolplane.updatepolicy",
      "com.oraclecloud.identitycontrolplane.deletepolicy"
    ]
  })
  actions {
    actions {
      action_type = "ONS"
      topic_id    = oci_ons_notification_topic.security_critical.id
      is_enabled  = true
    }
  }
}

# Vault key deletes (canonical irreversible event) -> Notifications.
resource "oci_events_rule" "vault_key_deletes" {
  compartment_id = var.tenancy_ocid
  display_name   = "vault-key-deletes"
  is_enabled     = true
  condition = jsonencode({
    eventType = [
      "com.oraclecloud.keymanagement.deletekey",
      "com.oraclecloud.keymanagement.scheduledeletion"
    ]
  })
  actions {
    actions {
      action_type = "ONS"
      topic_id    = oci_ons_notification_topic.security_critical.id
      is_enabled  = true
    }
  }
}

# Cloud Guard Critical / High problems -> Notifications.
resource "oci_events_rule" "cloud_guard_critical" {
  compartment_id = var.tenancy_ocid
  display_name   = "cloud-guard-critical"
  is_enabled     = true
  condition = jsonencode({
    eventType = ["com.oraclecloud.cloud-guard.problemdetected"]
    data      = { riskLevel = ["CRITICAL", "HIGH"] }
  })
  actions {
    actions {
      action_type = "ONS"
      topic_id    = oci_ons_notification_topic.security_critical.id
      is_enabled  = true
    }
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-07-notifications" \
  --display-name "oci-log-07-notifications" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-07-notifications" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and 'Service Name' in ('ons', 'sch')
          and eventName in ('DeleteTopic', 'DeleteSubscription', 'UpdateServiceConnector')
          | eval target_topic = data.target.topic.name
          | where target_topic like '%paging%' or target_topic like '%cloud-guard%'
          | stats count by 'User Name', target_topic, eventName

Equivalent on: AWS · Azure · GCP

The Audit service stores tenancy-wide management-plane events for 365 days; anything beyond that is the responsibility of an archive. Ship the Audit log to an Object Storage bucket via Service Connector Hub, encrypt the bucket with a Vault key (so the archive is part of the same key-policy boundary as the live audit stream, and key destruction destroys both — which is the correct invariant for incident response, because an archive an attacker can delete is not an archive), apply a LOCKED retention rule of 2 years (730 days) so the archive becomes immutable after the 14-day grace window and cannot be reduced or deleted even by tenancy-admin. This is the two-tier mirror of oci-log-01: oci-log-01 enforces the live retention configuration; this control owns the immutable forensic archive. The forensic search workflow during an incident is to query Logging Analytics or Audit search against the live 365-day window for current activity, and against the Object Storage archive (via OCI Storage Gateway or via a Functions-driven re-ingest) for activity older than 365 days. Cross-reference oci-data-08-object-retention — the retention-rule pattern itself is owned by the Object Storage page; this control composes it with the Audit-to-bucket pipeline (OCI — exporting Audit log files (accessed 2026-05)). Typed RESPONSIVE not DETECTIVE because the archive's value is forensic — it is searched only after an incident is declared, and its presence does not by itself surface alerts or block unsafe state. MEDIUM severity because operating without the archive is recoverable up to the 365-day live retention horizon; below that horizon, evidence is gone.

Remediation — OCI CLI

# oci CLI (v3.x)
# Step 1: create the audit-archive bucket KMS-encrypted with a Vault key.
oci os bucket create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --name audit-archive-forensic \
  --namespace-name "$OS_NAMESPACE" \
  --versioning Enabled \
  --kms-key-id "$VAULT_KEY_OCID"

# Step 2: apply the 2-year LOCKED retention rule.
oci os retention-rule create \
  --bucket-name audit-archive-forensic \
  --namespace-name "$OS_NAMESPACE" \
  --display-name forensic-2y-locked \
  --duration '{"timeAmount":730,"timeUnit":"DAYS"}' \
  --time-rule-locked "$(date -u -d '+14 days' +%Y-%m-%dT%H:%M:%SZ)"

# Step 3: create the Service Connector from the tenancy Audit log to the archive bucket.
oci sch service-connector create \
  --compartment-id "$LOGGING_COMPARTMENT_OCID" \
  --display-name audit-to-forensic-archive \
  --source '{"kind":"logging","logSources":[{"compartmentId":"'"$TENANCY_OCID"'","logGroupId":"_Audit","logId":"_Audit"}]}' \
  --target '{"kind":"objectStorage","bucketName":"audit-archive-forensic","namespaceName":"'"$OS_NAMESPACE"'"}'

Remediation — Terraform

# Terraform OCI provider ~> 5.0
# Source: Oracle Cloud docs (accessed 2026-05)
resource "oci_objectstorage_bucket" "audit_forensic" {
  compartment_id = var.logging_compartment_id
  namespace      = var.os_namespace
  name           = "audit-archive-forensic"
  versioning     = "Enabled"
  kms_key_id     = var.vault_key_ocid
  retention_rules {
    display_name = "forensic-2y-locked"
    duration {
      time_amount = 730
      time_unit   = "DAYS"
    }
    # Lock the rule 14 days after creation: rule becomes immutable, cannot be
    # reduced or deleted even by tenancy-admin (mirrors S3 Object Lock Compliance).
    time_rule_locked = timeadd(timestamp(), "336h")
  }
}

resource "oci_sch_service_connector" "audit_to_forensic" {
  compartment_id = var.logging_compartment_id
  display_name   = "audit-to-forensic-archive"
  source {
    kind = "logging"
    log_sources {
      compartment_id = var.tenancy_ocid
      log_group_id   = "_Audit"
      log_id         = "_Audit"
    }
  }
  target {
    kind      = "objectStorage"
    bucket    = oci_objectstorage_bucket.audit_forensic.name
    namespace = var.os_namespace
  }
}

Remediation — OCI Resource Manager

# Submit the Terraform block above to OCI Resource Manager via a configured
# Git source-provider. Variables are entered through the Console UI (schema-driven
# by an optional schema.yaml); state is stored in OCI Object Storage automatically.
# This is an INVOCATION snippet — the .tf body is the existing Terraform block
# on this same control-box (do NOT duplicate HCL here).
oci resource-manager stack create-from-git-provider \
  --compartment-id "$COMPARTMENT_OCID" \
  --config-source-provider-id "$CONFIG_SRC_PROVIDER_OCID" \
  --repository-url "https://example.com/org/hardening-iac" \
  --branch-name "main" \
  --working-directory "modules/oci-log-08-audit-archive" \
  --display-name "oci-log-08-audit-archive" \
  --terraform-version "1.5.x"

# Plan + apply via the ORM job lifecycle (state stored in OCI automatically).
STACK_OCID=$(oci resource-manager stack list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oci-log-08-audit-archive" \
  --query 'data[0].id' --raw-output)
PLAN_JOB_OCID=$(oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID" --query 'data.id' --raw-output)
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --execution-plan-strategy FROM_PLAN_JOB \
  --execution-plan-job-id "$PLAN_JOB_OCID"

Compliance mapping

'Log Source' = 'OCI Audit Logs'
          and (
            ('Service Name' = 'object-storage' and eventName in ('UpdateBucket','DeleteBucket','UpdateRetentionRule','DeleteRetentionRule')
             and data.target.bucket.name like '%audit-archive%')
            or
            ('Service Name' = 'sch' and eventName in ('DeleteServiceConnector','UpdateServiceConnector')
             and data.target.serviceConnector.displayName like '%audit-archive%')
          )
          | stats count by 'User Name', eventName, 'Compartment Name'

Equivalent on: AWS · Azure · GCP