Introduction to Conformity Rules

Contents

What rules does Conformity support?

What is the frequency of running the rules?

What rules are run?

New Accounts

Rules configuration

Rule settings

Anatomy of a rule

Check summary

Not scored

Deprecated Rules

Rules supported by Real Time Monitoring

FAQs

Cloud Sentry FAQs

What rules does Trend Micro Cloud One™ – Conformity support?

Conformity supports over 540 rules founded on cloud and security governance best practices, and Compliance Standards.

Conformity's rules cover the 6 categories of security and governance best practices:

1. Security
2. Cost Optimisation
3. Operational Excellence
4. Reliability
5. Performance Efficiency
6. Sustainability

Rules are run against your cloud account services, resources, their settings, and configurations.

What is the frequency of running the rules?

Conformity rules are run:

1. Periodically on your added Accounts by the Conformity Bot, or
2. In real-time for selected rules, if you have the Real-Time Monitoring subscription turned on for your account.

What rules are run?

Refer to Conformity Knowledge Base for all the rules supported by Conformity.

• Is there any rule that looks for open access to all ports? Rule: EC2-001 (Security Group Port Range) checks for any range of open ports including all ports.
• Are all the rules in AWS Config included in Conformity? We support every rule in AWS Config as soon as they become available through config:DescribeConfigRules API

If Conformity doesn't support a rule you need, you have the option to create custom rules using AWS Config Service.

New Accounts

When an account is first added to Conformity, a set of default rules will be run on the account by the Conformity Bot.

Rules configuration

Rules can be configured to better cater to your organisation's circumstances and governance needs. Some rules require configuration before they can be run, and all rules have configuration options including adjusting severity and enabling/disabling.

See Rule Configuration.

Rule settings

There are common rule settings (such as new rule behavior, and rule configurations) that can be managed at the Cloud Accounts level. See Rule settings.

Anatomy of a rule

A Conformity rule is run against an AWS (or other Cloud Provider) or Conformity Service. For example Guard Duty, CloudTrail, Conformity. A full list of services can be found on the Knowledge Base.

Conformity runs Checks for each Rule against the Service and or Service resources, the Rule belongs to. Checks can fail or succeed and are captured by Conformity's numerous reporting tools.

Note: New rules or rules that are updated will be marked accordingly for 10 days after the release.

Check summary

Provides a count for different check statuses. See Model: Check for more info on each status.

Not Scored

Conformity creates checks with the status 'Not Scored' for specific rules. A 'Not Scored' check is an informational marker or notification for when a Failure or Success condition can't be explicitly assessed. They may help you conduct a manual audit of a recommended configuration, or provide partial information about resources in your account.

Possible 'Not Scored' Scenarios

• Some recommendations are required for certain compliance standards, but may not be practical or possible to assess via a scan of cloud resource metadata. For example, limitations with the API or SDK response from the cloud provider may restrict rule development. In this scenario you may see a single 'Not Scored' check saved to your account checks for the given rule.
• The recommendation may not be directly applicable to your cloud resource configuration, for example it may relate to an external configuration or internal setting within a resource that is not assessed at the level of the cloud resource metadata.
• A relevant automated check may only be partially possible, for example if additional contextual information is required to fully determine the Failure or Success condition. In this scenario, you may see a 'Not Scored' check with respect to a particular cloud resource.
• Informational findings may be ingested and saved as 'Not Scored' checks from certain cloud native services.

For more information see Model Check.

Deprecated Rules

Rules marked for removal by Conformity are identified as Deprecated Rules.

Why are rules marked for deprecation?

A Deprecated Rule has been identified for future removal because the associated recommendation is either no longer valid, has been superseded by another recommendation, or has been incorporated into another rule recommendation.

How do I know a rule is deprecated?

The rule title and associated Knowledge Base page will reflect whether a rule is deprecated. A warning message will display in an account's Rule Settings and in Profile Settings if a rule marked for deprecation has been configured.

What should I do if I have configured deprecated rules in an account?

Deprecated Rules should be left with default settings in place. This is important to avoid disruption on your account for when the rule is later removed.

If a deprecated rule is configured in a Account Rule Settings, to edit via the Dashboard:

1. Click on the account and navigate to Settings, Rule settings and click Update rule settings
2. Search for the offending rule and click Configure
3. In the rule settings window, click Reset to default

What should I do if I have configured deprecated rules in a Profile?

If a deprecated rule is configured in a Profile, to edit via the Dashboard:

