Introduction: The Gatekeeper of Access

In Lessons 6.1 and 6.2, we established the foundations of Identity and Access Management (IAM) and explored authentication mechanisms in financial institutions. We examined the core IAM concepts of identity, authentication, authorization, and accountability. We analyzed the identity lifecycle from registration to deprovisioning. We also explored authentication mechanisms including passwords, multi-factor authentication, biometrics, and certificate-based authentication. Each of these components ensures that users, systems, and devices are properly identified and verified before accessing resources.

However, authentication alone is insufficient. Once identity is verified, the system must determine what access is granted. This is the domain of authorization. Authorization is the process of determining what resources a verified identity can access and what actions they can perform. It is the gatekeeper of access, ensuring that users only access the resources they need and perform only the actions they are authorized to perform.

In financial institutions, authorization is of paramount importance because it:

  • Protects Sensitive Data: Ensures that customer information, financial data, and trade secrets are only accessible to authorized individuals.

  • Prevents Fraud: Restricts access to financial systems and transactions to authorized users.

  • Ensures Compliance: Meets regulatory requirements for access control (GLBA, SOX, GDPR, NYDFS, PCI DSS).

  • Enforces Least Privilege: Limits access to only what is necessary for each role, reducing the attack surface.

This lesson provides a comprehensive analysis of authorization and access control models. We begin by examining the Access Control Models: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Discretionary Access Control (DAC), and Mandatory Access Control (MAC). We derive the Access Control Security Score: A_CS = P_olicy * E_nforcement * A_uditing.

We then examine Role-Based Access Control (RBAC) in depth, including role engineering, role assignment, and role management. We derive the RBAC Effectiveness Score: R_ES = R_oles * P_ermissions * U_sers.

We also examine Attribute-Based Access Control (ABAC) , including attribute types, policy definition, and policy enforcement. We derive the ABAC Effectiveness Score: A_ES = A_ttributes * P_olicies * E_nforcement.

We also examine Access Control Models in Financial Institutions, including implementation considerations, best practices, and compliance requirements. We derive the Access Control Compliance Score: A_CC = R_egulations * P_olicies * M_onitoring.

By the end, you will have a complete understanding of authorization and access control models, and be able to design and implement access control systems for financial institutions.

Learning Objectives

Upon completion of this lesson, you will be able to:

  1. Analyze the Access Control Models: RBAC, ABAC, DAC, and MAC.

  2. Derive the Access Control Security Score: A_CS = P_olicy * E_nforcement * A_uditing.

  3. Analyze Role-Based Access Control (RBAC) : Role engineering, assignment, and management.

  4. Derive the RBAC Effectiveness Score: R_ES = R_oles * P_ermissions * U_sers.

  5. Analyze Attribute-Based Access Control (ABAC) : Attributes, policies, and enforcement.

  6. Derive the ABAC Effectiveness Score: A_ES = A_ttributes * P_olicies * E_nforcement.

  7. Analyze Access Control Models in financial institutions.

  8. Derive the Access Control Compliance Score: A_CC = R_egulations * P_olicies * M_onitoring.

Part 1: Access Control Models

1.1 The Access Control Definition

Access control is the process of determining what resources a verified identity can access and what actions they can perform.

text
Access Control = {Subject, Object, Operation, Authorization}

1.2 The Four Core Models

text
Access Control Models = {RBAC, ABAC, DAC, MAC}

1.3 Model Comparison

 
 
Model Description Granularity Complexity Use Case
RBAC Role-Based Access Control Medium Medium Employees by job role
ABAC Attribute-Based Access Control High High Dynamic policies
DAC Discretionary Access Control Low Low Resource owner control
MAC Mandatory Access Control High High Government, military

1.4 Role-Based Access Control (RBAC)

Definition: RBAC grants access based on the roles that users hold within the organization.

text
RBAC = {Roles, Permissions, Users}

Key Concepts:

 
 
Concept Description Example
User An individual or system John Doe, System Account
Role A job function or position Teller, Manager, Trader
Permission An action on a resource Read, Write, Execute
Role Assignment User assigned to a role John Doe assigned Teller role
Permission Assignment Role granted permissions Teller role has Read permission

