Is a Secure Online Exam Really Secure?

#cybersecurity

Thinking Beyond Technology: Security, Trust, and Risk in Digital Examinations

When university leadership rolled out our digital examination platform, the administration assumed the system was secure because it checked off three tools: a Secure Exam Browser (SEB), webcam proctoring, and student accounts. But buying software is not the same as managing risk. A system is only secure when its design protects specific operational objectives against real attackers. By treating security as a procurement checklist rather than an architecture, the university left fundamental weaknesses unaddressed.

Security Beyond Tooling

A secure system maintains acceptable risk across five core objectives: confidentiality, integrity, availability, authenticity, and accountability (CIAAA). Tools like SEB only constrain the student's local desktop. They do not secure backend databases, administrative APIs, or human interactions.

The pilot incidents demonstrated breakdowns across all five objectives:

Incident A (Question Leakage) violated confidentiality. Leaking exam questions to a messaging group exposed test content before the exam started. SEB restricts local browsing, but it cannot prevent an insider copying files from the central database or photographing a screen with a phone.
Incident B (Unauthorised Grade Changes) violated integrity and accountability. Altering a recorded grade corrupted data accuracy (integrity). Because the system logged the change without recording user identity or session context, the university could not determine who made the modification (accountability).
Incident C (Examination Disruption) violated availability. A 30-minute outage prevented hundreds of students from submitting their work. Security requires reliable, timely access to services; an unavailable system fails its operational purpose.
Incident D (Identity and Trust) violated authenticity. Valid login credentials proved an account exists, but could not confirm that the person typing was the registered student. Authenticity requires ongoing proof of human identity, not just a one-time credential check.

Evaluating an exam platform requires measuring whether these five objectives hold up under real operating conditions, not counting installed security features.

Threat Analysis: Incidents B and D

Analyzing Incidents B and D requires separating assets, vulnerabilities, threats, attacks, and risks.

Incident B: Unauthorised Grade Changes

Asset: The grade database and student academic records.
Vulnerability: An administrative dashboard endpoint lacking strict access controls, parameter validation, and audit logs.
Threat: A student seeking higher marks, an attacker with stolen credentials, or a corrupt insider.
Attack: The adversary discovers an exposed API endpoint on the web dashboard (software attack surface), issues a forged request, and alters the grade record without generating an attribution log.
Risk: Unearned grades enter transcripts, destroying academic trust, threatening accreditation, and exposing the university to legal liability.

Incident D: Identity and Trust Breakdown

Asset: Academic credential legitimacy and degree validity.
Vulnerability: Dependence on static, single-factor credentials without continuous identity binding.
Threat: A student hiring a proxy test-taker through contract-cheating services.
Attack: The student shares credentials with a proxy who logs in directly or uses external hardware to evade webcam monitoring (human and hardware attack surface).
Risk: Students graduate without demonstrating required competence, devaluing the university’s degrees.

Three Prioritised Security Controls

To correct these failures, the university must implement Defense in Depth and Zero Trust principles ("never trust, always verify"). Three controls should take priority:

Role-Based Access Control with Immutable Audit Trails (Preventive and Detective)

Enforce the Principle of Least Privilege by restricting database write permissions to verified registrar roles. Require dual authorization (separation of duties) for post-exam grade modifications, requiring two authorized staff members to sign off. Forward all database queries to an append-only, write-once, read-many (WORM) logging pipeline.
- Risk reduced: Prevents untraceable grade tampering and establishes accountability (Incident B).
- Trade-offs: Adds administrative approval delays during grade submission periods and increases log storage costs.
Phishing-Resistant MFA and Continuous Identity Verification (Preventive and Detective)

Deploy FIDO2/WebAuthn multi-factor authentication for exam logins. Supplement this with periodic, randomized webcam checks and typing pattern analysis during the session to confirm the active test-taker matches the registered student.
- Risk reduced: Stops credential sharing and proxy test-taking (Incident D).
- Trade-offs: Raises student privacy concerns regarding biometric capture, requires fallback procedures for students with faulty webcams, and creates support overhead for lost tokens.
High-Availability Infrastructure with Encrypted Local Caching (Preventive and Recovery)

Distribute the exam backend across auto-scaling application tiers with redundant database read-replicas. Pair this with client-side encrypted local storage within the exam interface, saving answers locally in real time and syncing them automatically when connectivity recovers.
- Risk reduced: Prevents submission loss and service downtime during peak exam traffic (Incident C).
- Trade-offs: Increases cloud hosting costs and local cryptographic key-handling complexity.

The Bottom Line

Locking down the student's browser while leaving backend APIs, database auditing, and identity verification unchecked creates an illusion of security. Real exam integrity requires layered controls: verifying identity continuously, logging every grade change immutably, and designing infrastructure that survives peak loads.

DEV Community