Operational Model of Cybersecurity

101

• A principal is an entity that has an authenticated identity
• A subject is an entity that acts on behalf of a principal, within a computer system.
• An action can read, write, create, delete objects or their metadata. For computer programs, actions can also execute.
• An object is a resource that an action is to be performed upon

What is Access Control?

• It's the process of determining and enforcing who can access what resources in a system.

  • Access Control the ability to control whether a subject (such as an individual or a process running on a computer system) can interact with an object (such as a file or hardware device)

• Importance: Protects sensitive information, prevents unauthorised access, and ensures compliance with regulations.

• But, does it confused with Authentication?

Authentication vs. Access Control: Not the Same!

Authentication deals with verifying the identity of a subject.

• Authentication: Think of it as logging into your computer with a username and password.

  • The system (authentication) checks your credentials to ensure you are who you say you are. Just like showing your ID to prove your identity.

• Access Control: Now, once you're in, what can you do?

  • AC determines what you can access on the computer or network.
    • Just because you logged in doesn't mean you can access all files and applications.

AC Principles

• Cybersecuity: CIA - Confidentiality, Integrity, Availability

The four parts of access control are:

• Identification—Who: is asking to access the asset?

• Authentication—Can: the requestor’s identity be verified?

• Authorisation—What :exactly, can the requestor access? And what can they do?

• Accountability: How can actions be traced to an individual?

  • Associating actions with users for later reporting and research is known as accountability.

AC Principles

These four parts are divided into two phases:

• The policy definition: This phase determines who has access and what systems or resources they can use. The authorisation definition process operates in this phase.

• The policy enforcement: grants or rejects requests for access based on the authorisations defined in the first phase. The identification, authentication,
  authorisation execution, and accountability processes operate in this phase.

Example: Linux Permissions

Access Control Models

1. Discretionary Access Control (DAC)

2. Mandatory Access Control (MAC)

3. Rule-Based Access Control (RuBAC)

4. Role-Based Access Control (RBAC)

5. Access Control Lists(ACL)

1. Discretionary Access Control (DAC)

• Access rights are determined by the resource owner.
  • Per user, not per file.
• Mechanism: Owners grant or deny access to users based on their discretion.
  • Sys Admin is the boss (or owner of the file)
• Characteristics:
  • Flexibility: Owners have control over their resources.
  • Vulnerability: Prone to accidental or malicious misuse.
  • Users can set read, write, and execute permissions for files they own.

DAC: E.g.

1. OS: Permission settings in Unix/Linux.

2. App:

   • Application-based DAC denies access based on context or content.
   • ATM's available options to a user.

DAC: Cont'

Scenario: Ameer owns a file and grants read access to Bob but denies access to Tim.

2. Mandatory Access Control (MAC)

Access rights are regulated by a central authority based on multiple levels of security.

• Mechanism: Users and resources are assigned security labels. Access is granted based on these labels and policies.

• SysAdmin is no longer the boss:

• Characteristics: High security: Strict and non-discretionary control.

• Complexity: Requires careful planning and management.

• Occasionally synonymous with MLS - Multi-Level Security (Unclassified, Confidential, Secret, Top Secret)

MAC Cont'

• Scenario: Bob has a "Secret" clearance and can access "Secret" documents, but not "Top Secret" ones.

• Example: Military systems with classified information, e.g. Bell LaPadula

  • Users need the appropriate clearance level to access certain documents.
  • System and owner collaboration determines access.
  • Bell-LaPadula model compares subject and object labels to grant/deny access

3. Rule-Based Access Control (RuBAC)

• Access is based on a set of pre-defined rules or policies, rather than roles or individual user attributes.

• Provides fine-grained access control by enforcing rules that specify conditions under which access is granted or denied.

• Data owners make or allow the rule.

RuBAC:Key Features

• Rules and Policies: Access decisions are made based on a comprehensive set of rules.
• Conditions: Rules can include conditions such as time of day, IP address, and user attributes (PAM in Linux).
• Automation: Automatically enforces policies without manual intervention.

PAM: Pluggable Authentication Modules

• It allows system administrators to define and manage how different applications or services authenticate users without needing to modify the applications themselves.
• By using different methods (like passwords, fingerprints, or two-factor authentication)

4. Role-Based Access Control (RBAC)

• It bases access control approvals on the jobs the user is assigned
• Simplifies administration and enhances security by grouping permissions by role rather than assigning them individually.

RBAC: Example

• Role Engineering: Before you can assign access rules to a role, you must define and describe the roles in your organisation.
• Risks: Overgeneralising.
  • Which leads to "a need-to-know violation"

