Compliance Jobs – Support Portal

Defining a compliance job can be a complex process. We will show you the mechanics of how to define a job in the Configuring Compliance Guide. As far as the feature is concerned, defining a compliance job entails many decisions and feature configurations to consider. Below image depicts a job of type System which evaluates all users, accounts and entitlements of a given system. Below figure shows a part of the job creation UI which depicts the resource type and CoT Selection and individual sections are explained in detail below. The recertification specific configurations of job are explained in the certification section.

The table below outlines all of the functionality built into a Fischer compliance job:

(Job) Type

This combo box allows Compliance Administrators to define the type of job to be executed.

Watch your computing resource consumption. Compliance assessments can be rather large

You'll also have the option to set the Maximum Parallel Process property. This links directly to the number of database connections the Compliance job will have available to it for processing. Note that assessments can consume a significant amount of system resources given the processing that is occurring. This is why it is important to execute smaller, more consistent compliance assessments against smaller user populations as opposed to a semi-annual or annual assessment where the processing load would be heavy. Whatever value is set in the Maximum Parallel Process property is one-to-one. This means one if the number is 10, the Compliance assessment process will consume 10 database connections. The maximum that can be set is 100.

When selecting a job type, IGA Administrators have 2 options.

Assessment Only
If the job is set for assessment only, the Compliance engine will pull the information from the the SYNCH tables (as described above) and compare the account and entitlement data with what is provisioned within Fischer. The "Resource Type" (as defined below) is the context of the job and subsequent assessment that Fischer will execute to determine if there are any access exceptions. For an assessment only job type, the results will only be displayed in the administration user interface within the context of the compliance job's instance. This will result in only IGA administrators (or Compliance Administrators) seeing the results and it will not present the results to certifiers within the self-service interface.

Assessment & Recertification
If the job is set for assessment & recertification, the Compliance engine will pull the information from the SYNCH tables and compare the account and entitlement data with what is provisioned with Fischer. The "Resource Type" will once again dictate the context of the job and ultimately how the exceptions are presented. When recertification is added to the job, this will result in Fischer calling upon the defined Chain of Trust (CoT) to present recertification & remediation tasks to certifiers. The recertification and remediation campaign will display the results within the compliance job instance in the administration user interface, however it will also present the results of the compliance assessment to the certifiers as well so action can be taken from the self-service interface.

Resource Type

This step in the definition of the Compliance job is where administrators will select the type of objects (called resources in the UI) will be assessed. Note the "Select All" option that displays. When checking this box, administrators do not need to click "Add" to add resources. That option is reserved for organizations that want to execute more granular assessments and/or re-certifications.

Policy
A job defined as a policy job will leverage Fischer's Provisioning Policy configuration during the assessment. This job will compare the data imported from the connected systems, into the SYNCH tables as described above. The synchronized data will then be compared to the provisioning policies defined within Fischer and assess each Identity to determine which policies they qualify for, and most importantly review the access granted if an Identity qualifies. Fischer will determine the status of the Identity as it relates to possible exceptions Fischer is capable of flagging.

Resource Group
A resource group job will compare the access each Identity has against any allocated resource groups. Resource group is a consolidated number of resources (i.e. accounts and entitlements) that can be provisioned to a user all at one time. This is used for requesting access via self-service. Organizations can expose a resource group to be requested and provisioned. A good example use case would be where an organization may not have a contractor role, however for a given type of contractor, that individual will receive an Identity and a defined set of access points. This means that a contractor resource group may include access to the domain, a vpn account and access to the application he or she is contracted to support on behalf of the organization. While there are many other scenarios where a resource group is relevant, we will provide the single example and ensure that it is understood that a resource group offers organizations the capability to bundle different accounts and entitlements (from different connected systems) into a single "access bundle" to provision a particular account type. Executing a resource group assessment will check to make sure that the Identity being assessed only has the access that was supposed to be granted via the defined resource group.

Resource
A resource based job will focus on the access granted via self-service. A resource only will assess "resources" allocated via self-service - where we listed the "resource" to select and not Policy to select via self-service. This is an important distinction to understand. This job type will only assess resources requested and allocated via self-service.

