Certifiers – Support Portal

Certifiers are one of the most important pillars of an IGA Program. These individuals are tasked with reviewing all the access any Identity has obtained within your organization. As certifiers are selected, there is an important set of criteria that should be met before anyone in your organization can be a certifier. At the top level, some regulations require executives to be the ultimate certification authority, however organizations must always consider credible, knowledgeable and trusted individuals to attest to access throughout the organization. For these reasons, defining who your certifiers will be should be more about the right Identity, than the political one. It should focus 100% on objectivity, security and governance and have absolutely nothing to do with the politics of Identity (which are very real).

Fischer provides organizations the following functionality when defining certifiers.

Name

Obviously you will need to name any new certifier configuration that is built. It is important to name the configuration something meaningful, especially if you are (which you should) leveraging the Dynamic or entity-derived certifier list.

Description

Providing a description is very important to the business side of the house. Describing the context of a particular certifier configuration will help auditors, compliance personnel as well as the business ascertain the necessary significance and relevance of the defined certifier list.

Certifier Type

This is the configuration option where organizations can set a Static certifier list or a Dynamic List. The table below outlines both options:

Static

If an IGA or Compliance Administrator defines a static certifier list, they will simply select the static Identity to authorize as a certifier. As mentioned in other guides, this approach can create overhead to the IGA team and can cause slow downs and/or potential points of failure within an organization's business process. If at any time a certifier is no longer eligible to be a certifier or has left the organization, IGA / Compliance Administrators are forced to find the certifier list(s) the individual Identity is statically defined within and make manual changes. If this does not happen prior to the next certification campaign, it can cause problems if a defined certifier is no longer available and in some cases hault a certification campaign and force a restart. This is why Fischer strongly recommends the use of the Dynamic, entity-derived certifier list. This will allow for the natural flow of business to occur (new hires, attrition, termination, promotions, etc.) to occur without the need to make changes to the defined certifier list. When selecting a static user, the IGA / Compliance Administrator will see the following:

Upon clicking "Add", they will see this:

Notice that when building a static list, all Identities are returned. This can create multiple, bad scenarios if the IGA / Compliance Administrator selects the wrong user. Keep in mind that Fischer's ABAC security model provides another layer of enforcement to ensure that only users provided the certifier rights will be able to view the certification feature; however if the wrong user is selected and that user does not have the necessary rights, the certification job will fail when it reaches the certifier defined by mistake. This can cause unnecessary administrative overhead and can potentially halt a certification job.

Dynamic

The dynamic option is the efficient option to use when defining certifier lists. It allows organizations to define entity-based certifier lists based on attribute / value pairs associated with an Identity to automatically resolve the correct individual(s) to the certifiers list. Within an organization, the job of certifier should not follow a person, rather the realm of authority should be maintained by the position or job function and never the static person. On top of drastically decreasing the risk of a failure of business continuity, it also provides for less risk. Once the entity-based certifier list is constructed, it does not need to be touched unless the organization decides to shift the certifier authority to another entity. It also decreases risk by removing the potential for human error that comes with statically defining certifiers. Organizations should always use entity-based resolution for constructing certifier lists. When selecting the Dynamic Filter radio button, the following filter will be displayed:

IGA / Compliance Administrators have 3 options to source their certifiers. By sourcing certifiers, we are speaking about where Fischer's Compliance engine will look to dynamically resolve the certifier list. The 3 options are described in the table below:

IdentitySystem
The Identity System is the native LDAP directory specified during product installation. For Identity-as-a-Service customers, this system would be considered an external source as it resides inside of Fischer's cloud. Regardless, if organizations want to source certifiers from the Identity System they will need ensure that all required attributes to resolve certifiers are provisioned or synchronized to Fischer's Identity System. Available Attributes for Certifier Resolution If the Identity System is used, organizations will want to make certain that during the creation of the Identity System user object that the all necessary attributes are mapped to Fischer's Provisioning Hub. You'll notice that the combo box is populated with Fischer's Provisioning Hub schema and not an LDAP schema. You'll find this to be the case for all dynamic filters throughout the product. The default down list provides 19 popular attributes. To extend the drop down list, more attributes need to be defined from Configuration→Attributes inside the administration user interface.

Identity Data Store
The Identity Data Store is Fischer's Identity Registry (or more specifically the FUP table for resolving certifiers dynamically). You'll notice that the default combo box lists different attributes than the Identity System. This is because the combo box list is populated from which attributes are mapped to FUP columns.

Extended user Profile LDAP System
This option will become available if an attribute or attributes are defined to be retrieved from an external system. Only then will this option become available. Fischer's engine will detect if Identity attributes are defined to be sourced from external systems at which point the this option will become available.

The Concept of Parallel Certifiers:

One important item to understand is that using a dynamic filter may produce more than one certifier. Often times this is intended or it may happen by accident. As a certifier receives the initial notification that there are pending certification tasks and an active campaign has started, he or she will be able to see if other certifiers are also taking action on the same set of users. Sometimes, this may be by design. An organization may have a large set of users to re-certify and qualifying multiple certifiers, with the same authorization level can help to expedite and streamline the business process associated with an active certification campaign.

