> ## 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 Brute Force Detection Alarm Configured ### More Info: Identify rapid, sustained bursts of IdentityAuthFailure from a single source. Prompt detection of brute force attacks allows automated blocking before credentials can be cracked ### Risk Level High ### 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 is a straightforward way to implement brute‑force detection via **OCI Monitoring + Alarms** using the OCI Console. The idea is: * Use **Audit logs** (failed logins) * Pipe them through a **Service Connector** to a **custom Monitoring metric** * Create an **Alarm** on that metric when failures exceed a threshold in a short time *** ## Prerequisites 1. You have permissions to: * Read Audit logs * Create Service Connectors * Create Metrics in Monitoring * Create Alarms 2. Audit is enabled (it is on by default for all tenancies). *** ## Step 1 – Identify Failed Login Events in Audit 1. In the OCI Console, go to **Observability & Management → Logging → Log Explorer**. 2. In the **Log Group** filter, choose: * **Compartment:** root (or tenancy-level compartment) * **Log Source:** `audit` 3. Use a basic **search filter** to see failed authentication events, for example: ```text theme={null} data.eventName = "Authenticate" AND data.responseCode != "200" ``` or (depending on audit event format): ```text theme={null} data.responseType = "FAILURE" ``` 4. Confirm that you see failed login events (console logins / API auth failures). You’ll reuse this filter (or a refined one) in the Service Connector. *** ## Step 2 – Create a Custom Metric via Service Connector 1. Go to **Observability & Management → Service Connector Hub → Service Connectors**. 2. Click **Create service connector**. 3. **Basic details**: * Name: `brute-force-login-metric-sc` * Compartment: choose appropriate security/operations compartment. 4. **Source**: * Source type: **Logging** * Log group: choose the Audit log group for the tenancy. * Logs: select the **Audit** log. 5. **Filter**: * Use the same filter you tested in Log Explorer, e.g.: ```text theme={null} data.eventName = "Authenticate" AND data.responseCode != "200" ``` 6. **Task**: * Task type: **Logging Analytics / Monitoring** → select **Monitoring (Create custom metric)**. 7. **Metric configuration**: * Namespace: `security_bruteforce` (or another name, but note it). * Metric name: `failed_login_attempts` * Dimensions (examples – key/value from log fields): * `user` → `data.requestPrincipalName` * `source_ip` → `data.clientIP` * `region` → `data.region` * Value: set to `1` (each event = one failed attempt). * Unit: `count`. 8. Leave aggregation default (count or sum). 9. Click **Create**. After a few minutes, failed login events will start to appear as a metric. *** ## Step 3 – Verify the Custom Metric 1. Go to **Observability & Management → Monitoring → Metrics Explorer**. 2. In **Compartment**, select the compartment where the Service Connector writes metrics. 3. In **Metric namespace**, choose `security_bruteforce` (or your chosen namespace). 4. For **Metric**, choose `failed_login_attempts`. 5. Set a time window (e.g., last 1 hour). 6. You should see data points when failures occur. If no data appears, wait a few minutes and then re‑test a failed login (e.g., intentionally try a wrong password once or twice) and re‑check. *** ## Step 4 – Create the Brute Force Detection Alarm 1. Go to **Observability & Management → Monitoring → Alarms**. 2. Click **Create alarm**. 3. **Alarm basic info**: * Name: `Brute-Force Login Detection` * Compartment: same as metric. * Status: Enabled. 4. **Metric selection**: * Metric namespace: `security_bruteforce` * Metric name: `failed_login_attempts` * Statistic: **Sum**. * Interval: e.g., **5 minutes**. * Dimensions: choose how to group: * To detect per user: group by `user` * To detect per IP: group by `source_ip` 5. **Alarm condition** (example): * Operator: `Greater than` * Threshold: `5` * So: `Sum(failed_login_attempts)[5m] > 5`\ → triggers if > 5 failed logins from same user/IP in 5 minutes. 6. **Notifications**: * If you don’t have one, first create a Notification topic: * Go to **Developer Services → Notifications (ONS)**, create topic (e.g., `security-alerts`), and subscribe an email or HTTPS endpoint. * Back in the alarm creation: * Notification destination: pick that **Topic**. 7. **Alarm severity**: * Set to **Critical** or **Error**. 8. (Optional) **Repeat notifications**: enable if you want recurring alerts while condition persists. 9. Click **Create alarm**. *** ## Step 5 – Test the Alarm 1. Intentionally perform several failed logins from the same user or IP to exceed the threshold in the chosen interval. 2. Wait a few minutes: * Confirm in **Metrics Explorer** that `failed_login_attempts` increased. * Confirm in **Alarms** that alarm state goes to **FIRING**. * Check that a notification (email/endpoint) is received. *** ## Operational Tips * Tune threshold and interval to reduce noise (e.g., 5 attempts in 5 minutes vs. 10 in 10 minutes). * You can create **multiple alarms**, e.g.: * One per user dimension * One per source\_ip dimension. * Restrict access to the metrics and alarms to security/ops admins only. If you share your current audit event format (sample JSON), I can give you an exact filter and dimension mapping to use in the Service Connector. Below is one practical way to satisfy “OCI Monitoring should have Brute Force Detection Alarm configured” using OCI Monitoring + Logging, controlled entirely via OCI CLI. Because OCI has no built‑in “Brute Force” metric, the usual pattern is: 1. Use Logging to collect authentication failures (e.g., Identity, IAM, or OS/Auth logs). 2. Use a Service Connector to push those logs into a custom Monitoring metric. 3. Create an OCI Monitoring alarm on that custom metric via OCI CLI. If you already have the custom metric in place, you can skip to **Step 3**. *** ## Prerequisites * OCI CLI installed and configured (`~/.oci/config`). * Tenancy and compartment OCIDs handy. * IAM permissions to: * Read logs * Manage service-connectors * Manage metrics / alarms * Use notification topics (ONS) *** ## Step 1 – (If needed) Route “failed login” logs into a custom metric 1. Identify the log(s) that contain authentication failures\ For example, IDCS or IAM logs in a compartment: ```bash theme={null} oci logging log-group list \ --compartment-id ``` Then: ```bash theme={null} oci logging log list \ --log-group-id ``` 2. Create a Service Connector that: * Source: Logging * Target: Monitoring (Metrics) * Filter: only failed login / auth events * Metric: e.g., namespace `security_auth`, name `failed_login_count` Example minimal JSON config for the task (save as `sc-task.json`): ```json theme={null} { "kind": "logRuleTaskDetails", "logSource": { "kind": "ocic", "logGroupId": "", "logId": "" }, "metricExtraction": { "metricNamespace": "security_auth", "metricName": "failed_login_count", "dimensions": { "user": "$.data.additionalDetails.userName", "sourceip": "$.data.additionalDetails.sourceIp" }, "value": "1", "unit": "count", "filter": "$[?(@.data.eventName == 'LoginFailure')]" } } ``` Create the Service Connector: ```bash theme={null} oci sch service-connector create \ --compartment-id \ --display-name "FailedLoginToMetric" \ --source '{"kind":"logging","logSources":[{"kind":"log","logGroupId":"","logId":""}]}' \ --target '{"kind":"monitoring"}' \ --tasks file://sc-task.json \ --is-enabled true ``` Adjust the JSON paths (`eventName`, `userName`, etc.) to match your log schema. Wait \~5–10 minutes and confirm metrics are arriving: ```bash theme={null} oci monitoring metric-data summarize-metrics-data \ --compartment-id \ --namespace-name security_auth \ --query-text "failed_login_count[5m].sum()" ``` *** ## Step 2 – Decide your Brute Force detection rule Example brute-force detection heuristic: * If failed\_login\_count sum over 5 minutes > 10\ (either per user/IP or aggregated) Metric query examples (Monitoring query language): * All failed logins: ```text theme={null} failed_login_count[5m].sum() ``` * Per IP: ```text theme={null} failed_login_count[5m].groupby('sourceip').sum() ``` Pick one based on how you want to detect brute force. *** ## Step 3 – Create a Notification Topic (if you don’t have one) ```bash theme={null} oci ons topic create \ --compartment-id \ --name "BruteForceAlarmTopic" \ --description "Alarm for brute force detection" ``` Take note of the `topic-id` from the output. Optionally subscribe an email: ```bash theme={null} oci ons subscription create \ --topic-id \ --protocol EMAIL \ --endpoint you@example.com ``` *** ## Step 4 – Create the Brute Force Detection Alarm via OCI CLI 1. Build the alarm body JSON (`alarm-body.json`): ```json theme={null} { "displayName": "BruteForceDetectionAlarm", "compartmentId": "", "metricCompartmentId": "", "metricCompartmentIdInSubtree": true, "namespace": "security_auth", "query": "failed_login_count[5m].sum()", "severity": "CRITICAL", "destinations": [ "" ], "isEnabled": true, "repeatNotificationDuration": "PT15M", "pendingDuration": "PT5M", "body": "Potential brute force login attack detected (failed_login_count > 10 in 5 minutes).", "resolution": "PT1M", "messageFormat": "PRETTY_JSON", "triggerDelay": "PT0M", "supression": null, "isNotificationsPerMetricDimensionEnabled": false, "overrideAlarmState": "OK", "rule": "failed_login_count[5m].sum() > 10" } ``` Notes: * `query` and `rule` are both required: `rule` is the Boolean condition; `query` defines the metric selection. * Adjust the threshold `> 10` and windows `5m` to your policy. 2. Create the alarm: ```bash theme={null} oci monitoring alarm create \ --from-json file://alarm-body.json ``` 3. Verify: ```bash theme={null} oci monitoring alarm get --alarm-id ``` *** ## Step 5 – (Optional) Brute Force per IP or per User If you want the alarm to fire when any IP exceeds a threshold: In `alarm-body.json`, use: ```json theme={null} "query": "failed_login_count[5m].groupby('sourceip').sum()", "rule": "failed_login_count[5m].groupby('sourceip').sum() > 10", "isNotificationsPerMetricDimensionEnabled": true ``` Then each offending IP will generate its own alarm notification. *** ## Step 6 – Test the Alarm * Generate some failed login attempts (in a test account). * Wait for the metric to ingest and meet your threshold. * Confirm notifications from the alarm topic. *** If you share: * Where your authentication logs are (IDCS, IAM, OS logs, etc.) * How you want to define “brute force” (failed attempts, time window, by IP or user), I can give you an exact `oci` command + JSON tailored to your environment. Below is a practical way to remediate this by creating an OCI Monitoring Alarm (using Python + OCI SDK) that fires when a “brute force–like” pattern of failed authentications is detected. Because “brute force detection” isn’t a single built‑in metric in OCI, you usually do this in two stages: 1. **Produce a metric that represents failed login attempts** (e.g., from IAM logs, OS logs, or WAF logs). 2. **Create a Monitoring alarm on that metric** with a condition that indicates brute force behavior. I’ll focus on the Monitoring/Alerting part in Python and show where the metric comes from. *** ## 1. Prerequisites 1. Install OCI SDK for Python: ```bash theme={null} pip install oci ``` 2. Configure OCI CLI credentials (used by the SDK): ```bash theme={null} oci setup config ``` This creates `~/.oci/config` with: ```ini theme={null} [DEFAULT] user=ocid1.user.oc1.. fingerprint=... key_file=~/.oci/oci_api_key.pem tenancy=ocid1.tenancy.oc1.. region=us-ashburn-1 ``` 3. Identify: * **Compartment OCID** where: * Your metric is emitted. * You want the alarm created. * **Notification topic OCID** (OCI Notifications) where alerts will be sent. *** ## 2. Ensure You Have a Metric for Failed Logins You must have (or create) a metric that reflects failed logins, for example: * **From IAM auth logs** → send to **Logging**, then: * Use **Logging Analytics** or **Service Connector Hub** to transform into a custom metric. * Or from: * **WAF logs** (for web login brute force), * **OS-level auth logs** (e.g., SSH) shipped via **OCI Logging Agent** → then to a custom metric. Assume for the example: * Metric **namespace**: `custom_security` * Metric **name**: `failed_login_count` * Dimension: `source` (e.g., `ssh`, `web`, etc.) You must replace these with the actual namespace/name/dimensions you created. *** ## 3. Decide a Brute Force Threshold Example logic (tune for your environment): * “Trigger if `failed_login_count` ≥ 20 in 5 minutes” *** ## 4. Build the Monitoring Query OCI Monitoring uses a query language like: ```text theme={null} metric[].[= 20 ``` * `custom_security` – your metric namespace. * `failed_login_count` – your metric. * `[5m]` – window for evaluation. * `{source = "ssh"}` – optional filter. * `.sum()` – sum of failed logins. * `>= 20` – threshold. *** ## 5. Python Code: Create the Alarm ```python theme={null} import oci from oci.monitoring.models import ( CreateAlarmDetails ) # --- CONFIGURATION --- # OCI config profile CONFIG_PROFILE = "DEFAULT" # Compartment where the metric and alarm live COMPARTMENT_OCID = "ocid1.compartment.oc1..xxxx" # Notification topic OCID (OCI Notifications) TOPIC_OCID = "ocid1.onstopic.oc1..xxxx" # Alarm name and description ALARM_DISPLAY_NAME = "Brute Force Login Detection Alarm" ALARM_DESCRIPTION = ( "Triggers when failed login attempts indicate possible brute force attack." ) # Monitoring query – ADJUST THESE TO MATCH YOUR METRIC # Example for custom metric: # namespace: custom_security # metric: failed_login_count # dimension: source = "ssh" ALARM_QUERY = 'metric[custom_security].failed_login_count[5m]{source = "ssh"}.sum() >= 20' # Severity: CRITICAL | ERROR | WARNING | INFO SEVERITY = "CRITICAL" # Notification content ALERT_MESSAGE = "Possible brute force attack detected - high rate of failed logins." ALERT_BODY = ( "The alarm for failed login attempts has fired, indicating possible brute force " "activity on the monitored resources. Please investigate the source(s) of failed " "logins (SSH, web application, IAM, etc.)." ) # --- CREATE ALARM --- def create_bruteforce_alarm(): # Load config and create client config = oci.config.from_file(profile_name=CONFIG_PROFILE) monitoring_client = oci.monitoring.MonitoringClient(config) # Define alarm details alarm_details = CreateAlarmDetails( display_name=ALARM_DISPLAY_NAME, compartment_id=COMPARTMENT_OCID, metric_compartment_id=COMPARTMENT_OCID, namespace="custom_security", # Must equal your metric namespace query=ALARM_QUERY, severity=SEVERITY, body=ALERT_BODY, message_format="TEXT", # or "JSON" is_enabled=True, # Notifications destinations=[TOPIC_OCID], # Optional: treat missing data # MISSING = treat as missing, BREACHING = treat as breaching, NOT_BREACHING pending_duration="PT0M", # ISO 8601. 0 means trigger as soon as condition met. repeat_notification_interval="PT15M", # re-notify every 15 mins while in alarm is_notifications_per_metric_dimension_enabled=False, # Alarm description freeform_tags={ "purpose": "security", "type": "brute_force_detection" }, defined_tags={} ) # Call create_alarm response = monitoring_client.create_alarm(create_alarm_details=alarm_details) print("Alarm created:") print(" OCID: ", response.data.id) print(" Name: ", response.data.display_name) print(" Query: ", response.data.query) print(" Destinations:", response.data.destinations) if __name__ == "__main__": create_bruteforce_alarm() ``` ### Things you must adapt: 1. `COMPARTMENT_OCID` 2. `TOPIC_OCID` 3. `namespace` and `ALARM_QUERY`: * `namespace="custom_security"` * Query string with correct metric name + dimensions. 4. Threshold numbers and time window to fit your environment. *** ## 6. (Optional) Enforce Organization‑wide If this is part of a security control, you can: * Turn this into a reusable script or Terraform module. * Run it as part of CI/CD for each compartment/region. * Periodically verify via script: list alarms and ensure the brute force one exists and is enabled. *** If you share how your failed login signal is generated (IAM logs, WAF, Linux auth logs, etc.), I can give a concrete metric namespace/name and a more precise query. ```hcl theme={null} resource "oci_monitoring_alarm" "identity_bruteforce_detection" { # OCI compartment OCID where you want the alarm to live compartment_id = "OCID_OF_COMPARTMENT_FOR_ALARM" display_name = "identity-bruteforce-detection" is_enabled = true severity = "CRITICAL" # Topic to notify when suspected brute-force is detected destinations = [ "OCID_OF_OCI_NOTIFICATIONS_TOPIC" ] # Adjust this tenancy/compartment filter and threshold to match your environment and policy # - Replace IDENTITY_COMPARTMENT_OCID with the compartment/tenancy you want to watch # - Replace sourceIpAddress with the correct dimension key for the metric in your tenancy # - Replace 10 and 5 with the burst size and duration you consider "brute force" # # This example: # - Watches IdentityAuthFailure every 1 minute # - Groups by source IP address # - Triggers if any single IP has >10 failures per minute # - For at least 5 consecutive minutes metric_compartment_id = "IDENTITY_COMPARTMENT_OCID" namespace = "oci_identity" query = "IdentityAuthFailure[1m]{compartmentId = \"IDENTITY_COMPARTMENT_OCID\"}.grouping('sourceIpAddress').sum() > 10" resolution = "1m" pending_duration = "PT5M" # ISO-8601: alarm must remain in breach 5 minutes before firing message_format = "TEXT" body = "Potential brute-force activity detected: rapid, sustained IdentityAuthFailure events from a single source IP." # Optional: suppress duplicate notifications for the same ongoing incident repeat_notification_duration = "PT30M" # re-notify at most every 30 minutes while still in ALARM # Optional tags freeform_tags = { OWNER = "SECURITY_TEAM" PURPOSE = "Brute-force detection on identity auth failures" ENVIRONMENT = "PRODUCTION" } } ``` This change updates/creates the `oci_monitoring_alarm` in place and does not force replacement of other resources; only this alarm resource is added/updated. Verification: `terraform plan` should show one `oci_monitoring_alarm.identity_bruteforce_detection` to add (or to update if it already exists), with the `query`, `pending_duration`, and related arguments matching the brute-force detection threshold you require.