At its core, application onboarding is the use of software that can manage, and grant users access to applications as long as they have the proper permission and roles. More importantly, this puts applications under the jurisdiction of an identity governance product or process. Using application onboarding enables your organization to carefully manage access and have the correct identity governance tools in place to see who, or what is trying to make changes to your system. Recently, industry and government mandates, as well as high-profile data breaches, have emphasized the need for application governance.
There are mandates from governance organizations, which may be governmental based on geography (GDPR, SOX), or based on a vertical market that the enterprise is involved in (PCI, HIPAA). Another source of the mandates are the boards or directors that control the enterprise. With the rise in cyberattacks, especially those related to ransomware, corporate management has received a crash-course in the need for strong cybersecurity and the importance of proper application onboarding to long-term operational protection. Vulnerabilities include:
- Identities – often the entry point into the enterprise for threat actors
- Access to applications – even those that are not mission-critical can be a foothold to get to other areas of the enterprise, such as the computing and network infrastructure, additional applications, and data that holds PII or business-critical information
- Compromised credentials – access entitlements are the most common way that attackers gain access into an enterprise
Apps in the cradle and the silver spoon
During application onboarding, they implement policies and procedures for user access requests, user approval and provisioning, run periodic or on-demand certification campaigns, and have reporting function to assist with audits, etc. But too often the 80/20 rule applies. Meaning that 80 percent of the critical business functions are provided by 20 percent of the applications. And those are brought under governance control. But what about the other 80 percent of applications? Like all good intentions, the organization has a goal to get to the other apps eventually, which may not happen for many years – if at all.
What’s the hold up?
So, why don’t more enterprises give more consideration to governance when executing applications onboarding? Because – with typical governance solutions, it’s a lot of effort for an already overworked team. Plus, it involves not just the IGA team but also the group that actually owns the application and its data. Furthermore, it normally includes the compliance team, if one exists.
The typical steps to application onboarding include:
- Gaining access to the application and its data
- Integrating the application data with your IGA system
- Configuring the IGA system to manage access to the application
In gaining access to the application, this will take some type of integration. It may be a ‘pull’ type, where the IGA system is pulling the data on a polling interval or by some other trigger, or it may be one that the application has a way to be configured to ‘push’ the information to the IGA system using an interface standard.
Next, once the IGA system collects the data, it needs to be mapped to a data schema that the IGA system can work with. There are many ways that the various IGA systems allow this to happen. Some have a strict data model to which an integrator must map the incoming data. Others allow their schemas to be extended.
Configuration and line-of-business control
Lastly, to ensure long-term governance prior to application onboarding, the IGA system must be configured so that entitlements and access rights are managed according to the needs of the business. This includes tasks such as:
- Defining the user roles
- Implementing Separation of Duty policies
- Mapping user roles to entitlement types
- Configuring access-request and approval workflows
- Configuring certification campaign workflows, including
- Approvals processes
- Additional considerations:
- Reporting requirements for management, audits, etc.
- Notification procedures
- Integrations to systems, such as ITSM ticketing systems
This is a crucial step in the application onboarding process and one that should have different tasks within it is delegated to different teams (business and IT) that use or benefit from the application. For instance, the actual resource owners know best about the various user roles and the mapping of entitlements to them. Whereas the compliance teams would know the ideal separation of duties.
Your IGA system should have a clear process that supports efficient application onboard , whether it’s one at a time or in bulk. Having your applications under the control of an identity governance system is critical to the productivity and security of your organization.