Day 54 – Attacks and Access Control: From “Who Are You?” to “Can This Action Be Performed?”

Authentication

Subjects include patients, doctors, pharmacists, administrators, partner institutions, servers, devices and micro‑services. Each requires a distinct identity; micro‑services must present certificates or tokens.

Three factor categories

Knowledge – e.g., password, PIN.

Possession – e.g., hardware token, smart card, mobile phone.

Biometrics – e.g., fingerprint, facial scan.

Multi‑factor authentication (MFA) requires at least two different categories. A password + SMS code (knowledge + possession) satisfies MFA; password + security question does not because both are knowledge factors.

Why passwords are not re‑entered on every request

After a successful login the system issues a session identifier, access token, ticket or short‑lived certificate. Subsequent requests present these credentials, which are validated for issuer trust, expiry, revocation, audience and required permissions. Zero‑trust therefore means “verify identity on every access”, not “prompt for a password on every click”.

SSO vs. MFA

Single Sign‑On (SSO) lets a user authenticate once and reuse the result across trusted systems. MFA strengthens the confidence of that single authentication. They can be combined – e.g., a doctor completes MFA, then uses SSO to reach prescription, imaging and outpatient services.

Common authentication attacks

Brute‑force – mitigated with rate‑limiting, delays, risk detection, MFA and weak‑password policies.

Credential stuffing – mitigated by blocking password reuse, enforcing MFA and detecting anomalous logins.

Phishing – mitigated with user education, trusted domains, anti‑phishing authentication and risk detection.

Replay – mitigated with one‑time nonces, timestamps, sequence numbers, short‑lived tokens and server‑side replay caches.

A nonce is a random challenge that must be unique; the server rejects a request if the same nonce reappears or if it falls outside its validity window.

Authorization

Four basic elements

Subject  – who initiates the request (e.g., doctor, service process)</code><code>Object   – what is accessed (e.g., prescription, medical record, API endpoint)</code><code>Action   – what is done (read, create, modify, delete, approve)</code><code>Policy   – under what conditions the request is allowed

Example rule: a doctor with the “prescription‑doctor” role may create a prescription only for patients with an active treatment relationship and only during the doctor’s shift; the doctor cannot approve his own prescription.

Access‑Control Lists (ACL)

ACLs are attached to the resource side and enumerate which subjects may perform which actions.

Prescription file ACL:</code><code>Doctor A → read, modify</code><code>Pharmacist B → read, approve</code><code>Auditor C → read‑only</code><code>All others → deny

Discretionary Access Control (DAC)

Owners decide who may access their objects and can delegate permissions. Example: a file owner grants “read” to a colleague and can later revoke it. DAC offers high flexibility but delegated permissions can proliferate and become hard to control.

Mandatory Access Control (MAC)

Subjects and objects receive security labels; a central policy enforces access regardless of owner wishes. Example: a user with “Secret” clearance cannot read a “Top‑Secret” file, and a “Top‑Secret” file cannot be written to an “Unclassified” location (No‑Read‑Up / No‑Write‑Down).

Role‑Based Access Control (RBAC)

Roles bridge users to permissions. In the internet‑hospital scenario:

Prescription doctor – create prescriptions, view own patients’ prescriptions.

Review pharmacist – view pending prescriptions, approve or reject.

Auditor – query operation logs, no write access.

Ops admin – manage servers, no direct view of full medical records.

RBAC simplifies permission management, supports least‑privilege and separation‑of‑duties, but does not enforce fine‑grained data‑range limits; attribute‑based checks (ABAC) are added.

Extended models

Task‑Based Access Control (TBAC) – permissions change with workflow state (e.g., a prescription becomes “awaiting review” and the pharmacist gains temporary review rights).

Object‑Based Access Control (OBAC) – ACLs, attributes and inheritance are defined around the protected object (e.g., a folder’s sub‑files inherit its ACL).

Attribute‑Based Access Control (ABAC) – decisions are made dynamically from subject, object, action and environmental attributes (e.g., a doctor may read a patient record only if the doctor‑patient relationship is active, the request occurs within shift hours, and the risk level is low).

Security‑model families

Bell‑LaPadula (BLP) – protects confidentiality; rules: No‑Read‑Up, No‑Write‑Down.

Biba – protects integrity; rules: No‑Read‑Down, No‑Write‑Up.

