Skip to main content

More Info:

The OCI Audit service should be actively producing events. If audit is not enabled or has zero events, security-critical activities are not being recorded for investigation.

Risk Level

Medium

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AWS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • FedRAMP
  • GDPR
  • HIPAA
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • PCI
  • Reserve Bank of India (RBI) Cyber Security Framework
  • Reserve Bank of India (RBI) Master Direction – Information Technology Framework
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Here’s how to actively monitor OCI Audit logs using Logging search alerts and Notifications in the OCI Console.

1. Confirm Audit Logs Are Being Collected

  1. Sign in to the OCI Console.
  2. Open the navigation menu → LoggingLogs.
  3. In the top-left compartment selector, choose your root compartment (tenancy).
  4. Filter for Service = Audit or look for a log named Audit or Audit Logs.
    • If present and showing recent entries, Audit logging is active (Audit is usually always-on; you’re verifying visibility in Logging).

2. Create a Notification Topic & Subscription

You will use OCI Notifications to receive alerts (email, Slack, etc.).
  1. Open the navigation menu → Developer ServicesNotificationsTopics.
  2. Click Create Topic.
    • Name: e.g. audit-alerts-topic
    • Description: e.g. Alerts for OCI Audit events
    • Compartment: choose the compartment where you manage ops/security.
  3. Click Create.
Add a subscription:
  1. On the topic details page, click Create Subscription.
  2. Choose protocol (e.g. Email).
  3. Enter destination (e.g. your security team’s email).
  4. Click Create.
  5. Go to your email and confirm the subscription (required before alerts are delivered).

3. Build a Logging Search for Audit Events

  1. Open the navigation menu → LoggingLogs.
  2. In the compartment selector, choose the compartment with your Audit log (often root).
  3. Click on the Audit log (the log resource, not a single entry).
  4. Click Search or View Log (depending on UI version).
  5. Use a filter query defining what you want to be alerted on. For example, to catch sensitive API calls: Example query:
    Or to alert on any ERROR:
  6. Run the query and verify it returns the events you care about.

  1. With the query loaded and validated, look for Create Alert or Save as Alert (typically near the search bar).
  2. Click Create Alert (wording may be “Create” → “Alert Rule” or similar).
Configure the alert:
  1. Name: e.g. High-Risk Audit API Calls Alert.
  2. Description: e.g. Triggers when destructive or high-risk Audit events happen.
  3. Compartment: choose where you manage security/ops resources.
  4. Query: your tested logging query should already be populated.
  5. Schedule:
    • Choose how frequently to run (e.g. Every 5 minutes or Every 15 minutes).
  6. Trigger condition:
    • Example: “Trigger when count of matches > 0”.
  7. Notifications:
    • Select Notifications Topic and choose the topic you created: audit-alerts-topic.
  8. Save / Create the alert.

5. Test the Alert

  1. Perform a non-destructive test action that will generate a relevant Audit event (e.g. modify a test resource’s tag, or create/delete a small, non-critical resource, depending on your query).
  2. Wait for the schedule interval (e.g. 5–15 minutes).
  3. Confirm that:
    • The event shows up under Logging → Audit log search.
    • A notification email (or other protocol) is received.

6. Operationalize & Tune

  • Refine queries to:
    • Include only critical services / compartments.
    • Exclude known-noisy operations.
  • Create multiple alerts for different severities, e.g.:
    • Critical destructive actions.
    • IAM/Policy changes (data.eventSource = "identity").
    • Unexpected regions or compartments.
With this in place, your OCI Audit Logging is actively monitored via OCI Logging, scheduled searches, and Notifications, all configured from the OCI Console.
Below is a minimal, step‑by‑step way to ensure OCI Audit logs are actively monitored using OCI CLI:
  • enable (or confirm) Audit logs are going into OCI Logging
  • create a metric‑based alarm on those logs with OCI Monitoring
Replace all ... placeholders (compartment OCIDs, regions, etc.) with your values.

1. Prerequisites

Make sure:
  • OCI CLI is configured:
  • You know:
    • Tenancy OCID: ocid1.tenancy.oc1..xxxxx
    • Compartment OCID for security/logging: ocid1.compartment.oc1..xxxxx
    • Region: e.g., us-ashburn-1
You can set region at CLI level (recommended):

2. Ensure OCI Audit is sending logs to OCI Logging

