Holacracy and Identity and Access Management

As IAM-consultants we are experienced in designing access models, and we are used to a typical environment where access is derived from an employee’s department, position and role. A person only needs access if and for as long that access is relevant in relation to his or her position in the organization and the tasks assigned. If there is no need for access, all authorizations should be revoked. This access models are unique to every organisation yet require some form of framework to base them on. Like roles, hierarchy, and organizational structures. Holacracy, more specifically IAM and holacracy, poses a new challenge in that regard.

At two of our recent customers we ran into a new ‘experience’. When we discussed how to design the access model we found out that these organizations applied a holocratic way of working. That requires some explanation of the concept of Holacracy. You may wonder what that is and so did we. We know about holistic philosophy: that is about everything. We know about hierarchical organization types and matrix organizations, that’s all about organization. And holocracy is trying to combine these two: everything about an organization. But still it is not that easy to define.

Holacracy. What is that?

Holocracy is a management framework, beyond hierarchical management, that is based on maximum self management of and by employees. Decision making is decentralized and teams are self-organizing, to an extreme level. It goes beyond agile ways of working in that sense.

As Identity and Access Management experts at SonicBee we are currently facing the challenge of managing access in this non-hierarchical, non-matrix-like, non-agile way of working at two customers.

In general you can say that people get their authorizations based on different characteristics, such as their place in the organization (department), their position and role, their physical location and several other of this type of ‘attributes’. The main structure usually is the top-down hierarchy. In contrast in holocracy there is no hierarchical structure, so it’s less obvious to find persons accountable for access, and besides, teams and roles within teams constantly change. This makes IAM and holacracy a tough combination to crack.

Holocracy is ‘the next way of organizing’. We used to have strict hierarchical organizations with a central and top-down management of work. The past years we’ve also seen a more agile way of working develop, with more autonomy in teams and less central and top-down direction. Holocracy takes this even further: there is no central and there is no top-down, the organization works in teams and these teams define the work themselves.

For us as IAM-experts we now lack the comfortable environment of departments, functions and roles. Then how to define why someone gets access or not?

Access based on roles – the traditional way of RBAC

Traditionally we design a model where access is granted to employees through the concept of roles. These roles are a bundle of individual authorizations. So for example: a customer service representative may need access to 8 applications. Instead of one-by-one granting these authorizations, which takes time, it is easier to bundle these 8 authorizations in one role. It is even more easy then to decide up front: every customer service rep will get this role. In this way we don’t need to decide for every individual employee that he or she is a customer service rep, but we create a line of code that says: if an employee has the job function of customer service rep, then automatically give this role, which effectively will give that employee the 8 applications. Now that is what we call efficiency (and we also label it ‘role based access’ or RBAC).

Automating that workflow of employees joining and leaving the company, or moving internally, is no rocket science. Getting an identity feed from an HR-system with all changes and performing some magic to create or delete accounts is what the so-called Identity Governance and Administration software suites do. And after managing the accounts, adding authorizations is a little more complex, we add ‘roles’ (groups of authorizations) to the identities: A manager can define the authorizations of a direct report, the manager grants and revokes authorizations, the manager receives reports and recertifications. The manager is accountable for the tasks the employee performs.

Holacracy: Roles without hierarchy

But not so in holacratic organizations. Holocractic organizations have teams, they call ‘circles’. And there is no hierarchical organization, there are only circles. And within circles there can be even more circles. People work in one or more circles. And the challenge is that there are no managers in the traditional sense. Each circle has governance in some kind of self-organized way of working. A circle has a specific goal and the people working in the circle define their governance to reach the goal.

Within circles ‘roles’ are assigned to people, but these roles can vary in time, in context. There is no set relation between hierarchical, RBAC-roles and Holacratic roles. In fact, in a holacracy even those roles may vary in time.

Holacracy and RBAC? Does that work?

In regular hierarchical RBAC, a person gets a business role and that business role connects to roles in applications and platforms, the so-called application roles. These application roles in turn give more fine grained access, the effective authorizations, or entitlements. This role creation process is not simple, It is so complex, that once a role is created, it cannot change easily. In fact I would invite any organization to celebrate the creation of any role!

This complexity as a consequence means that roles are static. And that creates some difficulty in holacratic circles: self-governance implies that when authorizations in roles can vary, the traditional RBAC-method doesn’t fit easily.

In dynamic, holacratic role management the roles are not static. Meaning that for IAM and holacracy, assigned roles can result in different effective authorizations. The role that was granted yesterday, can have different meaning today. So the employee still has the same role (that of the customer service rep), but today there are 9 applications part of that role, and yesterday there were only 8. This puts a lot of emphasis on proper role management, and otherwise the access might change over time, without anyone really being in control of that.

Access Governance

From the perspective of authorization management, this means that in a holacratic organization, access governance must be implemented differently. Managing roles and authorizations requires a dynamic view on authorizations. And for Role Based Access Control it means that dynamic role management is essential and that version control and monitoring of role assignement is a key requirement.

