About the Problems Page

Understand how he Problems page works,

Overview of Problems

  • A problem is action or setting on a resource that could potentially cause a security problem.

  • Problems are triggered through detectors.

  • The Problems page displays information about each problem, including:
    • Problem Name
    • Risk Level
    • Detector Type
    • Resource affected
    • Target
    • Region
    • Labels
    • First Detected
    • Last Detected
  • Within the Problems page you can filter problems by Compartment, Status, Date, Risk Level, Resource Type, Detector Type, and Region.
  • You can click an individual problem to:
    • Learn more about that problem
    • View problem history
    • Take action to resolve or dismiss the problem

Problem Lifecycle

Here is how Cloud Guard manages problems as they occur, are processed, and reoccur.

  • Problems can have these lifecycle states:
    • Open: Problem has not yet been processed
    • Remediated: Fixed using Cloud Guard responder
    • Resolved: Fixed by other process
      Note

      A problem can appear to be resolved twice in the problem history. When you first resolve a problem, Cloud Guard doesn't pick it up as resolved until the next scan. In that scan, if the problem is not really resolved, Cloud Guard re-opens the problem, Then when the problem is actually fixed, Cloud Guard adds another history record, acknowledging that problem is indeed closed.
    • Dismissed: Ignore and close
    • Deleted: the associated target has been deleted (see table below under Problem Reconciliation Process)
      Note

      Cloud Guard considers a configuration problem to be orphaned if the problem:
      • Remains undetected, and...
      • Is still in the Open lifecycle state after multiple scans over a period of 4 days.
  • If Cloud Guard detects an issue again for:
    • An Open (unresolved) problem, it updates the problem history, but doesn't create a new problem.
    • A previously solved problem, it reopens the issue and updates the history.
    • A previously dismissed problem, it updates the history.
      Note

      For dismissed problems triggered by an Activity Detector rule, the dismissed problem is also moved from dismissed to open state.

Problem Reconciliation Process

Based on your Cloud Guard configuration, every problem has four specific object associations:

  • Detector rule
  • Target in which the rule is enabled
  • Compartment in that target
  • Resource in that compartment

If any of these problem associations change, after the problem is triggered and before it's resolved, the normal problem lifecycle is interrupted. The following table describes the problem reconciliation process that Cloud Guard uses to handle different types of configuration changes that interrupt the normal problem lifecycle.

Configuration Change / Cloud Guard Action * Later Configuration Change Later Cloud Guard Action *

Target is deleted /

Problem Status changes to Deleted

New target is created for same compartment New problem is created (Status is Open)

Detector rule is disabled

Problem Status changes to Resolved

Detector rule is re-enabled Resolved problem is reopened (Status is Open)

Detector recipe is detached from target

Problem Status changes to Resolved

Detector recipe is reattached to target Resolved problem is reopened (Status is Open}

Compartment or resource is deleted

Problem Status changes to Resolved

Compartment or resource is re-created Resolved problem is reopened (Status is Open}

* Cloud Guard actions in response to configuration changes that interrupt the problem lifecycle typically are not effective immediately, and might take up to a few days to appear in the Console.

Note

The problem reconciliation process just emits events. To generate notifications for these events, see Configuring Notifications.

Tip

To quickly clear problems that you now consider to be false positives, for each user-managed recipe rule that produced these false positives, disable and then re-enable the rule. See Editing Rule Settings in an OCI Detector Recipe.

Taking Actions on Problems

You can take the following actions on problems:

  • Remediate: When you remediate a problem, you're telling Cloud Guard to do one of two things:

    • Either execute a responder to fix something in your environment so that the problem doesn't happen again.
    • Or automatically resolve future instances that do occur, by executing the same responder.
  • Mark as Resolved: When you mark a problem as resolved, you're telling Cloud Guard that it was in fact a problem, but you've taken an action that handled it. If another instance of this same problem occurs, it's detected again.

  • Dismiss: When you dismiss a problem, you're telling Cloud Guard to ignore this instance of the problem for that resource, and simply ignore it if it happens in the future. Only the problem history of the dismissed problem is updated.

Here is a summary of the differences between the three problem actions:

  • Remediate - when you remediate a problem:
    • Number of problems that are resolved at one time:

      Current problem only.

    • When the same problem occurs later:

      The problem can be automatically resolved in same way; future instances appear in Responder Status tile in Overview page, but still appear in Problems page list. Automatically resolved problems can also be viewed from the Problems page by choosing the Resolved filter.

    • Result of implementing the resolution:

      A Cloud Guard responder is executed.

  • Mark as Resolved - when you mark a problem as resolved:
    • Number of problems that are resolved at one time:

      Current problem or all selected problems.

    • When the same problem occurs later:

      The problem will be detected and reported again; future instances appear in Problems page list.

    • Result of implementing the resolution:

      Whatever action you decide to take.

  • Dismiss - when you dismiss a problem:
    • Number of problems that are resolved at one time:

      Current problem or all selected problems.

    • When the same problem occurs later:

      The problem is not detected as a new problem. Problem history's last detected time is updated.

    • Result of implementing the resolution:

      The problem is ignored.