Saltar al contenido principal

Planning & RoE — Hands-on lab

You step into the role of a freelance pentester. You receive a request from a medical practice that wants "a full security audit." The scenario is deliberately booby-trapped — several zones cannot legally be tested, several of the client's requests are vague. Your job is to untangle it.

Time: 3 to 4 hours.

Deliverable: an RoE-medical-practice.md file of about 4 pages, plus a refusal / negotiation note listing the points where you had to correct the client.

The scenario — Bellevue medical practice​

Bellevue is a group of doctors in Sherbrooke, 12 professionals, 6 administrative employees. Dr. Ouellette, the senior partner, contacts you.

The initial request, verbatim:

"Hello. We read that we needed to run security tests, and we would like a full one. You need to look at everything we have. We use the OmniMed electronic medical record, hosted at the provider. We have Windows laptops and a file server in the office. We would also like to check that our employees do not fall for emails. How much does it cost?"

Information gathered over the phone on the first call:

  • EMR (electronic medical record): OmniMed, hosted on OmniMed Cloud.
  • Laptops: 18 Windows 11 workstations, provided by the practice.
  • File server: Windows Server 2016, in office, holds administrative documents (billing, reports, letters).
  • Public website: hosted on GoDaddy, WordPress.
  • Wi-Fi: shared between doctors and the waiting room.
  • Approximate budget: "20,000 CAD maximum."
  • Deadline: the practice wants the report "before summer," so within 6 weeks.
  • Point of contact: Dr. Ouellette himself.

Your objectives for the lab:

  1. Identify everything that cannot be tested in this scope.
  2. Draft a consistent RoE for what can be tested.
  3. Draft a negotiation note explaining to the client what you refuse or rephrase.

What we expect from you​

Deliverable 1 — RoE-medical-practice.md​

Structured as follows:

# Rules of Engagement — Bellevue medical practice

## 1. Identification of parties
## 2. Technical scope
### 2.1 Testable zones
### 2.2 Exclusions
## 3. Test regime by zone (black/grey/white-box)
## 4. Allowed and forbidden techniques
## 5. Intervention windows
## 6. Escalation contacts
## 7. Handling critical situations
## 8. Evidence handling
## 9. Applicable legal framework
## 10. Deliverables and timeline
## Appendix A — IPs and domains
## Appendix B — List of human targets for phishing
## Appendix C — Provider PGP key

Deliverable 2 — Negotiation-notes.md​

One to one and a half pages. For each point you refuse or modify, state:

  • What the client asked for.
  • Why it is a problem (technical, legal, ethical).
  • What you propose instead.

The eight traps to spot​

Do not read this section before trying the lab a first time. It contains the points you should have identified.

Trap 1 — The EMR on OmniMed Cloud​

The practice does not own the OmniMed infrastructure. You cannot test the EMR, unless OmniMed explicitly agrees. What you can test:

  • The client-side workstation (how the application is installed on laptops).
  • The credentials (password policy, MFA on or off).
  • The transport layer (well-configured HTTPS, current certificates).

But everything behind the connection — the OmniMed servers — is out of scope. Write it down in black and white.

Trap 2 — The WordPress site on GoDaddy​

GoDaddy allows pentests on their customers' sites, under conditions (notification, rate limits, no test against shared infrastructure). Check the current policy at the time of the engagement. Write in the RoE that you have verified this policy.

Watch out: a WordPress is often shared with other sites of the same customer on the same hosting plan. Only test your site.

Trap 3 — The shared Wi-Fi​

The waiting-room Wi-Fi carries patient traffic. Testing the Wi-Fi means risking:

  • Intercepting patient traffic (health data — very strong protection).
  • Triggering an incident under the RSS.

Two options:

  • Refusal: patient Wi-Fi is not tested. Recommendation of an audit instead.
  • Constrained test: only outside opening hours, no captured outbound traffic recorded, WPA2/WPA3 only verified.

Pick option 1 for this case. It is safer.

Trap 4 — The doctors' laptops​

A pentester who compromises a doctor's laptop can, technically, access the medical records they had open. That falls under the RSS (Quebec's Health Services and Social Services Act) and Law 25.

The RoE must forbid:

  • Active compromise of a doctor's workstation while it is in use in consultation.
  • Exfiltration of files whose names suggest a patient record.