System
A system job will export accounts and entitlements from connected systems and display them to certifiers for review.

The following resource types are available in the combo box:

User Access

As you build a compliance job, the next step after selecting the type of job. You will now select the objects to be assessed. We use the term objects since the object will be different depending on the job type selected. If a policy job is selected, clicking "Add" will display a list of policies to select for the assessment (job), if a resource (or group) job is select it will display a list of resources (or groups) to be selected, the same will hold true for a system job as shown above.

What exactly am I selecting?

It's important to note that you are selecting the objects that will actually be assessed and/or certified. The list of objects to select from will be within the context of the Resource Type defined. The important item to take away is that each job type is mutually exclusive at assessment time. This means you cannot select multiple object types to be assessed within the same job. You need to understand that this means, in order to assess all potential configurations employed, and ultimately make sure that all potential methods of obtainment are assessed. This an important concept to understand. For example, if a policy job is defined and all related access is assessed in the context of Fischer's policy engine, it will exclude any access that may have been obtained via self-service via an access request.

CoT Selection

The next option available for configuration is setting the defined Chain of Trust (if applicable). Remember that a CoT is mandatory only if the job type is "Assessment and Re-Certification" since the re-certification campaign will require a defined chain of trust to present exceptions to, so that access and any flagged exceptions can be certified via the defined certifiers and get remediated. An unassigned COT selection will only available for System type job and need to be used only if we need to certify HPAM or unassigned accounts and entitlements.

If an unassigned COT is selected, we provide an option for user to perform certification only for entitlements by providing a checkbox. In this case Accounts of entitlements need not be certified.

Note : This setting is not required if Compliance administrators are only executing an assessment only job. If COT is provided, it will be used to scope down the users who will be assessed as part of teh campaign.

Assessment Options

This selection provides Compliance administrators with the ability to perform a more granular assessment beyond just assessing the access itself. It provides for the ability to assess data elements that may be relevant. When selecting one or both of these available options the following attributes will also be assessed.

While Fischer does provide for governance over relevant business information to be assessed during a compliance job, these attributes are not presented to certifiers. The goal of providing for an attribute-level assessment is to provide oversight into how the technical definition of a resource (that most business personnel would not understand) can have the gap bridged for business users. Executing a detailed assessment should absolutely be considered as a part of any assessment OR create a specific assessment to review these values. It is important that the technical team always keep in the front of their minds that those reviewing access requests via self-service and those requesting the access should be provided with a functional description of what access is provided. Often times this information is skipped over for the sake of expediency and/or just because the majority of personnel deploying an IGA solution do not consider the business user. Fischer creates these fields to help organizations build a relevant and transparent resource (i.e. account and entitlement) catalog that is understood by both technical and non-technical Identities. The information assessed in the context of a detailed assessment helps organizations to ensure technical processes that are exposed to business users properly bridge the communication gap, therefore, Fischer highly recommends performing a detailed assessment to make sure both parties are aligned.

*Note that while Compliance administrators can define mutually exclusive compliance assessments for accounts or entitlements. The purpose of providing this level of granularity matches for accounts and entitlements to the documentation has combined accounts and entitlements where applicable.

Assessed Attributes

The following attributes are assessed during the execution of a compliance job:

ACCOUNT_DESCRIPTION / ENTITLEMENT_DESCRIPTION
This attribute is defined within the Fischer resource definition. It is a recommended best practice that the account description field within the resource definition be populated with a business-friendly description of the context of the access the account provides.

ACCOUNT_DN
This attribute stored within Fischer's Identity Registry stores the exact mapping the an LDAP-based account (object). This can help administrators to ensure that Fischer's account association is correct. This is important for scenarios where organizations move DN values. A prime example is when organizations move disabled users to a different OU within LDAP. If this task happens manually (via native LDAP administration tools) Fischer will not have the correct account association stored in its registry which will create an error when the end user is attempting to reset their password, or it can create assessment exceptions during a compliance job that can be avoided if this particular attribute is governed properly. Note that while a detailed assessment can help Compliance administrators ensure that all accounts are associated properly; most of the time during an implementation consultants will make sure that DNs are going to stay in place of if they will in fact move. If DNs are going to move, implementors can build out processes to make sure Fischer is able to detect a DN move. We also have other implementation methods that will allow the object to move without the need for Fischer to execute a utility process.

