OCI Monitoring Should Have Configuration Change Alarm

More Info:

Monitor ConfigurationChange events in the Audit service. Tracking configuration drift ensures that unauthorized modifications to critical infrastructure are reviewed and reverted if necessary

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)
• Essential 8
• HITRUST CSF
• ISO/IEC 27017
• ISO/IEC 27018
• ISO/IEC 27701
• KSA PDPL
• MAS Technology Risk Management (Singapore)
• MITRE ATT&CK (Cloud)
• NIS2 Directive
• NIST CSF
• NIST SP 800-171
• NYDFS 23 NYCRR 500
• SOC2
• SWIFT Customer Security Controls Framework
• Sarbanes-Oxley IT General Controls
• UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Remediation

Using Console

Below are the exact console steps to get alerts when the OCI Monitoring configuration (alarms) changes, using OCI Events + Notifications. This is the supported way to alert on configuration changes; Monitoring alarms themselves are for metric thresholds, not config changes.

---

1. Create (or identify) a Notifications Topic

1. Sign in to the OCI Console.
2. Open the navigation menu → Developer Services → Notifications.
3. Click Topics.
4. Click Create Topic.
   • Name: e.g. monitoring-config-changes-topic
   • Description: e.g. Alerts for Monitoring alarm configuration changes
5. Click Create.

Add a Subscription (e.g., email)

1. On the topic details page, click Create Subscription.
2. Protocol: Email (or HTTPS/Slack/other as per your environment).
3. Email: enter your email.
4. Click Create.
5. Confirm the subscription from the email you receive.

---

2. Create an Event Rule for Monitoring Configuration Changes

1. Open the navigation menu → Observability & Management → Events Service → Rules.

2. Click Create Rule.

3. Fill in:

   • Rule Name: e.g. monitoring-config-change-rule
   • Description: e.g. Triggers when Monitoring alarms are created/updated/deleted
   • State: Enabled
   • Compartment: pick the compartment where your Monitoring alarms live (or a higher-level/root compartment if needed).

4. Under Rule Conditions:

   • In Service, select Monitoring.
   • In Event Type, add the following (at minimum):
     • Alarm - Create
     • Alarm - Update
     • Alarm - Delete
     • (Optionally also: Alarm - Move Compartment, Alarm - Enable, Alarm - Disable, depending on your policy.)

5. Under Actions, click + Add Action:

   • Action Type: Notifications.
   • Topic: select the topic you created earlier (e.g. monitoring-config-changes-topic).

6. Click Create Rule.

---

3. Test the Alert

1. Go to Observability & Management → Monitoring → Alarm Definitions.
2. In the same compartment specified in the rule, create a new alarm or update an existing alarm (e.g., change threshold).
3. Within a short time, you should receive a notification (email or whatever protocol you chose).

---

This configuration satisfies the requirement that OCI Monitoring configuration changes (alarm create/update/delete/etc.) generate alerts, implemented fully via the OCI Console.

Using CLI

In OCI you detect configuration changes with Events + Notifications, not directly with Monitoring metrics.
Below are minimal, CLI‑only steps to create an email alert for configuration changes.

---

0. Prerequisites

Make sure your OCI CLI is configured:

oci iam compartment list

If this works, you’re good.

You will need:

• TENANCY_OCID – your tenancy OCID
• COMPARTMENT_OCID – compartment to watch for changes
• REGION – e.g. us-ashburn-1
• Your email address for notifications

You can export these to avoid repetition:

export TENANCY_OCID="<your-tenancy-ocid>"
export COMPARTMENT_OCID="<your-compartment-ocid>"
export OCI_REGION="<your-region>"

---

1. Create a Notifications Topic

oci ons topic create \
  --compartment-id "$COMPARTMENT_OCID" \
  --name "config-change-alerts-topic" \
  --description "Alerts for OCI configuration changes" \
  --region "$OCI_REGION"

Capture the returned id as TOPIC_OCID:

export TOPIC_OCID="<topic-ocid-from-previous-command>"

---

2. Add an Email Subscription

oci ons subscription create \
  --compartment-id "$COMPARTMENT_OCID" \
  --topic-id "$TOPIC_OCID" \
  --protocol "EMAIL" \
  --endpoint "you@example.com" \
  --region "$OCI_REGION"

Then go to your email and confirm the subscription.

---

3. Create an Events Rule for Configuration Changes

Define the rule condition JSON in a file, e.g. config-change-condition.json.

Example that triggers on any configuration‑changing events (create, update, delete) for common services (compute, network, block volume, IAM, etc.).
Adjust to your needs (add/remove event types).

config-change-condition.json:

