OCI Monitoring Should Have Anomalous Multi-AD Activity Alarm Configured

Using Console

Below are step‑by‑step instructions to configure an “Anomalous Multi‑AD Activity” alarm in OCI Monitoring using the Console. Because metric names can differ slightly between tenancies / regions, I’ll show you how to find the right metric and then build the alarm on it.

1. Confirm the Compartment and Region

In the OCI Console, top-right, select the Region where you want to monitor activity.
In the left compartment selector, choose the compartment where the audit / security metrics are emitted (commonly the root compartment if you’re looking at tenancy-wide activity).

2. Open Monitoring and Locate the Metric

In the left menu, go to:
Observability & Management → Monitoring → Metrics Explorer.
In Metrics Explorer:
- Compartment: choose the compartment where you expect the metric.
- Namespace: look for a namespace related to security/audit. Typical candidates:
  - oci_audit
  - oci_cloud_guard
  - oci_identity
- Once a namespace is selected, open the Metric name dropdown and look for a metric whose name or description indicates “anomalous” or “multi-AD”/“multi-availability-domain” activity. Examples you may see (will vary per tenancy):
  - anomalous_multi_ad_activity
  - anomalous_activity_count
If you find a candidate metric:
- Add it to the chart and confirm it has data points when suspicious / test activity is generated.
- Note:
  - Metric name
  - Namespace
  - Any dimensions (e.g., region, availabilityDomain, resourceId).

If you don’t immediately see the metric:

Make sure Time range is large (e.g., Last 24 hours or 7 days).
Try another compartment and/or namespace.
If your organization uses Cloud Guard, check namespace oci_cloud_guard for a metric that tracks the count of detector findings related to anomalous multi‑AD activity.

3. Create the Alarm

Once you have located the correct metric:

In the left menu, go to:
Observability & Management → Monitoring → Alarms.
Click Create alarm.

3.1. Basic Alarm Details

Alarm name:
Anomalous-Multi-AD-Activity-Alarm
Alarm severity: e.g., Critical or High.
Compartment: same compartment where the metric lives.

4. Define the Alarm Query (MQL or Basic UI)

You can use either the visual builder or MQL.

Option A – Visual (if available)

Metric namespace: select the namespace you identified (e.g., oci_audit or oci_cloud_guard).
Metric name: select the anomalous multi‑AD metric (e.g., anomalous_multi_ad_activity).
Dimensions:
- Optionally group by region or availabilityDomain if you want to see per-AD triggers.
Statistic: usually sum over interval.
Interval: 5 minutes (or as required by your policy).
Trigger rule:
- Condition: greater than
- Threshold: 0
- Meaning: alarm fires whenever any anomalous multi‑AD activity is detected in the evaluation period.

Option B – MQL Example

If you use MQL, a typical pattern is:

SUM(metric[<namespace>, <metric_name>]) > 0

For example (adjust to your environment):

SUM(metric[oci_audit, anomalous_multi_ad_activity]) > 0

Or, if in Cloud Guard:

SUM(metric[oci_cloud_guard, anomalous_activity_count]{category = "multi-ad"}) > 0

Adjust the namespace, metric name, and dimensions to match what you saw in Metrics Explorer.

5. Set Evaluation and Trigger Behavior

Evaluation period: e.g., 5 minutes.
Trigger delay (optional): e.g., 1–2 evaluation periods if you want to avoid transient spikes.
Trigger when: keep the default (e.g., “Any time the condition is met”).

6. Configure Notifications

If a Notification Topic doesn’t exist yet:

In another tab:
Application Integration → Notifications → Topics → Create Topic, e.g., Security-Alerts.
Under the topic, Create Subscription:
- Protocol: EMAIL, HTTPS, or PagerDuty, etc.
- Endpoint: your security/SOC distribution list, webhook, etc.
Confirm the subscription (click the confirmation link if using email).

Then, back in the alarm creation wizard:

