Certification

Overview

Re-Certification is a process that provides organizations with the necessary oversight to maintain a compliant IGA ecosystem.  Re-certification is required by some regulatory bodies such as Sarbenes-Oxley which states that persons of authority, up to the executive level must attest to the access granted to all users immediately under his level within the organization, honoring the Chain Of Trust.  This is an important process for any organization to deploy as it will aid organizations in governing access.  Governing access is the root of IGA and it is essential that those responsible for user access be required by the IGA solution to review, attest and certify the access.  This provides another layer of audit, and creates a culture of governance throughout any organization employing this feature.  Fischer provides multiple types of certifications.  The table below outlines the different types available:

When defining a certification campaign there are many things to consider to ensure the campaign is built efficiently, sufficiently and will meet the necessary governance goals and/or requirements of the organization.  Fischer offers an extensible feature to help any organization build out a process that works for them.

When building our your governance strategy, specifically how your organization will roll out re-certification, consider all the factors before deciding on how to define your campaigns. The factors to be considered are as follows:

1. What access do I want certified? Administrative? Standard End Users? Application Owners? Global Admins? etc?
2. What is the level of risk associated with the access being certified?
3. What is the break point in terms of what should be consistently reviewed versus access that may not? (This should be a follow on question for #2)
4. How many actual types of access will be certified for each certification campaign?
5. How many tasks will this create for our certifiers?
6. What access is bound by regulation?
7. What is the goal of certifying different types of access?
8. Who are the individuals within my organization that should be responsible for the access to be certified?
9. How much time would it take to certify the amount of access we are defining within a single certification campaign?
10. How often is access changing within a given connected system? (The answer to this question will help organizations to start to split the different systems and accesses to be certified within a single campaign)
11. Should we certify by department? By system? By a particular set of policies?

Design Time Details - Administrative UI

The recertification process involves a hierarchical Chain of Trust with certain Identity users designated as certifiers, who are responsible for certifying users’ access to corporate resources. A compliance Assessment and Recertification job is used to define the Chain of trust, certifiers, and the resources to be accessed and certified, including notifications and reminders. The job details not specific to recertification are explained in the compliance job section .

The recertification specific configurations shown in the image below and is explained in the following section.

 Configurations Explained

The following table will outline the features and functions available in the screenshot above:

Technical Review On

Setting the option to "All Actions by Certifier" will require the technical review to occur for all actions taken by the certifier. This equates to post-certification governance after the certifier is finished with his or her certification tasks. Before the certification campaign can complete, the assigned Tech Reviewer just review the certifiers decisions regarding access.

Technical Review Override!

It is very important that organizations understand that the Tech Reviewer has the authority to overrule (i.e. "Confirm" or "Change") the decision made by the certifier. Given the level of authority provided to the Tech Reviewer, organizations must ensure that they are considering their hierarchy as it relates to access decisions before selecting who will be authorized as a Technical Reviewer. An organization would not want this level of authorization granted to someone who does not have the authority to override the decision made by the certifier. Fischer strongly recommends that the Technical Reviewer role be reserved for Compliance and Audit personnel (including third party entities). An organization should never place Technical Reviewer of an entity that may introduce a separation of duty violation. The technical reviewer role should be considered to be a mutually exclusive entity with the authority to govern and effectively change what the certifier allowed, removed or remediated.

The Technical Reviewer role can also be used more strategically to meet oversight and governance requirements of a given organization. To use the Technical Reviewer role in a more strategic way, IGA and/or Compliance Administrators should select the second option, "Specific Action by Certifier". By selecting this option, the other two sub-configurations will become available.

Review All Removal actions before de-provisioning

If this option is selected, the Technical Reviewer will only be brought into the certification campaign when the certifier has decided that access is to be removed from the Identity. This will help organizations to ensure that access granted to the Identity for specific reasons is not suddenly removed because the certifier may not understand the type or level of access they decided to remove or remediate. This approach to technical review will provide organizations with a significant level of oversight to maintain business continuity. Without technical review at this level, a certifier would be able to remove any access they wanted to, which can create problems if the certifier made a mistake and decided to remove access from an Identity that truly does need it.

Review All Actions taken on Exception

If this option is selected, the Technical Reviewer will only be brought into the certification campaign when a certifier is presented with an access exception (i.e. an Identity may have more access than the access control structure says it should have). All decisions made by the certifier as it relates to excessive access will be sent to the Technical Reviewer for final confirmation before the excessive access is removed from the Identity. This is a strategic feature that organizations can utilize not only to maintain business continuity but it also provides an extra step in the governance process. The Technical Reviewer may not be aware that an Identity has excessive access, and including them in any decision made by the certifier as it relates to excessive access may help the Tech Reviewer and the organization gain a better understanding of the type of access Identities need. If the same access exception is constantly popping up, this Technical Review can serve as a flag that an organization may want to consider the access as part of what is provided a particular Identity type.

What if both Tech Review Options are Selected?

Action when certifier(s) of a node is a subset of certifiers at lower level nodes

This is an important option to consider when defining certification campaigns. Once organizations delve into defining dynamic filters in the context defining who the ultimate certifier will be. This is a best practice from a continuity standpoint as opposed to defining a single (static) individual as a certifier, rather the product can automatically resolve who the certifier needs to be as long as an organization employs Fischer's dynamic filtering capabilities. This provides for an entity-based approach to determining who the certifiers are, so as Identities move within an organization, the entity responsible for certifying will remain the same even though it may be a new body in the seat with the Job Title that is qualified and authorized as the certifier. To that end, there can be situations where an individual can resolve to multiple nodes in different contexts. For example a Identity may resolve as the node level certifier for one certification campaign, but that same person may resolve as a lower level certifier within the same certification campaign. This could be for multiple reasons including mis-configuration, or possibly the organization may be smaller in size and the individual may be the top (Node) level certifier for certain access types, but not for others. For this case, Fischer ensures that organizations have an option to configure when Fischer detects this scenario. The options are as follows:

Use Hierarchy

If this situation occurs organizations can allow Fischer to provide oversight and automatic enforcement. If Use Hierarchy is selected, and a top (Node) level certifier is also resolved as a lower level, Fischer will fail the job and notify Compliance Administrators of the situation automatically.

Ignore

As mentioned before. Sometimes organizations needs to rely on the same individual, in different contexts because of personnel or resource constraints. For that scenario, Fischer offers an "Ignore" option. When this option is employed, Fischer will ignore the fact that a top (Node) level certifier is also going to certify access at a lower level (i.e. before it gets to the top level). At this point, the top (node) level certifier will still need to certify the node if configured or required to do so by the job configuration however Fischer will ignore the fact that it is the same person.

Certifier Action on Resource Exceptions when Recertify All is Optional

The "Recertify All" option is defined when selecting the object(s) to be re-certified.

This is presented as a combo box with two options:

Optional

When set to optional, this will provide certifiers with the ability to perform a bulk selection of all pending re-certification tasks and take a global action on all tasks. Organization's should consider the context of what is being certified within the campaign before deciding to allow certifiers to perform a bulk certification which will remove the requirement for the certifier to review each task and potential excessive access individually. Allowing a bulk re-certification may appear on the surface to be a streamlined approach to completing a certification campaign. However, when you consider the oversight that a re-certification process is supposed to provide, allowing a global (bulk) action to occur against many Identities may have unintended consequences. This once again speaks to how you should think through your campaign planning, specifically which access should be brought into a specific re-certification job. Fischer recommends only using this option for low level access if they use it at all.

Mandatory

When set to "Mandatory", the certifier will be required to review each pending certification task and take individual action. This the most secure, least risk approach to executing a certification campaign and should be the default option for any organization attempting to leverage re-certification to provide the added level of oversight and governance the feature is intended for.

The following options are available for configuration when Re-certify all is set to "Optional"

For User Access

While Fischer does provide for organizations to allow bulk certifications, we do offer further granularity as to when this feature is available and more importantly upon which exceptions can it be used. The options available are:

Certify All Exceptions

If this option is selected in conjunction with "Re-certify all" set to Optional, certifiers will have the ability to perform a bulk certification for all actions, including all exceptions that are present.

Certify only New Exceptions

If this option is selected in conjunction with "Re-certify all" set to Optional, certifiers will only be allowed to perform bulk certification for any new exceptions. This means that if a previous certification campaign flagged an access exception and it was allowed, and the next certification job flags the same exception, it is not considered a new exception. Only new exceptions found will be allowed for bulk certification and any previous exception that was flagged in a subsequent certification campaign would require individual action to be taken on each exception found that may have been found in a previous campaign.

For High Privileged and Unassigned Accounts

This certification campaign is specific to a System certification job as defined previously. When a system level job is defined, and it found that the system is also being leveraged for HPAM, the certification job will initiate re-certification tasks for those privileged accounts. It is very important that these accounts are certified on a regular basis given the amount of access they are granted and the level of risk it represents to an organization. Unassigned accounts is an exception thrown when Fischer's Compliance engine finds accounts in the connected system that are not assigned to an Identity within Fischer.

When Re-Certify All is set to Optional, the same options are available as defined above in the User Access certification campaign.

New Certifier for a Node must certify all resources

This option provides organizations with governance and oversight for new certifiers, which means the first time a particular certifier is responsible for certifying. Fischer is able to recognize if the assigned certifier has never certified a Node. If this is the case, enabling this option in conjunction with Re-certify all set to "Optional" it will force the new Node certifier to review each certification task individually the first time, and subsequent reviews by the certifier may allow them to perform a bulk certification, depending on the options set above (For User Access and For High Privileged and Unassigned Accounts) which will come into effect upon the second certification campaign for a given node certifier stays the same.

All resources for a new users must be certified

This option set in conjunction with "Re-certify all" set to Optional will force all resources to be certified individually if any new users show up in the certification campaign. So for all users that have been certified previously can be available for bulk certification (depending upon the settings above) but any new users must be certified and will not be allowed to be certified in bulk.

All new resources of users must be certified

This option set in conjunction with "Re-certify all" set to Optional will force any new resources that may have been allocated to a user since the last certification campaign to be certified individually and will not be allowed to be certified in bulk. So if a user that has been previously certified now has new access to certify, it will need to be reviewed individually and depending on the settings above.

Notifications

Fischer's certification feature provides with many layers of communication and options to set when to initiate the correspondence per task. Here is a screenshot of the notifications available to be sent within a certification campaign:

The following options are available for specific notifications:

Status to (Compliance) Administrator

1. Job Completed - This will notify the Compliance Administrator when the entire certification job is competed (1 notification per campaign)
2. Task Completed - This will notify the Compliance Administrator when a certification task is completed (lots of notifications!)
3. Daily - This will notify the Compliance Administrator daily regarding the status of active campaigns.

Re-certification Progress to Admin

1. Daily - The Administrator will be notified daily as to the progress
2. End of Each Node - This will notify the administrator when each node is completed for a given campaign

Reminder to Certifier

1. Daily - This will send a reminder email to a certifier with pending tasks once a day
2. Once - This will send a reminder email to the certifier upon initial assignment of certification tasks and will not remind him or her again.

Configuration Properties

• Administrator Remediation Comment: Whether the Administrator must enter a comment while remediating a compliance exception. The values are Mandatory, Hidden and Optional. Default one is Mandatory. Org level property.
• Certifier Comment: Whether the certifier must enter a comment while submitting a recertification request. The values are Mandatory, Hidden and Optional. Default one is Mandatory. Org level property.
• Compliance Administrators: List of Compliance Administrators. Only static certifiers are listed as compliance administrators. Org level property.
• Daily Notification Dispatch Time: The time of the day when the daily recertification notifications are sent. The default time is 12:25 AM. This is not a organization level property.
• Percentage Time Left for Job Level Reminder: Percentage of time left for sending any job level reminder notification when the reminder is configured to send 'Once'. Values range: 1 to 100. The default value is 50. Org level property.
• Previously Certified Resources: Options for the resources previously certified for the Certifier. The values are Hidden, Read Only, Allow Certification. The default value is Read Only.
• Reassign Certifier Search Criteria: The filter applied for listing certifiers to reassign. An example of the filter is, Certifier(Job-Department) = Reassign(Job-Department).
• Recertification Polling Interval: Interval in minutes between recertification process polls of the recertification tables. Values range: 1 to 1440 i.e., 24 hours. Default value is 60.
• Technical Review on actions on Previously Certified Resources: Whether technical review is required for action on previously certified resources. The values are None, For all actions and For Remove Only. The default value is For Remove Only.
• Use Resource Approval: Whether resource approval will be done during a provisioning or deprovisioning based on certifier actions. Approval of only root/top-level objects will done, not sub objects. For example, if the root/top-level object is a group, then only group level approval will be done, if the root/top-level object is a policy, then only policy level approval will be done. The values are Never and Always. The default value is Never.

Run Time Details - Self Service UI

The following functions are available to the re-certification feature (this is accessed via the Self-Service Portal):

View Requests

A logged in user who is qualified as a certifier will have access to the recertification sub tab under users tab in self-service UI. The below figure shows the tab and sub tab when logged in user is a certifier. 

Recertification UI -System

A sample UI shown when a certifier who certifies Unassigned accounts logged in is shown below 

If there is an active campaign and the authenticated certifier has a list of users to certify, the feature will display a listing of all assigned certifications. In this case since job had only unassigned CoT, we are seeing the option Highly Privileged and Unassigned Accounts in the view option drop down. Since the certifier had a node immediately under him he is a sub-level certifier also, which is why he is seeing the Sub Levels Recertfications option as well. The count in the parenthesis denotes the number of resources assigned to him for certification.

The user will be presented with two views - Account View and Entitlement View. The account view will list all the accounts initially and on expanding each account the entitlements that account posses will be listed. The entitlement view is just opposite where certifier can see the listing starting with entitlements and under it, the accounts who have that entitlement will be listed. These certifiers can switch between account view and entitlement view and complete certification campaign, provided they save their changes before switching views.. If the job is configured as entitlement only certification, only entitlement view will be available for the certifier as shown below.

View Options

Sub-Level Recertifications

A person will be authorized for "Node Certification"  or "Sub- level Certification" only if the node to which he qualifies as a certifier has a child node, as defined in the Chain of Trust. If the logged in user qualifies as explained he will see the option in the drop down.

Highly Privileged and Unassigned Accounts

If job had a unassigned CoT and the logged in user was a certifier for unassigned accounts as well, the above view option will also be shown in the drop down, where he could certify the assigned resources.

User Access

If job had a assigned CoT and the logged in user was a certifier for assigned accounts as well, an option User Access will also be shown in the drop down, where he could certify the assigned resources.

Technical Review

If the logged in user was a technical reviewer  as well, an option Technical Review will also be shown in the drop down, where he could review the assigned resources.

Note: If only one of the above 4 types of request is present for the user at the time of login , he will not see the drop down  section to select the view at all, and instead will directly see the respective screen with resource list to take action.

Review Access Details - System

Fischer provides a very detailed view of an outstanding certification task. Below is a view of all the information available when a System certification job is executed.

Allow (Access)

Select Allow to accept the provisioned resource for this user. If the resource has an Excess exception, then choosing Allow will override the exception, allowing the exception to continue, which may violate the company policy.

Remove (Access)

Select Remove if users should not have access to the provisioned resource. If the resource has Excessive Access, choosing Remove will remove the entire resource not just the Excessive Access. For example, if the resource being certified is a provisioning policy that contains multiple resources and only one has an Excess exception, choosing Remove will de-provision access to the entire policy, which includes all resources that are part of the policy for the users.

Remediate (Access)

This option is only available for resources that have an exceptions. Select Remediate to remove the Excessive Access. Excessive Access is defined as access an Identity has in the context of the connected system being certified that they do not qualify for, or that Fischer's Compliance engine has flagged as more access than the user is supposed to have. This option allows the certifier to correct Excessive Access while retaining a users’ access to the provisioned resource. For example, if the resource being certified is a provisioning policy that contains multiple resources and only one has an Excess exception, choosing Remediate will only remove the one excessive access, while retaining the access the qualifying user is supposed to have.

Reassign (Request)

Where allowed, certifiers are able to reassign requests to other certifiers

Explanation of Access

Fischer provides space on the screen to explain to certifiers what the context of the access is. Often times, certifiers are not the most technical users and need help understanding the context of the access they are tasked with certifying or attesting to. Here is an example of what the certifier will see. It's important to note that the text answering the question comes from the description field associated with the connected system being certified.

It is very important that resource / system descriptions are populated. While technical personnel often don't pay attention to description fields, it is very important to business users and end users. In short, make sure you fill out the descriptions when defining resources! It helps the business.

Method of Obtainment

When a certification campaign is executing, it is extremely important that the certifier understand how the Identity obtained the access which is now subject to certification. Fischer understands that how a user obtained an account is useful information and can help build a complete picture for the certifier providing them all the necessary data points to make an informed decision. Fischer will show how a user obtained the access that is up for certification.

Here is an example of what a certifier will see to help them determine how the access was obtained (note if the access was obtained via multiple methods all methods will be displayed:

Account/Entitlement Certification

Fischer's re-certification feature provides the ability to certify accounts as well as entitlements when you perform a re-certification of Systems. By selecting Object type as System, we can certify assigned and unassigned accounts as well as entitlements of the selected systems. Recertification campaign of all other object types (Policy/Resource) will allow only actions in the respective object level. If we choose the certification action as remediate,  based on the exception, remediation will be done at account level or entitlement level. For eg:- if we  have an excess entitlement reported, and we take remediation action. that excess entitlement will be removed. As of now only Excess exceptions are remediated.

Assigned System Certification

By selecting Object type as System and configuring the assigned CoT, we can perform the re-certification of all accounts and entitlements that are assigned to users in Fischer Identity Suite. Here user is provided with the capability to do certification in the most granular way, i.e, User can take individual actions on accounts and any entitlements under the account.

High Privileged and Unassigned Accounts Certification

By selecting Object type as System and configuring the unassigned CoT, we can perform the re-certification of all accounts and entitlements that are not assigned to any users in Fischer Identity Suite and exists in  a target system of interest Here user is provided with the capability to do certification in the most granular way, i.e, User can take individual actions on accounts and any entitlements under the account. We will consider HPAM accounts as well in the certification campaign with unassigned CoT.

Previously certified access recertification

After the recertification process for resources or accounts is complete, the next time a recertification process for the same resources or accounts is executed again, information regarding the previous certification may be available to review and/or recertify. This is controlled by a property Previously Certified Resources under Configuration àCompliance, which can be set to:

• Hidden - Previously certified resources will not be shown.
• Read Only - Previously certified resources will be available to review only.
• Allow Certification - Previously certified resources can be certified again, if desired.

Default value is Read Only. So the next time certifier is able to view the previously certified resources under the section “Previously Certified Resources” in User Access request or High Privileged and Unassigned request.

If certification is allowed and performed on previously certified resources, then further recertification by a Technical Reviewer may also be required depending on the compliance configuration property Technical Review on actions on previously certified resources setting, which can be set to:

• None - No action is required by a Technical Reviewer on previously certified resources.
• For all Actions - All certification actions on previously certified resources are required to be recertified by a Technical Reviewer.
• For Removal Only - Only remove or remediate actions on previously certified resources are required to be recertified by a Technical Reviewer.

Reassignment

Configuration property Reassign Search Criteria is used where a filter is defined for listing the reassign certifier lists. The users qualifying this filter will be listed while reassign. If the above configuration parameter is not defined then all certifiers are listed.

Reassignment can be done through the admin UI too by viewing the Tabular or Tree view in the case of User Access Recertification and Recert details –System for Unassigned Accounts Recertification

User Access, High Privileged and Unassigned , Technical Review and Sub Level Recertification requests can be reassigned.

In the Self-Service portal, if we go to Users tab and then Recertification sub tab and expand a User Access request and  click the radio button corresponding to the action Reassign,  a pop up window will be displayed from which we can perform the reassign operations.

In the Ressignment popup dialog, the following 3 options are available

• ESCALATE TO NEXT LEVEL. (certifier list name of the next upper level certifier)

Note: Click the link to display details of the next level certifier(s).

• REASSIGN TO ADMINISTRATOR (select a user from Compliance Administrators).
• REASSIGN TO A SPECIFIC CERTIFIER/REVIEWER (select another certifier/reviewer).

 

Note: For Global Reassign the option ESCALATE TO NEXT LEVEL will not be displayed

Timeout in recertification

While adding chain of trust, duration (days) is specified for each node level. Thus certifier at each node level (both certifier and technical reviewer) gets that many days for certifying. For example if a node has 1 day duration then the certifier at that node should get 1 day for completing the certification. If certifier didn’t take any action then that node will get escalated timeout after 1 day (1day 0 hrs 0 min). If certifier took action and technical reviewer didn’t review the action then too the node will get escalated timeout after 1 day (1day 0 hrs 0 min), the status of node too changes to Escalated Timeout. The recertification requests along with sub level recertification of that node will get expired after timeout period.

If a certifier for a node reassigns some resources to another certifier, then the original certifier’s duration is applicable to the new certifier. If however, a certifier escalates all the certifications to the next level up Node Certifier (or they are auto-escalated due to expiration time-out), then the Node Certifier’s duration is applicable for the escalated user resource certifications.