...

Creating and uploading Segregation of Duties (SOD) Policies

...

• If an application’s name is changed in Zilla, it will no longer match the policy or an existing upload file (that has the original name). Any application name change needs to be updated in the SOD upload file to update the SOD policies.

• Only applications that Zilla is collecting information for are considered valid in the SOD upload. Applications that have been Archived are considered invalid and must be removed from the upload file as the resulting policy will fail to import.

Wildcard Support (*)

Support for wildcards (*) in the Segregation of Duties rules will match any value as long as it exists. Wildcards are only supported for the entire permission and / or resource (partial wildcards, such as “create*”, “*cash*”, “admin*” are not currently supported. Wildcard options are added to the PermissionA or PermissionB columns for the respective Applications in the SOD CSV file.

For example:

• “*” - This will match any permission in the corresponding application that does not have a resource associated. Note: this will not match any permission that has a resource associated.

• “*: *” - This will match any permission that has any resource associated.

• “permissionName: *” - This will match “permissionName” with any resources. Note: this will not match a permission without a resource, if the policy needs to consider both a permission with and without a resource, two entries are needed: “permissionName, permissionName: *”.

• “*: resourceName“ - This will match any permission with the resource “resourceName”.

Note: the space after the “:” must be included after the colon and before the wildcard or the specified resourceName.

The findings generated will record and display the actual permission and resource that triggered the violation.

Example Segregation of Duties conflicting access matrix

...