Under Notifications:
- Select Notifications service topic.
- Choose the topic you created (e.g., Security-Alerts).
Optional: Add Destinations like OCI Functions or PagerDuty if you need automated response.

7. Save and Test the Alarm

Click Create alarm.
In the Alarms list, ensure status is Enabled.
Test:
- If feasible, trigger a test anomalous multi‑AD activity (per your org’s procedure), or temporarily lower the threshold to >= 0 and check if existing datapoints cause the alarm to fire.
- Verify that a notification is delivered to your configured channel.

8. Lock Down and Document

Apply IAM policies so only security/operations roles can edit or disable this alarm.
Document:
- Namespace, metric name, and query.
- Threshold, evaluation periods, and recipients.
- Expected response playbook when the alarm fires.

If you can paste a screenshot of Metrics Explorer (namespace + metric list), I can give you an exact MQL expression and precise field values for your tenancy.

Using CLI

Below is a minimal, end‑to‑end way to meet the “OCI Monitoring Should Have Anomalous Multi‑AD Activity Alarm Configured” requirement using the OCI CLI. Since Monitoring only works on metrics (not raw logs), the flow is:Audit Logs → Service Connector → Custom Metric → AlarmAdjust names/queries to match your environment.

1. Prerequisites

Install & configure OCI CLI:

oci setup config

Note the following IDs:

Tenancy OCID
Root (or security) compartment OCID
Region
User OCID (for auth profile)

Set default region if needed:

oci configure set region <region>

2. Create a Notifications Topic and Subscription

The alarm needs a destination (Notifications).

# 2.1 Create topic
oci ons topic create \
  --name "security-anomalies-topic" \
  --compartment-id "<COMPARTMENT_OCID>" \
  --description "Security anomalies / multi-AD activity alerts"

# Capture the topic OCID from the output, or:
TOPIC_OCID=$(oci ons topic list \
  --compartment-id "<COMPARTMENT_OCID>" \
  --query "data[?name=='security-anomalies-topic'].id | [0]" \
  --raw-output)

# 2.2 Create an email subscription
oci ons subscription create \
  --topic-id "$TOPIC_OCID" \
  --protocol "EMAIL" \
  --endpoint "security-team@example.com"

Confirm the subscription by clicking the email link.

3. Route Audit Logs to a Custom Metric (Multi‑AD Activity)

You generally:

Send Audit logs to a Log Group.
Use a Service Connector to transform/filter “multi‑AD‑related” events into a custom metric (e.g., multi_ad_activity_count in namespace security).

If you already have a custom metric for multi‑AD anomalies, skip to step 4 and just use that metric in the alarm query.

3.1 Create a Log Group (if not exists)

oci logging log-group create \
  --compartment-id "<COMPARTMENT_OCID>" \
  --display-name "audit-log-group" \
  --description "Audit log group for security monitoring"

Capture:

LOG_GROUP_OCID=$(oci logging log-group list \
  --compartment-id "<COMPARTMENT_OCID>" \
  --query "data[?\"display-name\"=='audit-log-group'].id | [0]" \
  --raw-output)

3.2 Enable Audit Log into that Log Group

oci logging log create \
  --log-group-id "$LOG_GROUP_OCID" \
  --display-name "audit-log" \
  --log-type "SERVICE" \
  --configuration '{"source":{"category":"audit","resource":"tenancy","service":"audit"}}'

3.3 Create Service Connector → Custom Metric

This is where you define what counts as “anomalous multi‑AD activity”. A simple example:

Count Audit events where the same principal calls OCI APIs in more than one AD within a short period, or
Count any security‑relevant events across multiple ADs for a protected workload.

For CLI, create a Service Connector that:

source: Logging (the Audit log)
target: Monitoring
custom metric namespace: security
metric name: multi_ad_activity_count

Example (basic skeleton; refine filters/fields as needed):

