Enabling and Disabling Rules¶
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.
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.
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:
Navigate to the Rules page in Fugue.
Toggle the switch at the end of the row:
An enabled rule is purple with a checkmark:
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:
In the image below, the rule “IAM root user access key should not exist” has been disabled, as shown below.
It is displayed as
Passed on the compliance pages.
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
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.
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.
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.