> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # OCI Monitoring Should Have Anomalous Multi-AD Activity Alarm Configured ### More Info: Monitor for deployments across unusual Availability Domains. Attackers often deploy infrastructure in previously unused regions or ADs to evade detection by standard operational dashboards ### 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 Critical Security Controls v8 * CMMC 2.0 * CSA Cloud Controls Matrix v4 * DPDPA * Digital Operational Resilience Act (EU) * ISO/IEC 27017 * ISO/IEC 27018 * ISO/IEC 27701 * KSA PDPL * MAS Technology Risk Management (Singapore) * MITRE ATT\&CK (Cloud) * NIS2 Directive * NIST SP 800-171 * NYDFS 23 NYCRR 500 * SWIFT Customer Security Controls Framework * Sarbanes-Oxley IT General Controls * UK NCSC Cyber Assessment Framework ### Triage and Remediation ### Remediation 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 1. In the OCI Console, top-right, select the **Region** where you want to monitor activity. 2. 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 1. In the left menu, go to:\ **Observability & Management → Monitoring → Metrics Explorer**. 2. 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` 3. 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: 1. In the left menu, go to:\ **Observability & Management → Monitoring → Alarms**. 2. Click **Create alarm**. ### 3.1. Basic Alarm Details 1. **Alarm name**:\ `Anomalous-Multi-AD-Activity-Alarm` 2. **Alarm severity**: e.g., **Critical** or **High**. 3. **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) 1. **Metric namespace**: select the namespace you identified (e.g., `oci_audit` or `oci_cloud_guard`). 2. **Metric name**: select the anomalous multi‑AD metric (e.g., `anomalous_multi_ad_activity`). 3. **Dimensions**: * Optionally **group** by `region` or `availabilityDomain` if you want to see per-AD triggers. 4. **Statistic**: usually `sum` over interval. 5. **Interval**: `5 minutes` (or as required by your policy). 6. **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: ```text theme={null} SUM(metric[, ]) > 0 ``` For example (adjust to your environment): ```text theme={null} SUM(metric[oci_audit, anomalous_multi_ad_activity]) > 0 ``` Or, if in Cloud Guard: ```text theme={null} 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 1. **Evaluation period**: e.g., **5 minutes**. 2. **Trigger delay** (optional): e.g., 1–2 evaluation periods if you want to avoid transient spikes. 3. **Trigger when**: keep the default (e.g., “Any time the condition is met”). *** ## 6. Configure Notifications If a Notification Topic doesn’t exist yet: 1. In another tab:\ **Application Integration → Notifications → Topics → Create Topic**, e.g., `Security-Alerts`. 2. Under the topic, **Create Subscription**: * Protocol: `EMAIL`, `HTTPS`, or `PagerDuty`, etc. * Endpoint: your security/SOC distribution list, webhook, etc. 3. Confirm the subscription (click the confirmation link if using email). Then, back in the alarm creation wizard: 1. Under **Notifications**: * Select **Notifications service topic**. * Choose the topic you created (e.g., `Security-Alerts`). 2. Optional: Add **Destinations** like OCI Functions or PagerDuty if you need automated response. *** ## 7. Save and Test the Alarm 1. Click **Create alarm**. 2. In the **Alarms** list, ensure status is **Enabled**. 3. 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 1. Apply **IAM policies** so only security/operations roles can edit or disable this alarm. 2. 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. 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 → Alarm Adjust names/queries to match your environment. *** ## 1. Prerequisites 1. Install & configure OCI CLI: ```bash theme={null} oci setup config ``` 2. Note the following IDs: * Tenancy OCID * Root (or security) compartment OCID * Region * User OCID (for auth profile) Set default region if needed: ```bash theme={null} oci configure set region ``` *** ## 2. Create a Notifications Topic and Subscription The alarm needs a destination (Notifications). ```bash theme={null} # 2.1 Create topic oci ons topic create \ --name "security-anomalies-topic" \ --compartment-id "" \ --description "Security anomalies / multi-AD activity alerts" # Capture the topic OCID from the output, or: TOPIC_OCID=$(oci ons topic list \ --compartment-id "" \ --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: 1. Send Audit logs to a Log Group. 2. 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) ```bash theme={null} oci logging log-group create \ --compartment-id "" \ --display-name "audit-log-group" \ --description "Audit log group for security monitoring" ``` Capture: ```bash theme={null} LOG_GROUP_OCID=$(oci logging log-group list \ --compartment-id "" \ --query "data[?\"display-name\"=='audit-log-group'].id | [0]" \ --raw-output) ``` ### 3.2 Enable Audit Log into that Log Group ```bash theme={null} 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): ```bash theme={null} oci sch service-connector create \ --display-name "audit-multi-ad-metric-connector" \ --compartment-id "" \ --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: ```bash theme={null} oci monitoring metric-summary list-metrics \ --compartment-id "" \ --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: ```bash theme={null} oci monitoring alarm create \ --compartment-id "" \ --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 "" \ --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 1. List the alarm: ```bash theme={null} oci monitoring alarm list \ --compartment-id "" \ --query "data[?\"display-name\"=='Anomalous Multi-AD Activity Alarm']" ``` 2. 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. 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 1. Install the OCI Python SDK: ```bash theme={null} pip install oci ``` 2. Have an OCI config file (usually `~/.oci/config`) with: * Tenancy OCID * User OCID * Fingerprint * Private key path * Region Example: ```ini theme={null} [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 ``` 3. IAM policy on the target compartment (or tenancy) to allow the user/principal to create alarms: ```text theme={null} Allow group to manage alarms in compartment ``` *** ## 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: ```text theme={null} 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 ```python theme={null} 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 1. 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 2. 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. ```hcl theme={null} 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`.