oci sch service-connector create \
  --display-name "audit-multi-ad-metric-connector" \
  --compartment-id "<COMPARTMENT_OCID>" \
  --source '{"kind":"logging","logSources":[{"logGroupId":"'"$LOG_GROUP_OCID"'","logId":"*"}]}' \
  --target '{
     "kind": "monitoring",
     "metricNamespace": "security",
     "metric": "multi_ad_activity_count",
     "batchSizeInKbs": 64,
     "batchTimeInSeconds": 60
  }' \
  --description "Convert audit multi-AD anomalies into custom metrics" \
  --is-enabled true

In practice, you’d add a taskConfiguration JSON with filters/field mapping to only emit metrics when your multi‑AD anomaly pattern is matched (this is specific to your policy and is usually easier via Console; once defined there, you can oci sch service-connector get to see the JSON and re‑apply in code).Once this is running, confirm the metric exists:

oci monitoring metric-summary list-metrics \
  --compartment-id "<COMPARTMENT_OCID>" \
  --namespace "security" \
  --name "multi_ad_activity_count"

4. Create the Alarm for Anomalous Multi‑AD Activity

Assuming your Service Connector emits a metric:

Namespace: security
Metric: multi_ad_activity_count
Dimension(s): e.g., principalName, availabilityDomain

A simple alarm that fires if any multi‑AD anomaly is detected in the last 5 minutes:

oci monitoring alarm create \
  --compartment-id "<COMPARTMENT_OCID>" \
  --display-name "Anomalous Multi-AD Activity Alarm" \
  --is-enabled true \
  --severity "CRITICAL" \
  --body "Anomalous multi-AD activity detected from audit logs (see security team runbook)." \
  --metric-compartment-id "<COMPARTMENT_OCID>" \
  --namespace "security" \
  --query-text "multi_ad_activity_count[5m].sum() > 0" \
  --destinations "[\"$TOPIC_OCID\"]" \
  --pending-duration "PT5M" \
  --repeat-notification-duration "PT30M"

Notes:

Adjust [5m] window, threshold (> 0), severity, and repetition interval to your policy.
pending-duration controls how long the condition must hold before firing.

5. Validate

List the alarm:

oci monitoring alarm list \
  --compartment-id "<COMPARTMENT_OCID>" \
  --query "data[?\"display-name\"=='Anomalous Multi-AD Activity Alarm']"

Force / simulate a multi‑AD anomaly (or temporarily lower threshold) and confirm:
- Metric is visible in Monitoring.
- Alarm state changes to FIRING.
- Email is received via Notifications.

If you share how you’re currently detecting “multi‑AD” in the logs (e.g., specific event fields or queries), I can give you an exact Service Connector task configuration JSON and a more precise query-text for the alarm.

Using Python

Below is a minimal, practical way to remediate this by creating an OCI Monitoring Alarm via Python that detects anomalous multi‑AD activity (e.g., unusual cross‑AD compute instance activity). Adapt metric/query to your exact use case.

1. Prerequisites

Install the OCI Python SDK:

pip install oci

Have an OCI config file (usually ~/.oci/config) with:

Tenancy OCID
User OCID
Fingerprint
Private key path
Region

Example:

[DEFAULT]
user=ocid1.user.oc1..aaaa...
fingerprint=12:34:56:...
key_file=/path/to/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..aaaa...
region=us-ashburn-1

IAM policy on the target compartment (or tenancy) to allow the user/principal to create alarms:

Allow group <group-name> to manage alarms in compartment <compartment-name>

2. Decide on the Metric & Query (Multi‑AD “Anomalous” Activity)

You need to define what “anomalous multi‑AD activity” means in your environment. Common patterns:

Compute example: Detect unusually high count of InstanceLaunched events across multiple ADs in a short window.
If you are exporting such events as custom metrics, a possible Monitoring Query Language (MQL) example:

my_namespace.my_multi_ad_activity_metric[1m].grouping(ad).sum() > 10

Where:

my_namespace = your metric namespace
my_multi_ad_activity_metric = metric you emit whenever cross‑AD activity is seen
> 10 = threshold for “anomalous”

