Information Security (IT-801) - Unit 3 Short Notes

UNIT 3: Access Control Models & Mechanisms

3.1 Discretionary Access Control (DAC)

• Definition: Access decisions based on identity and discretion of the resource owner. Users can grant permissions to others.

• Implementation Mechanisms:

  • Access Control Lists (ACLs): Metadata attached to objects listing subjects and their permissions (e.g., read/write/execute).

  • Capabilities: Tokents held by subjects that grant access to specific objects.

• Examples: Unix file permissions (owner/group/others), Windows NTFS ACLs.

• Limitations:

  • Trojan Horse Problem: A program with user privileges can misuse granted access.

  • Lack of centralized control; permissions can proliferate.

  • Difficult to enforce organization-wide policies.

[!TIP] Exam Focus: DAC is owner-centric. Contrast with MAC's system-centric enforcement. Common question: "Compare DAC and MAC."

3.2 Mandatory Access Control (MAC)

• Definition: System-enforced access based on security labels and policy rules. Users cannot override decisions.

• Key Components:

  • Security Levels: Hierarchical classifications (e.g., Top Secret, Secret, Confidential, Unclassified).

  • Categories: Non-hierarchical compartments (e.g., {NATO, Nuclear, Finance}).

  • Clearance: Subject's authorization level (level + categories).

  • Classification: Object's sensitivity label (level + categories).

• Bell-LaPadula Model (Confidentiality-focused):

  • Simple Security Property: No read up – subject can read object only if subject's clearance ≥ object's classification.

  • *-Property (Star Property): No write down – subject can write to object only if object's classification ≥ subject's clearance.

• Examples: Military/government systems (DoD Orange Book), SELinux/AppArmor in enforcing mode.

• Limitations: Inflexible for commercial use; administrative overhead; does not address integrity.

[!TIP] Exam Focus: MAC prevents information flow from high to low (confidentiality). Bell-LaPadula is mandatory for state transitions.

3.3 Role-Based Access Control (RBAC)

• Core Concepts:

  • Roles: Job functions (e.g., Manager, Auditor).

  • Permissions: Assigned to roles, not individuals.

  • Users: Assigned to roles (many-to-many).

  • Sessions: User activates a subset of assigned roles.

• Role Hierarchy: Senior roles inherit permissions from junior roles (e.g., Senior Manager inherits Manager permissions).

• Separation of Duties (SoD):

  • Static SoD: Conflicting roles cannot be assigned to same user (e.g., same person cannot create vendor and approve payment).

  • Dynamic SoD: Conflicting roles cannot be activated in same session.

• Advantages in Large Organizations:

  • Scalable management (assign roles, not per-user permissions).

  • Enforces principle of least privilege.

  • Supports compliance (e.g., SOX, HIPAA) via SoD.

• Examples: ERP systems (SAP, Oracle), enterprise applications.

[!TIP] Exam Focus: RBAC is policy-neutral and scales via roles. SoD prevents fraud. Contrast with DAC/MAC.

3.4 Task-Based Access Control (TBAC)

• Definition: Permissions are dynamically assigned based on tasks/activities within a workflow. Access is temporary and task-specific.

• How It Works:

  • Tasks are defined with required permissions.

  • When a user starts a task, permissions are granted.

  • Permissions automatically revoked upon task completion/termination.

• Suitable Scenarios:

  • Workflow systems (e.g., loan approval, order processing).

  • Collaborative environments (e.g., project teams, healthcare).

  • Situations requiring temporary access with strict audit trails.

• Examples: Hospital information systems (doctor accesses patient record only during consultation), project management tools.

[!TIP] Exam Focus: TBAC is dynamic and context-aware. Ideal for temporary, task-oriented access vs. static roles in RBAC.

3.5 Other Control Mechanisms

• Password Management:

  • Policies: Complexity (length, character types), expiration, history, lockout thresholds.

  • Storage: Never plaintext. Use salted cryptographic hashes (e.g., bcrypt, PBKDF2).

  • Cracking Countermeasures:

    • Rate limiting & account lockout.

    • Multi-Factor Authentication (MFA).

    • Passwordless authentication (FIDO2/WebAuthn).

    • User education (avoid reuse, phishing).

• Rule-Based Access Control:

  • Access decisions based on system rules (e.g., time of day, IP address, location).

  • Often implemented in firewalls and network devices.

  • Example: "Allow access only from corporate IP range 10.0.0.0/8 during business hours."

[!TIP] Exam Focus: Password hashing must use salt to prevent rainbow table attacks. Rule-based is environmental, not identity-based.

Comparison: DAC vs. MAC vs. RBAC vs. TBAC

[!TIP] Common Pitfall: MAC ≠ "more secure" than DAC; MAC enforces confidentiality via labels, DAC enables sharing. RBAC is not a replacement but complements for scalability.

Diagram: RBAC Core Model

[[DIAGRAM: CANVAS: A central diagram showing:

• Left: Users (U1, U2) connected to Roles (R1, R2, R3) via "assignment" arrows.

• Roles connected to Permissions (P1, P2, P3, P4) via "authorization" arrows.

• Role Hierarchy: R3 (Senior) inherits from R2 (Junior), which inherits from R1 (Basic).

• Bottom: Session box showing User U1 activating roles R1 and R3 (subset).

• Caption: "RBAC: Users → Roles → Permissions; Sessions activate subset of roles; Role hierarchy enables inheritance."]]

Key Formulas & Definitions

• Bell-LaPadula Constraints:

  • Read: $\text{clearance}(S) \geq \text{classification}(O)$

  • Write: $\text{classification}(O) \geq \text{clearance}(S)$

• Separation of Duties: $\nexists$ user $u$ such that $u$ assigned to conflicting roles $$\displaystyle r_i, r_j $$.

• Password Security: Stored password = $\text{Hash}(password + \text{salt})$. Salt is random per-user.

\boxed{\text{RBAC scales via roles; MAC enforces labels; DAC is owner-driven; TBAC is task-temporal.}}