Evaluating Ambiguous Security Requirements and Human Factors in Telemedicine

Assessment

• 'All patient data must be encrypted' fails on scope and measurability: which data (notes, recordings, identifiers, backups, logs, exports), in transit or at rest, which algorithms and key lengths, how keys are managed and rotated? A tester cannot decide pass or fail.
• 'The system must be secure' is a goal, not a requirement. There is no threshold, no attacker model and no acceptance criterion, so any test result can be argued either way.

Both violate basic criteria: unambiguous, measurable, traceable, feasible, and associated with a verification method.

Rewritten, using ISO/IEC 25010 security characteristics and OWASP ASVS as the reference baseline

• Confidentiality in transit: consultation notes, recordings and identifiers are protected by TLS 1.2 or higher with approved cipher suites, verified by configuration review and a protocol scan; no plaintext fallback.
• Confidentiality at rest: the same data is encrypted with AES-256, keys held in the key management service with rotation at most every 90 days, verified by configuration inspection and sampling stored objects and backups.
• Accountability and non-repudiation: every read or write of a patient record is logged with user, timestamp, patient and action, retained 12 months and tamper-evident, verified by log inspection after scripted actions.
• Access control: a clinician can access only records of patients with an active care relationship, verified by negative tests using two clinician accounts.

Each item now names the data, the mechanism, the verification method and the evidence.

The observations are evidence that controls exist but are not usable, which means the top risk is more likely than the workshop estimated - the flaw is in the design of the controls, not in user discipline.

Interpretation

• A shared login destroys accountability and non-repudiation; audit logs can no longer identify who saw a record, which undermines a GDPR-relevant control.
• A password on a whiteboard defeats authentication, and MFA on a phone the user cannot reach means the second factor is either shared or bypassed. Two factors become one shared secret.
• Thirty re-authentications per shift is a designed-in incentive to work around the control; the workaround is the predictable outcome.

Tests that follow

• Contextual observation and task timing: measure actual re-authentication count and minutes lost per shift, and confirm the sharing pattern across wards.
• Usability test of alternatives: badge tap or proximity authentication, fast user switching on a shared device, longer idle timeout combined with re-authentication on sensitive actions.
• Helpdesk impersonation test, with written authorisation, to see whether an attacker can obtain a password reset or MFA reset.
• Log review for patterns indicating shared accounts (one account active in two locations at once).

Report these as security-relevant usability defects with severity and business impact, not as user error.

The three evidence streams answer different questions and should not be averaged into a single score.

• Requirement verification shows whether specified controls are implemented.
• Penetration testing shows whether a motivated attacker can break them.
• Human-factors evidence shows whether the controls survive contact with real work.

Building the recommendation

• The shared-login and whiteboard-password findings attack the top risk directly. Technically passing encryption and access-control checks does not offset unproven accountability, because the auditor's question and the attacker's opportunity both concern who is behind the session.
• Treat elimination of shared logins as a release condition, or define a compensating control with the risk owner: per-user login with fast switching so attribution is preserved, plus monitoring for concurrent sessions. A control that exists only in the policy is not a compensating control.
• Items with genuine compensating controls can be accepted with a named owner, expiry date and a scheduled retest.

What to state plainly State residual risk rather than a verdict: technical controls verified within the stated scope, but accountability remains unproven until shared logins are removed. List what was not tested, so the decision is not over-read. A conditional go with tracked conditions is more honest and more defensible than a bare approval or a blanket block.