You can plug any metric/MQL you already have for cross‑AD activity into the alarm definition.

3. Python Code to Create the Alarm

Replace:

compartment_ocid – target compartment for the alarm
metric_compartment_ocid – where the metric lives (often same as compartment_ocid)
metric_query – your actual MQL query implementing “anomalous multi‑AD activity”
notification_topic_ocid – OCID of an OCI Notifications topic to send alarm notifications

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

# -----------------------------
# 1. Load config & create client
# -----------------------------
config = oci.config.from_file("~/.oci/config", "DEFAULT")
monitoring_client = MonitoringClient(config)

# -----------------------------
# 2. Basic parameters
# -----------------------------
compartment_ocid = "ocid1.compartment.oc1..xxxx"       # Alarm's compartment
metric_compartment_ocid = "ocid1.compartment.oc1..xxxx"  # Where metrics live
notification_topic_ocid = "ocid1.onstopic.oc1..xxxx"

# Example query – replace with your own metric/MQL
metric_query = (
    # Example: custom metric indicating multi-AD events
    # Trigger if sum across ADs in last 5 minutes is > 10
    "my_namespace.my_multi_ad_activity_metric[5m].grouping(ad).sum() > 10"
)

# -----------------------------
# 3. Define the alarm
# -----------------------------
alarm_details = CreateAlarmDetails(
    display_name="Anomalous Multi-AD Activity Alarm",
    compartment_id=compartment_ocid,
    metric_compartment_id=metric_compartment_ocid,
    namespace="my_namespace",  # must match your metric's namespace
    query=metric_query,
    severity="CRITICAL",        # INFO | WARNING | ERROR | CRITICAL
    destinations=[notification_topic_ocid],
    is_enabled=True,
    pending_duration="PT5M",    # condition must hold for 5 minutes
    body="Anomalous multi-AD activity detected.",
    message_format="SMS",       # or "JSON", "ONS_OPTIMIZED"
    resolution="PT5M",          # how often the alarm re-evaluates
)

# -----------------------------
# 4. Create the alarm
# -----------------------------
response = monitoring_client.create_alarm(alarm_details)
print("Alarm created with OCID:", response.data.id)

4. Verification Steps

In OCI Console:
- Go to Observability & Management → Monitoring → Alarms
- Locate the alarm by its Display Name.
- Confirm:
  - Status: Enabled
  - Compartment & Namespace: Correct
  - Query: Matches your intended multi‑AD anomaly rule
  - Destinations: Correct Notifications topic
Generate test activity (or send test custom metrics) that should trigger the rule to verify notifications.

If you share:

The exact metric namespace/name you use for multi‑AD activity
Your definition of “anomalous” (rate, count, etc.)

I can give you a precise metric_query line tailored to your case.

Using Terraform

resource "oci_monitoring_alarm" "anomalous_multi_ad_activity" {
  # Replace with your tenancy/compartment OCID where the resources live
  compartment_id        = "OCID_OF_TARGET_COMPARTMENT"
  metric_compartment_id = "OCID_OF_TARGET_COMPARTMENT"

  display_name   = "anomalous-multi-ad-activity"
  is_enabled     = true
  severity       = "CRITICAL"
  namespace      = "oci_computeagent" # Replace if you use a different namespace for your metric
  resource_group = null               # Or set to your resource group if used

  # Build a Monitoring query that:
  # - counts deployments per availabilityDomain
  # - compares against your expected ADs / threshold for “unusual” activity
  #
  # Example placeholder – REPLACE the whole string with your actual query:
  #   METRIC_NAME[1m].groupBy(availabilityDomain).max() > THRESHOLD
  #
  # For example, if you expose a custom metric "multiAdDeployments" where
  # value = number of deployments in previously unused ADs, and you want
  # to alert when this exceeds 0:
  #   "multiAdDeployments[5m].max() > 0"
  query = "METRIC_QUERY_FOR_MULTI_AD_ACTIVITY"

  # How often the alarm is evaluated
  resolution     = "1m"
  pending_duration = "PT5M" # alarm must be in ALARM state for 5 minutes before firing

  # Notification destination (use an existing Notifications topic)
  destinations = [
    "OCID_OF_ONS_TOPIC_FOR_ALERTS"
  ]

  # Optional: human-readable info
  body           = "Alert when anomalous multi-AD activity (deployments in unusual Availability Domains) is detected."
  message_format = "ONS_OPTIMIZED"

  # Optional: suppress notifications during maintenance windows
  is_suppressed = false

  # Optional tags
  freeform_tags = {
    "OWNER" = "TEAM_NAME"
  }
}

