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