In regular Identity Governance and Administration solutions the hierarchical view on governance is part of the features. Therefore traditional IGA solutions do not fit well in non-hierarchical environments.

In a future blog we will explain how we try to solve these issues for our customers and we will show that being in control may not require a hierarchy after all.

Lessen over datalekken

De afgelopen weken hebben we ons keer op keer verbaasd over de aard en omvang van de datalekken bij de GGD’s. Inmiddels hebben de eerste arrestaties plaatsgevonden.

Ook zijn inmiddels maatregelen getroffen om het risico van datalekken in de toekomst te beperken. Er worden nu volop VoG’s opgevraagd, autorisaties zijn ingeperkt, de export-knop en de print-knop zijn uitgeschakeld. Maar dit is natuurlijk vooral achterstallig onderhoud. Natuurlijk moeten we niet uit het oog verliezen dat CoronIT en HPZone Lite door de GGD’s met stoom en kokend water voor het corona-testproces werden ingezet. En de plotselinge massaliteit maakte het blijkbaar moeilijk om alles netjes in te richten. Maar dan nog, het is achterstallig onderhoud, want wat nu fout bleek, was dus al langer fout.

Historisch besef

“Focus was steeds op wat er allemaal mogelijk is met data, niet op wat er niet zou moeten kunnen. Dat is wel belangrijk”, aldus een politicus tijdens het GGD Tweede Kamerdebat op 3 februari.

En dat is een interessante constatering. Deze politicus heeft wel begrepen dat wat ooit kon, nu misschien eigenlijk niet zou moeten mogen. Misschien had wel nooit gemogen…

Laten we voorop stellen dat inderdaad niet alles perfect kan of hoeft te lopen. Voor ons als buitenstaanders is het niet makkelijk om vast te stellen wat er in de informatievoorziening is fout gegaan. Wij kunnen niet bepalen hoe autorisaties eruit moeten zien.

Voorbeeld:
Het is volstrekt valide dat het voor bron- en contactonderzoek goed is als een onderzoeker in bestanden kan rondkijken. Maar dan wordt het spannend. Dat rondkijken moet wel mogen. Het moet noodzakelijk zijn. Er moet ook een grondslag voor zijn. En dat betekent al dat er nagedacht moet zijn over de manier om het proces uit te voeren. Iemand moet hebben nagedacht over het proces en de regels bepaald hebben voor het proces. En dat is de Governance vraag. Wie mag wat en waarom is dat zo?

Moeilijk

En dan deze:

“Het moet toch niet zo moeilijk zijn één systeem te maken dat regelt dat alleen bevoegden toegang hebben tot data?”, aldus een politicus in het GGD debat….

Tsja, eigenlijk verklaart dit zoveel: Hier heerst een volkomen onbegrip over wat er kan, wat er mag en wat we willen. ‘Het is niet zo moeilijk om’  is de kern van het probleem waarom het nu juist zo vaak fout gaat. In de praktijk merken we namelijk dat ‘Het is niet zo moeilijk’ in feite neerkomt op Organizational Change. En daar zijn weinig organisaties klaar voor.

In mijn optiek moeten we werken aan Access Governance. We moeten op een fatsoenlijke manier beheersen, besturen en verantwoording afleggen over wie nu wat mag met systemen en gegevens, en vooral waaróm iemand dat zou moeten mogen. Die waarom-vraag is cruciaal om het vraagstuk van toegang te kunnen beoordelen. Maar dat probleem wordt vaak niet onderkend en dan komt het knelpunt vaak terecht bij de ICT-afdeling. Die het vervolgens niet alleen kan oplossen..

Informatiebeveiliging: Meer dan alleen IAM

Vanuit ons perspectief is informatiebeveiliging het managen van wie toegang heeft tot wat. IAM, Identity and Access Management, wordt vaak gezien als het enige beroep om het wie, wat en waarom te managen.

Naar onze mening is dat niet zo. Het beheren van identiteiten en het beheren van toegang komen er een aantal zaken aan bod in verschillende domeinen. Bij identiteitsbeheer draait alles om het automatiseren van processen voor joiner, mover en leaver in een identiteitslevenscyclus. Het gaat over personeelsbeheer, klanten en consumenten, dingen, elk afzonderlijk object of elke dienst die mogelijk toegang moet krijgen tot alles wat moet worden beveiligd.

Toegangsbeheer is anders. Bij toegangsbeheer draait alles om het overhandigen van de sleutels van het kasteel. Maar deelt de sleutels uit en waarom? Mag dat wel? Op welk deel van het kasteel passen de sleutels? En waarom zou iemand de sleutels uitdelen?