This change is an in-place addition/update of the oci_monitoring_alarm resource and does not force replacement of other OCI resources.For verification, terraform plan should show one oci_monitoring_alarm.anomalous_multi_ad_activity to be created (or updated if it already exists) with the query matching your finalized anomalous multi-AD activity condition and the intended destinations and severity.

OCI Misconfigurations

OCI Monitoring Should Have Anomalous Multi-AD Activity Alarm Configured

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Confirm the Compartment and Region

2. Open Monitoring and Locate the Metric

3. Create the Alarm

3.1. Basic Alarm Details

4. Define the Alarm Query (MQL or Basic UI)

Option A – Visual (if available)

Option B – MQL Example

5. Set Evaluation and Trigger Behavior

6. Configure Notifications

7. Save and Test the Alarm

8. Lock Down and Document

1. Prerequisites

2. Create a Notifications Topic and Subscription

3. Route Audit Logs to a Custom Metric (Multi‑AD Activity)

3.1 Create a Log Group (if not exists)

3.2 Enable Audit Log into that Log Group

3.3 Create Service Connector → Custom Metric

4. Create the Alarm for Anomalous Multi‑AD Activity

5. Validate

1. Prerequisites

2. Decide on the Metric & Query (Multi‑AD “Anomalous” Activity)

3. Python Code to Create the Alarm

4. Verification Steps

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​1. Confirm the Compartment and Region

​2. Open Monitoring and Locate the Metric

​3. Create the Alarm

​3.1. Basic Alarm Details

​4. Define the Alarm Query (MQL or Basic UI)

​Option A – Visual (if available)

​Option B – MQL Example

​5. Set Evaluation and Trigger Behavior

​6. Configure Notifications

​7. Save and Test the Alarm

​8. Lock Down and Document

​1. Prerequisites

​2. Create a Notifications Topic and Subscription

​3. Route Audit Logs to a Custom Metric (Multi‑AD Activity)

​3.1 Create a Log Group (if not exists)

​3.2 Enable Audit Log into that Log Group

​3.3 Create Service Connector → Custom Metric

​4. Create the Alarm for Anomalous Multi‑AD Activity

​5. Validate

​1. Prerequisites

​2. Decide on the Metric & Query (Multi‑AD “Anomalous” Activity)

​3. Python Code to Create the Alarm

​4. Verification Steps

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Confirm the Compartment and Region

2. Open Monitoring and Locate the Metric

3. Create the Alarm

3.1. Basic Alarm Details

4. Define the Alarm Query (MQL or Basic UI)

Option A – Visual (if available)

Option B – MQL Example

5. Set Evaluation and Trigger Behavior

6. Configure Notifications

7. Save and Test the Alarm

8. Lock Down and Document

1. Prerequisites

2. Create a Notifications Topic and Subscription

3. Route Audit Logs to a Custom Metric (Multi‑AD Activity)

3.1 Create a Log Group (if not exists)

3.2 Enable Audit Log into that Log Group

3.3 Create Service Connector → Custom Metric

4. Create the Alarm for Anomalous Multi‑AD Activity

5. Validate

1. Prerequisites

2. Decide on the Metric & Query (Multi‑AD “Anomalous” Activity)

3. Python Code to Create the Alarm

4. Verification Steps