Creating an Access Review Campaign

Overview

This document provides instructions on how to define and create an Access Review. This function can be done by admin users.

In this guide you will learn:

The types of access reviews that can be created
How to define the users, applications and permissions to be included
The options for advanced campaign settings
Ways of enabling and controlling email notification and automated escalation

Creating the access review

To create a new campaign, click Create Campaign on the Access Reviews page that lists all the current and completed Access Review Campaigns.

Select the Campaign Type -> Enter a campaign name in Name of Access Review Campaign → Enter description in Description text area field → Select a due date in Campaign Due Date. These fields can be edited at a later date. → Click on Create Campaign button.

A new campaign will be created. User will land on About Campaign tab of the campaign.

Selecting users, applications and permissions

A Campaign monitor can filter the list of users to be included in the access review. By default all directory users are included.

Select the applications to be reviewed. You can filter the list to specific departments or regulations. A warning icon indicates applications that do not have any data or have out of date data. Use the Get Ready feature to collaborate with your company to update your data for your campaign.

The “Limit Permissions to Review” link at the lower left allows you to further customize which permissions for each application will be reviewed, by name. If you do not enter anything here, all permissions for the selected applications will be included in the review.

Limiting permissions in the review

You can limit the review to specific permissions, or you can exclude certain permissions from the review. Enter the permissions you want to include or exclude in the appropriate field; if you want to include/exclude multiple permissions you can specify a list separated by commas. The text is case-insensitive but needs to match the whole name of the permission. You can use an asterisk * as a wildcard: for example, “admin*” will match “Administrator”; “*reader* will match any phrase with “reader” or “Reader” in it. “default” matches Zilla’s default permission for users with no explicitly set permissions.

Limiting permission types in the review

You can also limit the review to certain types of permission, as listed in the “Permission Type” column in the review: e.g. “Role”, “Group”, a plain “Permission”, etc. You do this with the keyword “@type:” in either the include or the exclude column.

Here, “@type: group” in the Include column would include only permissions of type “Group” for the specific application, and “@type: permission, @type: role” in the Exclude column would include all permissions that are not of type “Role” or type “Permission”.

The match is case-insensitive, but wildcards are not allowed for types, and the name must match the entire type. Whitespace after the prefix “@type:” is optional.

Customizing campaign settings

Campaign settings are across three tabs ‘What to Review’, 'Who Reviews”, and “Campaign Options”.

What to Review tab

Who Reviews tab

Campaign Options tab

To customize your campaign for your specific requirements, click Edit in Campaign Settings section.

Edit in “What to Review” tab

Edit in “Who Reviews” tab

Edit in “Campaign Options” tab

Note:

In “Campaign Options” tab, for “Allow Requesting Permission Change”, If you select “Yes - Reviewers get an additional option to request a Change to the existing permission” , any review marked as Change will be tracked on the Report tab as a Revoke.

Allow self-review: This setting can be used to control whether reviewers are allowed to review their own permissions. By default, there is no restriction on this.
- If this is set to “Reassign self reviews to the application Technical Owner”, then when populating the campaign, a review that would go to the reviewee will instead go to the Technical Owner, or if that is not possible, to the first available campaign monitor (or if neither is possible, it will remain unassigned).
- If this is set to “Reassign self reviews to the application monitor”, then a review that would go to the reviewee will instead go to the first available campaign monitor, or if that is not possible, to the Technical Owner (or if neither is possible, it will remain unassigned).
- This setting also disables the individual reassignment of reviews to the reviewee. In bulk reassignments and review delegation, the above rules will be honored.
Require Comments: By default, reviewers' comments on review items are optional. With this setting, you can make them mandatory for certain review actions: Maintain actions, Revoke actions, or all actions. Zilla will require the reviewer to enter an explanatory comment when they make the selected type(s) of action.
- If Change actions are enabled, “Require comments on all actions” will make comments mandatory for them.
Require Comments on Flagged Items/Violations: This makes review comments mandatory for any review items that have policy violation flags on them (currently, this applies to Segregation of Duties violations).

The last several settings all have to do with controlling how review items are automatically assigned to a reviewer, and, in some cases, automatically pre-processed. This can save your organization a lot of time.

