Interested in pre-deployment compliance checks? Our open source tool Regula evaluates Terraform for security and compliance prior to deployment.
For instructions on manually bringing noncompliant resources back into compliance, see the Rule Remediation Steps.
Fugue can check the cloud resources in your environment for compliance with the compliance families you select:
Fugue also supports custom compliance rules.
You may select any combination of compliance families, including none if you prefer. To change the selected compliance families, see the FAQ.
A control is a specific recommendation within a compliance family. Example: PCI DSS 1.3.5. A rule checks cloud infrastructure configurations to determine whether a resource, region, or account complies with a specific policy. Example: “VPC flow logging should be enabled.” Rules and controls map to each other. To learn more, jump ahead to Compliance Concepts.
Your overall compliance state for each environment is shown on the All Environments page shown when you log in:
Select the name of an environment to see its dashboard. You’re taken to the Compliance page, which shows overall and detailed compliance state:
Browsing the Data¶
The main elements of the Compliance page include:
The Environment Summary¶
Scanned resources shows the total number of resources that were scanned.
Compliant resources shows the total number of resources that are compliant based on the standards you’ve selected.
Noncompliant resources shows the number of resources that are noncompliant based on the standards you’ve selected.
Each compliance family shows how many of its controls are compliant.
The Compliance Tabs¶
There are three Compliance tabs:
5. Compliance by Resource¶
For each resource, the Compliance by Resource tab also shows:
If you select the resource, the details will expand to show the following:
6. Compliance by Resource Type¶
The Compliance by Resource Type tab shows resource evaluations grouped by resource type and shows a ratio of compliant to noncompliant resources.
Filtering is available based on the tab selected and varies along with the way the data is organized and displayed:
Compliance by Resource filters
Compliance by Resource Type filters
Compliance by Control filters
What is a rule?¶
A rule checks cloud infrastructure configurations to determine whether a resource, region, or account complies with a specific policy. For example, the rule “IAM password policies should require a minimum length of 14 characters” checks whether an AWS account has an appropriately complex IAM password policy. The rule “Virtual Machine data disks (non-boot volumes) should be encrypted” checks whether an Azure data disk resource has encryption enabled.
What is a control?¶
A control is a specific recommendation within a compliance family that defines a process, policy, or approach. For example, PCI-DSS 1.3.5, “Permit only ‘established’ connections into the network,” is a control.
How do rules relate to controls?¶
Rules map to one or more controls, and controls map to one or more rules. For example:
The control PCI-DSS 1.3.5, “Permit only ‘established’ connections into the network,” maps to these rules:
“VPC flow logging should be enabled”
“VPC default security group should restrict all traffic”
The rule “VPC flow logging should be enabled” maps to these controls:
PCI-DSS 1.3.5, “Permit only ‘established’ connections into the network”
ISO 27001 A.12.1.3, “The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure the required system performance”
Some compliance families are more prescriptive than others. For example, the CIS Foundations Benchmarks recommend very specific configurations, and therefore a CIS Foundations Benchmark control maps to a single rule. In contrast, SOC2 controls are much broader in scope and map to many rules (and vice versa), impacting different AWS and Azure resource types.
What is a rule result?¶
A rule result is determined by evaluating a rule on a specific resource, region, or account, and it has one of the following values:
Pass: The resource meets the rule’s set of conditions
Fail: The resource does not meet the rule’s set of conditions or a required resource is missing
Unknown: An error prevented the rule from being evaluated
Waived: The result was waived for this rule and resource
The relationships between a rule and the underlying resources (or accounts, regions) that are being evaluated form the core of higher-level compliance calculations such as resource evaluations and control evaluations. In both cases, values are determined from the underlying rule results.
You can view results for all rules applied to a resource by selecting the resource on the Compliance by Resource page:
Above, the resource
fugue-bucket-example has one
Passed, and one
Waived rule result.
What is a resource evaluation?¶
A resource evaluation is a compliance value for a resource based on the rule results for all applicable rules. If the resource fails any applicable rule (e.g., if there is a single rule result with a “fail” value), the resource evaluation is noncompliant. If the resource passes all applicable rules (e.g., there are no rule results with a “fail” value), the resource is compliant.
A resource evaluation may be different for a given resource depending on which rules are applied.
For example, an Amazon S3 bucket might pass all the rules associated with SOC2 and therefore be compliant in that context. On the other hand, when evaluated against all applicable rules in an environment (e.g., rules mapping to other compliance families), it might have one or more “fail” rule results and therefore be noncompliant.
What is a control evaluation?¶
A control evaluation is the compliance value of a control based on the results of all applicable rules. If any resource fails any rule that maps to a control (e.g., if there is a single rule result with a “fail” value), the control is noncompliant. If all applicable resources pass all the rules that map to a control (e.g., there are no rule results with a “fail” value), the control is compliant. If the control can’t be assessed because a required resource doesn’t exist or Fugue lacks permission to assess it, the control’s value is Missing Data. Note that “missing data” is called
Unknown in the API.
For example, if PCI-DSS was selected for an environment, an Amazon VPC without a flow log could pass the rule “VPC default security group should restrict all traffic” but fail the rule “VPC flow logs should be enabled.” Since both rules map to the control PCI-DSS 1.3.5, “Permit only ‘established’ connections into the network,” the control is noncompliant.
Control evaluation values¶
There are three outcomes for control evaluations, viewable on the Compliance by Control page:
All resources pass the control’s underlying rules.
One or more resources fails one or more of the control’s underlying rules.
- Missing Data (labeled
Unknownin the API)
A control can’t be assessed because it requires a specific resource, but the resource doesn’t exist or Fugue lacks the necessary permissions to assess it.
You can hover over the
i symbol next to the Missing Data label to see which resources are required:
Rule Severity Definitions¶
Rule severity establishes the level of risk posed by a misconfiguration to the security posture of your cloud infrastructure.
Critical: A misconfiguration that directly exposes infrastructure and data to public access or enables attacks to take control of infrastructure via privilege escalation.
IAM root user access key should not exist
SQS access policies should not have global
S3 bucket ACLs should not have public access on S3 buckets that store CloudTrail log files
High: A misconfiguration that may expose information to public access, such as overly permissive security group rules or unencrypted data.
IAM should have virtual MFA enabled for the root account
EBS volume encryption should be enabled
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 22 (SSH)
Medium: A misconfiguration that may not lead to data or infrastructure compromise but represents gaps in security posture such as lack of logging or monitoring that will impair investigation efforts.
IAM password policies should prevent reuse of previously used passwords
VPC flow logging should be enabled
S3 bucket versioning and lifecycle policies should be enabled
Low: A misconfiguration that may violate security best practices, but is unlikely to affect your infrastructure and data or ability to respond to issues.
IAM policies should not be attached to users
Ensure a support role has been created to manage incidents with AWS Support
RDS instances should have FedRAMP approved database engines
Informational: A misconfiguration that is not security-related but may impact operational excellence or cost optimization.
Fugue Best Practices¶
Fugue offers its own compliance family, Fugue Best Practices. The Fugue Best Practices Framework complements the CIS Benchmarks by providing guidance and recommendations to secure cloud resources against advanced misconfiguration exploits. To learn how to enable Fugue Best Practices (and other compliance families), see the FAQ.
FBP includes the following rules. Click the rule ID to see rule remediation steps:
- FBP R001
IAM policies should not allow broad list actions on S3 buckets
- FBP R002
S3 buckets should have all block public access options enabled
- FBP R003
IAM role trust policies should not allow all principals to assume the role
- FBP R004
IAM roles attached to EC2 instance profiles should not allow broad list actions for S3
- FBP R005
S3 bucket policies should not allow all actions for all principals
- FBP R006
S3 bucket policies should not allow list actions for all principals
- FBP R007
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 9200 (Elasticsearch)
- FBP R008
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 9300 (Elasticsearch)
- FBP R009
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 2379 (etcd)
- FBP R010
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 27017 (MongoDB)
- FBP R011
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 27018 (MongoDB)
- FBP R012
VPC security group rules should not permit ingress from ‘0.0.0.0/0’ to TCP/UDP port 27019 (MongoDB)
To learn how to receive daily or weekly emails containing a summary of your compliance state at an environment or organization level, see Compliance Reports.
While Fugue can be viewed as an essential component for maintaining your infrastructure compliance, we cannot provide an explicit guarantee or official certification for any compliance standard(s) or benchmark included in the product. We recommend working with an approved auditor to obtain any official compliance certifications.