Add rule documentation for allowing rules

You can add rule documentation to the allowing (and partially allowing) device rules for a change request.

AFA finds these rules during the initial plan and validation queries, and when configured to do so, FireFlow stores the results in FireFlow fields.

You can access these rules and add documentation to them with your own custom scrip. The initial plan results are returned in XML format, and the validation results are returned in JSON format.

Add rule documentation

Do the following:

1. If you want to add rule documentation to allowing rules found in the initial plan query, configure FireFlow to store the allowing rules from the initial plan query. See Enabling/Disabling Storing Allowing Rules From the Initial Plan Query (see Enabling/Disabling Storing Allowing Rules from the Initial Plan Query).

   For each change request, after Initial Planning, the allowing rules found in the initial plan query will be stored in FireFlow.

   Note: If you want to add rule documentation to allowing rules found in the validation query, no FireFlow configuration is required. FireFlow always stores the allowing rules found in the change validation query.

2. Write a scrip to access the desired FireFlow field (see below) to get the list of rules, iterate them, and use the rule documentation API to add the rule documentation.

   For allowing rules from the...	Access this FireFlow field...
   Inital plan query	Initial Plan Results
   Validation query	Validation Results

   Both fields can be obtained from the ticket object. Once obtained, the initial plan results can be easily parsed as XML (see the example output below). The change validation results are in less readable JSON format. Therefore, they have a function that assists parsing the result which is Ticket_Vendor::getAllowingRulesFromValidation.

Allowing rules output format

For rules on Cisco devices, the rule ID will be in the HexUID field in the hash. All other brand's rule IDs will be in the UID field.

In the initial plan results, all the hash keys are lower-case, and in the validation results they are upper-case. For example, in the initial plan results, "uid" will appear as "uid", and in the validation results, "uid" will appear as "UID".

For more details, see:

• Initial plan allowing rules example
• Validation allowing rules example

For additional assistance, contact AlgoSec Professional Services.

Initial plan allowing rules example

Validation allowing rules example