OCI Audit is always on, but you must create a service log for audit in Logging so you can monitor it.

2.1 Create (or identify) a Log Group for Audit

Save the returned "id" as LOG_GROUP_OCID.
Example:
(If you already have a log group, you can list and pick one:)

2.2 Create a service log for Audit

Save "id" as AUDIT_LOG_OCID (optional for later reference).

3. Create a Monitoring Alarm for Audit Logs

Typical security control: alert if no audit events occur for a certain period (e.g., 1 hour) in a tenancy or key compartment.OCI exposes metrics for logs in namespace oci_logging. When you enabled the service log, you can now build alarms on those metrics.

3.1 Decide on alarm behavior

Example:
  • Trigger if no audit log entries are written for 1 hour.
  • Evaluation period: 1h
  • Severity: CRITICAL
  • Destination: an ONS topic (email/SNS endpoint).
First, make (or reuse) an ONS topic:
Save "topic-id" as TOPIC_OCID.Then subscribe your email (one time only):
Confirm the subscription from your email.

3.2 Create the alarm

We’ll use the Logging metrics to detect when the Audit service log is completely quiet. Metric name examples: LogsVolume, LogsCount.
Below is a generic example using LogsCount — adjust as needed if your tenancy uses different metric names or dimensions.
Alarm logic: if LogsCount for our Audit log group in the last hour is 0, raise an alarm.
Notes:
  • namespace "oci_logging" is used for Logging metrics.
  • The exact metric name and dimensions (LogsCount, logGroupId) may vary; if necessary, list available metrics:
Update the alarm query if your metrics differ (for example, filter by resourceDisplayName = "audit-service-log" or by sourceService = "audit" if that dimension exists).

4. (Optional) Alarm for high audit volume

You can also detect abnormal spikes (possible attack / misconfiguration). For example, alert if audit events > 10,000 in 5 minutes:

5. Verification

  1. List alarms:
  2. Check their state:
  3. Confirm you receive email from the ONS topic when alarm triggers (you can temporarily lower thresholds or query values to force a test).

If you share the output of oci monitoring metric list --namespace oci_logging I can give you an exact --query-text tailored to your environment.
Below is one straightforward way to “actively monitor” the OCI Audit Logging service using Python:
  • use the OCI Python SDK
  • create an ONS notification topic and subscription
  • create a Monitoring Alarm on Audit metrics (namespace oci_audit)
That satisfies common “actively monitored” requirements for security/compliance.

0. Prerequisites

  1. Install OCI SDK:
  2. Configure ~/.oci/config (or use instance principals) with:
    • tenancy
    • user
    • fingerprint
    • key_file
    • region
    • profile name (e.g., DEFAULT)

1. Create a Notification Topic and Subscription (Email) via Python


2. Create an Alarm on Audit Metrics via Python

You can monitor the Audit service using the metric namespace oci_audit.
Example: fire an alarm if the number of audit events suddenly spikes beyond a threshold.
Below example:
  • Metric namespace: oci_audit
  • Metric: audit.events.count
  • Condition: sum(audit.events.count) > 100 over a 5-minute window
    (Tune this threshold to your environment.)
  • Sends notifications to the ONS topic created above.

3. Optional: Alarm for “No Audit Logs Seen”

To detect if the Audit service stops emitting events (e.g., misconfiguration, region issue), you can create an alarm on absence of data by using comparison to 0 with evaluate_missing_data = "EVALUATE_AS_ZERO" and a condition like:

4. Validate

  1. In OCI Console:
    • Go to Monitoring → Alarms
    • Verify the alarms exist and are enabled.
  2. In Notifications:
    • Confirm subscription is CONFIRMED.
  3. Generate audit activity (e.g., create/delete small test resources) and ensure:
    • Audit metrics update (Monitoring → Metrics → oci_audit)
    • Alarms fire when thresholds are crossed and email is received.
This configuration uses Python to put Monitoring and Notifications around the OCI Audit Logging service, which is typically what “OCI Logging Audit Service should be actively monitored” requires.
Substitute:
  • OCID_OF_TENANCY_OR_TARGET_COMPARTMENT with the OCID where you want Audit logs configured (typically the tenancy/root compartment).
This change updates the existing configuration in place and does not force resource replacement.Verification: terraform plan should show is_enabled changing from false (or unset) to true on oci_logging_audit_configuration.audit_monitoring.