Public clouds have made the provisioning, utilizing, and deprovisioning of infrastructure an easy task. A setup that might have required weeks, if not months, can now be set up, used, and destroyed within hours and even minutes.

You can set up a production environment with unprecedented speed with applications available to general public. Companies face the following challenges around ensuring that these quickly deployed applications are secure and integrated into security standards correctly and that they remain easy to manage and monitor:

  • How to ensure that security standards are met.

  • What are these security standards?

  • How to get notifications and corresponding mitigation recommendations when a security rule (either created or provided) Is violated.

  • Is there flexibility to fine-tune these rules?

All these challenges can now be addressed with two services recently announced, Oracle Cloud Guard and Security Zones.

In this blog, we discuss the configuration options that are available with Oracle Cloud Guard. (Cloud Guard is not available for Always Free tenancies.)

Oracle Cloud Guard

Oracle Cloud Guard has two main configuration options. These options deal with how certain violations are detected (detector recipes) and how the violations are responded to (responder recipes). In this blog, we discuss detector recipes and how to customize them.

Detector recipes

Detector recipes are a predefined and preconfigured set of rules. These recipes detect security violations and risks (if any) that are present in your cloud account, based on security best practices of Oracle Cloud Infrastructure (OCI). This recipe has the following variations:

  • Configuration detector recipe: This recipe checks and detects any configuration that violates a security rule, as determined by Cloud Guard’s preprovisioned rules. Examples include Compute instances with a public IP and database patches not applied. This recipe detects configuration violations in your tenancy.

  • Activity detector recipe: This recipe checks and detects any action or activity that violates a security rule, as determined by Cloud Guard’s preprovisioned rules. Examples include the database system being terminated and a subnet being deleted. This recipe detects admin or individual user’s actions that result in security violations in your tenancy.

Customizing detector recipes

Oracle provides a default recipe for both configuration and activity detector recipes. First, clone these recipes. This step is same for both recipes.

A screenshot of the Detector recipes page, with the Clone Detector Recipe window open.

When the new cloned recipe is available, click the recipe name. The recipe details page is then displayed.

Here, you can choose to enable or disable a specific rule or modify its field, such as risk level and number of days if it’s related to an expiration (such as API key expiration date).

A screenshot of the My Configuration Detector recipe page in Oracle Cloud Guard.

The following screenshot shows an example of SSL certification expiration on a load balancer security rule:

Responder recipes

Upon detecting a rule violation through the detector recipe, Cloud Guard can take one of the preconfigured actions. These actions are resource-dependent. It stops or deletes a Compute instance if it has a public IP, makes a publicly visible Object Storage bucket private, and so on. These responder recipes can use more rules to recommend an action, and the selection of rules depends on the resource type.

You can follow the same cloning process as detector recipes and customize responder recipe in the following configurations:

  • Use these policies as is (No need to clone).

  • Modify the rules to meet specific needs (after cloning).

  • Enable and disable responder rules individually (after cloning).

  • Limit the scope for applying individual rules by specifying conditions that must be met (after cloning).

Example use case

Here’s an example scenario on how to configure Identity and Access Management (IAM) policies for Cloud Guard service, depending on the role a user has. We take the example of tenancy administrator and a security-operations (sec-ops) admin and list the policies that should be configured for these roles.

Let’s look at one use case, what kind of IAM policies are required, and what functionality is enabled with those permissions



Lets look a bit closer at one of the Policies to see what kind of permissions it allows;

Sec-ops admin with read-only access to Cloud Guard detected problems:

The tenancy admin can create a group <cgreadproblems> and assign the following IAM policies. In this case, the admin is allowing the sec-ops admin to read Cloud Guard problems across the entire tenancy, but they can modify the policy to only read problems from certain compartments. For more on those use cases, see the Cloud Guard prerequisites.

  • Allow group cgreadproblems to read cloud-guard-problems in tenancy

  • Allow group cgreadproblems to read compartments in tenancy

  • Allow group cgreadproblems to inspect cloud-guard-config in tenancy

  • Allow group cgreadproblems to inspect cloud-guard-risk-scores in tenancy

  • Allow group cgreadproblems to inspect cloud-guard-security-scores in tenancy

With the previous policies, the sec-ops admin now assigned to the group ‘cgreadproblems’ can only read the problems but can’t remediate the problems. They also can’t create or delete targets or recipes in Cloud Guard. The last two policies are only required if the user needs to also read the risk and security scores across the entire tenancy.

Summary

In summary, customizing detector rules enables customer to detect and act upon security violations as they pertain to the specific deployment. It also provides a more accurate security score (risk level as associated to security rules) per customer’s specific requirement.

We discuss responder recipes and managed lists in another blog.

Reference