A couple of months ago, I wrote about cloud security posture management (CSPM), and introduced Oracle Cloud Guard, a new Oracle Cloud Infrastructure (OCI) service designed to help you maintain a strong security posture. Cloud Guard is just one of the new services that are part of Oracle’s vision to make cloud security easier by default and always-on.
I have been involved in the limited availability programme for Oracle Cloud Guard for some time and the great news is that on 14th September 2020 Cloud Guard was officially released and is now generally available to all OCI customers.
In my previous post, I briefly introduced you to Cloud Guard, but thought it would be useful to dive a little bit deeper into Cloud Guard, why it was released, and how it works.
I have talked before about why security must be easier and some of the challenges driving that need, such as:
These challenges provided Oracle with a great opportunity for inflection; to analyse exactly what is needed to address this. One of the results of this analysis was Oracle Cloud Guard. Some of the key design principles of Cloud Guard include:
This brand-new cloud service enables customers to maintain a strong security posture by monitoring OCI, identifying problems and fixing them. Conceptually, Oracle Cloud Guard is simple to understand. It receives signals from different source components within OCI, which are fed into Detectors. These detectors identify Problems, which can then be associated with Responders, to provide a notification and/or automated remediation of the problem.
The power of Oracle Cloud Guard lies in the Detector and Responder rules, which are bundled into Recipes and are applied to compartments that you specify within your Oracle Cloud Infrastructure tenancy (or indeed tenancy wide). You can apply different recipes to different compartments. Oracle is using our security expertise and knowledge of OCI to provide a strong set of out-of-the-box detectors to identify common security problems. These detectors are divided into configuration-based and activity-based detectors. As an example, here are a few of the configuration-based detector rules.
Similarly, here are a few of the activity-based detector rules.
Once a problem has been identified, you have the option to remediate that problem using the responder recipes. As with detector recipes, not only do we provide a range of out-of-the-box remediation and notification actions, but since Cloud Guard is an OCI cloud service, it can use the full power of OCI for its responders. For example, from a responder notification, an event can be fired, which is used to launch a number of different notification types, including a serverless function (using the open-source fn project language).
Some responder remediation rules include:
Of course, with both detector and responder recipes, you can customise them to meet your individual requirements. For example, different recipes can be applied to different compartments within Oracle Cloud Infrastructure.
The diagram below is an example of the flow for Oracle Cloud Guard using the scenario of an object storage bucket that has been made public. It shows how Cloud Guard identifies the problem based on its detectors, and uses a responder to automatically (or with approval) remediate the problem, thus making the bucket private again. As you can see, Cloud Guard minimises the period of time the security risk is increased and the security posture is affected.
Oracle Cloud Guard is focused on delivering tailored, useful information. Therefore, the dashboard gives you key information like a security score rating, risk score and top ten recommendations.
Have a look at this demo scenario I have recorded below during the limited availability programme. Click the image below to watch.
Finally, don't forget that Cloud Guard for OCI is provided at no-additional cost within your OCI tenancy. To Learn more about Oracle Cloud Guard and how you can adopt it for yourself, please visit our website.