> ## 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 Cloud Guard Should Not Have Critical/High Problems

### More Info:

Cloud Guard should not report unresolved Critical or High severity problems. Unresolved problems indicate active security vulnerabilities, exposed assets, or ongoing suspicious activity

### 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
* 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        Below is how to handle “OCI Monitoring Cloud Guard Should Not Have Critical/High Problems” using the OCI Console, focusing on Monitoring/Alerting.

        ***

        ### 1. Find the Exact Cloud Guard Problem

        1. In OCI Console, open **Navigation Menu → Identity & Security → Cloud Guard**.
        2. Go to **Problems**.
        3. Filter by:
           * **Status**: `Open`
           * **Risk Level**: `High` and `Critical`
           * **Detector Type**: look for Monitoring / related (e.g., misconfigured alarms, disabled alarms, missing notifications).
        4. Click a specific problem to open the details pane:
           * Note the **Resource Type** (Alarm, Compartment, Metric, etc.).
           * Note the **Recommendation** text – Cloud Guard usually tells you what is missing/misconfigured.

        ***

        ### 2. Identify What’s Wrong With the Monitoring/Alerting

        Common Monitoring/Alerting-related Cloud Guard problems:

        * No alarms configured for key resources/metrics.
        * Alarm is in `Disabled` / `Suppressed` state.
        * Alarm missing **notification** (no topic, no subscription).
        * Alarm severity or condition not aligned with policy (e.g., wrong thresholds, wrong evaluation period).
        * Alarm not attached to correct compartment/region.

        From the problem details, confirm which of these applies.

        ***

        ### 3. Fix Alarms in Monitoring

        1. Go to **Navigation Menu → Observability & Management → Monitoring → Alarms**.
        2. Make sure you are in the **same region and compartment** as the resource shown in the Cloud Guard problem.

        #### A. If no alarm exists (resource unmonitored)

        1. Click **Create alarm**.
        2. Fill fields:
           * **Name**: meaningful (e.g., `cpu-high-app-prod`).
           * **Compartment**: same as the resource.
           * **Metric namespace**: select correct service (e.g., `oci_computeagent`, `oci_vcn`, etc.).
           * **Metric name & dimension**: pick the metric Cloud Guard expects (from the problem recommendation).
           * **Alarm severity**: set appropriately (e.g., `Critical` or `High`).
           * **Trigger rule**: define threshold/rule as suggested (e.g., CPUUtilization > 80 for 5 minutes).
        3. Under **Notifications**:
           * Choose/assign an **OCI Notifications topic** (create one if needed).
        4. Click **Create alarm**.

        #### B. If alarm exists but is disabled/incorrect

        1. From the **Alarms** list, locate the alarm named in the problem.
        2. For each issue:

           * **Disabled alarm**:
             * Open it; click **More Actions → Enable** (or toggle to Enabled).

           * **No notification**:
             * Edit the alarm.
             * Under **Notifications**, select a **Topic**.
             * Click **Save changes**.
             * If no topic exists:
               * Open new tab: **Navigation Menu → Application Integration → Notifications → Topics → Create Topic**.
               * Then add **Subscriptions** (email, PagerDuty, Slack via HTTPS, etc.) and confirm them.
               * Return to the alarm and attach this topic.

           * **Wrong condition / severity / resource scope**:
             * Edit the alarm:
               * Correct **metric**, **dimensions**, and **compartment**.
               * Adjust **threshold**, **operator**, **evaluation period** to match security / SRE requirements or Cloud Guard recommendation.
               * Set **Severity** to match the risk level (e.g., `Critical` for production outages).
             * Save.

        ***

        ### 4. Validate and Close the Cloud Guard Problem

        1. After fixing the alarm(s), wait a few minutes for Cloud Guard re-evaluation.
        2. Go back to **Cloud Guard → Problems**.
        3. Refresh:
           * If Cloud Guard recognizes the fix, the problem status should move to `Resolved` / `Closed` automatically.
        4. If it remains `Open`:
           * Re-open the problem, verify:
             * The resource/compartment/region aligns with the alarm’s configuration.
             * The alarm is **Enabled** and in the correct **compartment**.
           * Make corrections and wait again.

        ***

        ### 5. Optionally Tune Detection (Detector/Responder Recipes)

        If you’re getting false positives or want automatic remediation:

        1. Go to **Cloud Guard → Detector Recipes**.
        2. Open the **Monitoring-related Detector Recipe** assigned to your target.
        3. For the specific detector rule:
           * Adjust **Risk Level**, conditions, or **Targets** if needed (e.g., exclude non-prod compartments).
        4. For auto-fix:
           * Go to **Cloud Guard → Responder Recipes**.
           * Enable/attach a responder that can create/enable alarms automatically (if available for that rule).
           * Associate that responder recipe with the same **Target** as the detector.

        ***

        If you paste one actual problem’s text (detector name + recommendation), I can give you exact field values for the alarm and any Monitoring settings to change.
      </Accordion>

      <Accordion title="Using CLI">
        Below is a pragmatic way to handle **“OCI Monitoring – Cloud Guard Should Not Have Critical/High Problems”** using the **OCI CLI**, focusing on Monitoring / Alerting–related problems.

        ***

        ## 1. Identify the relevant Cloud Guard problems

        First, list Cloud Guard problems with **HIGH/CRITICAL** severity for the Monitoring service.

        ```bash theme={null}
        TENANCY_OCID="<your_tenancy_ocid>"
        COMPARTMENT_OCID="<target_compartment_ocid>"   # use tenancy OCID for root

        oci cloud-guard problem list \
          --compartment-id "$COMPARTMENT_OCID" \
          --compartment-id-in-subtree true \
          --severity-filter "HIGH,CRITICAL" \
          --all > problems.json
        ```

        Filter only Monitoring-related problems:

        ```bash theme={null}
        jq '.data[] | select(.resourceType | test("alarm|monitoring"; "i"))' problems.json > monitoring_problems.json
        ```

        You can inspect one problem:

        ```bash theme={null}
        PROBLEM_ID="<problem_ocid_from_monitoring_problems.json>"

        oci cloud-guard problem get \
          --problem-id "$PROBLEM_ID" \
          --query 'data'
        ```

        Look at:

        * `resourceType`
        * `resourceId` (often the alarm OCID)
        * `detectorRuleId`
        * `riskLevel` / `severity`
        * `recommendation`

        ***

        ## 2. Inspect and fix the underlying Monitoring resources

        Most Monitoring-related Cloud Guard problems are about:

        * disabled alarms
        * missing notification destinations
        * bad alarm query / incorrect conditions
        * alarm in `INSUFFICIENT_DATA` due to misconfigured metric query
        * alarms not covering critical metrics

        ### 2.1 Get details of the alarm mentioned in the problem

        From the problem details note `resourceId` (e.g., alarm OCID) and its compartment.

        ```bash theme={null}
        ALARM_OCID="<alarm_ocid_from_problem>"
        ALARM_COMPARTMENT_OCID="<compartment_of_alarm>"

        oci monitoring alarm get \
          --alarm-id "$ALARM_OCID" \
          --query 'data'
        ```

        Fields to check:

        * `isEnabled`
        * `destinations`
        * `metricCompartmentId`
        * `query`
        * `severity`
        * `pendingDuration`
        * `suppression`
        * `resolution`
        * `lifecycleState`

        ***

        ### 2.2 Enable disabled alarms

        If `isEnabled: false`, enable it:

        ```bash theme={null}
        oci monitoring alarm update \
          --alarm-id "$ALARM_OCID" \
          --is-enabled true
        ```

        ***

        ### 2.3 Add a notification destination (if missing)

        If `destinations` is empty, set an OCI Notifications topic OCID:

        ```bash theme={null}
        TOPIC_OCID="<notifications_topic_ocid>"

        oci monitoring alarm update \
          --alarm-id "$ALARM_OCID" \
          --destinations '["'"$TOPIC_OCID"'"]'
        ```

        ***

        ### 2.4 Fix the alarm query or configuration

        If Cloud Guard indicates misconfiguration (e.g., wrong metric namespace or dimensions), you may need to update:

        * `namespace`
        * `metric-name`
        * dimensions in the `query`
        * `pendingDuration` / thresholds
        * `severity`

        Example changing the `query` and `severity`:

        ```bash theme={null}
        NEW_QUERY="CpuUtilization[5m].mean() > 80"

        oci monitoring alarm update \
          --alarm-id "$ALARM_OCID" \
          --query "$NEW_QUERY" \
          --severity "CRITICAL"
        ```

        If Cloud Guard complains about `INSUFFICIENT_DATA`, ensure:

        * correct namespace/metric
        * correct `metricCompartmentId`
        * resource is actually generating that metric

        For example, change metric compartment:

        ```bash theme={null}
        NEW_METRIC_COMPARTMENT_OCID="<metric_compartment_ocid>"

        oci monitoring alarm update \
          --alarm-id "$ALARM_OCID" \
          --metric-compartment-id "$NEW_METRIC_COMPARTMENT_OCID" \
          --metric-compartment-id-in-subtree true
        ```

        ***

        ### 2.5 (Optional) Create new alarms for missing coverage

        Sometimes the problem is “no alarm on critical metric”. Create an alarm via CLI:

        ```bash theme={null}
        COMPARTMENT_OCID="<compartment_for_alarm>"
        DISPLAY_NAME="High CPU Alarm"
        NAMESPACE="oci_computeagent"
        QUERY="CpuUtilization[5m].mean() > 80"
        TOPIC_OCID="<notifications_topic_ocid>"

        oci monitoring alarm create \
          --compartment-id "$COMPARTMENT_OCID" \
          --display-name "$DISPLAY_NAME" \
          --is-enabled true \
          --namespace "$NAMESPACE" \
          --query "$QUERY" \
          --severity "CRITICAL" \
          --destinations '["'"$TOPIC_OCID"'"]' \
          --metric-compartment-id "$COMPARTMENT_OCID" \
          --metric-compartment-id-in-subtree true \
          --body '{"resolution": "1m"}'
        ```

        ***

        ## 3. Mark the Cloud Guard problem as resolved/dismissed

        Once the underlying issue is fixed and verified (alarm is enabled, properly configured, and functional), change the problem’s lifecycle state so it is no longer an active HIGH/CRITICAL problem.

        To mark as `RESOLVED`:

        ```bash theme={null}
        PROBLEM_ID="<problem_ocid>"

        oci cloud-guard problem update \
          --problem-id "$PROBLEM_ID" \
          --lifecycle-state "RESOLVED"
        ```

        If it is a false positive and you want to dismiss it:

        ```bash theme={null}
        oci cloud-guard problem update \
          --problem-id "$PROBLEM_ID" \
          --lifecycle-state "DISMISSED" \
          --comment "Known exception; accepted risk."
        ```

        ***

        ## 4. (Optional) Automate via Cloud Guard responders

        Instead of manually resolving:

        * Enable or customize **responder recipes** in Cloud Guard to auto-fix some Monitoring issues (e.g., enabling alarms).
        * Use CLI to update the Cloud Guard target’s detector/responder recipes.

        Example (very high-level):

        ```bash theme={null}
        TARGET_ID="<cloud_guard_target_ocid>"

        oci cloud-guard target update-target-detector-recipe \
          --target-id "$TARGET_ID" \
          --target-detector-recipe-id "<target_detector_recipe_ocid>" \
          --detector-rules file://detector_rules_update.json
        ```

        (Where `detector_rules_update.json` enables the appropriate rules and responders.)

        ***

        If you paste one sample Monitoring-related problem JSON (from `oci cloud-guard problem get`), I can give exact CLI commands tailored to that specific problem type.
      </Accordion>

      <Accordion title="Using Python">
        Below is a practical way to handle this with Python: detect and remediate (or at least mark/track) critical/high Cloud Guard problems related to Monitoring/Alarms, using the OCI Python SDK.

        ***

        ## 1. Prerequisites

        1. Install SDK:
           ```bash theme={null}
           pip install oci
           ```

        2. Configure OCI CLI/SDK auth (`~/.oci/config`):
           ```ini theme={null}
           [DEFAULT]
           user=ocid1.user.oc1..xxxxx
           fingerprint=xx:xx:xx:xx
           key_file=/path/to/oci_api_key.pem
           tenancy=ocid1.tenancy.oc1..xxxxx
           region=us-ashburn-1
           ```

        3. IAM permissions needed for the principal running this script:
           ```text theme={null}
           allow group <group-name> to read cloud-guard-family in tenancy
           allow group <group-name> to manage monitoring-family in tenancy
           ```

        ***

        ## 2. High-level remediation flow

        1. Use Cloud Guard to list all `CRITICAL` and `HIGH` problems.
        2. Filter problems that relate to Monitoring / Alarms.
        3. For each problem, inspect its `detector_rule_id` / `risk_level` / `resource_type` / `problem_description` to determine what needs fixing (e.g., missing alarm, disabled alarm, missing metric stream).
        4. Call appropriate Monitoring APIs to fix the configuration.
        5. Optionally, update the Cloud Guard problem state to `RESOLVED` (only if you are sure you fixed it).

        Because Cloud Guard problems are rule‑specific, the exact remediation depends on the rule. Below is a generic automation pattern that you can customize per rule.

        ***

        ## 3. Python: list & filter critical/high Cloud Guard problems

        ```python theme={null}
        import oci

        config = oci.config.from_file()  # or from_file(profile_name="DEFAULT")
        cloud_guard_client = oci.cloud_guard.CloudGuardClient(config)

        COMPARTMENT_OCID = "<your_root_or_target_compartment_ocid>"

        def list_high_critical_problems(compartment_id):
            problems = []
            # Use pagination
            list_resp = cloud_guard_client.list_problems(
                compartment_id=compartment_id,
                compartment_id_in_subtree=True,
                risk_level_filter=["CRITICAL", "HIGH"],
                # optionally: status="OPEN"
            )

            problems.extend(list_resp.data.items)
            while list_resp.has_next_page:
                list_resp = cloud_guard_client.list_problems(
                    compartment_id=compartment_id,
                    compartment_id_in_subtree=True,
                    risk_level_filter=["CRITICAL", "HIGH"],
                    page=list_resp.next_page
                )
                problems.extend(list_resp.data.items)

            return problems

        problems = list_high_critical_problems(COMPARTMENT_OCID)
        print(f"Found {len(problems)} critical/high problems")
        ```

        ***

        ## 4. Identify Monitoring-related problems

        Look at `resource_type`, `detector_rule_id`, `problem_description` etc. Monitoring issues usually have `resource_type` like `alarm`, `monitoringresource`, or refer to monitoring in the description.

        ```python theme={null}
        monitoring_related = []

        for p in problems:
            if (
                "monitor" in (p.resource_type or "").lower()
                or "alarm" in (p.resource_type or "").lower()
                or "monitor" in (p.problem_description or "").lower()
            ):
                monitoring_related.append(p)

        print(f"Monitoring-related problems: {len(monitoring_related)}")
        for p in monitoring_related:
            print(p.id, p.resource_type, p.problem_description)
        ```

        From this output, note which detector rules you want to automatically fix (e.g., “Alarm not configured for X metric”, “Alarm disabled”, etc.).

        ***

        ## 5. Example remediation patterns for Monitoring

        Below are generic remediation functions. You must map each Cloud Guard detector rule or description to one of these.

        ### 5.1. Create a missing alarm

        Suppose Cloud Guard says “No alarm configured for `<resource>` metric X”.

        ```python theme={null}
        from oci.monitoring import MonitoringClient
        from oci.monitoring.models import CreateAlarmDetails

        monitoring_client = MonitoringClient(config)

        def create_alarm_for_metric(compartment_id, display_name, namespace, query,
                                    severity="CRITICAL", destinations=None):
            """
            destinations: list of OCIDs of Notifications topics
            """
            details = CreateAlarmDetails(
                compartment_id=compartment_id,
                display_name=display_name,
                metric_compartment_id=compartment_id,
                namespace=namespace,
                query=query,
                severity=severity,
                is_enabled=True,
                body="Automated alarm created from Cloud Guard remediation.",
                destinations=destinations or [],
                pending_duration="PT5M",  # 5 minutes
                resolution="PT5M"
            )

            resp = monitoring_client.create_alarm(details)
            return resp.data

        # Example usage:
        # query example for CPU > 80% avg 5m:
        # "CpuUtilization[5m]{resourceId = 'ocid1.instance.oc1..aaaa'}.mean() > 80"
        new_alarm = create_alarm_for_metric(
            compartment_id="<target_compartment>",
            display_name="Auto-created CPU alarm",
            namespace="oci_computeagent",
            query="CpuUtilization[5m]{resourceId = 'ocid1.instance.oc1..aaaa'}.mean() > 80",
            destinations=["ocid1.onstopic.oc1..xxxxx"]
        )
        print("Created alarm:", new_alarm.id)
        ```

        You would build the `query` and `display_name` from data embedded in the Cloud Guard problem (e.g., `p.resource_id`, `p.resource_name`, or freeform tags).

        ### 5.2. Enable a disabled alarm

        If the problem says an alarm is disabled:

        ```python theme={null}
        from oci.monitoring.models import UpdateAlarmDetails

        def enable_alarm(alarm_id):
            update = UpdateAlarmDetails(is_enabled=True)
            resp = monitoring_client.update_alarm(alarm_id=alarm_id, update_alarm_details=update)
            return resp.data

        # Example using resource_id from problem
        for p in monitoring_related:
            if "disabled" in (p.problem_description or "").lower():
                alarm_id = p.resource_id
                enabled_alarm = enable_alarm(alarm_id)
                print("Enabled alarm:", enabled_alarm.id)
        ```

        ***

        ## 6. Mark Cloud Guard problem as resolved (optional)

        Once you’ve programmatically remediated, you can mark the problem as `RESOLVED` (if your process requires that):

        ```python theme={null}
        from oci.cloud_guard.models import UpdateProblemStatusDetails

        def resolve_problem(problem_id, comment="Remediated via automation"):
            details = UpdateProblemStatusDetails(
                status="RESOLVED",
                comment=comment
            )
            resp = cloud_guard_client.update_problem_status(
                problem_id=problem_id,
                update_problem_status_details=details
            )
            return resp.data

        for p in monitoring_related:
            # Only resolve if you’re sure the remediation succeeded
            resolved = resolve_problem(p.id)
            print("Resolved problem:", resolved.id)
        ```

        ***

        ## 7. Putting it together (skeleton)

        You can orchestrate this into a single script:

        1. List problems (critical/high).
        2. Filter monitoring‑related.
        3. For each:
           * Branch based on `detector_rule_id` / description.
           * Call the appropriate remediation function (create alarm, enable alarm, etc.).
           * Optionally resolve the problem.

        Skeleton:

        ```python theme={null}
        def remediate_monitoring_problem(problem):
            desc = (problem.problem_description or "").lower()

            if "alarm" in desc and "not configured" in desc:
                # Build an alarm for the affected resource
                # You must parse the resource info from `problem`:
                query = build_query_from_problem(problem)  # your function
                create_alarm_for_metric(
                    compartment_id=problem.compartment_id,
                    display_name=f"Auto-alarm for {problem.resource_name}",
                    namespace="oci_computeagent",
                    query=query,
                    destinations=["ocid1.onstopic.oc1..xxxxx"]
                )
            elif "alarm" in desc and "disabled" in desc:
                enable_alarm(problem.resource_id)

            # After remediation:
            resolve_problem(problem.id, comment="Remediated by Python script")

        for p in monitoring_related:
            remediate_monitoring_problem(p)
        ```

        ***

        If you can paste an example Cloud Guard problem JSON for “OCI Monitoring” from your environment, I can provide a more precise mapping from each problem type to exact Python remediation code.
      </Accordion>

      <Accordion title="Using Terraform">
        OCI Monitoring and Cloud Guard configuration in Terraform cannot “clear” or resolve existing Critical/High problems; this is an operational action on findings, not a configuration property of `oci_monitoring_*` or Cloud Guard resources.

        Use the Console or CLI to investigate and resolve each problem (Cloud Guard → Problems → filter by Critical/High → remediate or mark resolved), and optionally tighten your alarms/policies going forward via Terraform (e.g., adjusting Monitoring alarm queries), but there is no Terraform argument on `oci-monitoring-cloudguard-configuration` (or related resources) that can make existing Critical/High problems disappear.

        Since there is no Terraform-exposed setting to remediate this finding, `terraform plan` will correctly show **no changes** related to Cloud Guard problems themselves.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>