ACCOUNT_ENABLED
This is useful information to Compliance administrators as it will compare what the current state of the account is with what Fischer thinks the status is. While this process should be handled during the course of standard provisioning solution, there are situations where native administrative actions are taken against a target system and if continuous monitoring is not built into the solution, the actual account status on the target system will be mismatched from what Fischer believes the account status to be. From a governance standpoint, this is an important assessment to execute to ensure that the correct account status is represented and/or known to Fischer at all times.

ACCOUNT_ENDDATE / ENTITLEMENT_ENDDATE
Assessing the account end date against what Fischer believes to be the end date for a given account is useful when attempting to determine what future dated transactions may have occurred or are going to occur. Keep in mind that an assessment is taking a real-time snapshot of the data within the target system being assessed and comparing it to Fischer's Identity Registry. A useful example of how to employ this feature would be to validate that all access that is disabled within Fischer is actually disabled within the target system. This can help organizations to ensure there are no orphan accounts on the system. While there are other mechanisms in place to catch orphan accounts (Review the Exception Status Page for specifics), this detailed reporting of the actual end Fischer posted to it's registry in fact matches what the system itself is reporting. Note that some connected systems may not store this information so the use of this assessment tool is subject to the availability of the data from the connected system itself and whether or not it can be imported into an assessment job.

ACCOUNT_LOCKED
Executing a detailed assessment to obtain and compare the status within Fischer against the connected system as to whether or not an account is locked is important. This is an assessment that can and should be ran on a regular basis. While Fischer presents the status of accounts and whether or not they are locked within interfaces such as help desk, it is good practice for Compliance administrators to execute a detailed assessment consistently to keep up with the status of the actual accounts. Note that you can build out smaller compliance assessment jobs that are granular to a detailed assessment and for a single system. While executing a detailed assessment against all systems all the time may be time and resource consuming, executing smaller, point assessments on a regular basis can allow Compliance administrators to have an up-to-date view of the accounts in their target systems and correlate to what Fischer's Identity Registry is storing. This is an important component of maintaining compliance.

ACCOUNT_STARTDATE / ENTITLEMENT_STARTDATE
Tracking the start date of an account within Fischer is important to ensure that it matches the actual account start date within the connected system itself. This assessment will provide a comparison of the actual date the account was provisioned within Fischer to the date when the account was created on the target system itself.

ACCOUNT_USERNAME
This comparison will provide Compliance administrators with the ability to determine if the username stored within Fischer's Identity Registry matches the username for the user in the target system. This is a very specific mapping but equally important to ensure that connected system information is properly represented within Fischer.

ENTITLEMENT_NAME
Assessing entitlement names will help Compliance administrators to ensure that Fischer's Identity Registry is in synch with the actual name of the entitlement for a given connected system. This can help to ensure that there are no mismatches in a scenario where a group name or permission may have been changed on the target system manually but Fischer's resource definition was not properly updated. This oversight provides organizations with the ability to review and govern the manual administrative actions taken within a target system and make sure those are properly reflected within Fischer's Identity Registry.

ENTITLEMENT_TYPE
Validating the type of entitlement is something that can be assessed as well. While the value of assessing the entitlement type is useful in the context of once again making sure Fischer is configured properly, it is most important for Compliance administrators to be aware of the types of entitlements that may be present within their connected systems to ensure they are properly provisioned by Fischer. As with any assessment, it also provides oversight to ensure that manual administrative action taken directly within a connected system is also detected by Fischer during the detailed assessment.

You'll notice that the "Account Attribute List" and the "Entitlement Attribute List" "Add" and "Remove" buttons are initially disabled. These options will only become available once a compliance administrator elects to build a detailed assessment job. Once you've selected one or both of the detailed options, the buttons will become enabled and compliance administrators can then select which of the above attributes they want to assess in more detail.