Clark‑Wilson – enforces controlled programs, separation of duties and audit for business‑critical transactions (e.g., prescription creation → pharmacist review → system‑controlled state change).

Chinese Wall – prevents conflict‑of‑interest by tracking prior accesses and blocking access to competing clients.

Common attacks and mitigations

SQL Injection

Vulnerability: concatenating user input into SQL statements.

SELECT * FROM prescription WHERE id = 'user_input';</code><code>Attacker input: ' OR 1='1

Result: the query logic is altered. Primary defense: use parameterised queries or prepared statements. Depth‑defense: input validation, least‑privilege DB accounts, hide DB errors, log anomalous queries, optional WAF assistance.

Cross‑Site Scripting (XSS)

Untrusted data is rendered as executable script in the victim’s browser.

Output‑encode HTML, attributes, URLs appropriately.</code><code>Apply a reliable HTML sanitizer for rich‑text fields.</code><code>Deploy Content‑Security‑Policy (CSP) to restrict script sources.</code><code>Set HttpOnly on cookies (mitigates cookie theft, not XSS itself).

Cross‑Site Request Forgery (CSRF)

Attacker forces the victim’s browser to send an authenticated request.

Use CSRF tokens.</code><code>Set SameSite attribute on cookies.</code><code>Validate Origin/Referer headers.</code><code>Require re‑authentication for high‑risk actions.</code><code>Avoid state‑changing GET requests.

Denial‑of‑Service (DDoS)

Massive traffic exhausts bandwidth, connections, CPU, memory, DB pools, etc.

Upstream traffic scrubbing.</code><code>CDN or distributed entry points for cacheable content.</code><code>Gateway rate‑limiting, connection caps, timeouts.</code><code>Queueing, isolation and graceful degradation for core services.</code><code>Elastic scaling for legitimate spikes.</code><code>Monitoring, alerting and fail‑over.

Scaling alone does not solve DDoS; upstream filtering and business‑logic protection remain necessary.

Network‑level attacks

ARP spoofing – mitigate with dynamic ARP inspection, IP‑MAC binding, switch security, network segmentation.

DNS spoofing – use trusted resolution chains, DNSSEC, secure resolvers, TLS certificate validation.

Port scanning – close unused services, firewall rules, scan detection, timely patching.

Man‑in‑the‑Middle & Replay

Use TLS or mTLS with proper certificate validation.</code><code>Protect private keys and trust roots.</code><code>Employ nonces, timestamps, monotonic sequence numbers, one‑time tokens.</code><code>Sign or MAC the message together with anti‑replay fields.</code><code>Server‑side replay‑cache to reject duplicates.

Security Auditing

A qualified audit record must answer:

Who – user, service account, role, session or token.</code><code>When – trusted timestamp.</code><code>From where – IP, device, client, service instance.</code><code>What – patient, prescription, API, file.</code><code>Action – read, create, modify, approve, export, delete.</code><code>Result – allow, deny, failure, error code.</code><code>Why – matched role, policy, approval.</code><code>How linked – request ID, trace ID, business transaction ID.

Audit logs must be centrally collected, append‑only, tamper‑evident, time‑synchronised, retained per policy and protected from modification. They should exclude raw passwords, full tokens or unnecessary sensitive payloads. Logging alone does not replace pre‑emptive authorization; without proper access checks, damage can occur before a log entry is written.

Integrated solution for the internet hospital

Establish a unified identity provider; assign distinct identities to patients, doctors, pharmacists, auditors, ops admins and partner pharmacies; enforce MFA for high‑risk subjects.

Issue short‑lived session or access tokens after authentication; validate issuer, audience, expiry and revocation on each request.

Implement RBAC for role‑level permissions; augment with ABAC rules that check patient ownership, active treatment relationship, shift timing and creator‑exclusion for pharmacists.

Apply parameterised queries for all database access; enforce least‑privilege DB accounts; add input validation and WAF as depth‑defence.

Encode all user‑generated output, sanitise rich‑text, enable CSP and HttpOnly cookies; protect against XSS and CSRF as described.

Deploy upstream DDoS mitigation, CDN caching, gateway rate‑limiting and graceful degradation for critical workflows (appointment booking, prescription issuance, emergency services).

Collect comprehensive audit logs as per the checklist; store them centrally with append‑only storage, integrity checks and alerting on anomalous patterns.