Custom Policy Request Requirements

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

Policy Logic and Evaluation Criteria

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

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:// - 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] 0.0.0.0/0
   TCP inbound [port range] 0.0.0.0/0
   TCP inbound [port range] 0.0.0.0/0

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 from 3-5 business days depends on the policy complexity and completeness of the original request.