5 Steps for Transitioning to RBAC Models

In my last article, I explored why so many organizations are switching from UID, to role-based access control (RBAC) models along with the preparatory process for preparing for this transition. So, the next question becomes: If the use of Roles is convenient for our systems and we’ve done the prep work for the transitioning, what comes next? Here are 5 steps you should follow.

1. Access Analysis

The ACFRPTRX Report

The ACFRPTRX report generator produces a Logonid Access Report showing all rule sets that apply to a specific logonid (LID) mask or user identification string mask.

The ACFRPTRX report gives a detailed overview of user logonid records, their associated permissions, and other related details. Here's a breakdown of its utility and relevance to the process of transitioning to role-based access:

• Comprehensive User Access Overview: The report provides detailed insights into which users (logonids) have access to which resources, their level of access, and any special permissions or restrictions. This granularity can help determine current access levels and understand where over-privileges or under-privileges might exist.
• Baseline for Role Modeling: By reviewing the ACFRPTRX report, you can get an idea of common access patterns. For instance, if several users have a similar set of permissions, it might indicate the need for a specific role that encapsulates those permissions. The report helps in creating initial role models by grouping users with similar access rights.
• Identification of Anomalies: In large organizations, especially after years of operations, there might be outdated permissions or anomalies in user access. The ACFRPTRX report can highlight such discrepancies. For instance, users who've switched departments but still retain old permissions can be spotted, which aids in the cleanup process.
• Validation and Verification: As you begin transitioning to a role-based model, the ACFRPTRX report can be used for validation. You can ensure that the permissions granted by new roles align with the original permissions users had, ensuring no unintentional access is given or taken away. It acts as a reference point to verify that the transition is proceeding as expected.

The Cross-Reference Report (ACFRPTXR)

The ACFRPTXR, known as the Cross-Reference Report in ACF2, produces a comprehensive overview of rule entries and their associated resources. When transitioning to a role-based access model, understanding how permissions and resources interplay is crucial. The ACFRPTXR report can assist in various capacities during this transition:

• Mapping Resources to Rules: The Cross-Reference Report provides an exhaustive list of rule entries and the specific resources they govern. This mapping can be crucial in understanding how resources are currently protected and which rules need modification or consolidation in a role-based model.
• Identifying Overlapping Permissions: By analyzing the report, you can identify if multiple rules are governing the same resources. This overlap might indicate redundancy or even conflicting rules. Spotting these overlaps early can help in simplifying and streamlining role definitions.
• Optimizing Rule Consolidation: As you transition to roles, you may wish to consolidate several rules into broader ones aligned with specific roles. The report can guide this process by highlighting which rules are frequently used together.
• Highlighting Infrequently Used Rules: Rules that are rarely invoked or associated with few resources can be candidates for reevaluation or removal. The Cross-Reference Report can help pinpoint such rules, ensuring that the role-based model is efficient and devoid of unnecessary complexities.
• Audit and Compliance: The report offers a bird's-eye view of rule-resource relationships, which can be vital for audit purposes. Being able to demonstrate how resources are protected and which rules govern them can aid in compliance checks and internal audit verifications.
• Validation and Verification: Post-transition, the ACFRPTXR can be employed to validate that resources are adequately protected by the new role-based rules. It acts as a measure to ensure that the transition has not inadvertently exposed resources or introduced security gaps.
• Troubleshooting and Resolution: In case of access issues or conflicts, the Cross-Reference Report can be a first point of reference to determine which rules might be causing the problem. By understanding the rule-resource relationship, troubleshooting becomes more efficient, reducing system downtime or user access issues.

2. User Segmentation

User segmentation is the process of categorizing and subdividing a larger user base into more specific and manageable groups based on shared characteristics, needs, behaviors, or attributes. In the context of IT security and access controls, user segmentation is an indispensable approach that ensures that the right people have the appropriate levels of access to specific resources. By segmenting users, organizations can craft more accurate, efficient, and secure access policies.

Why is User Segmentation Essential?

• Granular Control: It ensures that access controls can be tailored for specific groups, ensuring that users only have access to the resources they genuinely need.
• Ease of Management: When users are segmented, applying, updating, or modifying access controls becomes simpler as the changes can be implemented at a group level.
• Enhanced Security: By minimizing unnecessary access and ensuring that only relevant personnel can reach sensitive resources, the potential attack surface is reduced.
• Efficiency: It's far more efficient to manage access at a group level rather than individually. Group-based policies ensure uniformity and reduce the chances of oversight or error.

Grouping Users by Departments

One of the most common and logical ways to segment users is by department. This approach makes sense because, typically, members of a particular department have similar roles and, therefore, similar access needs.

