Theory: How to Approach These
This case uses every part of Week 8. Read the scenario and all seven Evidence Cards before answering. Some cards point one way and some point another: use evidence, not guesses, and name the cards in every answer (“Card 3”).
- Q1 The threat (see 8.2): decide intentional vs. accidental from the evidence; classify the source with NIST SP 800-30 (adversarial, accidental, structural, environmental) and ISO/IEC 27005 (D, A, E; technical failure as a threat type); check STRIDE; then test the alternative explanation against the other cards.
- Q2 The principle (see 8.3): walk the medication process Create Order (TP1) → Verify Order (TP2) → Record Given (TP3) and check each Clark-Wilson rule: well-formed transactions, separation of duties, access triple, audit (and IVP).
- Q3 Failed controls (see 8.4): for each card, ask what should have stopped, found or fixed this? Label P / D / C.
- Q4 Fix it (see 8.4, 8.5): one control of each type, how it would have changed this incident, and its Annex A number (5.3, 8.13, 8.15, 8.32).
- Q5 The law (see 8.5): Computer Crime Act s.9 (and s.7) if intentional; Electronic Transactions Act s.10–11 for whether the log is reliable evidence of who.
The Case
What happened. At 07:30 this morning, a patient in Ward 5, bed 3, received 40 units of insulin. This was the dose written in the EHR. The doctor, Dr. Pim, says she ordered 4 units. A nurse noticed the patient’s symptoms in time, and the patient is now safe. MediCare Plus has asked you, the hospital’s integrity investigator, to find out how the number changed, which controls failed, and what the hospital should do next.
| Card | Title | Evidence |
|---|
| 1 | EHR Audit Log | Order M-4471 (Ward 5, bed 3) was created at 18:05 yesterday by Dr. Pim: insulin 4 units. At 02:14, the order was edited by account nurse.somsri on shared workstation WARD5-PC02: dose changed from 4 to 40. The “reason for change” field is blank. |
| 2 | Statement from Nurse Somsri | “From 02:05 to 02:30, I was handling an emergency in room 512.” Her handheld device shows she recorded vital signs in room 512 at 02:12. “PC02 is a shared computer. Nobody logs out at night. We are too busy.” |
| 3 | Statement from Nurse Dao | “Around 02:10, I used PC02. The on-call doctor gave me a phone order: insulin 40 units for the patient in bed 7. I entered it.” “I did not check whose account was open. I just used the screen.” The audit log shows the bed 7 order was edited at 02:16 by the same account, nurse.somsri. On PC02, the ward list shows all patients on insulin together; bed 3 and bed 7 are next to each other on this list. |
| 4 | IT Change Record | Last Tuesday, EHR version 4.2 was deployed to all wards. By mistake, it removed the dose range check from the “edit order” screen (the check still works on the “new order” screen). There is no RFC and no CAB approval on file. The test report covers only the “new order” screen. |
| 5 | Pharmacy Night Shift | Only one pharmacist is on duty from 00:00 to 08:00. On the night shift, the pharmacist often skips re-checking orders that nurses have edited. Edited order M-4471 was not re-checked; it went straight to the ward. |
| 6 | Ward Clerk Anan | Last week Anan received a written warning after an argument with Dr. Pim. His badge shows he entered Ward 5 at 01:50 and left at 02:05. His account can view patient lists but cannot edit medication orders. The CCTV camera near PC02 was not working that night. |
| 7 | Reconciliation and Backup | The pharmacy’s nightly check (drugs given vs. orders) runs at 06:00; the insulin was given at 07:30, after the check. The EHR backup taken at 23:00 last night still shows the original order: insulin 4 units. |
Timeline
| Time | Event | Card |
|---|
| 18:05 | Dr. Pim creates M-4471, bed 3, 4 units | 1 |
| 23:00 | Backup: M-4471 = 4 units | 7 |
| 01:50 – 02:05 | Anan in Ward 5 | 6 |
| 02:05 – 02:30 | Somsri in room 512 (vitals recorded 02:12) | 2 |
| around 02:10 | Dao uses PC02 to enter phone order for bed 7 | 3 |
| 02:14 | M-4471 (bed 3) edited 4 → 40, account nurse.somsri, PC02, no reason | 1 |
| 02:16 | Bed 7 order edited, account nurse.somsri | 3 |
| 06:00 | Nightly reconciliation runs | 7 |
| 07:30 | Bed 3 patient given 40 units | Scenario |
Case Questions & Model Answers
Exercise Q1
The Threat (Parts 1–2). Was the change intentional or accidental? Give your conclusion and the evidence that supports it. Classify the threat source using NIST SP 800-30 and ISO/IEC 27005. Which STRIDE threat(s), if any, apply? Explain why. Is there any evidence that could point to a different conclusion? How does other evidence rule it in or out?
Show solution ↓Hide solution ↑
Solution
Conclusion: accidental. Nurse Dao entered the bed 7 phone order on the wrong patient (bed 3), under nurse.somsri’s still-open session on the shared PC.
Supporting evidence
- Card 1: the change was made at 02:14 on PC02 under nurse.somsri, from 4 to 40.
- Card 2: Somsri was in room 512 from 02:05 to 02:30; her handheld recorded vitals there at 02:12, two minutes before the edit. She did not make it. She also says nobody logs out of PC02 at night, so her session was open.
- Card 3: Dao used PC02 around 02:10, without checking whose account was open, to enter insulin 40 units for bed 7. The wrong value on bed 3 is exactly the dose she was entering, and the time fits.
- Card 3: on the PC02 list bed 3 and bed 7 are next to each other, an easy wrong-row click. The bed 7 order was edited at 02:16 by the same account, two minutes after the bed 3 edit: Dao was entering the same order for bed 7, the patient she meant. This pattern (same dose, adjacent rows, minutes apart) fits a selection slip, not a planned attack.
- Card 1: the blank reason field fits a rushed night-shift entry.
Threat source
| Framework | Classification | Why |
|---|
| NIST SP 800-30 | Accidental (human error by a user with access) | A nurse made a mistake while doing legitimate work. |
| ISO/IEC 27005 | Accidental (A) | No intent to harm. |
A structural / technical factor contributed: version 4.2 removed the dose check from the edit screen (Card 4), so the error was not caught. The root event is still the human slip.
STRIDE
- Tampering: no, in the STRIDE sense. Integrity was broken, but STRIDE Tampering means a deliberate change; this one was a mistake.
- Repudiation: the condition for it exists. Because the session was shared, the log names an account (nurse.somsri) that was not the person who acted. If the change had been malicious, the actor could deny it and the log could not prove otherwise.
- Spoofing: in effect Dao acted under another user’s identity, though unintentionally. The shared, open session is the same weakness an attacker would use to spoof.
So: no STRIDE attack occurred, but the shared session created Spoofing and Repudiation exposure.
Alternative explanation: Ward Clerk Anan (Card 6)
- Points toward him: a motive (warning after an argument with Dr. Pim, whose order was changed); he was in Ward 5 that night; the CCTV was down, so there is no video.
- Rules him out: his badge shows he left Ward 5 at 02:05, nine minutes before the 02:14 edit; his own account cannot edit medication orders; and Dao’s statement and the bed 7 edit (Card 3) already explain the change fully. The CCTV failure means we cannot visually confirm who was at PC02, so the badge record and Dao’s statement carry the weight.
Final answer: accidental (NIST Accidental / ISO A), with a structural contributing factor; no STRIDE attack, but Spoofing/Repudiation exposure from the shared session; Anan is ruled out by Cards 3 and 6.
Exercise Q2
The Principle (Part 3). Which Clark-Wilson rule(s) were broken? Explain how, using the medication process (Create Order → Verify Order → Record Given).
Show solution ↓Hide solution ↑
Solution
Walk the process. The CDI is the medication order M-4471.
TP1 Create Order (doctor): Dr. Pim created the order correctly (4 units, Card 1). But the dose was then changed by an edit run under a nurse account.
- Well-formed transactions: broken. A CDI must change only through a correct, approved TP. The “edit order” screen in version 4.2 had no dose range check (Card 4), so it was not a well-formed TP: it accepted a tenfold change without validation. A phone order should also be entered as a proper order for the right patient, not as an edit of an existing order.
- Access triple (User, TP, CDI): broken. The triple must bind the real user to the TPs they may run. Dao ran the edit TP as nurse.somsri (Cards 1–3). The system could not know who the user really was, so the triple was meaningless.
TP2 Verify Order (pharmacist)
- Separation of duties: broken. The edited order was not re-checked by the pharmacist (Card 5). The nurse’s change went straight to the ward, so in practice one person changed the order and nobody independent checked it. The checker step existed on paper only.
TP3 Record Given (nurse): the dose was given as written at 07:30.
- Audit: weakened. The log recorded the change, but it names the wrong person (shared session) and the reason is blank (Card 1). The trail cannot fully explain who changed the order and why.
- IVP: ineffective. The reconciliation ran at 06:00, before the 07:30 dose (Card 7). It also compares drugs given against orders, and both said 40, so it could not catch a wrong order anyway.
Answer: well-formed transactions (edit TP without validation), access triple (wrong user identity), and separation of duties (pharmacist re-check skipped) were broken; audit and IVP were too weak to catch it.
Exercise Q3
Failed Controls (Part 4). List the controls that failed or were missing. For each one, name the Evidence Card and label it Preventive (P), Detective (D), or Corrective (C).
Show solution ↓Hide solution ↑
Solution
Go card by card and ask what should have stopped, found or fixed the error.
| # | Failed or missing control | Card(s) | Type |
|---|
| 1 | Individual login / automatic logout on the shared PC; staff use their own session (no shared, open session) | 2, 3 | P |
| 2 | Dose range check on the edit screen (input validation), removed in version 4.2 | 4 | P |
| 3 | Change management: no RFC, no CAB approval, testing covered only the new-order screen | 4 | P |
| 4 | Separation of duties / maker-checker: pharmacist re-check of edited orders skipped; one pharmacist on night shift | 5 | P |
| 5 | Patient identification on entry (confirm patient before saving; adjacent beds on the list) | 3 | P |
| 6 | Mandatory “reason for change” field | 1 | P (also weakens D) |
| 7 | Audit trail that identifies the person, not just the account | 1, 2 | D |
| 8 | Reconciliation (IVP) timing: ran at 06:00, before the 07:30 dose | 7 | D |
| 9 | CCTV near PC02 not working | 6 | D |
Corrective controls that worked: the 23:00 backup still holds the original 4 units (Card 7), proving the original value and supporting a correction with a trail.
Answer: preventive controls failed most (shared session, removed range check, no change management, skipped pharmacist check); detective controls were weak (account-only audit, blank reason, late reconciliation, CCTV down); the backup is the corrective control that preserved the original value.
Exercise Q4
Fix It (Parts 4–5). Recommend three controls: one preventive, one detective, and one corrective. For each control, explain how it would have stopped, found, or fixed this incident. Match each control to an ISO/IEC 27001:2022 Annex A control.
Show solution ↓Hide solution ↑
Solution
| Type | Recommended control | How it changes this incident | Annex A |
|---|
| Preventive | Change management: every EHR release needs an RFC, CAB approval, testing of all affected screens (including “edit order”), a rollback plan; restore the dose range check on the edit screen now. | The missing check would have been found in testing. With the check in place, the 4 → 40 edit would have been flagged before saving. | 8.32 Change management |
| Preventive (alternative) | Separation of duties enforced by the system: an edited order cannot reach the ward until a pharmacist re-verifies it (with remote verification or a nurse double-check at night). | The 02:14 edit would have been held for verification, and the pharmacist would have seen a tenfold dose change for the wrong bed. | 5.3 Segregation of duties |
| Detective | Protected audit logging with alerts: personal login (badge tap) so the log names the real person; mandatory reason; alert on large dose changes; reconcile orders against the original before administration. | An alert on “insulin 4 → 40, no reason” at 02:14 would have reached the pharmacist or charge nurse hours before 07:30, and the log would name Dao, not Somsri. | 8.15 Logging |
| Corrective | Tested backups + correction with a trail: keep and test backups (3-2-1, immutable copy); correct records by adding the right value and keeping the wrong one with who/when/why. | The 23:00 backup proves the original was 4 units. The order is corrected to 4 with a trail, so the history (and the evidence) remains complete. | 8.13 Information backup |
The shared-session problem is also fixed by enforcing unique user authentication and automatic logout on shared workstations (Annex A 8.5 Secure authentication).
Answer: P = change management / SoD (8.32 / 5.3), D = protected logging with alerts (8.15), C = tested backup and correction with a trail (8.13).
Exercise Q5
The Law (Part 5). If the change had been intentional, which Thai law and section could apply? The audit log shows which account made the change. Can MediCare Plus use it to prove which person made the change? Explain, using the Electronic Transactions Act (original form and evidential weight).
Show solution ↓Hide solution ↑
Solution
If intentional
- Changing another person’s computer data without permission → Computer Crime Act, Section 9: up to 5 years imprisonment, or up to 100,000 baht, or both.
- Using someone else’s session to get into data not meant for you → Section 7 (unauthorized access to data) may also apply.
(In this case the evidence shows an accident, so these sections do not apply to Dao; the hospital still has duties under PDPA §35 to keep the data accurate.)
Does the log prove who?
- Section 11 (evidence): a court weighs electronic evidence by how reliably it was created, stored, and sent.
- Section 10 (integrity of the original): the record must be kept by a reliable method so that it stayed complete and unchanged.
- The log reliably shows what changed (order M-4471, 4 → 40), when (02:14), where (PC02) and which account (nurse.somsri), and the 23:00 backup (Card 7) supports that the original was 4 units.
- But the method for identifying the person is not reliable: PC02 is shared and nobody logs out (Card 2), so anyone at the screen acts as whoever is logged in. Card 2 proves Somsri was elsewhere; Card 3 shows Dao used the PC.
Answer: Computer Crime Act s.9 (and s.7) if intentional. The log proves which account made the change, not which person: because the session was shared, the identification method was unreliable, so under ETA s.10–11 the log alone has little weight for attribution and must be backed by other evidence (statements, handheld records, badge logs). Individual logins and automatic logout make the log usable as evidence.