{
  "eventType": [
    "com.oraclecloud.computeapi.createinstance.end",
    "com.oraclecloud.computeapi.terminateinstance.end",
    "com.oraclecloud.computeapi.updateinstance.end",
    "com.oraclecloud.networkapi.createvcn.end",
    "com.oraclecloud.networkapi.updatevcn.end",
    "com.oraclecloud.networkapi.deletevcn.end",
    "com.oraclecloud.blockvolumeservice.createvolume.end",
    "com.oraclecloud.blockvolumeservice.deletevolume.end",
    "com.oraclecloud.identity.createuser.end",
    "com.oraclecloud.identity.updateuser.end",
    "com.oraclecloud.identity.deleteuser.end",
    "com.oraclecloud.identity.creategroup.end",
    "com.oraclecloud.identity.updategroup.end",
    "com.oraclecloud.identity.deletegroup.end",
    "com.oraclecloud.identity.createpolicy.end",
    "com.oraclecloud.identity.updatepolicy.end",
    "com.oraclecloud.identity.deletepolicy.end"
  ],
  "data": {
    "compartmentId": [
      "$COMPARTMENT_OCID"
    ]
  }
}

Note: the $COMPARTMENT_OCID will not be expanded inside JSON automatically. Replace it manually or generate the file via cat <<EOF as shown below.

Create the file with environment expansion:

cat > config-change-condition.json <<EOF
{
  "eventType": [
    "com.oraclecloud.computeapi.createinstance.end",
    "com.oraclecloud.computeapi.terminateinstance.end",
    "com.oraclecloud.computeapi.updateinstance.end",
    "com.oraclecloud.networkapi.createvcn.end",
    "com.oraclecloud.networkapi.updatevcn.end",
    "com.oraclecloud.networkapi.deletevcn.end",
    "com.oraclecloud.blockvolumeservice.createvolume.end",
    "com.oraclecloud.blockvolumeservice.deletevolume.end",
    "com.oraclecloud.identity.createuser.end",
    "com.oraclecloud.identity.updateuser.end",
    "com.oraclecloud.identity.deleteuser.end",
    "com.oraclecloud.identity.creategroup.end",
    "com.oraclecloud.identity.updategroup.end",
    "com.oraclecloud.identity.deletegroup.end",
    "com.oraclecloud.identity.createpolicy.end",
    "com.oraclecloud.identity.updatepolicy.end",
    "com.oraclecloud.identity.deletepolicy.end"
  ],
  "data": {
    "compartmentId": [
      "$COMPARTMENT_OCID"
    ]
  }
}
EOF

Now create the Events rule that sends these events to the Notifications topic:

oci events rule create \
  --compartment-id "$TENANCY_OCID" \
  --display-name "config-change-rule" \
  --is-enabled true \
  --condition file://config-change-condition.json \
  --actions '{
    "actions": [
      {
        "actionType": "ONS",
        "isEnabled": true,
        "topicId": "'"$TOPIC_OCID"'"
      }
    ]
  }' \
  --region "$OCI_REGION"

This is the key step that provides “configuration change alerting” for your OCI environment.

---

4. (Optional) Verify by Making a Test Change

For example, update the display name of a test instance or create a small VCN; confirm:

• An event is generated (Audit/Event service)
• You receive an email from Notifications.

---

If you need a pure Monitoring alarm on top of Events (for example, on failures of event delivery), you can then create a Monitoring alarm on the oci_events namespace, but for “configuration change alarms” per CIS‑style requirements, the above Events + Notifications setup is the standard remediation.

Using Python

Below is a concise, step‑by‑step way to remediate “OCI Monitoring Should Have Configuration Change Alarm Configured” using Python and the OCI SDK.

1. Prerequisites

• Python 3 installed
• oci SDK installed:

  pip install oci

• OCI config file at ~/.oci/config (or custom path), with:
  • tenancy OCID
  • user OCID
  • fingerprint
  • private key path
  • region

Assumptions:

• You already know:
  • The compartment OCID where you want this alarm.
  • An OCI Notification topic OCID for sending alarm notifications (SNS‑like).

The alarm will detect configuration‑related API activity using the Audit service logs as a metric.

2. Metric & Alarm Concept

We’ll create an alarm on the Audit logs metric. Example query:

sum(AuditLogs[5m].count()) > 0

This fires when any audited API call (including configuration changes) happens in the compartment during a 5‑minute window.

You can filter further by event type or target if desired (e.g. only for network changes) by using dimensions in the query, but this is the basic pattern.

3. Python Script to Create the Alarm

import oci
from oci.monitoring import MonitoringClient
from oci.monitoring.models import CreateAlarmDetails

# --------------- CONFIGURE THESE VALUES ---------------
# Path to your OCI config file and profile
CONFIG_FILE = "~/.oci/config"
CONFIG_PROFILE = "DEFAULT"