Advantages:

• Natural Division: Departments inherently represent different functions within an organization (e.g., HR, Finance, IT, Sales). These functions typically have distinct data and application needs.
• Ease of Implementation: Many organizations already have an organizational chart or a structure that clearly defines these departments.
• Scalability: As the organization grows or evolves, new departments can be added, or existing ones can be subdivided further.

Challenges:

• Inter-departmental Roles: Some roles might span multiple departments, requiring a more nuanced approach to access controls.
• Changing Structures: Departments can be merged, divided, or restructured, which would necessitate a review and modification of access controls.

Conducting Surveys or Interviews

To further refine user segmentation and truly understand the access needs of different groups, conducting surveys or interviews can be invaluable. This approach helps gather insights directly from the users.

Advantages:

• Understanding Actual Needs: Surveys and interviews can shed light on what resources users frequently access, which ones they rarely use, and what they might need in the future. This direct feedback ensures that the segmentation is not just based on assumptions but actual use cases.
• Identifying Overlaps and Gaps: Through direct communication, it's possible to spot areas where multiple departments might need access to the same resources or where there are unmet needs.
• Enhancing Security Awareness: The act of engaging users in surveys or interviews can serve as an opportunity to enhance their awareness of security protocols, the importance of proper access controls, and the rationale behind the segmentation.

Challenges:

• Time and Resources: Conducting thorough surveys or interviews requires a commitment of time and potentially additional resources.
• Subjectivity: While user feedback is invaluable, it's essential to balance user desires with security best practices. Not all access requests may be granted based on user feedback alone.

User segmentation, whether by departmental grouping or refined through surveys and interviews, is a cornerstone of crafting robust and efficient access controls. In an era where data breaches are frequent and costly, ensuring that users have the right level of access—not too much and not too little—is not just a matter of efficiency but of security. Engaging users in the process, understanding their needs, and tailoring access controls to suit those needs can help strike the right balance.

3. Model Role Creation

The process of Model Role Creation is an essential component of Role-Based Access Control (RBAC). Instead of assigning permissions directly to individual users, permissions are assigned to roles, and users are then assigned to these roles. This approach centralizes permissions management and makes it more scalable and maintainable.

Based on the segmentation and access analysis, define model roles that represent common permission sets. For example, an "accountant role" might have access to certain financial datasets.

Not every user will fit perfectly into a model role, but the idea is to cover as many users as possible with these roles. 

Data Owners are often in a position to accurately identify and define the different roles that need to be established within a role-based access control model, ensuring that each role has the appropriate level of access to perform their job functions without compromising security or compliance.

Data owners typically understand the nature and sensitivity of the data they oversee. They can define who needs access to what data and at which permission levels and can assist in segregating users based on their data access needs, which is critical in the development of roles and permissions within ACF2.

Here are some of the more technical roles related to the mainframe infrastructure.

Mainframe System Administrator:

• Responsibilities: Oversees the daily operations of the mainframe system, ensures optimal performance, conducts routine maintenance, and coordinates updates or upgrades. Also responsible for troubleshooting system-level issues.
• Access: Broad access to system-level functionalities, but typically restricted from accessing application-level data, especially sensitive financial or customer data.

Mainframe Security Administrator:

• Responsibilities: Manages user profiles, roles, rules. Ensures that security policies are enforced and conducts regular audits to verify compliance. Addresses vulnerabilities and ensures data protection standards are met.
• Access: Comprehensive access to security-related tools and configurations. Often uses tools like ACF2, Top Secret, Cleanup, TAMz…

Database Administrator (DBA):

• Responsibilities: Manages mainframe databases, optimizes performance, ensures data integrity, and manages data backups. Implements and enforces database security measures.
• Access: Full access to the mainframe's database systems, such as Db2 or Datacom, but restricted from non-database applications.

Application Developer:

• Responsibilities: Designs, codes, tests, and deploys mainframe applications. These applications often include core banking systems, loan processing systems, and other financial tools.
• Access: Access to development and testing environments. Depending on the policies, they might have restricted or no access to production environments.

Batch Job Scheduler:

• Responsibilities: Schedules, monitors, and manages batch jobs, ensuring they run at optimal times and without conflicts. Handles job dependencies and ensures timely processing.
• Access: Primarily to scheduling tools and job queues. Limited access to the actual data being processed.

Transaction Processing Specialist:

• Responsibilities: Monitors transaction processing systems like CICS or IMS. Ensures smooth processing of real-time transactions.
• Access: Access to transaction processing systems and related monitoring tools.

Storage Administrator:

• Responsibilities: Manages mainframe storage solutions, ensures data is backed up correctly, and optimizes storage for performance and cost.
• Access: Full permissions for storage-related tools and data repositories.

Mainframe Network Engineer:

• Responsibilities: Manages the mainframe's networking capabilities, ensuring connectivity, security, and optimal data transfer rates.
• Access: Networking configurations and related tools.

Audit and Compliance Officer:

• Responsibilities: Regularly reviews mainframe operations to ensure compliance with internal policies and external regulations. Identifies risks and recommends mitigations.
• Access: Audit logs, security configurations, and often, read-only access to various parts of the system for review purposes.

4. Validation and Testing

Once roles are defined and users are segmented, data owners can validate whether the permissions granted align with the requirements of each role and ensure that there are no excessive permissions or access limitations.

The transition to a role-based system, especially in complex environments such as mainframes, should be approached with caution and careful planning. Implementing a gradual transition is a sound strategy to ensure that the new system works correctly without causing disruptions. 

Here's a step-by-step guide on how this gradual transition can be executed:

Pilot Selection:

• Users: Start by selecting a small group of users, preferably those who are well-versed with the system and can provide constructive feedback.
• Roles: Define a limited set of roles that represent a cross-section of your overall planned roles.
• Rules: Identify a subset of the rules that govern access and permissions for the selected roles.

Initial Implementation:

1. Define: Explicitly detail the permissions, responsibilities, and access for each role.
2. Assign: Grant the selected users their respective roles in the test environment.
3. Document: Keep a detailed record of all configurations, permissions, and assignments. This will aid in troubleshooting and future scalability.

Testing Phase:

• Functional Testing: Ensure that users can perform all tasks associated with their roles without any issues.
• Boundary Testing: Verify that users cannot perform functions outside of their assigned roles.
• Feedback Loop: Encourage users to provide feedback about their experiences, challenges, or any ambiguities they encounter.
• Review and Iteration: Based on feedback and test results, make necessary modifications to the roles, rules, or assignments.
• Repeat the testing phase as many times as necessary until the system operates flawlessly.

Incremental Expansion:

• Phase-wise Rollout: Once satisfied with the pilot, gradually expand the implementation to include more users, roles, and rules in phases.
• Continuous Monitoring: As you expand, continuously monitor the system for any anomalies or challenges.
• Feedback Collection: As more users get involved, continue collecting feedback to refine and optimize the system further.

Training and Communication:

• Training: As the transition progresses, ensure that all users are trained on the new role-based system and understand their responsibilities.
• Communication: Maintain open channels of communication to address concerns, queries, or feedback from the users.

Full-Scale Implementation:

After successful phased implementations and when confident in the system's stability, you can proceed with a full-scale rollout.

Ensure that backup and recovery mechanisms are in place to revert to the old system if any unforeseen challenges arise.

Continuous Review and Refinement:

Even after a full transition, regularly review the role-based system to ensure it remains relevant and effective.Be sure to adjust roles or rules as necessary to cater to evolving business needs or to address any newly identified challenges.

Data owners would likely engage in a continuous review of roles and access, ensuring that as the business evolves, access controls evolve too, maintaining the principle of least privilege. They are key for initiatives like recertifications, where data owners validate that the existing access aligns with current needs and adjust accordingly.

Remember, the key to a successful gradual transition lies in meticulous planning, continuous feedback, rigorous testing, and open communication. By implementing in phases, you can identify and address challenges on a smaller scale before they become widespread issues.

There are two utilities in ACF2 that can help us during this phase:

The TEST Subcommand

The TEST subcommand lets you interactively test a compiled rule set. Testing determines whether the rule set allows the access you intended. When you specify the TEST subcommand, ACF2 performs a validation of the compiled rule but does not create any loggings for violations. The TEST subcommand checks the test rule against the current rules in a directory; you might have to store the rule and rebuild the directory before testing to get accurate results for the test.

After you enter the TEST subcommand keywords, the system displays all of the current values that describe the environment being tested. For example, the following keywords test whether the access rule set PAYROLL lets the user TFINPAYNLT access the data set:

The Access Subcommand

The ACCESS subcommand simulates validation for users that match the UID mask, ROLE, or USER on each matching rule line.

The following example shows how the ACCESS subcommand is used:

 ACF

access dsname(‘public.jcllib’) ← Specify the access to be checked

$KEY(PUBLIC) ← Rule found

Logonids with access to: PUBLIC.JCLLIB

USER04 READ, WRITE

USER02 READ, WRITE

ALL LIDS READ

Logonids prevented access to: PUBLIC.JCLLIB USER07 USER09

