Rules and Rulesets

All CloudGuard components, Posture Management, Intelligence, and Image Assurance, use a combination of rulesets to test your environments. Rulesets contain rules, which are individual tests of function in your environment. For example, a rule can test if a password policy is enforced.

Rulesets Management

There are two types of rulesets management:

CloudGuard-Managed Rulesets - CloudGuard includes a set of built-in rulesets developed by its research team. These rules test your environments for compliance with best practices and with the same cloud security standards, such as PCI-DSS, HIPAA, and CIS Foundations for AWS Amazon® Web Services. Public cloud platform that offers global compute, storage, database, application and other cloud services., Azure Collection of integrated cloud services that developers and IT professionals use to build, deploy, and manage applications through a global network of data centers managed by Microsoft®., GCP Google® Cloud Platform - a suite of cloud computing services that runs on the same infrastructure that Google uses internally for its end-user products, such as Google Search, Gmail, Google Drive, and YouTube., and Kubernetes Kubernetes, often abbreviated as “K8s”, orchestrates containerized applications to run on a cluster of hosts.. They include remediation steps that you can apply to your environment.

Periodically, CloudGuard research team update the rulesets based on the recent changes, for example, add rules, delete rules, etc. From January 2024, CloudGuard-managed rulesets have designated versions. For more information about versions, see Viewing a Ruleset Version.

Note - When remediation steps are applied to an environment, and CloudGuard is updated (time may change, based on internal sync intervals). Run the assessment again to verify the remedy.

Customer-Managed Rulesets - Although the CloudGuard-Managed rulesets cannot be changed, you can clone them to make a copy and then change the copy. You can find your modified rulesets if you filter them by the Customer Managed type.

Severity Levels

While in CloudGuard each finding has its triggers and conditions, the information below describes the general criteria and implications to reflect finding risk.

CloudGuard assigns each finding one of five severity levels:

Informational - There is no security or infrastructure risk. Administrator awareness is recommended.
Low - There is no security or infrastructure risk. The response is based on best practices.
Medium - A possible security risk exists. Action is required in reasonable time.
High - This may lead to a possible risk. Immediate action is required.
Critical - An asset is compromised. Immediate action is required.

Severity Criteria and Implications

Three criteria below define and affect these severity levels:

Infrastructure exposure: - If a finding shows an infrastructure exposure that is not necessary, which can provide attackers a possible ground for exploitation.
- None - There is no risk of infrastructure exposure.
- May lead - Some conditions can cause infrastructure exposure.
- Exists - There is an infrastructure exposure.
Information disclosure: If a finding describes an information disclosure, which can lead to sensitive data exfiltration and can be used maliciously.
- None - There is no risk of information disclosure.
- May lead - Some conditions can cause infrastructure exposure.
- Exists - There is an information disclosure.
Possible impairment: - If a finding describes a lead to infrastructure or information impairment, in terms of security, misconfiguration, or maintenance.
- None - There is no risk of impairment
- May lead - Some conditions can cause infrastructure exposure or information impairment.
- Exists - There is a lead for an infrastructure or information impairment

In addition, each severity level correlates with two implication levels:

Level of required action:
- None - No action is required.
- Advised - The response is based on best practices.
- Not immediate - Action is required in a reasonable time.
- Immediate - Immediate action is required.
Compromised assets:
- None - The asset is not compromised.
- Compromised - The asset is vulnerable.

Severity Matrix

The table below shows the relationship between each severity level and the mentioned criteria and implications. For each finding, its severity is defined by the highest severity that meets a minimum of one criterion.

Severity	Criterion			Implication
Severity	Infrastructure Exposure	Information Disclosure	Possible Impairment	Compromised Asset	Action Level
Informational	None	None	None	None	None
Low	None	None	None	None	Advise
Medium	May lead	None	None	None	Not immediate
High	Exists	May lead	May lead	None	Immediate
Critical	-	Exists	Exists	Compromised	Immediate

