> ## 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 Impossible Travel Detection Alarm Configured ### More Info: Detect impossible travel logons. Logins originating from two geographically distant IP addresses within an impossibly short timeframe are a near-certain indicator of compromised credentials. ### Risk Level Critical ### 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 * HIPAA * ISO 27001 * 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 * SWIFT Customer Security Controls Framework * Sarbanes-Oxley IT General Controls * UK NCSC Cyber Assessment Framework ### Triage and Remediation ### Remediation Below are step‑by‑step console instructions to implement “impossible travel” alerting in OCI. The most robust/native way is by using **Cloud Guard** (which then uses Notifications for alerting). OCI Monitoring Alarms are metric‑based, so “impossible travel” (a log pattern) is normally implemented via Cloud Guard rather than a direct Monitoring metric. *** ## Option 1 – Using Cloud Guard (recommended, native “impossible travel” detector) ### 1. Enable Cloud Guard (if not already) 1. Sign in to the **OCI Console**. 2. From the left hamburger menu, go to **Security & Identity → Cloud Guard**. 3. If Cloud Guard is not enabled: * Click **Enable Cloud Guard**. * Choose your **home region**, **target compartments** (start with root if you need org‑wide), and **configuration**. * Click **Enable**. ### 2. Ensure Audit logging is active Cloud Guard’s “Impossible Travel” detector uses **Audit logs**. 1. Go to **Identity & Security → Audit**. 2. Confirm **Audit** is enabled for the tenancy (it usually is by default). 3. Ensure the compartments where identities are used are covered (root compartment covers all). ### 3. Configure the “Impossible Travel” detector 1. Go to **Security & Identity → Cloud Guard → Detector Recipes**. 2. Under **Oracle‑Managed Detector Recipes**, find something like: * **Activity Detector Recipe** (or “OCI Activity Detector Recipe” – name varies slightly by region/version). 3. Click the recipe name to open it. 4. In the list of detectors, locate: * **Impossible travel activity** (or similar; e.g., “ACTIVITY\_IMPOSSIBLE\_TRAVEL”). 5. Click the **… (Actions)** next to it and choose **View details** to confirm behavior. 6. To customize: * Click **Create Target‑Specific Recipe** or **Clone** (depending on your UI). * Name it (e.g., `Custom-Activity-Detector-Recipe`). * Ensure the **Impossible travel activity** detector is **Enabled**. * Set the **Risk level** (e.g., High) according to your policy. * Save the custom recipe. ### 4. Attach the detector recipe to your Cloud Guard target 1. Go to **Cloud Guard → Targets**. 2. If you don’t have a target yet, click **Create target**: * Target type: **Compartment** (often root compartment). * Attach your **Custom Activity Detector Recipe**. 3. If you already have a target: * Click the target. * Under **Detector Recipes**, click **Attach recipe** (or **Edit**). * Attach your custom detector recipe with **Impossible travel activity** enabled. 4. Save the target configuration. ### 5. Configure alerting via Notifications Cloud Guard findings can generate alerts through **Notifications**. 1. Go to **Cloud Guard → Responder Recipes** (or use the default, cloned if necessary). 2. In your chosen **Responder Recipe**, ensure there is a responder rule like: * **Send Notification** / **Notify on detector finding** (name may vary). 3. If needed, create or edit a responder rule: * Condition: match detector type or category: * Filter by detector: **Impossible travel activity** or * Filter by Risk Level (e.g., High/Critical) for all detectors, including impossible travel. * Action: **Send Notification**. * Choose or create an **OCI Notifications topic**. 4. Configure the **Notifications topic**: * Go to **Developer Services → Notifications → Topics**. * Open the topic you selected. * Under **Subscriptions**, click **Create subscription**. * Choose protocol: **Email**, **HTTPS**, **PagerDuty**, etc. * Enter the endpoint (e.g., security team email). * Confirm the subscription via the email/endpoint’s confirmation mechanism. From this point, when Cloud Guard detects **impossible travel** events, it creates a **finding** and triggers the responder rule to send a notification (your “alarm”). *** ## Option 2 – Using Monitoring + Logs (only if you must use the Monitoring “Alarms” service) This is less common, but if your policy explicitly requires an **OCI Monitoring Alarm**, you can: 1. **Send Audit logs into Logging** (usually automatic in new tenancies). 2. Use **Service Connector Hub** to: * Source: **Logging** (Audit log group). * Task: **Streaming or Functions** that detect “impossible travel” and emit a **custom metric** (e.g., namespace `security_custom`, metric `impossible_travel_count`). 3. In **Monitoring → Alarms → Create alarm**: * Metric namespace: your custom namespace (e.g., `security_custom`). * Metric name: `impossible_travel_count`. * Define a query: for example, trigger when `impossible_travel_count > 0` in a 5–15 minute window. * Set **Notification** to an OCI Notifications topic and configure email/subscribers. This approach requires you to implement the logic to: * Correlate logins by user and IP, * Geolocate IPs, * Calculate whether sequential logins are physically impossible between timestamps, and then push a metric. In OCI this is typically done via **Functions**, **Streaming**, or **Logging Analytics**, so it’s more complex than using Cloud Guard’s built‑in detector. *** **Summary for most environments:**\ Use **Cloud Guard → Activity detector recipe → “Impossible travel activity”**, attach it to a **target**, and configure **Responder rules + Notifications**. That gives you a reliable “Impossible Travel Detection Alarm” using only the OCI Console. Below are concise, CLI‑focused steps to get “impossible travel” detection enabled and alerting in OCI. This uses **Cloud Guard** (where the “IAM – Impossible Travel Activity Detected” rule lives) plus **Notifications** for alerts. > Replace all placeholder values in `<>` (e.g. ``) with your own. *** ## 1. Prerequisites 1. Install/configure OCI CLI: ```bash theme={null} oci setup config ``` 2. Ensure you’re using a profile with tenancy-level permissions: * `MANAGE cloud-guard-family` on tenancy * `MANAGE ons-family` for Notifications *** ## 2. Enable Cloud Guard at Tenancy Level Check status: ```bash theme={null} oci cloud-guard cloud-guard-configuration get ``` If not `ENABLED`, enable: ```bash theme={null} oci cloud-guard cloud-guard-configuration update \ --status ENABLED ``` *** ## 3. Find the Oracle-Managed Detector Recipe List Oracle-managed activity detector recipes: ```bash theme={null} oci cloud-guard detector-recipe list \ --compartment-id \ --detector RECOVERY \ --all ``` If above returns nothing, also check: ```bash theme={null} oci cloud-guard detector-recipe list \ --compartment-id \ --detector ACTIVITY \ --all ``` Look for a recipe with a display name similar to: * `OCI Activity Detector Recipe` * or `Oracle Managed Activity Detector Recipe` Copy its `id` as ``. *** ## 4. Create a Custom Detector Recipe From the Managed One ```bash theme={null} oci cloud-guard detector-recipe create-detector-recipe \ --compartment-id \ --source-detector-recipe-id \ --display-name "Custom Activity Detector Recipe with Impossible Travel" \ --description "Custom recipe enabling IAM - Impossible Travel Activity Detected" ``` Copy the new recipe OCID as ``. *** ## 5. Enable the “IAM – Impossible Travel Activity Detected” Rule 1. List detector rules in the custom recipe: ```bash theme={null} oci cloud-guard detector-recipe list-detector-rules \ --detector-recipe-id \ --all ``` 2. Find the rule with `displayName` like: * `IAM - Impossible Travel Activity Detected` Copy that rule’s `id` as ``. 3. Enable it and (optionally) set risk/threat level: ```bash theme={null} oci cloud-guard detector-recipe update-detector-rule \ --detector-recipe-id \ --detector-rule-id \ --details '{ "isEnabled": true, "riskLevel": "HIGH", "lifecycleState": "ACTIVE" }' ``` *** ## 6. Create a Cloud Guard Target (Tenancy or Compartment) Most commonly you target the entire tenancy: ```bash theme={null} oci cloud-guard target create \ --compartment-id \ --display-name "Tenancy Target with Impossible Travel Detection" \ --target-resource-type TENANCY \ --target-resource-id \ --target-detector-recipe-ids '[ { "detectorRecipeId": "" } ]' ``` Copy the target OCID as ``. *** ## 7. Configure Notifications for Cloud Guard Problems (Alerts) ### 7.1 Create an OCI Notifications Topic ```bash theme={null} oci ons topic create \ --compartment-id \ --name "cloud-guard-impossible-travel-topic" \ --description "Alerts for IAM impossible travel detections" ``` Copy topic `topic-id` as ``. ### 7.2 Add a Subscription (e.g., Email) ```bash theme={null} oci ons subscription create \ --topic-id \ --protocol EMAIL \ --endpoint ``` Open the confirmation email and confirm the subscription. *** ## 8. Route Cloud Guard Problems to Notifications (Events Rule) Cloud Guard raises “problems” that are emitted via **Events**. Create an Events rule that sends all Cloud Guard problems (or only IAM ones) to the Notifications topic. 1. Create an Events rule: ```bash theme={null} oci events rule create \ --compartment-id \ --display-name "CloudGuard Impossible Travel Alerts" \ --description "Send Cloud Guard impossible travel problems to Notifications" \ --is-enabled true \ --condition '{ "eventType": [ "com.oraclecloud.cloudguard.problemdetected" ], "data": { "additionalDetails": { "detectorRuleName": [ "IAM - Impossible Travel Activity Detected" ] } } }' \ --actions '{ "actions": [ { "actionType": "OSS", "isEnabled": true, "description": "Notify on impossible travel detections", "topicId": "" } ] }' ``` Notes: * If matching on `detectorRuleName` fails (schema differences), you can initially make the rule more general and later narrow it: ```json theme={null} { "eventType": ["com.oraclecloud.cloudguard.problemdetected"] } ``` *** ## 9. (Optional) Verify via CLI List active Cloud Guard problems: ```bash theme={null} oci cloud-guard problem list \ --compartment-id \ --lifecycle-state OPEN \ --all ``` When an “IAM – Impossible Travel Activity Detected” problem is raised, it will match the Events rule and trigger Notifications to your configured email. *** This configuration gives you **impossible travel detection** (Cloud Guard) and **alerting** (Events + Notifications), all managed via **OCI CLI**. Below is a practical way to implement “impossible travel” detection alerting in OCI using Monitoring + Python: High-level approach: * Use Cloud Guard to detect impossible travel as a security problem. * Use OCI Monitoring to create an alarm on Cloud Guard problem metrics. * Use Python (OCI SDK) to create the alarm programmatically. *** ## 1. Prerequisites 1. **Cloud Guard enabled** for the tenancy: * In Console: Security → Cloud Guard → Enable (if not already). * Set Target = Tenancy (or desired compartments). 2. **Cloud Guard detector recipe** for “Impossible Travel” is enabled: * Cloud Guard → Detector Recipes. * Look for an identity/ IAM / activity detector containing “Impossible Travel” (name can vary slightly by region/tenancy). * Ensure it is enabled in the recipe that’s attached to your target. 3. **Notifications topic** (for alert delivery): * Console → Application Integration → Notifications → Create Topic (e.g., `cloudguard-impossible-travel-topic`). * Add Email / PagerDuty / HTTPS subscription as needed. * Get the Topic OCID. 4. **IAM policy** for the principal running the script (user / group / dynamic group): ```text theme={null} allow group SecurityAdmins to read metrics in tenancy allow group SecurityAdmins to manage alarms in tenancy allow group SecurityAdmins to use ons-topics in tenancy ``` Adjust the subject (group name) and scope (compartment / tenancy) as needed. 5. **Python OCI SDK installed and configured**: ```bash theme={null} pip install oci ``` And `~/.oci/config` set up with a profile (e.g., `DEFAULT`). *** ## 2. Metric & Alarm Design Cloud Guard exposes problem metrics under a security-related namespace (varies; commonly `oci_cloud_guard` or similar). A common pattern: * **Namespace:** `oci_cloud_guard` * **Metric Name:** `ProblemsCount` (example – adjust to what exists in your tenancy) * **Dimensions:** * `ProblemType` – includes something like `IAM.ImpossibleTravelActivity` or `ImpossibleTravel`. * `Severity` – e.g., `CRITICAL`, `HIGH`. You can confirm the real metric/dimensions from: * Console → Observability & Management → Metrics Explorer * Namespace: try `oci_cloud_guard` * Look for a metric like `ProblemsCount` * Inspect the dimension values to find the exact `ProblemType` string for impossible travel. Then build an alarm query such as: ```text theme={null} oci_cloud_guard_ProblemsCount[1m]{problemType="IAM.ImpossibleTravelActivity", severity="CRITICAL"}.sum() > 0 ``` Adjust names to what you actually see in Metrics Explorer. *** ## 3. Python Script to Create the Alarm Replace placeholders with your actual values. ```python theme={null} import oci import datetime # ------------------------- # CONFIGURATION # ------------------------- PROFILE_NAME = "DEFAULT" # profile from ~/.oci/config COMPARTMENT_OCID = "ocid1.compartment.oc1..xxxx" NOTIFICATION_TOPIC_OCID = "ocid1.onstopic.oc1..xxxx" # Monitoring metric details NAMESPACE = "oci_cloud_guard" METRIC_NAME = "ProblemsCount" PROBLEM_TYPE_VALUE = "IAM.ImpossibleTravelActivity" # adjust from Metrics Explorer SEVERITY_VALUE = "CRITICAL" # or HIGH / MEDIUM as needed ALARM_NAME = "Impossible Travel Detection Alarm" ALARM_DESCRIPTION = "Triggers when Cloud Guard detects any new impossible travel security problem." # 1-minute window, sum across all occurrences > 0 ALARM_QUERY = ( f"{NAMESPACE}_{METRIC_NAME}[1m]" f'{{problemType="{PROBLEM_TYPE_VALUE}", severity="{SEVERITY_VALUE}"}}.sum() > 0' ) # ------------------------- # INITIALIZE CLIENT # ------------------------- config = oci.config.from_file("~/.oci/config", PROFILE_NAME) monitoring_client = oci.monitoring.MonitoringClient(config) # ------------------------- # CREATE ALARM # ------------------------- create_alarm_details = oci.monitoring.models.CreateAlarmDetails( display_name=ALARM_NAME, compartment_id=COMPARTMENT_OCID, metric_compartment_id=COMPARTMENT_OCID, # often same as above; can be tenancy-level if needed namespace=NAMESPACE, query=ALARM_QUERY, severity="CRITICAL", # Alarm severity (separate from metric severity) is_enabled=True, # When the condition is met, send notification to the topic destinations=[NOTIFICATION_TOPIC_OCID], body=( "Cloud Guard has detected a new Impossible Travel activity. " "Investigate IAM user activity and location anomalies." ), message_format="TEXT", repeat_notification_duration="PT30M", # re-notify every 30 minutes if still in ALARM pending_duration="PT1M", # require 1 minute in breach before ALARM resolution="Investigate user sign-ins, IP addresses, and geo-locations for compromise." ) response = monitoring_client.create_alarm(create_alarm_details) print("Created Alarm OCID:", response.data.id) print("Lifecycle State:", response.data.lifecycle_state) ``` *** ## 4. Validate 1. In Console → Observability & Management → Alarms: * Verify the alarm exists, is `ENABLED`, and query matches your intent. 2. In Metrics Explorer: * Run the same query to ensure metrics are present and the query is valid. 3. Test: * Temporarily lower the threshold (e.g., `>= 0`) or simulate a problem (if possible). * Confirm a notification is sent to your topic subscriber. *** ## 5. Optional: Update Existing Alarm via Python If you need to modify an existing alarm instead of creating a new one: ```python theme={null} alarm_id = "ocid1.alarm.oc1..xxxx" update_details = oci.monitoring.models.UpdateAlarmDetails( query=ALARM_QUERY, is_enabled=True ) response = monitoring_client.update_alarm( alarm_id=alarm_id, update_alarm_details=update_details ) print("Updated Alarm OCID:", response.data.id) ``` *** If you share the exact metric namespace/metric name/dimensions you see in Metrics Explorer, I can refine the query string precisely for your tenancy. ```hcl theme={null} resource "oci_monitoring_alarm" "impossible_travel_logins" { # OCI compartment where the alarm itself lives compartment_id = "OCID_OF_SECURITY_OR_MONITORING_COMPARTMENT" display_name = "Impossible Travel Login Detection" is_enabled = true severity = "CRITICAL" # Where the metric being queried lives (often your root compartment / tenancy) metric_compartment_id = "OCID_OF_COMPARTMENT_WITH_CLOUD_GUARD_METRICS" # Cloud Guard publishes security problem metrics into this namespace namespace = "oci_cloud_guard" # Alarm query to fire on any detected "Impossible Travel" problem # # Replace the detectorRuleId value below with the exact Cloud Guard # detector rule OCID or name used by your tenancy for impossible travel, # if it differs. This example uses the canonical rule name. # # This expression: # - checks every 5 minutes (5m) # - sums the number of problems from the Impossible Travel rule # - fires if > 0 problems are present in that window query = "problems[5m]{detectorRuleName = \"OCI_Activity_Impossible_Travel\"}.sum() > 0" # Notification destinations (e.g., OCI Notifications topic OCID) destinations = [ "OCID_OF_OCI_NOTIFICATIONS_TOPIC_FOR_SECURITY_ALERTS", ] # Optional free‑form text included in the notification body = "OCI Cloud Guard has detected an Impossible Travel login event. Investigate immediately for potential credential compromise." message_format = "JSON" } ``` Changing or adding an `oci_monitoring_alarm` is an in‑place update and does not force replacement of other resources; applies are safe aside from normal alarm behavior (new alerts will start firing under the defined condition). For verification, `terraform plan` should show either: * `+ oci_monitoring_alarm.impossible_travel_logins` being created with the `namespace`, `metric_compartment_id`, and `query` as above, or * an in‑place `~ update in-place` on an existing `oci_monitoring_alarm` resource where only the alarm query / namespace / destinations / text fields change to match this configuration.