5. Roles and Rules

X-ROL Records

Cross-reference role group (X-ROL) records lets you implement role-based security at your site. You can assign users to roles and assign accesses that are based on those roles. Roles can also be grouped into role groups. Both roles and role Groups can be specified in data set and resource rules.

The data set or resource rule is created or modified by entering the X-ROL record name in the new role field in place of the UID string in the rule lines

During access validation on a roleset rule, the first role in a user’s table is used for validation against the rule line. If the user is not granted access by a rule line from this role, the next role from the table is used and validation of the rule starts over. This process continues until access is allowed or the user’s table of roles is exhausted, when access is denied. Loggings are reported on the active role.

The general structure for defining an role would look something like this:

• Rolename: Specify 1 to 8 characters unique to the role.
• ROLE|GROUP: Select if the entries in this definition refer to LIDs (ROLE) or roles (GROUP).
• Entryn: Specify 1 to 8 characters to identify LIDs for one role or several roles grouped in a role.
• Asterisk characters can be used for masking.
• DESCRIPT(description): Specify any text string of up to 100 characters.

In the following examples we can see how to create different types of Roles and how to add hundreds or thousands of users in a single command using masks.

ACF2 Rules: UID VS Role

Access rules outline the specific circumstances or settings under which certain data sets can be accessed, deciding if a user or a collective group can or cannot gain access. On the other hand, resource rules lay out the specific conditions for gaining access to distinct resources. These resources encompass elements like TSO accounts, procedures related to TSO, IMS-related elements, commands, and CICS-related files and data, among others. They also include system elements guarded by SAF calls and any other resource the organization wishes to specify. 

In ACF2, the distinction between rules using the UID String and those using X-ROL is foundational to how access control is managed. Here's a breakdown of the differences:

Who the rule applies to:

• Traditional: Use UID(uidmask)
• ROLESET: Use ROLE(rolename) or USER(lid)

$Key(high-level-index): $KEY is the only required control statement.Specifies the high-level index of the data set name for which this rule is being written or the VSAM key of the rule set. You can specify one- to eight-characters. For example, when you compile a rule set to permit access to the data set SYS1.PARMLIB, the $KEY control statement contains $KEY(SYS1), because SYS1 is the high-level (or first) index of the data set name. This field cannot be masked.

UID(LASSLMGRACCT023): This UID mask can represent any UID that begins with the letters LASSLMGRACCT023 and ends with up to 9 characters. (A valid UID can contain up to 24 total characters.) A UID mask can be defined by omitting ending characters, by using asterisks (*), or by using a dash (-).

$Roleset: Designates this rule set as a role rule set that must contain role parameters in rule line entries. UID parameters are NOT allowed in this rule set. ROLE and USER are valid parameters on roleset rule line entries.

ROle(role): Specifies the name of an X(ROL) record to indicate the users for whom this rule entry applies. If you specify ROLE(-), the entry applies to all users of the system. Masks other than ROLE(-) are not allowed. During access validation on a Roleset rule, the first role in the list is used for validation. If access is denied, the next role in the list is selected and validation is redriven. This process continues until access is allowed or the user's list of roles is exhausted.

ROLE cannot be used in non-$ROLESET rules.

USer(logonid): Specifies a logonid to indicate the particular user for whom this rule entry applies. If you specify USER(-), the entry applies to all users of the system. 

%CHANGE and %Rchange are used to delegate rule set administration.

Using NEXTKEYs with $ROLESET Rules

In ACF2, you have the flexibility to blend both $ROLESET rules and the traditional UID rules within the same NEXTKEY path. This means that while migrating towards a $ROLESET-based system, you don't need to make an abrupt transition and upend your entire existing setup. Instead, you can incrementally introduce $ROLESET rules while still retaining and functioning with the traditional UID-based rules.

The NEXTKEY parameter directs ACF2 to evaluate an alternate access rule set when a particular environment applies to the access, but the access is prevented. ACF2 only checks the NEXTKEY parameter when the access matches the environment, but the rule prevents the access.

When using the NEXTKEY parameter in a ROLESET rule, the same ROLE has to match throughout the NEXTKEY chain. Higher level rules could use ROLE(-) since ROLE(-) will match any role. ROLE(-) will also match for logonids that have no roles.

During access validation on a $ROLESET rule, the first role in the user’s list of roles is used for validation. If access is denied, the next role in the list is selected and validation is re-driven, possibly taking a different NEXTKEY path. This process continues until access is allowed or the user’s list of roles is exhausted.

Learn More

If you have questions about this process, please feel free to reach out to me at jose.arias@broadcom.com.