RBAC Principles:

 
 
Principle Description Implementation
Role Engineering Identify and define roles Role analysis, role mining
Least Privilege Grant minimum necessary permissions Role-based permissions
Separation of Duties No single role has complete control Role segregation
Role Management Manage roles lifecycle Role creation, modification, deletion

1.5 Attribute-Based Access Control (ABAC)

Definition: ABAC grants access based on attributes of the subject, object, environment, and action.

text
ABAC = {Attributes, Policies, Enforcement}

Attribute Types:

 
 
Attribute Type Description Examples
Subject Attributes Attributes of the user Role, department, clearance level
Object Attributes Attributes of the resource Data classification, owner
Environment Attributes Attributes of the environment Time, location, device
Action Attributes Attributes of the action Read, Write, Execute

ABAC Policies:

 
 
Policy Element Description Example
Rule A condition that must be satisfied Role = Manager AND Location = Office
Policy A set of rules Access allowed if rules are satisfied
Policy Set A set of policies Multiple policies combined

1.6 Discretionary Access Control (DAC)

Definition: DAC grants access based on the discretion of the resource owner.

text
DAC = {Owner, Permissions, Access Control Lists}

Key Concepts:

 
 
Concept Description Example
Owner The creator or owner of the resource File owner, document owner
Access Control List (ACL) List of users and their permissions Read: John, Write: Mary
Permission Granting Owner grants permissions Owner adds user to ACL

1.7 Mandatory Access Control (MAC)

Definition: MAC grants access based on system-wide security labels and clearances.

text
MAC = {Security Labels, Clearances, Policy}

Key Concepts:

 
 
Concept Description Example
Security Label Classification level of resource Top Secret, Secret, Confidential
Clearance Security clearance of user Top Secret clearance
Policy System-wide access policy No read up, no write down

1.8 The Access Control Security Score

The Access Control Security Score quantifies the security of access control:

text
A_CS = P_olicy * E_nforcement * A_uditing

Where:

  • P_olicy is the Policy Score (0-1)

  • E_nforcement is the Enforcement Score (0-1)

  • A_uditing is the Auditing Score (0-1)

 
 
