Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Use this article to define the criteria for a custom Compliance Engine policy request.

Request workflows

Policy create request workflow:

  1. Customer creates service request for every required policy.

  2. Customer provides the following information:

    1. Policy details

    2. Policy logic and evaluation criteria

    3. Violation details

    4. Set of test objects

  3. Policy request forwarded to policy development team

  4. Policy 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. Policy delivered to the organization where set of test objects (2.d) exists.

  6. Request closed


Policy update workflow:

  1. Customer opens a new service request and links to the original Policy create request.

  2. Customer provides updates to the original request and outline required changes. 

  3. 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: 

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

Example B: 

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: 

The group will be INCOMPLIANT if:

The object A exists in the AWS

AND 

The object B has a name that contains "prod" 

AND 

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

AND 

Etc…

Example B: 

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

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.
    %POLICY.DESCRIPTION%
    This security group has %NUMBER_OF_VIOLATING_RULES% incompliant rules:
    // please iterate rules and for each rule compile following row

%PROTOCOL% %DIRECTION% [%FROM PORT% - %TO PORT% if not empty] %CIDRIP OR GROUP% 

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 - customer must provide test object for each of these states

    2. If policy accommodates for absence of data due to insufficient collector permissions - customer must 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 the service desk.

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

  • No labels