Identity and Access Management (IAM) systems and technology have evolved over two decades, resulting in many mature and modern IAM products for protecting users, applications and even entire ecosystems. Ravishankar Ponnusamy, CISSP, suggests how SaaS applications can fit into an organization’s identity and access management (IAM) strategy and how to effectively manage identity security.

Ravishankar Ponnusamy, CISSPOne of the major pain points for the cyber security industry is onboarding applications within identity and access management (IAM) systems. In my experience, this effort consumes a great deal of the CISO’s budget and can hinder any modernization/migration programs.

In many of my implementation experiences, the IAM team needs to spend more time on the application than on activities such as developing new features, data analysis, automation and integrating the IAM system with other cyber tools like artificial intelligence (AI) or the security operations center (SOC).

What would help?

Identity Governance and Administration

More standards-based integration through protocols, reducing API or connector-based integration: Application onboarding is one of the timing consuming activities in the identity governance and administration (IGA) sub-category of IAM. I’ve seen many instances where my team of business analysts and developers have needed multiple conversations with application owners and software-as-a-service (SaaS) vendors to find relevant APIs or develop workarounds. A few cases have become stuck, without the right APIs. On other occasions, a system for cross-domain identity management (SCIM) API has not had IGA-related functionality, or attributes have not been properly mapped. More standards-based integration through protocols, reducing API or connector-based integration, would help.

Bringing rich entitlement metadata through automated aggregation process: Many cloud applications come with a default list of entitlements. These entitlements can have additional information like description, special privileges, GDPR or SOX or PCI compliance, based on application domain or functionality. IAM systems can fetch this information through entitlement aggregation. In my opinion, application owners have sound knowledge about business functionality, but are unable to guide IAM integration fully. For many critical applications, I have to personally work with the SaaS vendor responsible to gather the entitlement metadata to the extent that is possible.

Build a mature entitlement model to avoid confusion between user metadata and access: Entitlement is the basic access unit of an IAM system. However, modern enterprise applications have complex access control mechanisms and user attributes, account metadata and entitlements are frequently used interchangeably. Thus, a combination of user attributes and entitlement can define new access – for example, “location” and “deployment” can give access to a specific region, which is something to be avoided.

During certification or access review cycles, my team and I manage these access-related ambiguities to avoid wrongful approval or rejection. In my opinion, these products should introduce hierarchy-based entitlements. This is something that many cloud IAM products have started supporting recently.

Access Management

Implement authentication and authorization processes through standard platforms like AD/LDAP: Many standards like SAML and Oauth2.0 simplify the process of authentication and authorization. Streamlining access exchange details and account information like status, display name and entitlements will further simplify the onboarding process. My hope is that the organization can devise its own standard to streamline the onboarding process.

Authorize users for SaaS apps only through centralized IAM tools, to avoid access ambiguity: Some applications have the ability to support authorization through protocols without users being created in the applications or without user access data being available within the system. Access information stored in multiple places can give rise to ambiguity. I suggest restricting applications to storing and acquiring access-related information only through your IAM system. Having faced this kind of situation for enterprises with a very large number of applications (>5,000 applications), I advise that this approach will improve the security posture of applications across all IAM areas.

Privileged Access Management (PAM)

App-to-app information exchange through service accounts should be processed through a PAM tool: As the number of enterprise applications increases, you need to focus on ensuring secure interaction between these them. Onboarding of these applications and securing access through an application’s identity manager (note that terminology may vary between products) is one of the key components of identity security. My recommendation to SaaS application architects is to devise a way of dynamically using passwords or tokens from the PAM during connection and to regularly rotate any relevant credentials. Many applications are only able to directly store the password or tokens. In my implementation experience, many application development teams avoid this step due to a lack of design or to avoid time-consuming scripting work.

Next-Generation IAM Controls

IAM technologies and systems have evolved to bring more centralized control over identity security, but the challenge they face has also evolved, prompting a need for the next generation of IAM technologies to combat emerging IAM security challenges.

Manage user authorization only through IAM tools, with enhanced app settings and controls: Applications in the future might include a new setting to provide "Access managed by IAM system", so that no users/accounts need to be created in the system, or that only user metadata is enough for the system. Though many applications support platform-based integration, users can still be created in the target systems, which can create a shadow IAM for platform-based applications. In one of my implementations, when applications were converted to platform-based applications in the access management system, direct account were missed in the system. An application-based setting could go a long way towards reducing access ambiguity and correctly handling complex use cases through the IAM system.

Advanced data gathering and analytics would help IAM systems limit usage correctly : There is a lot of difference between the access users have, the access they use, and how much time they use. I’ve seen numerous instances of service account privileges not being fully utilized, entitlements never assigned to any user, privileged accounts used only once a year and more. I’ve seen many SaaS applications that save a lot of statistics and use the data to improve the business functionality. I recommend the development of SaaS applications that store access-related data and enhance the ability of IAM systems to ‘see’ this data. This additional information should enable enhanced security functionality.

Extend zero trust architecture to application authorization for enhanced security and productivity: Let’s assume that access to applications is controlled by your IAM system only (based on the previous recommendation) and that there’s no separate user base or access data present as part of the apps. The IAM system can control access based on the circumstances too. Many access management products support conditional access based on location, user risk, logon risk, device compatibility and control user access outside of the apps. Let’s consider the example of a person working through open Wi-Fi and trying to access some critical applications - the privileged entitlements he has as part of his profile won’t be available to him. Though these kinds of requests are rare, a few of my banking clients requested restricting access based on circumstances. Doing so improved productivity simultaneously. I recommend products to enable only certain entitlements based on the circumstances, but not all.

Apply universal, time-limited privileged access across all the system: Best practice requires that a user's normal account (the one used for regular activities) should have no privileged entitlement and that an additional account be required to add privileged entitlements. Many hackers use privileged access to extract the organization's crown jewel (data), so near-zero privileged access will largely reduce their attack surface. Since the IAM system controls the authorization (based on my previous recommendation), I suggest providing privileged entitlements on a time-limited basis instead of permanently, along with sticking with regular user accounts to reduce the attack surface. Your IAM system can handle this automatically without any target provisioning.

IAM registration/orchestration service to enable auto onboarding and simplify the overall IAM program for large enterprises : I have spent considerable time and resources in the discovery of applications. I propose, to both app developers and IAM engineers, that, when a new tenant or SaaS application instance is launched, the app should automatically register itself to IAM systems for pending onboarding. This is similar to when a Windows machine is created: it is immediately domain-joined, AD policies are applied etc. My ideas here are only early-stage, more discussion is needed around registration processes such as URL patterns, information for registering, measure of IAM usage and so on.

IAM will continue to play a pivotal role in safeguarding identities. Although a next-generation solution will represent a paradigm shift in managing identities, my hope is that these recommendations, suggestions, best practice ideas and other thoughts will help our industry progress towards that next generation of IAM systems.

Ravishankar Ponnusamy, CISSP, has 17 years of experience in identity management, authentication and authorization, access management and zero trust. He has held IAM Delivery Manager, cyber competency leader roles, with responsibility for strategic planning, technology implementation, team building and project management.