Enabling and Disabling Rules

Note

Fugue’s infrastructure as code (IaC) security features for repository environments are now available in closed beta. Fugue IaC security integrates with Regula to scan code files locally and in CI/CD pipelines. Repository environments currently utilize compliance settings that are configured locally with Regula. In a subsequent release, users will be able to manage which rules are enabled/disabled with the Fugue SaaS UI, API, and CLI.

Note

Rules are disabled or enabled for all relevant resources across all environments with associated compliance families. To waive a rule for one or more resources in a single environment, see Rule Waivers.

Fugue’s enable/disable rule feature allows you to disable or enable Fugue rules or custom rules at the organization level. Most Fugue rules are enabled by default when they are released, but some are disabled by default to minimize disruption to your compliance results.

  • When a rule is disabled, it is no longer applied to any resource in any environment.

  • When a rule is enabled, it is applied to relevant resources in environments with associated compliance families.

Rule changes take effect for an existing environment after that environment’s next scan (whether manual or scheduled). See Effects on Compliance in an Environment to learn how these changes affect your environment.

Newly created environments do not have disabled rules applied.

Note

Only users with the Admin RBAC policy can enable and disable rules.

How to Enable or Disable a Rule

To enable or disable a rule, follow the steps below:

  1. Navigate to the Rules page in Fugue.

  2. Find the desired rule in the table. You can search by a number of terms (such as provider, name, etc.) and sort by name or severity.

  3. Toggle the switch at the end of the row:

_images/rule-toggle.gif

An enabled rule is purple with a checkmark:

An enabled rule is purple with a checkmark.

A disabled rule is gray with an X:

A disabled rule is gray with an X.

Changes take effect for an environment after its next scan. You can confirm that a rule has been enabled or disabled by selecting an applicable resource on the Compliance by Resource tab of an environment with an associated compliance family.

In the image below, the rule “Virtual Machines data disks (non-boot volumes) should be encrypted” has been enabled, and you can see it on the Compliance by Resource page for an applicable resource:

_images/rule-enabled-compliance-by-resource.png

In the image below, the rule “IAM root user access key should not exist” has been disabled, as shown below.

_images/rule_disabled.png

It is displayed as Passed on the compliance pages.

_images/rule_disabled_compliance_resource.png

Rules Enabled/Disabled by Default

Fugue’s policy team frequently adds new rules to the application to reflect new platform support/service coverage and identify additional misconfigurations and threats. Most of the time, these rules will be enabled by default when released, but on occasion, Fugue will disable specific new rules by default when:

  • A rule will fail for resources with default configurations (ex: VPC network ACLs should not allow ingress from 0.0.0.0/0 to port 3389)

  • A rule has a low or informational severity rating

Fugue’s release notes indicate whether new rules are enabled or disabled by default upon release.

Effects on Compliance in an Environment

Compliance calculations (resource compliance, control compliance, and rule results) are recalculated at the next scan to reflect only rules that are enabled.

As a result, enabling and disabling rules may generate compliance events for resource evaluations:

  • You may see that a noncompliant resource becomes compliant after all failing rules are disabled.

  • You may see a compliant resource become noncompliant after any failing rule is enabled.

If you have notifications enabled for compliance events, you will be alerted to the compliance changes after the environment’s next scan.

Enabling and disabling rules may cause compliance changes for control evaluations as well, though they don’t produce compliance notifications:

  • You may see that a noncompliant control becomes compliant if all of its corresponding failing rules are disabled.

  • You may see a compliant control become noncompliant after any corresponding failing rule is enabled.

If you delete or disable a custom rule, the rule is not removed from an environment until after the next scan. The deleted or disabled rule continues to display in the environment’s compliance tabs and the pass/fail results count toward your compliance posture. After the next scan, the rule is removed from the environment and results are not counted toward your compliance posture.

Reports and exported data do not show rule violations for disabled rules.

Note

The following are automatically considered compliant:

  • A resource without any rules applied to it.

  • A compliance control whose corresponding rules are all disabled.

Example of Effects on an Environment

For example, suppose your organization has a requirement that AWS IAM password policies should require a minimum length of 12 characters. You might choose to disable the rule “IAM password policies should require a minimum length of 14.”

Since the rule maps to CIS AWS (v1.2.0) 1.9, an environment with the CIS AWS (v1.2.0) compliance family enabled would show this control as compliant, because the only corresponding rule was disabled.

If the environment has a password policy requiring only 12 characters, the rule would no longer produce a FAIL rule result for the password policy – in fact, there would be no result at all for that rule. If the password policy passes all other rules, its resource evaluation would be compliant.

Rules can map to multiple compliance controls, and compliance controls can map to multiple rules. In this example, an environment with SOC 2 (v2017) enabled could also reflect compliance changes.

If you then enabled the rule, it would be applied to environments with corresponding compliance families again. An environment with a password policy requiring only 12 characters would show a rule result of FAIL, and the resource evaluation would be noncompliant. CIS AWS (v1.2.0) 1.9 would also have a noncompliant control evaluation.