Custom cloud rules

Cloud → Settings → Custom Rules is where you define your own cloud security checks. An enabled rule runs during every CSPM scan, and each asset it matches becomes a finding. Custom rules sit alongside the standard checks Heimdall already runs. Use them for the policies specific to your organisation, such as a tagging standard or an encryption requirement.

​

The rules table

The actions menu on each row lets you edit, test, or delete a rule. Turning a rule off keeps it for later without running it.

​

Starting from a template

Browse templates opens a gallery of ready-made checks for common misconfigurations, including unencrypted S3 buckets, security groups open to 0.0.0.0/0 on port 22, resources missing an Environment tag, IAM users with console access but no MFA, and publicly accessible databases. Use template creates a normal custom rule from the definition, which you can then edit like any other.

​

Writing a rule

New rule opens the rule builder.

​

Details

Name the rule after what it enforces. All S3 buckets must have encryption enabled reads better in a finding than S3 rule 1. Add a description, a severity, and a category of your choosing.

​

Conditions

Each condition tests one field on an asset. The field is a dot-path into the asset record, so metadata.encryption.enabled reads the encryption block Heimdall captured and tags.Environment reads a tag. You can see the fields available on any asset under Metadata on its detail page. The operators are equals, not equals, contains, greater than, less than, exists, and does not exist. The last two take no value.

​

Scope

Scope limits which assets the rule is evaluated against. Leave a field empty to place no limit on it:

• Providers: AWS, Azure, or Google Cloud
• Resource types: specific types such as S3 buckets or EC2 instances
• Regions: a list of regions
• Accounts: specific connected accounts
• Tag filters: key and value pairs, using the same equals, not equals, exists, and does not exist operators

​

Remediation

Guidance explains how to fix a violation and Reference URL links to supporting documentation. Both appear on the findings the rule raises, so whoever picks one up knows what to do.

​

Testing a rule

Test on any rule dry-runs it against your current assets. The result reports how many assets matched out of how many were in scope, and previews the first of them with their name, type, provider, and region. A test writes nothing and creates no findings, so it is the quickest way to check that a condition path is right before you switch a rule on.