📘

See Building Custom Policies for a detailed procedure for creating Custom Policies in Bridgecrew Cloud.

Overview

Custom Policies allow monitoring of cloud infrastructure configuration in accordance with your organization's specific needs. For example, for certain resource types, you may want to enforce a tagging methodology or a special secure password policy; or you may want to restrict usage of a new service.

Bridgecrew Cloud handles custom policies in a manner similar to the handling of built-in policies:

• They are checked in each scan.
• They are reflected in the Incidents list.
• For each Incident, relevant information is displayed, including a list of affected Resources, Guidelines, statistics, etc.
• You can Suppress an Incident for one or more Resources.
• You can create a Jira issue for an incident.

Preparing to Build a Custom Policy

Before building a custom policy you should gather the following:

• Policy Name
• Guidelines - as with built-in Policies, the Guidelines are displayed in each Incident to explain the issue to the user and related personnel for Investigation and prevention in the future.
• Benchmark (optional) - you can associate a Custom Policy with a benchmark and section. The custom policy will be checked in every scan but, when exporting Reports, will only appear in reports for the associated benchmark, in the section defined.
• Cloud Provider and Resource Type - each custom policy must be associated with a Provider and specific Resource Type.

Formulating Custom Policies

Custom policies are defined in this format:

Pass if [Argument] [Equal/Not equal] [Value].

• Legal Arguments differ per Provider and Resource type.
• The Argument dropdown list displays the relevant Arguments.
• Ensure that you use a Value relevant to the specific Argument and Resource Type.
• If you enter an unrecognized argument or value, Incidents will appear for the related resources.

Policy Examples

The table below presents examples of custom policies.

📘

Note

The custom policy "aws-networking-deny-public-ssh" uses 2 rules with arguments for cidr_blocks and to_port.
You can create Policies with as many nested arguments as needed.
For example to express a more complex ingress policy for an AWS security group you could use all of the following arguments:
ingress.from_port
ingress.to_port
ingress.protocol
ingress.cidr_blocks

Scanning Entries in an Array

In addition to creating Policies with multiple rules (as described above), you can create a Policy that checks multiple entries, of the same type, within an array.

Let’s consider this example. You want to scan all the Ingress CIDR blocks for this resource to determine if any = 0.0.0.0/0.

You create the Policy as shown below.

When the scan runs, it checks every ingress object within the array.