5. Access Control Lists(ACL)

• A set of rules that defines what actions (e.g., read, write, execute) specific users or groups can perform on system objects (like files or network devices).

• Used in operating systems (like Linux) and network devices (such as routers and firewalls) to enforce access permissions.

Key Features of ACLs:

1. Granular Control: Allows specific access permissions for individual users or groups.
2. Flexibility: Multiple rules can be applied to the same resource, allowing for fine-tuned access management.
3. Application: Common in both file system permissions (e.g., Unix/Linux) and network security.

• E.g.:

  • setfacl -m u:username:rwx /path/to/file

    • This command grants a user read, write, and execute permissions on a file

  • permit tcp any any eq 80 : Allows HTTP traffic on port 80

Others: Content-Dependent Access Control

Effects of Breaches in Access Control

Failure to implement robust access control

• Disclosure of sensitive information and data integrity corruption
• Loss of intelligence and system and process failure
• Short-term and long-term attacks
  

Threats to Access Controls

• Challenges: threats evolve all the time
  • The list can never be complete.

Centralised and Decentralised Access Control

1. Centralised Access Control: CAC
Access control decisions and enforcement are managed from a single, central point or authority;

• Single Point of Control
• Consistency: uniformly applied across all users and systems
• Ease of Management: easily update or change policies
• Scalability: Suitable for large organisations

Pros & Cons

CAC and AAA

• CAC is applied and enforced through the use of AAA servers
  • Less Administration Time: maintained on a single host.
  • Reduced Design Errors: Consistent formats
  • Simplified Training: Only one system needs to be learned by admin.
  • Improved Compliance Auditing: access requests are handled by one system.
  • Fewer Help-Desk Calls: A consistent user interface reduces confusion.
    

Types of AAA Servers:

A. Remote Authentication Dial-In User Service (RADIUS): networking protocol that provides centralised AAA management (passwords, tokens, certificates)

• Client Configuration File: Contains client address and shared secret for transaction authentication.
• User Configuration File: Contains user identification, authentication data, and connection/authorisation information.
  

Others

• TACACS+

• DIAMETER

• SAML

• Please do some research about'em.

Centralised and Decentralised Access Control

2. Decentralised Access Control DeAC

• is to handle access control decisions and administration locally.
• access control is in the hands of the people (e.g.managers who are closest to the system users)
• Eliminates the single-point-of failure problem.
• BUT, Loss of standardisation and to overlapping rights.

Decentralised Access Control DeAC: common examples

1. Password Authentication Protocol (PAP): Uses cleartext usernames and passwords.
2. Challenge-Handshake Authentication Protocol (CHAP): Hashes passwords with a one-time challenge to prevent replay attacks.
3. OATH (Open Authentication): Over 30 organisations contribute to developing authentication standards:
   • HMAC-based One-Time Password (HOTP): Uses an authentication server for generating one-time passwords.
   • Time-based One-Time Password (TOTP): Combines a time stamp with a hashed value to enhance security.

• HMAC: Hash-based Message Authentication Code

Thoughts:

• Policies alone do not suffice. Employers must clearly communicate what employees can and cannot do.

• The best way to do this is through training. When systems or policies change, those changes should be communicated to employees.

PAM: Pluggable Authentication Modules

• It is a flexible system used to manage authentication for applications and services.

• Provides a way to centralise and standardisa authentication methods, allowing the system to enforce authentication policies across different services.

• Why PAM Matters

  • Modular Design: Different authentication modules (e.g., password, token, biometrics) can be easily added or removed.
  • Service-Specific Control: PAM configurations allow different services (e.g., SSH, sudo) to have their own tailored authentication rules.
  • Security: Enforces consistent security policies and simplifies multi-factor authentication setup (MFA).

How PAM Works:

• PAM Modules: Each module performs a specific task (e.g., authentication, account management).
• Control Flags: Determines how PAM processes multiple modules. Flags include:
  • required: The module must pass for authentication to succeed.
  • requisite: Failure causes immediate termination.
  • sufficient: Success allows skipping further checks.
  • optional: Success or failure has no direct impact.

Example PAM Configuration:

• Located in /etc/pam.d/
• Each service has a configuration file (e.g., login, sshd).

auth required pam_unix.so
auth sufficient pam_google_authenticator.so

Further reading about PAM:

• IBM-PAM
• RedHat-PAM

Lab

• Access Control and PAM Lab:

• Extra:TryHackMe Lab for Brokern Access Control