Chapter 2 — Scope, permission and safe practice

Chapter 2 — Scope, permission and safe practice

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Curiosity needs a boundary"]
  N2["2.2 Write an authorization brief"]
  N3["2.3 Decide what information is necessary"]
  N4["2.4 Define stop conditions before the exercise"]
  N5["2.5 Report a finding with calibrated language"]
  N6["2.6 Lab: a bounded tabletop"]
  N7["Chapter 2 summary"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Curiosity needs a boundary"]
  N2["2.2 Write an authorization brief"]
  N3["2.3 Decide what information is necessary"]
  N4["2.4 Define stop conditions before the exercise"]
  N5["2.5 Report a finding with calibrated language"]
  N6["2.6 Lab: a bounded tabletop"]
  N7["Chapter 2 summary"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Curiosity needs a boundary]
    |
    v
[2.2 Write an authorization brief]
    |
    v
[2.3 Decide what information is necessary]
    |
    v
[2.4 Define stop conditions before the exercise]
    |
    v
[2.5 Report a finding with calibrated language]
    |
    v
[2.6 Lab: a bounded tabletop]
    |
    v
[Chapter 2 summary]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

After this chapter, you should be able to define an allowed study activity, identify who can authorize it, write stop conditions, choose a synthetic data set, and report an observation without collecting unnecessary personal information.

2.1 Curiosity needs a boundary

The first chapter used an invented schedule so every reader could practice the method. A public website is different. Being able to open a page does not mean you have permission to probe the system behind it, test accounts, collect records, or disrupt its operation. A training exercise needs a named environment, an owner, permitted actions, and a way to stop. Reading a public document and testing a live service are different activities, even when the learner's intent is educational.

This course uses synthetic records and paper exercises by default. A learner may work with a real system only after its owner has authorized the specific activity and the learner understands the organization's rules. This is a practice rule for the course, not legal advice about any jurisdiction. If authorization is unclear, the next step is to ask the owner; it is not to test first and explain later.

The NIST SP 800-115 testing guide describes planning and conducting technical assessments. Its rules-of-engagement definition emphasizes guidelines and constraints set before a test. This rapid course stays at the level of defining safe scope and reviewing evidence. It does not require active testing of anyone else's systems.

2.2 Write an authorization brief

Imagine that Harbor Library's service owner wants staff to rehearse what to do if the room-booking page becomes unavailable. The approved exercise can be entirely offline. A one-page brief should answer seven questions:

The brief is specific enough for a beginner to follow. It also prevents the exercise from expanding into an unapproved account or network test. A phrase such as “test the library” is not an adequate scope because it does not identify systems, actions, people, or time.

2.3 Decide what information is necessary

Good evidence does not require copying everything available. The exercise needs a booking time, a room identifier, a printout time, and a decision made by staff. It does not need a resident's name, contact details, or account credentials. Replace names with invented labels such as Resident A and use artificial booking IDs. This both reduces possible harm and makes the exercise reproducible for other learners.

For a real incident report, preserve required evidence under the organization's approved process; do not independently delete or transform records you have a duty to retain. For a classroom exercise, start with synthetic inputs so the privacy question is simple. The learner should be able to explain why each field in the exercise is present. If a field does not support an objective, remove it.

The following sample has enough information for a schedule comparison:

booking_id,room,start_time,created_time,status
SYN-001,Room 2,14:00,08:20,confirmed
SYN-002,Room 2,15:00,10:05,confirmed

SYN- identifies invented records. The sample contains no real identity data. A reader can ask whether a 09:00 printout would include both records without accessing a booking system. It would include only the first if the printout is a snapshot at 09:00; that is an exercise assumption to state explicitly.

2.4 Define stop conditions before the exercise

A stop condition is an observable reason to pause work and ask for direction. It should be written before an activity begins, when everyone can think clearly. Examples for this paper exercise are: a participant opens a real booking page to “check” the scenario; a sheet contains a real patron name; the exercise begins to interfere with front-desk service; or a result suggests an actual urgent problem that needs the organization's response process. In each case, pause the training, protect the material already collected, and ask the designated owner what to do next.

Stopping is not failure. It is evidence that the team respected its boundary. A good report can state, “The exercise stopped after the team noticed a real patron name in the sample sheet. The sheet was not circulated; the owner replaced it with synthetic data.” That sentence documents both the problem and the safe action without publishing the name.

2.5 Report a finding with calibrated language

The goal of an exercise report is to help the owner decide what to check or change. A compact structure is:

1. Objective and scope: what was the exercise intended to test, and what was excluded?
2. Method: which synthetic inputs and steps were used?
3. Observation: what did participants actually see or do?
4. Interpretation: what risk or control gap may follow, and what alternative explanation remains?
5. Recommendation: what can the owner verify or improve next?
6. Limitations: what did the exercise not establish?

For the invented library test, a fair statement is: “In one paper exercise, staff using a 09:00 snapshot did not see a synthetic reservation created at 10:05. The exercise suggests that a static printout is insufficient as the sole source for later bookings during an outage. The exercise did not test the real booking service or establish how a real front desk currently operates.” The sentence is useful because the observation and its limit are both visible.

Avoid dramatic labels such as “critical breach” when no breach has been observed. Avoid a vague recommendation such as “improve security.” Propose a decision the owner can evaluate: define a fallback source for later bookings, mark the printout time, and rehearse the procedure with a later synthetic reservation.

2.6 Lab: a bounded tabletop

This lab needs only a text editor or paper. Use the two synthetic CSV rows above and draw a 09:00 printout containing SYN-001 only. One learner plays the front-desk worker, one the resident asking about Room 2 at 15:00, and one the observer. If working alone, write three short lines for each role. The observer asks whether the worker knows the printout time, notices the missing later booking, and avoids promising a room without a current source.

Run two rounds. In round one, give the worker no fallback instruction and record what happens. In round two, give the worker this rule: “When the booking page is unavailable, mark the age of the printout and place unverified later requests in a pending queue until an approved source or the service owner confirms them.” Record whether the rule changed the decision. Do not infer that the rule will work in every setting. The result demonstrates only how this small scenario behaved under the stated assumptions.

An acceptable lab record has the date of the fictional exercise, role labels, the two synthetic booking IDs, the decision in each round, and a limitation statement. There is no need to create a live account, send a message, or access an external system.

Chapter 2 summary

An authorized boundary makes a security exercise useful and safe. State the owner, permitted data and actions, excluded systems, timing, stop conditions, and reporting route before starting. Use synthetic records when they can answer the learning question. Report exactly what was observed and what remains unknown. Chapter 3 will add a more complete model of systems, data flows, and dependencies within that boundary.

Chapter 2 exercises

Keep every activity within the synthetic paper-exercise boundary. Worked results appear at the end of this book.

EX006 — Write the scope

• Objective: Turn a vague activity into an authorized exercise boundary.
• Input: The Harbor Library tabletop in Section 2.6.
• Safe condition: Use only paper or a text editor and invented records.
• Task: Write a six-line brief naming owner, in-scope materials, excluded systems, permitted actions, time window, and recipient of results.
• Expected evidence: A brief another learner could follow without guessing the boundary.
• Rubric: Credit for all six elements and a clear exclusion of production systems and real residents.

EX007 — Minimize the data

• Objective: Select only information needed to test a learning outcome.
• Input: A fictional draft sheet with booking ID, room, start time, created time, resident name, personal phone number, and status.
• Safe condition: Do not use or invent realistic personal contact details.
• Task: Choose fields for the stale-printout exercise, explain each choice, and remove unnecessary fields.
• Expected evidence: A revised synthetic field list and one sentence per retained field.
• Rubric: Credit for retaining timing and room evidence while excluding name and phone number.

EX008 — Stop or continue

• Objective: Apply a prewritten stop condition.
• Input: Halfway through the paper exercise, a participant proposes opening the real library site to check an answer.
• Safe condition: Do not open or test any real service.
• Task: State whether to continue, what to record, who decides the next step, and how to finish the learning objective safely.
• Expected evidence: A four-part response with an offline alternative.
• Rubric: Credit for pausing the proposed live action, notifying the owner, preserving the exercise boundary, and continuing with synthetic data if approved.

EX009 — Calibrate the report

• Objective: Distinguish an observation from an exaggerated claim.
• Input: “The old printout did not show SYN-002; therefore the real library has a critical security breach.”
• Safe condition: Use the supplied fictional case only.
• Task: Rewrite the sentence as an observation, interpretation, limitation, and next check.
• Expected evidence: Four labeled sentences.
• Rubric: Credit for retaining the observed printout gap, removing the unsupported breach claim, and proposing an owner-approved check.

EX010 — Compare two tabletop rounds

• Objective: Assess whether a procedure changes a decision in a controlled exercise.
• Input: The two rounds in Section 2.6, including the pending-queue rule in round two.
• Safe condition: Role-play without real service data or communication.
• Task: Define one observable decision in each round, one criterion for improvement, and two limits on generalizing the result.
• Expected evidence: A short comparison table and limitations.
• Rubric: Credit for an observable measure, a plausible decision difference, and limits about synthetic data and one-session scope.

Continue studying — chapter 02 of 20

← Chapter 01 · Course chapter index · Chapter 03 →

Continue to the next authored lesson.