Component Description Scoring Factors
Policy (P) Quality of access control policies Completeness, clarity, currency
Enforcement (E) Effectiveness of enforcement Implementation, monitoring
Auditing (A) Effectiveness of auditing Coverage, frequency, quality
text
Access Control Models (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Role-Based Access Control (RBAC)                               ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Access based on job roles                                       ║  |
|  ║  User → Role → Permission                                       ║  |
|  ║  Granularity: Medium                                             ║  |
|  ║  Complexity: Medium                                              ║  |
|  ║  Example: Teller, Manager, Trader                              ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Attribute-Based Access Control (ABAC)                          ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Access based on attributes                                      ║  |
|  ║  Subject + Object + Environment + Action → Decision            ║  |
|  ║  Granularity: High                                               ║  |
|  ║  Complexity: High                                                ║  |
|  ║  Example: Role = Manager AND Location = Office                 ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Discretionary Access Control (DAC)                            ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Access based on owner discretion                                ║  |
|  ║  Owner grants permissions                                        ║  |
|  ║  Granularity: Low                                                ║  |
|  ║  Complexity: Low                                                 ║  |
|  ║  Example: File permissions, Access Control Lists                ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Mandatory Access Control (MAC)                                ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Access based on security labels                                 ║  |
|  ║  Labels + Clearances + Policy → Decision                        ║  |
|  ║  Granularity: High                                               ║  |
|  ║  Complexity: High                                                ║  |
|  ║  Example: Top Secret, Secret, Confidential                     ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  Formula: A_CS = P_olicy * E_nforcement * A_uditing                  │
└─────────────────────────────────────────────────────────────────────────┘

Part 2: Role-Based Access Control (RBAC)

2.1 The RBAC Definition

RBAC grants access based on the roles that users hold within the organization.

text
RBAC = {Roles, Permissions, Users, Assignments}

2.2 RBAC Components

 
 
Component Description Example
User An individual or system John Doe, System Account
Role A job function or position Teller, Manager, Trader
Permission An action on a resource Read, Write, Execute
User-Role Assignment User assigned to a role John Doe assigned Teller role
Role-Permission Assignment Role granted permissions Teller role has Read permission

2.3 Role Engineering

Definition: Role engineering is the process of identifying and defining roles based on business functions.

text
Role Engineering = {Role Identification, Role Analysis, Role Definition}

Role Engineering Steps:

 
 
Step Description Key Activities
1. Role Identification Identify roles in the organization Job descriptions, functional analysis
2. Role Analysis Analyze role requirements Access requirements, permissions
3. Role Definition Define roles and permissions Role definitions, permission assignments
4. Role Validation Validate roles with stakeholders Review, approval

2.4 The RBAC Effectiveness Score

The RBAC Effectiveness Score quantifies the effectiveness of RBAC:

text
R_ES = R_oles * P_ermissions * U_sers

Where:

  • R_oles is the Role Score (0-1)

  • P_ermissions is the Permission Score (0-1)

  • U_sers is the User Score (0-1)

 
 
Component Description Scoring Factors
Roles (R) Quality of role definitions Completeness, clarity, currency
Permissions (P) Quality of permission assignments Least privilege, separation of duties
Users (U) Quality of user-role assignments Accuracy, timeliness, reviews

2.5 RBAC Best Practices

 
 
Best Practice Description Benefit
Role Engineering Identify and define roles properly Accurate access control
Least Privilege Grant minimum necessary permissions Reduced attack surface
Separation of Duties No single role has complete control Fraud prevention
Regular Reviews Review roles and assignments regularly Maintain accuracy
Automation Automate role management Efficiency, accuracy
text
RBAC Architecture (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Users                                                               │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • John Doe (Teller)                                           │  │
|  │  • Mary Smith (Manager)                                        │  │
|  │  • Bob Johnson (Trader)                                        │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Roles                                                               │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Teller Role                                                  │  │
|  │  • Manager Role                                                │  │
|  │  • Trader Role                                                 │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Permissions                                                         │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Teller: Read Customer Data, Process Transactions           │  │
|  │  • Manager: Read Customer Data, Approve Transactions         │  │
|  │  • Trader: Execute Trades, View Market Data                   │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Formula: R_ES = R_oles * P_ermissions * U_sers                      │
└─────────────────────────────────────────────────────────────────────────┘

Part 3: Attribute-Based Access Control (ABAC)

3.1 The ABAC Definition

ABAC grants access based on attributes of the subject, object, environment, and action.

text
ABAC = {Attributes, Policies, Enforcement}

3.2 ABAC Components

 
 
Component Description Examples
Subject Attributes Attributes of the user Role, department, clearance level
Object Attributes Attributes of the resource Data classification, owner
Environment Attributes Attributes of the environment Time, location, device
Action Attributes Attributes of the action Read, Write, Execute

3.3 ABAC Policies

Policy Structure:

text
Policy = {Rule, Effect}

Policy Example:

text
If (Role = Manager AND Department = Finance AND Time = Business Hours)
Then Allow (Read, Write)
Else Deny (All)

3.4 The ABAC Effectiveness Score

The ABAC Effectiveness Score quantifies the effectiveness of ABAC:

text
A_ES = A_ttributes * P_olicies * E_nforcement

Where:

  • A_ttributes is the Attribute Score (0-1)

  • P_olicies is the Policy Score (0-1)

  • E_nforcement is the Enforcement Score (0-1)

 
 
Component Description Scoring Factors
Attributes (A) Quality of attribute definitions Coverage, accuracy, currency
Policies (P) Quality of policy definitions Completeness, clarity, correctness
Enforcement (E) Quality of policy enforcement Implementation, monitoring

3.5 ABAC Best Practices

 
 
Best Practice Description Benefit
Attribute Standardization Standardize attribute definitions Consistency
Policy Simplification Keep policies simple Manageability
Regular Reviews Review policies regularly Accuracy
Automation Automate policy enforcement Efficiency
Monitoring Monitor policy effectiveness Improvement
text
ABAC Architecture (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Subject Attributes                                                   │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Role: Manager                                               │  │
|  │  • Department: Finance                                         │  │
|  │  • Clearance: Confidential                                     │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Object Attributes                                                   │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Classification: Confidential                                │  │
|  │  • Owner: Finance Department                                   │  │
|  │  • Sensitivity: High                                           │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Environment Attributes                                              │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Time: 9:00-17:00                                           │  │
|  │  • Location: Office                                            │  │
|  │  • Device: Company-issued                                      │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Action Attributes                                                  │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Action: Read, Write                                        │  │
|  │  • Operation: View, Edit                                      │  │
|  │  • Scope: Finance Data                                        │  │
|  └────────────────────────┬────────────────────────────────────────┘  │
|                           │                                           |
|                           ▼                                           |
|  Policy Enforcement                                                  │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  If (Role = Manager AND Department = Finance AND              │  │
|  │      Time = Business Hours AND Location = Office)             │  │
|  │  Then Allow (Read, Write)                                     │  │
|  │  Else Deny (All)                                              │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Formula: A_ES = A_ttributes * P_olicies * E_nforcement               │
└─────────────────────────────────────────────────────────────────────────┘

Part 4: Access Control in Financial Institutions

4.1 Regulatory Requirements

 
 
Regulation Access Control Requirement
GLBA Safeguards Rule: Information security program
SOX Section 404: Internal controls
GDPR Article 32: Security of processing
NYDFS 500.07: Access privileges
PCI DSS Requirement 7: Restrict access to cardholder data

4.2 Access Control Best Practices

 
 
Best Practice Description Implementation
Least Privilege Grant minimum necessary permissions RBAC, ABAC
Separation of Duties No single role has complete control Role segregation
Regular Access Reviews Review and certify access Quarterly/Annually
Automated Provisioning Automate access provisioning Workflow automation
Monitoring Monitor access and detect anomalies SIEM, UEBA

4.3 The Access Control Compliance Score

The Access Control Compliance Score quantifies compliance with access control requirements:

text
A_CC = R_egulations * P_olicies * M_onitoring

Where:

  • R_egulations is the Regulation Score (0-1)

  • P_olicies is the Policy Score (0-1)

  • M_onitoring is the Monitoring Score (0-1)

 
 
Component Description Scoring Factors
Regulations (R) Coverage of regulatory requirements Breadth, completeness
Policies (P) Quality of access control policies Completeness, clarity, currency
Monitoring (M) Quality of monitoring Coverage, frequency, quality
text
Access Control in Financial Institutions (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Regulatory Requirements                                              │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • GLBA: Information security program                         │  │
|  │  • SOX: Internal controls                                      │  │
|  │  • GDPR: Security of processing                                │  │
|  │  • NYDFS: Access privileges                                    │  │
|  │  • PCI DSS: Restrict access to cardholder data                │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Access Control Best Practices                                        │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  • Least Privilege                                             │  │
|  │  • Separation of Duties                                        │  │
|  │  • Regular Access Reviews                                      │  │
|  │  • Automated Provisioning                                      │  │
|  │  • Monitoring                                                   │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Formula: A_CC = R_egulations * P_olicies * M_onitoring              │
└─────────────────────────────────────────────────────────────────────────┘

Summary and Bridge to Lesson 6.4

We have now completed the comprehensive analysis of authorization and access control models. You have learned:

  1. Access Control Models: RBAC, ABAC, DAC, and MAC.

  2. Access Control Security Score: A_CS = P_olicy * E_nforcement * A_uditing.

  3. Role-Based Access Control (RBAC): Role engineering, assignment, and management.

  4. RBAC Effectiveness Score: R_ES = R_oles * P_ermissions * U_sers.

  5. Attribute-Based Access Control (ABAC): Attributes, policies, and enforcement.

  6. ABAC Effectiveness Score: A_ES = A_ttributes * P_olicies * E_nforcement.

  7. Access Control in Financial Institutions: Regulatory requirements and best practices.

  8. Access Control Compliance Score: A_CC = R_egulations * P_olicies * M_onitoring.

In Lesson 6.4, we will explore Privileged Access Management (PAM) for financial institutions, including privileged accounts, privileged access, and privileged account security.

 
PreviousNext