# Compartment where the alarm will live
COMPARTMENT_OCID = "ocid1.compartment.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxx"

# Notification topic to send alarm notifications
NOTIFICATION_TOPIC_OCID = "ocid1.onstopic.oc1..xxxxxxxxxxxxxxxxxxxxxxxx"

# Alarm name and description
ALARM_DISPLAY_NAME = "Configuration Change Alarm"
ALARM_DESCRIPTION = (
    "Alarm for detecting configuration changes via Audit logs "
    "in the specified compartment."
)

# --------------- MAIN LOGIC ---------------
def main():
    # Load config and create Monitoring client
    config = oci.config.from_file(CONFIG_FILE, CONFIG_PROFILE)
    monitoring_client = MonitoringClient(config)

    # Alarm query:
    #   - Use AuditLogs metric from Audit service
    #   - Check last 5 minutes (5m) for any audited API calls
    #   - You can restrict to specific dimension(s) as needed
    alarm_query = "sum(AuditLogs[5m].count()) > 0"

    # Create alarm details
    create_alarm_details = CreateAlarmDetails(
        display_name=ALARM_DISPLAY_NAME,
        compartment_id=COMPARTMENT_OCID,
        is_enabled=True,
        # Alarm query
        query=alarm_query,
        # Metric namespace - Audit logs metrics use this namespace
        namespace="oci_audit",
        # Destination for notifications
        destinations=[NOTIFICATION_TOPIC_OCID],
        severity="CRITICAL",      # Options: CRITICAL, ERROR, WARNING, INFO
        body=ALARM_DESCRIPTION,
        # How often to evaluate (in seconds); 60 = evaluate every minute
        resolution="1m",
        # Optional: repeat notifications while alarm is firing
        is_notifications_per_metric_dimension_enabled=False
    )

    # Create the alarm
    response = monitoring_client.create_alarm(create_alarm_details)
    alarm = response.data

    print("Alarm created:")
    print(f"  OCID: {alarm.id}")
    print(f"  Name: {alarm.display_name}")
    print(f"  Query: {alarm.query}")
    print(f"  Namespace: {alarm.namespace}")
    print(f"  Destinations: {alarm.destinations}")

if __name__ == "__main__":
    main()

4. Optional: Tighten the “Configuration Change” Scope

If your security requirement is only to alert on configuration‑type actions (not all API calls), refine the query with dimensions. For example, to only watch for VCN changes:

sum(AuditLogs[5m]{resourceType = "Vcn"}.count()) > 0

Update the alarm_query string in the script accordingly.

---

This script, once run, will create an OCI Monitoring alarm that alerts (via the provided Notification topic) whenever configuration‑related activity is detected by Audit in the target compartment, fulfilling the “configuration change alarm” requirement.

Using Terraform

# OCI Monitoring alarm for Audit configuration change events
resource "oci_monitoring_alarm" "configuration_change_alarm" {
  compartment_id        = var.MONITORING_COMPARTMENT_OCID          # replace with the compartment OCID where the alarm should live
  display_name          = "Configuration Change Alarm"
  is_enabled            = true

  # Compartment where the Audit metrics are emitted (often the root/tenancy compartment)
  metric_compartment_id = var.AUDIT_COMPARTMENT_OCID               # replace with the compartment OCID that holds Audit metrics

  # Audit service metrics namespace
  namespace             = "oci_audit"

  # Alarm query to detect configuration change events from the Audit service
  # Adjust the comparison / threshold part (> 0) if your policy specifies a different threshold.
  query = "audit.events[1m]{eventType = \"com.oraclecloud.audit.config.change\"}.sum() > 0"

  severity       = "CRITICAL"                                      # adjust if a different severity is required
  message_format = "PRETTY_JSON"

  # One or more Notification Service (ONS) topic OCIDs to receive the alarm
  destinations = [
    oci_ons_notification_topic.configuration_change_topic.id       # replace with or reference your desired Notifications topic
  ]
}

# Example Notifications topic for context (if not already defined elsewhere)
resource "oci_ons_notification_topic" "configuration_change_topic" {
  name          = "configuration-change-topic"
  compartment_id = var.NOTIFICATIONS_COMPARTMENT_OCID              # replace with the compartment OCID for Notifications
}

This change does not force replacement of existing alarms unless you change immutable fields like compartment_id; updating query, is_enabled, or destinations is an in-place update.

To verify, terraform plan should show either a new oci_monitoring_alarm.configuration_change_alarm being created or an existing alarm updated so that its namespace is oci_audit and its query matches the configuration-change condition you require (e.g., audit.events[1m]{eventType = "com.oraclecloud.audit.config.change"}.sum() > 0).