Infolob.com > News

Cloud Security: Oracle Cloud Guard - Spring Update Package Contents

Oracle Cloud Guard can be referred to as the last nail on the cyberthreats’ coffin. Those who have already undertaken a successful migration to Oracle Cloud Infrastructure (OCI) know how cloud security looked like before Oracle’s 2nd generation cloud services came to market.

To give you an idea, enterprises depended on hardware that were vulnerable to the weakest of cyberattacks originating at the firmware level, with no concept of isolated network virtualization, zero-trust security model, or perhaps the embedded compliance of privacy regulations. Not to mention the absence of AI, ML, and blockchain for the most part, in affording cloud security the due orchestration and resilience. In short, cybersecurity was a nightmare.

Related pages from Oracle and Infolob:

  1. Oracle Cloud Infrastructure Security Features and Implementation Best Practices
  2. Four Key Deployment Learnings of Oracle Cloud Guard at Oracle Data Cloud
  3. Oracle Autonomous Database Services

OCI pioneered the new generation of cloud security in two-folds. First, by infusing security straight into their infrastructure’s design, both physically and logically. And second, by investing in the development of new capabilities that further strengthened customers’ security posture across their data, network, and systems in the Oracle cloud.

Oracle Cloud Guard at Work

In line with these initiatives, Oracle Cloud Guard is yet another success story that needs a retelling. And what is a better occasion than the release of its new features aimed at making Oracle customers’ lives easier?

Released barely a year ago, the Oracle Cloud Guard quickly became popular among Oracle customers seeking a unified solution for proactively detecting misconfigurations in resource and user activity, and their automatic remediation via security recipes to scale SOC (abbr. security operations center).

Simply put, the Oracle Cloud Guard turns out to be the innovation in cloud security the world anticipated for years.

Oracle Cloud Guard - Spring Update

So, what new features and enhancements are you looking at with the Oracle Cloud Guard’s latest update? Let us find out.

  1. New Detector Rules

The latest update for Cloud Guard houses several new detector rules for expanding security recipes. Included in both Cloned and Oracle managed recipes—as is the new Scanning detectors for bolstering Vulnerability Scanning Service (VSS)—the security in OCI stands further enhanced. The other significant detector additions are in the identity and access management (IAM), and Load balancer.

Load balancer configuration detectors: Till now, the load balancer permitted below TLS 1.2 operations for services requiring weaker TLS suites. However, because it is not a good practice from a security perspective, the new detectors in Oracle Cloud Guard suggest ways to fix it. Similarly, weak cipher suites featuring weaker DES and RC4 algorithms are also detected, and recommendations forwarded.

IAM activity detectors: Oracle broadened the existing list of IAM Activity detectors to subsume any type of create/discard operations for IAM users, user capabilities, groups, and credentials. However, to avoid unnecessary disturbance, few of these detectors are required to be enabled manually by Cloud Guard users.

  1. Oracle Cloud Guard Platform Fine-Tunings

Numerous enhancements are incorporated into the Oracle Cloud Guard’s existing capabilities, including the user experience, events-types, and problem lifecycle functionalities.

Reporting region switch: Reporting regions are chosen during customer onboarding to Oracle Cloud Guard. It enables customers to set the ‘data sovereignty’ for the data in Cloud Guard. With the spring update, customers can now seamlessly disable and enable Cloud Guard from one region to another, along with the reporting region. Although customers may experience a downtime of not more than 20 minutes for synchronization to complete, it is a much-requested feature for enterprises looking to make the switch for various reasons. However, please note that switching between reporting regions would not transfer your configuration or problem data. In other words, Oracle Cloud Guard users would not be able to navigate to problem data in the primary console or APIs from the last reporting region.

Greater OCI events integration: Oracle Cloud Guard has also advanced its integration with the OCI events service for bolstering additional activities. Till now, it only supported the three fundamental event types: ‘Target-Information’, ‘Problem-Detected’, and ‘Problem-Remediated’. Oracle added the Problem-Dismissed event type and amended the ‘Target-Information’ event-type name to ‘Problem Threshold Reached’ on top of numerous field additions to the event for offering extended summary of the security issue.

Manual re-opening of an initially dismissed problem: In majority of the cases, Cloud Guard users tag a configuration problem “dismissed” when they find the problem already addressed or weak enough to be ignored. However, at times the ‘dismissed’ resource configuration problem may turn out to be valid. For those cases, Oracle now extends users the ability to manually re-open a problem for remediation. Also, all transactions are recorded in the Cloud Guard problem history.

Problem retention in Oracle Cloud Guard: This one is rather a reminder than a feature update. The Oracle Cloud Guard persists problem data for 180 days. Meaning, any problem data antique than 180 days would be entirely purged from the dedicated databases. Note: The retention cycle period is decided in reference to the “Last Updated” time of the Cloud Guard problem data.

  1. New User Experience in Oracle Cloud Guard

‘Cloning of the cloned’ and managed recipe list: An Oracle Cloud Guard managed list is a series of parameters that facilitate the adjusting of detector and responder rules’ scope. For instance, users can build a “managed list” of OCIDs and include it as a conditional parameter in a detector rule – ‘instance has public IP’. This improvement encircling the managed list feature is to allow cloning on current ‘managed lists’ without the need for rebuilding from the ground up. Correspondingly, Oracle Cloud Guard is now compatible with the cloning of previously ‘cloned’ recipes on top of the default recipes.

More elaborate problem summary: Upon the Oracle Cloud Guard identifying a security issue for an activity, e.g., ‘user added to a group’, the ‘resource name’ field inside the problem summary specifies who performed the activity. However, for the administrators to take most appropriate action, they would need further insights on the user that was added to a group along with group’s name, type, recommendations, etc. Those details are now a part of the problem summary in Oracle Cloud Guard.