Limit Review to Unreviewed Permissions: If set to “Yes”, this allows you to limit the review only to permissions that have not already been reviewed within some period of time. The default is 90 days.
- Note that for this feature to filter out permissions, the permissions must have been continuously present in Zilla since they were was last reviewed. If the permissions were removed from Zilla since then by an application sync (including CSV upload) and then reconstituted by another sync, Zilla will treat them as new permissions that need to be reviewed again.
Limit Review by Account Type: Your application may have distinct types of account (actual users vs. bots, guest accounts, admin accounts, etc.) You can filter the review here to only cover accounts of certain types.
- You can choose to only include certain account types, or to exclude certain account types and include all others. The types are a comma-separated list that is case-insensitive: for example, User,BOT,guest
- Special feature: Reviewing groups. Zilla represents user groups as accounts with the type “Group”. In many applications (e.g. Azure Active Directory), the permissions belonging to these accounts will then be inherited by group members. By default, Zilla access reviews exclude accounts of type “Group”. By changing this setting to “No limit”, or by explicitly including groups, you can choose to review the permissions belonging to groups just as you would the permissions belonging to any type of account.
- Note that this option filters on the type of the account, rather than the type of the permission (which you can do on a per-application basis, covered under “Limiting permission types in the review” above).

See the following pages explaining some specific settings:

Generate Review Based on Pre-defined Business Roles: Automatically filtering access reviews using business roles
Designated Reviewers and Delegates: Fine-tuning review assignments with Designated Reviewers and Review Delegates
Assign Review to Resource Owner: Some permissions are resource permissions, having to do with access to or control of a particular application resource, such as a database. In some cases, these resources have a resource owner already defined. If “Assign Review to Resource Owner” is set to Yes, these review items will be automatically assigned to the resource owner. This setting takes precedence over Designated Reviewers, but not over delegation; that is, if the resource owner has a delegate, the delegate will be the reviewer.
Assign Review to Permission Owner: Some permissions (permissions, roles, groups, etc.) may have a permission owner already defined. (This can be set by editing the Available Permissions pane of the application’s Profile tab, as described in https://zilla.atlassian.net/wiki/spaces/ZILLASUP/pages/edit-v2/2352775169?draftShareId=ddaf37c2-6f29-4d65-9ab1-a8a213d1d509 ). If “Assign Review to Permission Owner” is set to Yes, these review items will be automatically assigned to the permission owner (or permission owners: see “Allow Shared Owner Reviews” below). This setting takes precedence over assignment to Designated Reviewers and Resource Owners, but not over delegation; that is, if the permission owner has a delegate, the delegate will be the reviewer.
Move Review Items Assigned to Inactive/Deleted Users to Unassigned: If set to Yes, review items that would have been automatically assigned to an inactive or deleted user (for instance, if the application owner is inactive/deleted in a shared owner review) will instead become unassigned. If No, inactive or deleted users can still be assigned review items.
Assign Review when Supervisor is Unknown: This setting exists for supervisory reviews only. If the item would be Unassigned because there is no known supervisor (or because the previous setting was enabled and the user was inactive/deleted), the item will go to the application business owner, much as in an application owner review.
Allow Shared Owner Reviews: By default, a permission in an access review can only have a single reviewer at a time. If this setting is enabled, a permission may have multiple reviewers. Currently, we support this for an application owner access review with a list of Additional Owners set, and also for the case of “Assign Review to Permission Owner” with multiple permission owners set. When a permission has multiple reviewers, any one of these reviewers may update the item to recommend an action, or add comments. Any reviewer may also reassign the item, which transfers only that reviewer’s assignment to the new reviewer. A task can be marked complete if all of its items have been reviewed by somebody (not necessarily the owner of the task).

Email notification settings

You can customize the message sent out to reviewers when the campaign is launched. The campaign can be programmed to automatically send out email notifications to reviewers whose reviews are overdue, or to escalate them to the reviewer’s manager. To enable and control these features, click the Edit link for Email Notifications.

The custom message at the top will be incorporated into notifications sent to reviewers when the campaign launches, letting them know they have a review to do. The campaign can also send automated reminders some number of days after the campaign starts or some number of days before it is due to end. (Note that in the second case, if the campaign’s end date is less than this number of days in the future, the reminders will go out immediately!)

For further customizations to the emails Zilla sends on your behalf, such as (but not limited to) changing greetings, language or updating logos, please contact support@zillasecurity.com.

If you enable these features, additional controls will appear. You can separately customize the reminder messages for these emails and control whether or not the reviewer’s manager will get a Cc: of the email.

The Escalation feature will automatically reassign incomplete reviews to the reviewer’s supervisor, some number of days before the campaign’s end. The reviewer and the supervisor will both receive notifications, and you can edit the message that will be included in the reviewer’s notification.

Again, note that if the campaign’s end date is soon enough that the number of days you enter here places escalation in the past, the escalation will happen immediately when the campaign starts.

Finally, it is possible to specify that all campaign monitors will receive copies of all campaign notifications. You can also limit these notifications to the case where a review item becomes (or is created as) unassigned to a reviewer.

Navigate to the Preview Campaign tab to preview the campaign before it is run.

Any questions? Contact support@zillasecurity.com