Auto Verification

In order for auto verification to function properly, you will need to add ccn:{change-control-number}; in the firewall policy.

To auto associate new rules, the rule created has to match exactly what was proposed for the change logs to be auto associated. It must match not only in address, but in name as well. Auto verification works for recommended and structured tasks. It does not work for unstructured tasks because there is nothing to make a match against.

Each task is independently verified. If there are two tasks on a ticket, you will be able to see if one is verified and one is not. The ticket is only auto-verified if all tasks are successfully verified. In the case of one task verified and one task not verified, the ticket will require manual verification.

Auto Verification Behavior

There are four verification processes for auto verifying rule changes. Theses processes run in order defined in the config file (this can be changed by Pro Services to either re-order them or remove them entirely if they are not necessary for your organization):

• Change Control Number Match

• Change Log Association (Post)

• Management Station Match

• Rule Search Match (Post)

The processes flagged as (Post) only run after all of the other processes both execute and pass (they will not run if the other processes don’t pass). Management Station Match is only applicable in cases where a management station is involved and acts as an override for the Rule Search Match.

When a ticket hits the sequence flow configured in the BPMN BPMN – Service task and timer configured in the BPMN determin at what point in the workflow Auto Verify occurs. Task Properties – Contains configuration options for the following: Number of retry attempts (Ex: “retryCount”: 10) Retry timer configured via an ISO 8601 expression (Ex: “retryTimer”: “PT10M”, once every 10 minutes) Array of elements describing which verification processes are to be run for which policy plan change types. Ex: "verificationProcesses": { "GENERAL": ["fmGeneralVerificationProcess"], "RULE": [fmChangeControlNumberMatchVerificationProcess", etc…] } , auto verification will immediately execute, ignoring any timer or retry configurations. If the ticket as a whole fully verifies with no processes returning a status of VERIFIED_PARTAIL or UNVERIFIED, then auto verification will complete, and the ticket will be immediately moved into the next user task. In the case of the default access request workflow, this is also configured to skip manual verification, and since this is the last user task in that flow, rule doc is executed and then the ticket will be completed. If the ticket has one or more processes which return a status of VERIFIED_PARTIAL or UNVERIFIED, then the ticket will be sent to the auto verify wait user task, utilizing the configured timer and number of retries.

During execution, auto verification iterates through each policy plan change of each policy plan requirement, and executes any verification processes as configured by policy plan change type to each policy plan change. If a policy plan change already has a verification status of VERIFIED, it will be skipped during this stage. An event log is created both at the ticket level indicating that verification has been processed, as well as an individual event log for each verification process that executes with specific details related to that process.

Behavioral Notes

• Number of retries is stored per ticket and persists between auto verification attempts. What this means is, if a ticket has retried their maximum number of times, goes back through redesign then goes through to auto verify again, it will not attempt to retry auto verify beyond the initial immediate attempt. Since auto verify always executes once immediately, it will always attempt auto verification at least once, but once the number of retries is exceeded it will never enter the timer loop again.
• Some policy plan change types may be flagged as skippable, which could result in auto verification not executing even though the ticket as a whole is not fully verified. This currently applies exclusively to GENERAL changes, which are inherently unable to be automatically verified, but still require verification by a manual user. If a ticket passes any other applicable verifications and has GENERAL policy plan changes, it will skip the retries and go directly to the manual verification step.
• Logic coded at a parental layer for all rule verification processes skip any policy plan changes of type rule with an action of NONE. In this scenario, the verification processes do not execute, and no result is generated.
• Logic coded at a parental layer for all rule verification processes determines what policy plan rule associated to the policy plan change is the rule to be verified. This determination is made on the action set on the policy plan rule change:
  • NONE action: There is no rule to verify, rule to verify is null.
  • DELETE action: The referenced rule is utilized for delete actions. If no referenced rule exists, an error is logged and rule to verify is returned as null. If more than one referenced rule is found, a warning is logged as auto verification has no method with which to determine which referenced rule to use. Lacking a better option, it will take the first referenced rule in the list to verify. When only one referenced rule is found, which is the expected scenario, it is used as the rule to verify.
  • Any other action: The tested rule is used as the rule to verify.
• Logic coded at the parental layer for all rule verification processes determines a verification outcome based on the action set on the policy plan rule change combined with the number of results found by the verification.
  • DELETE action: The policy plan rule change is considered verified for delete actions when the number of results found is zero.
  • Any other action: The policy plan rule change is considered verified for any other action when the number of results is greater than zero.

Auto Verify Settings

Section settings for tickets in the Auto Verify task can be adjusted per workflow in the Administration application (Workflows > Edit) to allow configurations to be made to automatically create change plans on tickets. The sections available to edit are dependent on the type of workflow.

• Auto Verify Settings—This setting specifies the key of a workflow field that the Auto Verification service task should reference for values to validate that rules specified in the Policy Planner ticket have been implemented correctly. If the field is left empty or set to a value that is not a valid workflow field key, the Auto Verify falls back to using the Ticket Number to verify change plans were implemented correctly.