Skip to main content
Skip table of contents

Custom Policy Request Requirements

The article helps to define the criteria for a custom Compliance Engine policy request.

Request workflows

Policy create request workflow:

  1. Create a service request for every policy.

  2. Provide the following information:

    1. Policy details

    2. Policy logic and evaluation criteria

    3. Violation details

    4. Set of test objects

  3. The policy request is forwarded to policy development team.

  4. The policy is coded and tested against set of test objects (2.d):

    1. Development team might require additional feedback and elaboration on the provided policy logic if they notice a discrepancy between the requested logic and provided test objects.

    2. SLA will be on hold while inconsistency will be addressed.

  5. The policy is delivered to the organization where the set of test objects (2.d) exists.

  6. The request is closed.

Policy update workflow:

  1. Open a new service request and a link to the original Policy.

  2. Outline required changes. 

  3. The workflow continues from section 3 of the Policy create workflow.

Policy Details - Expected Outcome

The expected outcome should include evaluation criteria, along with:

  1. Severity*

  2. Policy Name*

  3. Description*

  4. Tags

* - Required Fields

Example A

Example B

Severity: Low

Policy Name: AWS EC2 Reserved Instance Renewal (180 days before expiration) 

Description: Ensure that your AWS EC2 Reserved Instances are renewed before expiration in order to get a significant discount (up to 75% depending on the commitment term) on the hourly charges. The renewal process consists of purchasing another EC2 Reserved Instance so that Amazon can keep charging you based on the chosen reservation term.

Tags: EC2, AWS, RI, Cost

Severity: High

Policy Name: AWS S3 Bucket Public 'READ' Access

Description: Ensure that your AWS S3 buckets content cannot be publicly listed in order to protect against unauthorized access. An S3 bucket that grants READ (LIST) access to everyone can allow anonymous users to list the objects within the bucket.

Tags: S3, AWS, Security

Policy Logic and Evaluation Criteria

The expected outcome should include all the objects and the condition they should be evaluated at.

Example A

Example B

The group will be INCOMPLIANT if:

The object A exists in the AWS


The object B has a name that contains "prod" 


The source of this rule is IP (not other security group)


The group will be INCOMPLIANT if the bucket name LIKE '%test% AND (NOT Name LIKE '%public%') AND AWS Account is not = 'XXXXXXXXXXXX'

Violation Details

Provide details on how to convert input objects into a human-readable violation. Comment on what pattern to use, how to combine fields from objects, what additional fields and objects to update upon violation occurs, etc. 

Please supply the following:

  1. Description for the violation, when input object is INAPPLICABLE (if a policy sets this status), for example:
    This policy is inapplicable for this object since the object has been deleted on %DELETED_FROM_AMAZON%, and the policy only checks the objects that still exist

  2. Description for the violation, when input object is COMPLIANT with the policy:

    This account is compliant with the policy, because it has %NUMBER_OF_PASSWORDS_TO_REMEMBER% number of passwords to remember, which is greater than %NUMBER_OF_PASSWORDS_SAFE_LIMIT_FROM_POLICY_CONFIGURATION%

  3. Description for the violation, when input object is INCOMPLIANT with the policy:

    This security group has %NUMBER_OF_VIOLATING_RULES% incompliant rules:// - iterate rules

    %PROTOCOL% %DIRECTION% [%FROM PORT% - %TO PORT% if not empty] %CIDRIP OR GROUP%  - iterate descriptions for each rule

    Sample description for the policy that evaluates AWS EC2 Security Groups and attached AWS EC2 Security Group Rules:

    This security group has 3 incompliant rules:
    TCP inbound [port range]
    TCP inbound [port range]
    TCP inbound [port range]

4. Instructions for other fields in the similar format if needed.

Set of Test Objects

Create objects in a test environment, connected to CloudAware that will satisfy the following requirements:

  1. Objects that policy will evaluate as COMPLIANT

  2. [optional] Objects that policy will evaluate as INAPPLICABLE (if policy uses INAPPLICABLE state)

  3. Objects that policy will evaluate as INCOMPLIANT

    1. For complex policies that evaluate multiple states of objects as INCOMPLIANT - provide a test object for each of these states.

    2. If policy accommodates for absence of data due to insufficient collector permissions - provide objects from multiple test environments with different permissions applied.

  4. Other objects that can illustrate the edge cases of the policy.

Provide links and identifiers to created objects and their respective evaluation results: COMPLIANT, INCOMPLIANT or optionally INAPPLICABLE.

The environment should remain static during the whole policy create/update workflow.

SLA and Support

  • All custom policy requests are handled by the policy development team. 

  • Custom policy requests are handled only via Cloudaware Service Desk portal.

  • Expected turn around 3-5 business days depends on the policy complexity and completeness of the original request.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.