Birth Right Permissions: A Barrier to Zero Trust Security

Written by Jerry Chapman, CSA ZT Working Group Co-Chair.

Identity is a pillar or workstream in Zero Trust Security models. It has also been stated that it is a signal to support multiple Zero Trust Security Models. I agree with these assertions. The standard Identity and Access Management (IAM) professional will tell you, “Identity is a business enabler”. This is also a true statement; one with which, I agree. As you work with IAM professionals, the standard services dialog starts to revolve around roles and role-based security, based on information that comes from an authoritative source (e.g., an HR system). This is the paradigm that has been happening for the 20+ years I have been in Identity and Access Management. This simply will not work in a Zero Trust ecosystem!

Regardless of the security paradigm an organization chooses to undertake, it is imperative the organization does not continue to follow the same paradigm IAM professionals have utilized! This leads to more permissions than necessary and can create both technological challenges as well as business challenges!

“Birth Right” permissions are often configured during a “role-mining” exercise to determine the access a user needs when they are hired into a new position within an organization, regardless of whether they are a new employee or current employee. The access permissions are given completely based on a title or other attribute(s). This, inherently, is the problem! These permissions contain applications (in some cases, sensitive business applications), data storage locations, or even physical access to sensitive locations!

Both business and technology processes can be changed to support minimal “Birth Right” permissions. Organizations often ask, what, then, should be considered for “Birth Right” permissions. That is usually a simple answer: Laptop provisioning, email, office suite (Microsoft, Google, others), and front door access. Other applications or physical locations can be provisioned based on context and need. For example, if a user needs access to the CRM system, the request can be managed through workflow and provided based on information like risk (have they used the system before), context (are they geographically located in a safe place), Title (VP Sales), and Supervisor’s approval, until it is established the application is utilized on a consistent basis, the workflow that provides access will put “JUST ENOUGH FRICTION” in place.

This would create a curve for the user and supervisors. Initial friction would be inherent until the system understood the need and allowed access with enough friction to ensure the user's identity. The curve would be steep with the change, then gradually, the friction would decrease until another change!

Develop and demonstrate an in-depth understanding of Zero Trust with CSA’s Certificate of Competence in Zero Trust (CCZT). Learn more here.