1. Click on the Profile
2. Search for the offending rule
3. Click the Reset button to remove any rule settings
4. When asked to if you are sure you want to remove the rule setting, click Yes, remove it

If you have any Profile JSON files stored elsewhere, remove all the configurations connected to the deprecated rule and follow your normal Profile update processes.

Rule Removal

After a rule has been deprecated for some time, we will remove the rule entirely from the system. To ensure there is no disruption, do not forget to leave the rule in the default state.

Rules supported by Real Time Monitoring

AWS

Azure

GCP

Conformity

FAQs

1. A rule is marked as "New" or "Updated" on Conformity web interface. What does it mean?
   Rules that are updated and new rules are marked as "Updated" and "New" for 10 days after the release. Updates include changes to rule behavior, bug fixes, improvements, new settings, changes to default settings, changes to default risk level, etc.
2. Why does an AssumeRole action trigger a failure for our blacklisted region rule?
   Sometimes regions get picked up by the browser from the last session. Say the user’s last action was in us east 1. When the user next logs in, the console login may be us east 1 even if user normally logs in to eu west 1.
3. Is there a rule to check for S3 buckets with static website hosting option turned on? I created a bucket with static website hosting turned on, and it didn't trigger any violations.
   Refer to the link: S3 Buckets with Website Configuration Enabled
4. How are the AWS Inspector Findings risk levels calculated by Conformity?
   AWS Inspector Findings risk levels are calculated in the following way:
   Inspector.severity = High; Conformity risk level = HIGH
   Inspector.severity = Medium; Conformity risk level = MEDIUM
   Inspector.severity = Low; Conformity risk level = LOW
   Otherwise Conformity risk level = LOW
5. How are the GuardDuty Findings risk levels calculated by Conformity?
   GuardDuty Findings risk levels are calculated in the following way:
   GuardDuty.level >=7.0; Conformity risk level = HIGH
   GuardDuty.level >=4.0 & GuardDuty.level <=6.9; Conformity risk level = MEDIUM
   Otherwise Conformity risk level = LOW
6. How are the Macie Alerts risk levels calculated by Conformity?
   Macie Alerts risk levels are calculated in the following way:
   Macie.severity = Critical; Conformity risk level = EXTREME
   Macie.severity = High; Conformity risk level = HIGH
   Macie.severity = Medium; Cloud Conformity risk level = MEDIUM
   Macie.severity = Low; Cloud Conformity risk level = LOW
   Macie.severity = Informational; Cloud Conformity risk level = LOW
7. Adding several trusted accounts is a very time-consuming process. Is there a better way to do it?
   If you are adding several trusted accounts, you can perhaps use the Conformity API. Trusted accounts are part of Cross Account rules. Example here - https://www.cloudconformity.com/knowledge-base/aws/SQS/sqs-cross-account-access.htmlYou can use update rule setting endpoint - https://github.com/cloudconformity/documentation-api/blob/master/Accounts.md#update-rule-setting
8. We have experienced some issues with ACM Certificates expiring recently. It is my understanding that Conformity has rules for 7 Days (ACM-002), 30 Days (ACM-003), and 45 days (ACM-004) before expiry. However, when I visit our dashboard and filter by the ACM service I can only see ACM-004. I just wanted to clarify whether Cloud Conformity account is checking for all of the ACM certificate expiry rules. If they are being checked, is it possible for you to explain why am I unable to see them when filtering by ACM?
   Only one of ACM Certificates Renewal rule - 2,3,4 generates a Check at any given time to avoid overlap
   a. ACM-002 Certificate will expire within 7 days
   b. ACM-003 Certificate will expire between 7 and 30 days
   c. ACM-004 Certificate will expire between 30 and 45 days
   
   The reason for producing one Check out of ACM-002, ACM-003, an ACM-004 at any given time is to avoid overlap and create a reliable conformity score:
   ACM-002 is high risk
   ACM-003 is medium risk
   ACM-004 is low risk
   Between 45 and 30 days you receive a low risk Check; between 30 and 7 days you receive a medium risk Check; and eventually, between 7 days and expiry, you get a high risk Check.
9. Is there a rule to detect whether CloudTrail is configured to log to S3?
   Yes. CloudTrail Enabled rule detects whether CloudTrail is configured to log to S3. S3BucketName is required for configuring a trail.
10. Is it possible to check for log ons from users that aren’t whitelisted
    Sign-In Events rule checks Sign-In Events for IAM and Federated Users. Also, the User signed in to AWS from an approved country rule detects a user authentication session from an unapproved country.
