Chain of Trust – Support Portal

Fischer's Chain of Trust (CoT) feature does just what it says, it provides organizations with the ability to build out the chain of trust within the context of a re-certification campaign. As the name states, trust is the key component of how the CoT should be built. This is yet another scenario where the politics of Identity can get in the way of defining a proper CoT. By proper, we mean defining the right people, understanding the level of authority those individuals will have when they are making access decisions. As stated previously, in some cases executives must be involved in the CoT depending on which regulation a given organization must comply with, and sometimes executives are not as tuned into the access controls and different levels of access individuals have within an organization so while they must be a part of the CoT, Fischer provides peer review and features to help executives understand the access they are certifying with a business description associated with the certification task. This is another scenario where it is important to state that Fischer provides description fields for all resources that can be associated with a certification campaign, which can help provide the context for active campaigns. However as a chain of of trust is constructed, Fischer has purpose built the feature to allow for individuals that understand the access provided to Identities to be a part of what is called a "Node". The "Node" is a concept that mirrors the construction of a hierarchical workflow where organizations can define certifiers underneath an executive, and ultimately it is the executive that must provide the final attestation or certification approval but he or she will see multiple layers of attestation and review prior to making the final decision for a given set of access for a particular Identity.

In order to build this properly (again properly is making sure it's the right people performing these extremely important tasks), organizations must rely on the executives to define who should be part of a given Node at the lower levels, since the Node Level certifier (or the top of the CoT) should always be an executive or an individual with elevated authority within the organization depending upon what is being certified. To that end, while executives may not understand the ins and outs of a given application when it comes to the different security groups or roles available and what access those groups and/or roles provide, IGA / Compliance Administrators must present the security hierarchy to the executives in way they will understand making sure to pay special attention to the context, depth and risks associated with the access granted within different applications.

Keep Executives In the Loop:

IGA / Compliance Administrators must take the time to explain what access looks like throughout their organization. Furthermore IGA / Compliance administrators must also work with executives to define the CoT, making sure to explain what each of the different actions are and the significance of those actions. This information will help executives to understand the magnitude of the process (if they don't already) and more importantly it will help to provide them with the full picture of what they need to see before they can decide who to entrust within a certification campaign to ultimately certify access. Remember that the executive will need to be a part of the CoT at some point; sometimes by regulatory requirements but most certainly every executive should touch the certification campaign at some level so they stay in tune with the access models deployed by their staff. Providing context to executives will help them decide who should be involved in the upper layers of the CoT to ensure that the proper oversight and governance is being performed.

Context and Outcome Matter

When defining a CoT, IGA / Compliance Administrators must consider the scope to be certified. By this, we mean what access is going to be certified by a particular CoT workflow. Before deciding which Identities should be defined within a CoT, IGA/Compliance Administrators should ask themselves the following questions:

What access is going to be certified by this particular Chain of Trust?
What is the level of access involved? (i.e. standard end user accounts, administrator accounts, privileged accounts, etc?)
What departmental assets do I want to be certified by this CoT? Remember you should build out smaller certification jobs and not just one global job. Building smaller jobs can help organizations to more properly define who should be involved. This is important!!
Who is the ultimate authority (Node or Top Level Certifier) that is responsible for the access this CoT will certify?
Have I discussed and explained how the CoT works with the Node (Top) level certifier so he or she can help make decisions as to who should certify access within the context of this particular CoT and associated assessment and certification campaign?
While a Tech Reviewer is not required, which level of the CoT should have a Tech Reviewer defined? And more importantly who should that Tech Reviewer be, given they will have more authority than the actual certifier.
Once a CoT level is completed (node sub-level as it is called in Fischer), how confident can the organization be that the access was certified by someone that understands what they are certifying? (This answer can also help determine the answer to #6)
What regulatory framework (if any) do I need to understand before I select which entities should be certifying the access associated with the certification campaign? This is important to know; sometimes regulations dictate which entity needs to certify.
Do I feel confident that the entities defined at each level is the right person? Am I concerned about who is defined at a given level because I am being forced to define the CoT with individuals that may not be best suited to make such an impactful decision?
How many levels of certification and attestation are required for the access being certified within this CoT? Do I have enough layers defined? Do I have too many layers defined?
What are the risks associated with how the CoT will be constructed? If I have fewer certifiers involved is that in the best interest of the organization? How many layers, which directly correlates to how many individuals should see the access users have to be sure I've reduced our organization's risk? Remember that risk associated with the type of access Identities have should always be a part of the decision making process when building certification campaigns and more importantly who should see the access so we know we have thoroughly reviewed the access.

The following functionality is available to IGA/Compliance Administrators when defining a Chain of Trust:

Name

Of course a name must be given to the CoT. Make sure the name is representative of the access being certified OR if you build our your CoTs in the context of the type of access being certified you will want to name your CoTs accordingly. For example if the CoT being constructed is for standard end user access to the domain for a given department, you may wan to name your CoT "Standard Domain Access Certification". If you want to use a name that helps to represent the risk associated with the CoT and the corresponding certification campaign, you may want to name the CoT something like "Level 1 Risk Certification".

Description

The description is important. Provide the proper context, it will help you organize your assessment and certifications better. And auditors will ask anyway...

Type

There are two types of CoTs that can be built.

Certify User Access
CoTs build for User Access certification will be presented with accounts and entitlement data as it relates to each distinct Identity. Their job will be to take the available actions (Allow, Remove, Remediate, Reassign)

Certify High Privileged and Unassigned Accounts
CoTs built for High Privileged access and Unassigned (orphaned) accounts should be selected carefully. They will be reviewing access that equates to the highest level of risk within an organization.

Chain of Trust Tree Construction

The suggested best practice for organizations deploying certification would be to provide a risk-context. This means that you should define your certification campaigns and corresponding CoTs in the context of the risk the access being certified represents to the organization. Below is a suggested breakdown of how an organization should construct a risk-focused certification campaign with proper Chains of Trust to be followed for attestation and certification. Keep in mind that it is not suggested that you necessarily attempt to attest to the access itself. This means that your focus should be on the Identity type and all the access he or she may have. Attempting to build out a risk model based on the access itself can be challenging. For example you would not want to break apart an executive's access so it can be certified at each of the independent levels of risk. Rather you should introduce your Identity types and categorize them as defined below and all of their access will be certified within a single campaign. This may mean that as you build out your attestation and certification campaigns you will need to figure out how to filter out your user population by type when importing users into the Fischer so access can be assessed. This is easily accomplished in the Compliance workflows that are constructed specifically for the purpose of initiating assessments. You will also need to understand the depth of the Compliance assessment and re-certification job being defined. This will result in defining mutually exclusive campaigns (jobs) for the same system, while the product currently requires a global assessment, you can easily segregate the users being assessed into different certifier groups and different Chains of Trust according to the model below.

Build out a risk level diagram associated with the access granted throughout your organization.
1. Level 1 Risk Assessment (End User Attestation and Certification)
  
  Who should I certify? - An Identity's direct manager must be involved in attesting to the access detected by the Compliance Assessment, and this layer does not necessarily need to include a layer of Technical Review.
  1. System Campaign (Job) - Standard end user access (i.e. domain access, email access, standard (user) application access to perform job duties.
  2. Provisioning Policy Campaign (Job) - Define your access control (provisioning) policies in the context of how much access is obtained. Review the resources granted by the access policy and determine the level of risk it represents. Focus on birth right access for Level 1 Risk assessment and certification campaigns.
2. Level 2 Risk Assessment (Management Personnel Attestation and Certification)
  
  Technical Reviewers should be involved when attesting to and certifying managerial access to ensure that a layer of oversight is in place given the elevated risk these users and their corresponding access represents to the organization. Your Tech Reviewers should be peers to the managers, as well as management level administrative users (i.e. Directors of IT, Application, Infrastructure, Information Security, etc.)
  1. System Campaign (Job) - Focus your Level 2 Risk assessments on your managerial staff. These individuals will have a higher level of access than standard end users. These users will need a higher level of authority, which equates to a higher security clearance within your organization. These users should be assessed independent of standard end users since they represent a higher risk to the organization given their elevated access.
  2. Provisioning Policy Campaign (Job) - Review your access policies that result in management level access. You will also need to define the access itself so that it is transparent to IGA / Compliance Administrators what the level of access entails. This is again a good time to point out the importance of making sure the description fields available properly describe the type of access the resource, system or policy will provide. This will help you define your levels of risk, but it will also provide context to the business units so they are aware as to the level of access and more important exactly what the access will allow an Identity to have when they qualify for a Level 2 Risk Provisioning Policy
3. Level 3 Risk Assessment (Administrative Personnel Attestation and Certification)
  
  Your Tech Reviewers should be Compliance and Audit type personnel, with the ultimate Node (top level) certifier being an executive. The executive that will be defined as the top level (node) certifier for this assessment and certification should be one that is responsible for an entire segment of an organization. Depending on the size of your organization, you will need to decide who the proper executive would be.
  1. System Campaign (Job) - Focus your Level 3 Risk assessments on your administrative personnel. These users will have the highest clearances and therefore should be assessed independently. Users included in this group would be your Infrastructure, Information Security, Application Owners, System Owners, etc.
  2. Provisioning Policy Campaign (Job) - At this level you should already have a very granular understanding of the access policies that will provide Identities with administrative access withing your organization. These access policies should be explicitly defined and the level of access granted by these policies known to upper level management.
4. Level 4 Risk Assessment (Executive Personnel Attestation and Certification)
  
  Your Tech Reviewers should be Compliance and Audit type personnel, potentially third party entities that can certify executive access or at a minimum provide a Technical Review. In situations where it is not possible or financially feasible to contract a third party to help perform these assessments. Information Security Executives should certify Operational and Corporate Administrative Executives, and Operational / Corporate Administrative Executives should certify Information Security Executives.
  1. System Campaign (Job) - These campaigns will be much smaller in scope, however depending on the size of your organization it can be larger. This level of risk assessment should be reserved for any executive within your organization. This should include Directors, VPs, Presidents and the C-Suite.
  2. Provisioning Policy Campaign (Job) - Once again, at this high level, the access policies should be minimal and the members equally as small. Quite often there may not be policies at all as executives may be required to be manually on-boarded and their access attested to in unique ways.