Met trots presenteren wij u onze eerste officiële #tech #partnership. Wij kennen Nexis GmbH als een unieke oplossing voor het opzetten van complexe identity governance structuren. Hoewel dit nog grotendeels onderbelicht is, is het een enorm belangrijk element, omdat het beheer en de beveiliging van toegang zo veel beter en praktischer geregeld kan worden; kosten- en tijdbesparend. Bovendien integreert Nexis vrijwel naadloos met #IGA producten zoals SailPoint, OneIdentity etc. Omdat dit unieke element niet mag ontbreken in ons (managed) services portfolio, zijn wij erg blij met de start van onze samenwerking. Naast onze 3 consultants André Koot, Peter Stroomberg en Wilbert Sonnema met veel kennis van #IGA en dus ook Nexis, zullen ook de andere #SonicBees meer te weten komen over Nexis. Hiermee hebben we ook een primeur als eerste Nederlandse partij als kennispartner en #silverpartner van Nexis.

Geweldig om jullie als partner te hebben!
#RBAC #SoD #Attestation #RoleMining #IAM #Cybersecurity #collaboration

IGA versus CMDB  

(Identity Governance Administration v.s. Configuration Management Database) 

In my previous blog, I discussed the topic of managing the digital identity of devices, robots and other things. As I pointed out, effectively managing the identity of things is relevant from 2 viewpoints: the 'thing' getting access & the 'thing' as a managed object.

The Dual Role of 'Things' in Identity Management

The 'thing' as an accessing entity

It needs to use an account, in order to get access, to be able to perform tasks as a subject, or actor. Managing the identity cannot be done similarly to managing human identities managed in the human resource joiner-mover-leaver processes. Things are not onboarded in such a process, but thing identities are created in a change, managed in the change management process. The change can be a procurement of a device, or development of a device, or configuring of an RPA (Robotic Process Automation) and there may be multiple parties performing the change. Changes will also be put to the test in testing environments and acceptance environments before being put in production. 

The 'thing' as a managed object

The thing is a configuration item. It is managed in the configuration management database, through the already mentioned change management process. Furthermore, it is owned by someone who can provide access to a human actor who needs to maintain, read, or configure the thing, RPA (Robotic Process Automation), device, component, robot or whatever we can envision. 

Access Protocols for Things: How It Works

As I explained, managing the identities of things are done in the change management process. Access granted to the thing is done in this change management process (including all documentation and test results). And the owner of the thing will grant access to others, like service consumers, making use of the thing-capabilities. 

If the thing needs access, a digital identity will be created in the platform that the thing will use. An RPA identity will be created manually and conform to the naming convention for service accounts, like rpa_do_a_customer_analysis.  

Why IGA Isn't Suitable for Non-Human Accounts

The Limitations of Identity Governance and Administration (IGA)

In the previous blog, I focused on the account management processes to reach the conclusion that Identity Governance and Administration (IGA) solutions should not be used to manage non-human accounts. IGA solutions will find the digital identity that has been created during the reconciliation phase (while importing data from target systems). And the IGA administrator will classify the account as a non-personal account, to prevent all kinds of business processes, such as certification and being triggered incorrectly. 

The Inherent Differences Between Managing Human and Non-Human Identities

But there is a more fundamental reason why managing non-human accounts in an IGA system is not effective or efficient. And that's related to the difference in the very nature of things versus humans.

The Concept of Composition in Things

Composed Things: A Complexity Beyond Human Identity

In the article 'Managing non-human accounts' by Graham Williamson and me, we show differences between human and non-human accounts. But we didn't mention the concept of composition. 

Real-world Examples: The Transformative Tractor

Humans consist of one persona. And one person will always be one person. The one person can have multiple accounts, but that's an authorization issue, not an identity issue. 

A thing may not be just one thing. A thing can consist of multiple other things. And the assembly will act as one subject, one actor, one identity. The subcomponents are part of the thing. Think of a tractor. The tractor in itself consists of many parts. But a farmer can change the function of the tractor as a whole by changing parts for other special-purpose components. These things by themselves can perhaps not even operate autonomously. So, one tractor can change its nature. 

Context Matters: Identifying the True Nature of Composed Things

However, these other parts do not even belong to one tractor, other farmers can also use the component. That means that it's not possible to identify the function by just looking at the main component (the tractor, perhaps, the hitch, the power take-off, or whatever part looks essential). You need to look at the composed agricultural thing in the context of the workload, to identify its being.  

The Flexibility of RPAs and Their Management

Composed RPA (Robot Process Automation) 

The same is true for other things. Their nature may vary according to a change. An RPA may perform data harvesting activities, but it may be configured to destroy data after a change. It will not do so by itself, it's all based on the configuration. You need access to the component to make the component work. 

The Stakeholder Dilemma in RPA Management

Some may say that the line manager who is responsible for an RPA changes its role using an IGA system, but that misses the point. The thing has an owner, who needs to consult other stakeholders about the thing's activities, its character and its working time. The other stakeholders are accountable for granting access to the thing, it's not the operator of the accountable thing.  

Conclusion 

A thing is an actor. However, it is only allowed to act as long as the owners of the components that the thing is working on allowing it. For this reason, it is not just giving a role to a thing. It is changing the operation and thus changing its nature. It is a change.  

The way to manage these components is using a Configuration Management Database (CMDB). It can register relationships between components, create a hierarchical overview of parts and things, and change the compositions via the change management process.