Chapter 2: Access Control Models and CVSS Vulnerability Scoring

Discretionary Access Control (DAC)

Under DAC, the owner of a resource decides who else can access it. Linux file permissions (chmod 640) and Windows ACLs are classic implementations. The owner exercises personal discretion — grant, revoke, and delegate access at will.

Strength: Flexible and familiar. Weakness: Security depends entirely on the owner's judgment; a single mistake by an untrained user can expose sensitive data to the entire organisation.

Mandatory Access Control (MAC)

MAC removes access decisions from individual users. A central authority assigns security labels to both subjects (users, processes) and objects (files, ports). No user — not even the owner — can override labels. The Bell-LaPadula model governs classified systems with two core rules:

• No read up (Simple Security Property): A Secret-cleared user cannot read a Top Secret document.
• No write down (Star Property): A Top Secret-cleared user cannot write to a Secret document — preventing information leakage from high to low sensitivity.

Modern implementations include SELinux and AppArmor, which enforce type-enforcement labels on every process and file.

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, then assigns users to roles. A hospital defines physician, nurse, billing_clerk, and system_admin roles. A new hire inherits correct permissions by role assignment alone — no individual ACL management required.

RBAC naturally enforces least privilege: an accountant cannot restart database servers because no accounting role carries that permission. Auditing is simplified — inspect role definitions rather than thousands of individual ACLs.

Attribute-Based Access Control (ABAC)

ABAC evaluates access requests against rich attributes from the subject, object, action, and environment. A Policy Decision Point (PDP) evaluates policies in real time — enabling rules like "a physician may view a patient record from an internal workstation during business hours, but only for patients on their ward." No static role matrix can capture this context-sensitivity.

Enterprises commonly layer RBAC + ABAC: RBAC for stable job-function policies, ABAC for dynamic conditions like location, device health, and time-of-day.

Authentication, Authorization, and Accounting (AAA)

AAA is the three-part framework governing identity-based access in network infrastructure. Think of it as a nightclub:

• Authentication ("Who are you?"): The bouncer checks your ID — credentials, certificates, tokens, or biometrics.
• Authorization ("What are you allowed to do?"): The hostess checks your VIP wristband and directs you to the correct section.
• Accounting ("What did you do?"): The cash register logs every action — session times, bytes transferred, commands executed.

Accounting is critical for compliance and forensics. When an auditor asks "who changed the BGP route table at 03:14 on Tuesday?", accounting logs provide the answer.

Rule-Based and Time-Based Access Control

Rule-based access control conditions access on explicitly defined rules regardless of user identity. Cisco ACLs are the canonical example — permit tcp 10.0.0.0 0.0.0.255 any eq 443 applies independent of who sent the packet.

Time-based access control restricts access to defined time windows, reducing attack surface during off-hours:

time-range CONTRACTORS
 periodic weekdays 08:00 to 17:00
!
ip access-list extended CONTRACTOR-VPN
 permit ip any any time-range CONTRACTORS

RADIUS vs. TACACS+

Modern deployments integrate RADIUS and TACACS+ with centralised Identity Providers (IdPs) such as Microsoft Entra ID or Okta. IdPs centralise identity, enforce MFA, and federate via SAML 2.0 or OIDC, giving device-level TACACS+ granularity plus enterprise-wide identity governance.

aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+

CVSS v3.1 Overview

The Common Vulnerability Scoring System (CVSS) is an open framework published by FIRST for communicating vulnerability characteristics and severity. Version 3.1 produces a numeric score from 0 to 10. A critical distinction: CVSS measures severity, not risk. It evaluates intrinsic, worst-case technical impact independent of exploit likelihood or asset value.

Scores are organized into three metric groups applied in sequence:

Base Score → Temporal Score → Environmental Score

Base Metrics

Exploitability metrics measure how easily an attacker can reach and exploit the vulnerability:

Impact metrics measure consequences on the CIA triad. Scope (S) is uniquely important: if exploitation affects components beyond the vulnerable component (Scope: Changed), a higher multiplier (7.52 vs 6.42) substantially inflates the score. Log4Shell's Scope: Changed is what pushed it to 10.0.

Temporal Metrics

Temporal metrics capture factors that change over time — primarily exploit availability and patch status:

Environmental Metrics

Environmental metrics allow an organisation to contextualise the score for their specific deployment:

• Modified Base Metrics: Override individual base metrics to reflect actual deployment. If a Network-exploitable vulnerability is only reachable from an internal VLAN, set Modified AV = Adjacent.
• Security Requirements (CR/IR/AR): Assign High/Medium/Low importance to CIA triad components for the affected asset. A payment server carries CR:High; a dev sandbox might carry all three as Low.

A Base Score of 9.1 on an internal staging server with no production data might drop to ~5.2 after Environmental adjustments — still worth patching, but no longer a P1 emergency.

Definitions and Relationships

Analogy: A cracked lock (vulnerability) on your back door. A burglar (threat) in the neighbourhood. A crowbar technique (exploit). The probability × value inside (risk). Fix the lock (remediation), install an alarm (compensating control), or accept if nothing valuable is stored.

Risk Scoring and Reduction Strategies

The quantitative risk formula: Risk = Threat Likelihood × Vulnerability Severity × Asset Value

Threat Actors

Vulnerability Management Lifecycle

1. Asset Discovery: Inventory all systems (network scanning, CMDB, cloud asset APIs)
2. Vulnerability Scanning: Authenticated scans (Nessus, Qualys, OpenVAS) identify CVEs present in the environment
3. Prioritization: Apply CVSS Environmental scores, asset criticality, and threat intelligence to rank findings
4. Remediation: Patch, reconfigure, or mitigate high-priority findings; track SLAs (Critical: 24h, High: 7d, Medium: 30d)
5. Verification: Re-scan to confirm remediation; run penetration tests for critical findings
6. Reporting: Communicate risk posture to leadership; feed metrics into GRC platforms

Defense-in-Depth Strategy

Defense-in-depth (DiD) layers security controls so no single failure compromises the entire system — analogous to a medieval castle's concentric walls, moat, keep, and vault.

Detection Paradigms

5-Tuple Analysis and Data Loss Detection

The 5-tuple — Source IP, Destination IP, Source Port, Destination Port, Protocol — is the fundamental unit of network flow identification. Stateful firewalls use the 5-tuple to track connection state; security analysts use it for exfiltration detection:

• Volume anomalies: A workstation sending 500 MB outbound to an external IP over TCP/443 is suspicious even without payload inspection.
• Destination anomalies: Cross-reference the destination IP against threat intelligence — known C2 IPs, Tor exit nodes, bullet-proof hosting.
• Protocol anomalies: DNS queries over UDP/53 with unusually large responses (>512 bytes) may indicate DNS tunneling.
• Host isolation: Search all logs for a compromised host's IP as source or destination to reconstruct lateral movement paths.

Alert trigger: Outbound flow volume > 1 GB to single external IP
5-tuple:        (10.10.5.42, 185.220.101.5, 49152, 443, TCP)
Duration:       47 minutes
Bytes sent:     1.4 GB
Bytes received: 0.8 MB

Analysis:
- Source: Marketing workstation (low classification)
- Destination: 185.220.101.5 → Tor exit node (threat intel)
- Ratio: 1400:0.8 MB (upload-heavy = exfiltration profile)
- Preceded by large SMB access to \\fileserver\HR

Action: Isolate 10.10.5.42, block 185.220.101.5/32 at
        perimeter firewall, preserve PCAP, escalate to CSIRT.