August 30, 2019 By Daniel Wirth 3 min read

Allow me to shed some light on one of the critical organizational aspects of identity and access management (IAM) that we come across often when delivering IAM consulting services to our customers: Organizations that fail to address the quality of content for IAM processes may struggle to gain the acceptance of their business users before they even roll out their shiny new IAM strategy to the corporation.

Most critical access governance processes have a core set of key requirements, including:

  • Request and approval;
  • Periodical access reviews (aka, recertification);
  • Business role modeling; and
  • Audit.

To set the scene before we dive deeper into those core elements, let’s explore in greater detail two common failures that can derail even the best-laid of IAM plans.

Failure No. 1: Considering IAM an IT issue

Some organizations still consider identity and access management to be a technical topic for the IT team and do not make an effort to understand it from business users’ point of view. Including business stakeholders is generally a good practice when setting up IAM programs, but it’s equally important to present the content to business users in a way that is meaningful to them so they can perform IAM tasks.

Have you ever asked a business manager to review a set of access rights for their teams? If so, did you hand them the raw extract of access rights that you pulled from your IT systems?

If you were lucky, the manager kindly asked for an explanation of the presented data. In many cases, I have seen managers refuse to work with these reports — and they have my full support in doing so because they are simply not presented any information they can work with.

Failure No. 2: Presenting Low-Quality Content

The quality of the content presented to users is mission-critical, as in all IT projects. For IAM, this means describing the access rights in a suitable way that a business user can understand.

Instead of exposing information such as, “User A71239 is assigned to system SAP-P20 and has XPA_PRD_Z120_JBS_CZUP, XBAC_PRD_ZXY_UASDIUX…” — and hundreds more with similar technical labels — a core recommendation is to present a business-readable description of the access rights granted by assigning these objects.

But how do we to get there?

How to Document Access Control Structures

When introducing access governance, organizations should maintain documentation of access control structures for each business application. As noted above, the key objective of this exercise is to provide business managers with the information they need to understand the access rights they need to manage. Other stakeholders for this content are internal and external audit, the team working on business roles, and simply each IT user in the organization.

To draw a line here, I will not address building a business role model. My aim is simply to create the basis for understanding technical access rights from a business user perspective.

Access control structures address the functionality and content used for access control pertaining to a given business application. Other terms, such as authorization matrix, access catalog and entitlement structures, are used in a similar context. It doesn’t matter what you call it, but it should comprise all required information to interpret the access rights.

This includes the following information to define the context of the business application:

  • Application name
  • Business purpose of the application
  • Business owner
  • Technical owner

Next, you need to understand how this application enforces access control technically. We call this an access control model, which addresses:

  • Directories, databases and other repositories used;
  • Functions used for access control; and
  • Description of all parameters evaluated by the application to decide on access.

Now that we understand how access control technically works for the application, the next step is building an access catalog, which looks at each object we use for controlling access. This might comprise of set of composite roles in a SAP system, a set of Active Directory or lightweight directory access protocol (LDAP) groups, Resource Access Control Facility (RACF) authorizations, some legacy parameters in custom-built applications, or a combination of objects across several technical platforms used for a certain business application. For each object some key information must be maintained, including:

  • Business-readable name;
  • Business-readable description of access rights;
  • Technical name of the object;
  • Directory where it resides;
  • Business owner of the object (often referred to as “data owner”);
  • Technical owner of the object;
  • Approvers to review requests for this object; and
  • Applicable assignment rules on object level (e.g., separation of duties).

Life Cycle Processes for Access Control Structures

This exercise can’t be a one-time-effort; it must become a regular process. A good approach is to define life cycle processes to create, maintain and decommission access control structures for business applications and embed these in change management processes. Key factors to consider include:

  • Responsibility for maintaining access control structures;
  • Required approval flow for changes, including business, technical and editorial review; and
  • Procedures to publish the changed access catalog for use in IAM processes (e.g., request and approval, periodical access review, business role management). This includes importing the content into the catalog of identity governance and administration (IGA) components.

Depending on the starting point of the organization, creating and maintaining access control structures in defined life cycle processes may seem like an extensive and tedious task. But I assure you, it’s worth the effort.

More from CISO

Overheard at RSA Conference 2024: Top trends cybersecurity experts are talking about

4 min read - At a brunch roundtable, one of the many informal events held during the RSA Conference 2024 (RSAC), the conversation turned to the most popular trends and themes at this year’s events. There was no disagreement in what people presenting sessions or companies on the Expo show floor were talking about: RSAC 2024 is all about artificial intelligence (or as one CISO said, “It’s not RSAC; it’s RSAI”). The chatter around AI shouldn’t have been a surprise to anyone who attended…

Why security orchestration, automation and response (SOAR) is fundamental to a security platform

3 min read - Security teams today are facing increased challenges due to the remote and hybrid workforce expansion in the wake of COVID-19. Teams that were already struggling with too many tools and too much data are finding it even more difficult to collaborate and communicate as employees have moved to a virtual security operations center (SOC) model while addressing an increasing number of threats.  Disconnected teams accelerate the need for an open and connected platform approach to security . Adopting this type of…

The evolution of a CISO: How the role has changed

3 min read - In many organizations, the Chief Information Security Officer (CISO) focuses mainly — and sometimes exclusively — on cybersecurity. However, with today’s sophisticated threats and evolving threat landscape, businesses are shifting many roles’ responsibilities, and expanding the CISO’s role is at the forefront of those changes. According to Gartner, regulatory pressure and attack surface expansion will result in 45% of CISOs’ remits expanding beyond cybersecurity by 2027.With the scope of a CISO’s responsibilities changing so quickly, how will the role adapt…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today