11. Is it possible to detect if an RDS Snapshot is shared publicly?
    Yes. Amazon RDS Public Snapshots rule detects any public RDS snapshots.
12. Can we export cloudwatch logs from an EC2 instance and generate alerts?
    Conformity doesn’t have access to CloudWatch logs so we cannot generate alerts from of EC2 instances.
13. Does RTM-004 and RTM-006 run for Cloud One users?
    The rules; RTM-004 (Cloud Conformity user has signed in without MFA) and RTM-006 (Users signed in to Cloud Conformity from an approved country) run for Standalone Conformity only and do not run for Cloud One users.

Cloud Sentry FAQs

Q: What are the Conformity rule exceptions for Cloud Sentry and why?

Cloud Sentry feature has undergone thorough testing including security and performance in order to meet cloud configuration best practices. The following rules failures may occur:

• Lambda-009 - Enable Encryption at Rest for Environment Variables using Customer Managed Keys: Sentry resources are securely encrypted with default keys. In addition, the environment variables do not contain any secrets, so adding additional encryption using customer-managed keys is not required.

• SecretsManager-001 - Secret Encrypted With KMS Customer Master Keys: Sentry resources are securely encrypted with default keys so adding additional encryption using customer-managed keys is not required.

• Lambda-001: Lambda Using Latest Runtime Environment: Sentry ensures that all our Lambdas use a Supported Runtime Environment with no End Of Life date. All supported runtime environments receive frequent security updates from AWS.

• Lambda-003 Lambda Tracing Enabled: Sentry ensures that this feature is throughly tested before the release hence this additional visibility via Enabling Tracing is not required.

• SecretsManager-002:Secret Rotation Enabled: Sentry uses its own secrets feature instead of the one provided by AWS hence enabling the AWS provided Secret Rotation feature is not required.

• SecretsManager-003: Secret Rotation Interval: Sentry uses its own secrets feature instead of the one provided by AWS hence enabling the AWS provided Secret Rotation feature is not required.

• S3-024:S3 Transfer Acceleration: The Sentry feature does not use the transfer acceleration feature.

• Lambda-006: Using an IAM Role For More Than One Lambda Function: Sentry employs a strategy called "permission planes” where Lambda functions that require identical permissions use a single IAM role. This ensures both efficiency and manageability when deploying to multiple regions e.g. reduction of the number of IAM roles used in a customer’s cloud account.

• Lambda-007:VPC Access for AWS Lambda Functions: Sentry does not utilize resources like Redshift, ElastiCache, and RDS which may require a VPC implementation.

• CFM-001: CloudFormation Stack Notification: Sentry Cloudformation stack is already managed via V1 CAM instead AWS.

• CFM-002: CloudFormation Stack Policy: Sentry Cloudformation stack is already managed via V1 CAM instead AWS.

• CFM-005:CloudFormation Stack Termination Protection: In order to give customers control of the stacks in their environment, Sentry does allow users to deactivate and remove the stack from their account.

• S3-025: S3 Buckets Encrypted with Customer Provided Keys CMKs: Sentry is already encrypted using S3-Managed Keys.

• SQS-006:SQS Dead Letter Queue: Sentry implements Dead Letter Queue (DLQ) in some of its SQS resources where applicable.

• S3-013: S3 Bucket MFA Delete Enabled: Objects stored in S3 for Sentry are relatively short-lived requiring MFA for all delete actions would greatly increase operational toil for Customers using the Sentry feature

• S3-023: S3 Object Lock: Objects stored in S3 for Sentry are relatively short-lived locking specific objects would impact lifecycle and deletion policies for Sentry Lifecycle objects

What to do next?

To prevent these failures from affecting compliance of your cloud accounts, exclude Sentry resources from the rules above, you can create a rule exception using the resource tag. The rule failures are introduced by the Sentry resource that you can easily manage using rule exceptions with the resource tag - AppManagerCFNStackKey: C1 Sentry in the following two ways:

1. Set up Rule Exceptions using the tag

2. Use Profiles

   2.1. Create a Profile

   2.2. Configure the new Profile with Rule Exceptions.

   2.3. Apply Profile to Account.

   2.4. In the Overwrite window > Select Include Exceptions > Merge Profile with the desired account to apply rule exceptions.

You can also Configure an Organization Profile with the rule exceptions to apply these settings to all accounts in your Organization and override your default rule settings.