Oracle Cloud Guard helps customers maintain good security posture by detecting weak security configurations and activities that can indicate cloud security risks.
Cloud Guard detects security problems within a customer tenancy by ingesting audit and configuration data about resources in each region, processing it based on detector rules, and correlating the problems at the reporting region. Identified problems will be used to produce dashboards and metrics and may also trigger one or more provided responders to help resolve the problem.
Responders can mitigate, correct, and prevent security issues based on a problem.
Cloud Guard is available by default within your Oracle Cloud Infrastructure (OCI) tenancy and can be accessed from the OCI Security console. Here are the steps for enabling Cloud Guard for the first time:
Pre-Requisites: Cloud Guard is not available for free Oracle Cloud Infrastructure tenancies. Ensure that you have a paid tenancy before you attempt to enable Cloud Guard.
For the complete set of other pre-requisites please refer to https://docs.oracle.com/en-us/iaas/cloud-guard/using/prerequisites.htm
Cloud Guard for OCI Configuration and OCI Activity is provided free of charge for supported OCI services.
Cloud Guard is implemented regionally and aggregates problems to the customer-selected reporting region to provide a global view.
All commercial regions for the tenancy will be monitored regions. Please see here for a list of currently supported regions here: https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm
Yes, the reporting region can be changed by disabling Cloud Guard and re-enabling Cloud Guard in another region. Cloud Guard configuration and data will not be moved if the reporting region is changed.
The reporting region can only be selected during Cloud Guard enablement. So, if a customer needs to change the existing reporting region, they can disable Cloud Guard and choose the same or a different reporting region during the re-enablement process.
Please note that when you try to re-enable Cloud Guard with a different reporting region, there is a wait period of approximately 20 minutes; this is because a resource sync up must happen across regions.
Yes, Cloud Guard provides two key metrics the Risk Score and the Security score as part of the Overview page in the Console. Security Score is a normalized value ranging from 0-100 that uses the number, types, and severity of problems to determine an overall assessment of the strength of security posture. Risk Score complements the Security Score by evaluating the number of total resources being monitored, the sensitivity of each resource type, and the severity of any problems related to the resources to determine the total risk exposure of a tenant. These are used to help assess what could be “small but insecure” and “large but overall secure” environments correctly.
Cloud Guard aligns with the CIS Foundations benchmark standard for OCI. Additional compliance features are expected post-GA.
SIEMs and Cloud Guard are complementary services. Cloud Guard provides security posture assessment and security monitoring of OCI tenancy by ingesting audit/log data and by monitoring the configuration state of resources. OOTB detectors are provided and enabled by default in Cloud Guard that help detect the problems for your resources. SIEM based services ingest log data from resources and applications and provides support for search/analytics engine to perform forensic investigations and potentially identify new indicators of risk or custom event discovery. Cloud Guard’s automated remediation features (aka Responders) can be configured and initiated by Cloud Guard whereas actions should be defined as part of the rules construct for the SIEM tools.
Most customers want cloud security monitoring to integrate with existing processes, procedures, and people. Many InfoSec teams will integrate Cloud Guard problems with their internal SIEM tools to tie Cloud Guard problems with their internal processes. These integrations may use the Cloud Guard APIs, and/or existing OCI Infrastructure services such as OCI Events, OCI Notifications, and OCI Functions. Cloud Guard can be Events to trigger (e.g.) sending problems to email, Slack, and PagerDuty as well as to custom OCI Functions. Customers can also use the Events to OCI Functions to build custom integration or responses based on customers' use-cases.
Oracle Cloud Guard Fusion Applications Detector extends Oracle Cloud Guard beyond cloud security posture management for OCI to also monitor Oracle Fusion Cloud Applications and provide customers with a consolidated view of security policies. The service is available first for Oracle Fusion Cloud Human Capital Management (HCM) and Oracle Fusion Cloud Enterprise Resource Planning (ERP). The service provides preconfigured and customized configurations, or “recipes,” to monitor potential security violations in the applications. Detectors trigger alerts in response to sensitive configuration changes related to user privileges that impact important data access, including adding, deleting, or modifying data and function privileges for roles and users, as well as changes to sensitive objects.
The Cloud Guard Fusion Applications Activity Detector recipe (Oracle managed) is an out-of-the-box (OOTB) template and cannot be modified. Customers may clone and edit their own rules; for example, they can modify a name, change the risk level, filter out a specific user to monitor their activities, disable a rule, and so on.
No. As long as Cloud Guard can reach the pod’s API endpoints, Cloud Guard can monitor the pod.
Yes. As long as Cloud Guard can reach the pod’s API endpoints, Cloud Guard can monitor the pod.
Customers must first opt in to enable Cloud Guard within their OCI tenancy. Once Cloud Guard is enabled, there is a target registration flow within Cloud Guard that requires customers to provide their pod URL and the credentials of the service user that they will create up front within the Fusion Application. Once the target is created and the Fusion Application recipe is attached, monitoring is turned on automatically and Fusion Application user activity problems will trigger alerts.
One Fusion Application target in Cloud Guard can be associated with a single Fusion Application instance. A Fusion Application instance can host multiple Fusion Application pillar services such as Oracle Fusion Cloud HCM or ERP, depending on the customer’s Fusion Application provisioning and deployment preferences. The Fusion Application target is configured at the Fusion Application instance level as opposed to the Fusion Application service level. Therefore, while you cannot have a Fusion Application target monitoring multiple Fusion Application instances, it is possible to have a single Fusion Application target that can detect events across Oracle Fusion Cloud HCM and ERP enabled in a single Fusion Application pod.
Cloud Guard detectors for HCM will provide OOTB recipes that will trigger alerts in response to sensitive configuration changes related to user privileges that impact sensitive data access, such as adding, deleting, or modifying data and function privileges for roles and users. Cloud Guard will also be able to monitor and detect activities related to Personal Identifying Information (PII), such as name, address, citizenship, disability, and so on, that could indicate any potential issues around data handling, reporting, or exfiltration. In summary, Cloud Guard detectors for HCM will essentially cover role management, role provisioning, PII object management, and access management.
Customers can use the existing rules in Cloud Guard or create similar policies using the Cloud Guard templates.
Cloud Guard does not provide direct SIEM integration. Customers can make use of OCI Events and Functions such as the notification service, function service, and others to integrate Cloud Guard with third-party SIEM.
Customers require a paid OCI tenancy to access Cloud Guard, although they don’t need to consume any OCI services.