Cybersecurity: Identity and Access Management (IAM) and Role-Based Access Control (RBAC)
There are many items that I get to review and address, as I work side-by-side with my clients on their cybersecurity posture and resilience. One of the security aspects that are of a key concern is the organization’s Identity and Access Management (IAM). IAM is framework of policies, processes, and technologies that allow organizations to manage digital identities and to control access to the company’s crucial information. Some of the key factors that are considered when reviewing a organization’s IAM framework include:
- An understanding that IAM is a critical component of any organization’s security policy and is intended to support good cybersecurity and resiliency,
- A more interment comprehension that IAM helps to limit an organization’s cybersecurity risk exposure and decreases risk by ensuring that only the right personnel access specific systems and data within the organization,
- And that the use of Role-Based Access Control (RBAC) is an IAM strategy used by many systems to assign rights for who can do what within specific IT roles like applications, based on the organization’s structure and the users’ roles.
Role based access control (RBAC) (also called “role based security”) is an IAM method, as formalized in 1992 by David Ferraiolo and Rick Kuhn, has become the predominant model for advanced access control because it reduces this cost due to the simplicity of the model and the available tools to implement the model successfully. Also, it should be noted that the National Institute of Science and Technology (NIST) supports a model for RBAC deployment that was adopted as American National Standard 359–2004 by the American National Standards Institute, International Committee for Information Technology Standards (ANSI/INCITS) on February 11, 2004 and was revised as INCITS 359–2012 in 2012, indicating it’s significance as a viable cybersecurity approach to handling the IAM issues that an organization must contend with. The success of RBAC is due to several inherent design features including:
- RBAC is policy neutral.
- RBAC is NOT about authenticating users or managing users — it’s about managing access control (to files, objects, computers, etc.).
- ‘Entitlements’ or ‘Permissions’ are the foundation for role modeling (for creating roles).
- When a role is created in RBAC, specific permissions are granted to a designated role.
When using roles in RBAC, we create roles that a given user can be attached to. As an example, we can create a high-level Business role. As a high-level role, when can apply subordinate roles to the more generalized Business role. This will allow us to ultimately create a hierarchy of roles for the organization and then, assign specific rights and permissions to each role described in the hierarchy. For example:
9 Business roles are generic roles that a user can join.
9 Other roles such as a Manager (user role) or Business Analyst (user role) can be created.
9 Once roles are established, permissions are assigned to those roles.
9 Following the assignment of permissions to roles, users are assigned to a role.
Defining terms for RBAC
Prior to looking deeper into developing a process to capture RBAC rules for the Organization, a list of definitions will help us to better understand the process involved in describing RBAC for our organization. The following is a list of terms that we’ll later use when we discuss RBAC Roles, Users, and Rights in Figure 1.
- user: human being / autonomous agent / computer*
9 Note: Active directory separates out users (people/agents) from computers (hardware devices)
- Role (R): job function with associated semantics regarding the authority and responsibility conferred on a member of the role.
- Permission (P): an approval of a particular mode of access to one or more objects in the system.
- user assignment (UA): many-to-many relation between U and R.
- permission assignment (PA): many-to-many relation between R and P.
- session (S): mapping of one user to possibly many roles.
Some additional rules that drive the development of RBAC include the following:
- The Policy does not (typically) need to be updated when a specific person leaves a role in the organization (since Policy is associated with a Role)
- New Employee (or an Employee who changes roles) is activated into that role
- Concept is to maintain ‘least privilege’ for a given role
9 A user in one role has access to a defined ‘subset’ of files within the organization
9 The user can switch roles to gain access to other designated files
9 Enforce least privilege and segregation of duties on your privileged accounts.
The Bottom line with RBAC and Privileged credentials is that this provides the keys to the IT kingdom. Administrators must be able to customize permissions and access to meet security requirements and ensure that users can’t accidentally or intentionally change administrative settings they shouldn’t have rights to.
The aim of RBAC
The aim of RBAC as a framework is to provide for the simplification of managing permissions. Permissions (for access to a data store, for example) are simplified since permissions are granted by associating a set of permissions to specific roles. Then, once the roles are designed, users are assigned to roles.
Later, roles can be granted additional permissions as new applications and systems are incorporated into the organization’s portfolio of systems. Also, permissions can be revoked from roles as required by system changes. In RBAC, the development of roles is said to be more stable than assigning permissions directly to users. Since the organization’s activities or functions often change less frequently in contrast to the users’ membership to roles, the role can remain relatively unchanged for a duration of time. The diagram below shows the central focus of roles (and the role hierarchy) as it applies to (a) the rights/permissions granted to each role and (b) the users assigned to roles (see Figure 1 below).
Developing a Process to Capture RBAC rules for the Organization
To implement a set of suitable roles, a process to capture the organization’s rules must first be achieved. Conceptually, the organization can develop a hierarchy of roles that reflect how it does business. In the example below (see Figure 2), a hierarchy of “Business” roles that contain subordinate roles of (a) Administrative (roles) and (b) Engineering (roles) is identified. Further, the Administrative role is decomposed into (a) Manager, (b) Security Analyst, and c) Human Resource roles, as this hierarchy reflects how this given organization does business. In addition, the Engineering role is also decomposed into subordinate roles that contain Design, Quality Assurance, and Testing roles.
Steps for Gathering Information
A general stepwise approach for describing RBAC in an organization includes at least the following 4 steps. These include the 4 steps below and each step is further described in subsequent sections in this article. The 4 steps are:
• Step 1: Define Roles within the organization: Define a role hierarch for the organization. This hierarchy should reflect how the organization does business.
• Step 2: For Each Role, Define Access and type of access (CRUD): The record types highlighted in green represent functionality that must be specifically selected for your company, so you may not see those items in your list.
• Step 3: Designate one default access profile and one owner profile: For each role, you must designate one default access profile and one owner access profile.
• Step 4: Select the Appropriate Privileges for each role: For each role, you must select the appropriate privileges for each role.
Additional detail about each of the 4 steps used in the development of an RBAC scheme for the organization is provided I n the sections below.
Step 1: Define Roles within the organization
Our goal with the first step is to define a role hierarch for the organization. This hierarchy should reflect how the organization does business, or how the organization desires to do business in the future. While this can be mapped out in a document, Figure 3 shows the use of a spreadsheet to define role names, a description, and other items about each role that the organization is designing.
Step 2: For Each Role, Define Access and type of access (CRUD)
For each role that you described in the first step, define the access including the ability to create, read, update, and delete (CRUD). The record types shown in the spreadsheet below highlighted in green represent functionality that must be specifically selected for your company.
Step 3: Designate one default access profile and one owner profile
In the third step of defining the RBAC for your organization, designate one default access profile and one owner profile. By doing this, this approach allows for more flexibility when a given user or set of users fall slightly outside of their more generic roles.
Step 4: Select the Appropriate Privileges for each role
Once step 3 is completed, then select the Appropriate Privileges for each role: For each role, you must select the appropriate privileges for each role. Again, remember these are privileges for the role. Ultimately, your users will be assigned to the role or roles that they receive permissions from.
A Brief Tour of Applying RBAC in MS/Active Directory
Please keep in mind this article is about the preliminary design of roles in the RBAC scheme. Once roles are defined and permissions are provisioned to each role, the user is associated with their respective roles.
Many organizations use Microsoft Active Directory to implement roles within the organization. MS/AD is used by well over 72% of organizations to manage their IAM and RBAC services. Given this high percentage, the sections below briefly describe how MS/AD is used to set up roles. While this article is not intended to be a comprehensive tutorial of using server manager to define roles, a quick overview of a few essential screens are presented as a primer to using Microsoft Active directory add the organizational unit objects to provision RBAC.
To apply roles in MS/Active directory, log into the server manager dashboard. Under the “Active Directory Users and Computers” you will see the existing objects and folders, as shown in Figure 7 below.
The next step is to select the new and add an organizational unit to your Active Directory instance, as shown in Figure 8 below. At this time, I will stop at this brief overview, as this article is not intended to provide a comprehensive tutorial on Active Directory and the implementation of RBAC. That must be saved for later and for a different venue, such as a training venue.
In Summary
RBAC, or Roles Based Access Control, is a common IAM method deployed my many organizations. RBAC allows for the development of roles and the association of permissions to those roles. Users are then assigned roles. This schema disassociates the need for continual changes directly to user permissions, thus supporting a more robust way to manage the security and permissions for users in the organization. Also, since MS/Active Directory is the predominant way of implementing RBAC in an organization, given the high percent of AD deployment, a few screens were shown as a primer to doing a further exploration of implementing RBAC in an MS/Active Directory environment.
Resources
NIST standards for RBAC: https://csrc.nist.gov/projects/role-based-access-control
Role Based Access Controls (NIST): https://csrc.nist.gov/publications/detail/conference-paper/1992/10/13/role-based-access-controls
About the Author
Ron McFarland, PhD, CISSP is a Senior Cybersecurity Consultant at CMTC (California Manufacturing Technology Consulting) in Torrance, CA. He received his doctorate from NSU’s School of Engineering and Computer Science, MSc in Computer Science from Arizona State University, and a Post-Doc graduate research program in Cyber Security Technologies from the University of Maryland. He taught Cisco CCNA (Cisco Certified Network Associate), CCNP (Cisco Certified Network Professional), CCDA (Design), CCNA-Security and other Cisco courses and was honored with the Cisco Academy Instructor (CAI) Excellence Award in 2010, 2011, and 2012 for excellence in teaching. He also holds multiple security certifications including the prestigious Certified Information Systems Security Professional (CISSP) certification and several Cisco certifications.
CONTACT Dr. Ron McFarland, MSc, PhD, CDNA, CISSP
CMTC Email: rmcfarland@cmtc.com
Email: highervista@gmail.com
LinkedIn: https://www.linkedin.com/in/highervista/
Website: https://www.highervista.com
YouTube Channel: https://www.youtube.com/channel/UCJ57_1OgZ5H1nMVdGElcvrw