Malicious IP Classification

For rules that identify malicious IPs, CloudGuard uses Check Point's ThreatCloud technology. The table below explains the meaning of each IP category.

Class	Description
Unclassified	The service could not classify the IP. There is not sufficient data about this resource.
Adware	The IP domains operate in the gray areas of the law, collecting private data on the users, and show unwanted content or a website that contains sub-application to download.
Volatile	The IP domains contain malicious software, for example, hacking websites.
Benign	Legitimate IP that is not malicious.
CnC Server	Command and control of malware.
Compromised Server	Legitimate IP that was hacked and operates a malicious function.
Phishing	The IP domains attempts to get sensitive information such as usernames, passwords, and credit card details (and sometimes, indirectly, money), frequently for malicious reasons, by masquerading as a trustworthy entity in electronic communication.
Infection Source	The IP domains can infect their visitors with malware.
Web Hosting	The IP domains allow you to rent out space for websites to have your business in.
File Hosting	The IP domains allow you to rent out space for storage to have your business in.
Parked	The IP domains permanently do not have content. Possibly, they contain advertising content on pages that have been registered but do not (at this time) have initial content.
Scanner	The IP is a known Internet scanner.
Anonymizer	The IP is a known Tor (The Onion Router) anonymity proxy server.
Cryptominer	The IP domains are used for crypto mining.
Spam	The IP domains are used for spam.
Compromised Host	The victim's IP.

CloudGuard Rules Repository

CloudGuard Compliance Engine is an end-to-end security and compliance solution for assessment, remediation, and continuous security compliance enforcement. The CloudGuard GSL (Governance Specification Language) is a syntax to configure cloud security and compliance rules that can be applied in assessments for your environments with the CloudGuard Compliance Engine.

The Cloud Security Posture Repository is a shared security and compliance knowledge platform for AWS, Azure, GCP, and Kubernetes. It provides an evolving set of security and compliance best practices, curated and developed by CloudGuard. The controls include risk and remediation details needed for security governance and compliance with public cloud environments.

Actions

Viewing a Ruleset Version

For CloudGuard-managed rulesets, you can select a particular version to adhere to or automatically receive updated versions of the rulesets.

Navigate to the Rulesets page.
Click Add Filter and select Type > CloudGuard Managed.
Click a ruleset for which you want to see the available versions.
From the list on the top bar, see:
- Latest to automatically use the most recent ruleset version.
- a particular version that you can select to adhere to in the future.

Note - If you change the ruleset version from the ruleset page, it does not affect the policies. To adhere to a specific ruleset version, select it when you edit or add a new Continuous Posture policy.

Adding Rules to a Ruleset

Add rules to a ruleset. You can add rules to custom rulesets (new policies that you add), but not to preconfigured rulesets.

Navigate to the Rulesets page and select the ruleset.
Click New Rule to add a rule to the policy. This opens the online GSL rule builder (see Governance Specification Language (GSL)).
Enter a name for the rule and, optionally, a description, remediation (corrective steps), compliance sections that the rule covers, and a severity level (that is, the severity or effect of non-compliance with this rule).
Enter the rule in the GSL Editor box with GSL syntax, then click Test to check the rule. When you finish, click the Done button. The rule appears from the list of rules for the policy. You can enter the rule as text, in the Free text mode, or graphically, in the Builder mode.
Optionally, add Automatic Remediation with CloudBots tags in the Compliance Section of the rule. These tags are used only if the rule is used in a Continuous Posture policy. They show a remedial CloudGuard CloudBot to be run if the rule fails in an assessment. The tag has the form:

AUTO: ec2_stop_instance

The prefix 'AUTO' indicates that this is an auto-remediation tag. The expression that follows the tag is the name of a remediation bot (for example, 'ec2_stop_instance') followed, optionally, by parameters. You can add more than one tag for a rule, in which all the remediation actions are done if the rule fails.
Add more rules as needed.