Solution: workstation tests outside consultation hours, with a demo workstation whenever there is doubt.

Definition — why the RSS is stricter than Law 25 for a medical practice

Quebec's Health Services and Social Services Act (RSS), starting at article 19, protects the information contained in a user's record held by a practice or a health facility. It forbids any communication of that information without the express authorization of the person concerned, except for narrowly listed exceptions. Law 25, by comparison, frames personal data in the broad sense and leaves more room — presumed consent for certain purposes, exceptions for legitimate interest.

The pentester who touches a medical practice is therefore subject to two cumulative regimes. Law 25 for anything that is email, address, social insurance number. RSS for anything that belongs to a medical record: diagnosis, prescription, consultation note, test result, even the mere existence of an appointment. A file named Dr_Ouellette_notes_2026-03-15.docx on the file server likely falls under the RSS; you do not open it, you do not copy it, you do not build a named inventory of it.

The practical consequence for the RoE: an explicit exclusion clause for user records, a list of allowed exceptions (dedicated test files created by the practice for the exercise), and a written commitment from the pentester to signal without delay any accidental exposure of RSS information, so the practice can meet its own obligations to notify the affected user.

Trap 5 — The file server​

It holds billing data. Invoices carry patient name + medical act. Health data.

You cannot simply list the server's contents. You need:

  • A written agreement from the practice and a reminder to the client of its obligations to the professional order.
  • A clause stating that any patient data touched is erased without a copy after the exercise.

Trap 6 — Social engineering on the employees​

"Check that our employees do not fall for it." Fair enough. Except:

  • You need written consent from each targeted employee or a general agreement signed by the representatives (works council, HR).
  • You need to plan for what happens next. What do you do with an employee who clicks? Training? Reprimand?
  • You need to exclude employees in a vulnerable situation (sick leave, probation period) according to the practice's HR doctrine.

Without that consent: refusal, or reframing as "social engineering simulation on fictional personas," which does not carry the same weight.

Trap 7 — The budget and the deadline​

20,000 CAD for this scope, in 6 weeks, is tight. You can deliver:

  • A workstation configuration review.
  • A scan of the file server.
  • A test of the WordPress.
  • A framed phishing wave.

You cannot deliver, on that budget:

  • A code review of custom WordPress plugins.
  • A full test of the EMR.
  • A physical access test of the practice.

The RoE must say yes to few things and an explicit no to the rest, rather than a "yes to everything, done poorly."

Trap 8 — The single point of contact​

Dr. Ouellette is a doctor, not a CISO. In the event of a night-time incident, he will not know what to do. Require:

  • A secondary technical contact, even a subcontractor (the practice's IT provider?).
  • A clear administrative contact (the person who signs the invoices).

Without those contacts, refuse or postpone the project.

Self-assessment grid​

Ticked every point below? You have a defensible RoE.

  • The RoE clearly identifies both parties, with business numbers.
  • The scope distinguishes testable zones from excluded zones.
  • OmniMed is excluded with justification.
  • Patient Wi-Fi is handled (excluded or tested under strict conditions).
  • The regime (black/grey/white-box) is stated per zone.
  • The windows avoid medical consultation hours.
  • Two distinct contacts (operational + 24/7 emergency) are named, with phone numbers.
  • The "preexisting intrusion" clause is written.
  • Law 25 and RSS are cited with the corresponding obligations.
  • Phishing is framed: targets, volume, post-click, HR safeguards.
  • Deliverables have precise dates and an encrypted delivery mode.
  • The negotiation note explains why you refused or rephrased each point.

Optional extension — The kick-off meeting​

You have the RoE. Well done. What is left is to run the kick-off meeting. Prepare, on one page, an agenda for that meeting. It must include:

  1. Reminder of objectives (5 min).
  2. Confirmation of contacts and reachability (10 min).
  3. Reminder of zones and exclusions (10 min).
  4. Critical procedures: what do we do if… (15 min).
  5. Signature of minutes that count as an amendment if points have moved (5 min).

A pentester who skips this meeting is a pentester who will have a problem.

What you take away from this lab​

  • The reflex to question before you draft.
  • The habit of refusing what is not testable before signing, not after.
  • The distinction between the requested scope and the defensible scope.
  • A template RoE you can adapt to every engagement to come.

Next step: the module quiz. After that, back to actual technique — OSINT.