Resource Owners

The resource owner option is provided to configure resource owners as certifiers. The certifier list created using this option enables the resource owners of the selected resources to be certifiers. This type of certifier list can be picked only in unassigned COT configuration, which means it can be used in Unassigned Systems re-certification campaign only. Here we can see that the certifiers selection area is not there and the role configuration determines the scope of certification - entitlements and accounts to be certified.

This type of certifier was primarily introduced for remediating the unassigned accounts and entitlements automatically. The workflows in the qualified resource (resource of the resource owner certifier who took the certification action) will be used to perform any action on the target system for remediation.

The scope selection page determines the resources to be selected based on the systems selected. This in turn determines the certifiers and the scope for certification. If the resource selected have Entitlement A then all accounts that have this entitlement will be available for re-certification along with Entitlement A and the owners of the selected resource have to perform re-certification of those accounts and entitlements. User is provided teh option to pick selected resources of a system as well as an option to select all resources of the system.

Certifier Role

The next step in defining certifiers is to the set the role (i.e. the authority to be granted) to the certifier(s). A resource owner type certifier will only have Unassigned Access Certifier option as it is menat to be used for unassigned systems.The following configuration options control the certifier role:

User Access Certifier
A user access certifier will be responsible for Allowing, Removing & Remediation access. Access means Identities and their target system accounts and entitlements. While the context of the re-certification job can change (Policy, System, Resource or Resource Group), User Access Certifiers will still be responsible for certifying all related access and exceptions, including excessive access detected by Fischer's Compliance engine. If the User Access Certifier Role is selected, and the "Select" button is clicked or touched, the following screen will appear: You'll notice this screen looks familiar to other dynamic filter screens. However... The dynamic filter being defined within the context of the Certifier Role of User Access Certifier is to resolve the end user population (i.e the Identities) that the certifier(s) will be responsible for. For example. If Dan Dagnall was defined as the only certifier in a particular certifier configuration, and was provided the User Access Certifier role, the filter in this section will define who Dan Dagnall will be certifying access for. Two important items should be considered as IGA / Compliance administrators define this relationship: What is the certifier's realm of authority? What does he or she know about the Identities and the associated policies or systems that require certification? Do we want to limit the number of users to be certified by Dan? The answers to these questions is largely depending upon what is being certified and how this particular certifier list will be plugged into the certification process. As you build out each certifier list, you will want to consider the scope of certification intended for each certifier list, as well as keeping in mind that your certifier list as well as the scope of users to be certified should vary depending upon the type of object to be certified (Access Policies, Systems, Resources, or Resource Groups). Do not let Identity Politics interfere with selecting and authorizing the correct person that is best suited within your organization to make educated decisions regarding access and who should keep it versus who should lose it.

Unassigned Access Certifier (High Privileged and Unassigned Accounts)
A second certifier role is "Unassigned Accounts and High Privileged"). This certifier role is specifically for System certification jobs. Fischer's Compliance engine will assess a System a bit differently than it will do for Provisioning Policies, Resources or Resource Groups. The last 3 are centered around access that Fischer has provisioned to target systems and is aware of what the user should have. A system job will still interact with the Compliance engine but it will also detect the presence of HPAM accounts and/or any orphaned account in the target system and report back to Fischer's Compliance engine. This is a very important assessment / re-certification campaign to execute. It helps organizations maintain oversight within their end points to ensure that all accounts present in the connected system are associated with an Identity within Fischer. For accounts found in the connected system that are not associated with an Identity, Fischer's Compliance engine will flag these accounts as "Unassigned". This governance is very important since often times it is an orphaned account that hackers or malicious internal actors will find and use to institute a breach. Hackers often find these accounts and their activities will go undetected for some time since it is an "expected" account accessing the network so no one is the wiser. Executing a system campaign will help thwart these attacks by detecting orphaned (Unassigned) accounts and flagging them for certifiers and compliance personnel to take immediate actions to either find out who owns the account or disable it. This is another reason organizations must execute compliance assessments (at a minimum) and re-certification campaigns on a much more consistent basis. Executing an assessment once quarterly will give a malicious actor up to 90 days to wreak havoc before the account is detected. While there are other mechanisms available within Fischer to help monitor sensitive security groups, organizations must execute System assessments on a regular basis to reduce risk and increase awareness of exactly what accounts are present inside their end points and add on a certification campaign so the proper personnel can be aware of and/or attest to the access granted and the accounts present within an organization's end points.

Technical Reviewer
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.

Reminders

When defining a certifier list, IGA / Compliance administrators can set reminder emails at different time intervals to ensure certifiers are reminded of the work they have to do.

Notifications

Certifier lists can also have notifications constructed. Administrators know that if you define notifications within the certifier definition and then also build out notifications at the assessment and re-certification job level, the job level notifications will override the certifier list notifications. This is if the the same person is to be notified in both scenarios.