YanoSecA useful security test starts with a written scope and ends with evidence that someone can act on. Scope states the permitted target, actions, time, exclusions and stopping conditions. Rules of engagement are the agreed constraints on how a test will run. Knowing what a tool can do does not establish which of those actions are permitted.
The sequence used here is planning, observation, listing relevant details, checking a lead, writing a finding and reporting it. Reconnaissance means gathering permitted observations; enumeration means making a more detailed permitted list. Validation checks a lead against evidence. A finding states a supported claim, its evidence, its impact and a fitting remedy.
Before you begin
- Recommended first
- How a web app is put together, Same-origin policy, Binary, hex, Base64, and URL encoding, What a domain is
- Estimated time
- 14 min reading, 10 min activity. Setup and optional practice may take longer.
- Where you work
- Read the fictional cards in any current desktop or mobile browser. No installation, account, password tool, directory deployment or network request is required. Use only the evidence supplied on this page.
- Without a lab
- The page prints the evidence needed for the activity. Write your classifications and reasons in notes, then compare them with the activity rubric. This practices reasoning; it does not reproduce a live incident or tool operation. Reading works without JavaScript. Answer checking requires JavaScript and a secure browser context; saving progress also requires usable browser storage.
After this lesson you can:
- Order a scoped test from the grant through the report.
- Separate a lead from a finding that has been checked.
- Stop when a proposed target is outside the printed grant.
01Example
This fictional plan demonstrates a sequence, with permission established before observation. The scrambled activity cards let you reconstruct that sequence without running a command.
Grant: read the printed owned-notes card during this lesson.
1 scope, the grant
2 recon, observe only that card
3 enumeration, list only what the grant allows
4 validation, check a lead against the card
5 finding, claim, evidence, harm, and a fitting change
6 reporting, tell the person who can act
A link to any other host is a stop.02A lead is not a finding
A tool label or a suspicion is a lead. To support a finding, compare it with the evidence available inside the grant. For example, an unexpected edit response needs a stated role and permission rule before you can conclude that an access boundary failed. A real investigation may need more evidence than these cards supply.
The fictional grant permits only reading its printed card. If a link leaves that target, or private data appears, the stopping condition applies. Protect assessment notes as well: report only the evidence needed to support the claim through the agreed channel. You do not perform a live test in this activity.
Put the grant first, and keep a tool label from becoming a finding before it is checked.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Grant: read the printed owned-notes card during this lesson.
met · Printed owned-notes card during this lesson.1 scope, the grant 2 recon, observe only that card 3 enumeration, list only what the grant allows 4 validation, check a lead against the card 5 finding, claim, evidence, harm, and a fitting change 6 reporting, tell the person who can act
met · Scope remains fixed through all six stages.A link to any other host is a stop.
met · No other host is involved.Later workflow stages do not enlarge the initial grant.
Permission precedes observation; a lead needs validation before a finding.
Later workflow stages do not enlarge the initial grant.
Follow the explanation
- Later workflow stages do not enlarge the initial grant.
- A lead is not permission or a finding; do not follow the host.
Read every state and value
1. Later workflow stages do not enlarge the initial grant.
- Case
- read
- Conditions inspected
- Fixed grant · Six stages · Other-host stop
- Decision shown
- Yes
2. A lead is not permission or a finding; do not follow the host.
- Case
- outside
- Conditions inspected
- Fixed grant · Six stages · Other-host stop
- Decision shown
- Yes
03Put the grant first
The six cards below describe different stages of a test. Put them in an order that establishes permission before any observation, then compare your sequence with the provided activity rubric.
Original fictional test. No command was run. The grant is made up.
Grant
Owner: training-lab owner
Target: the printed owned-notes card
Allowed action: read that card
Time: during this lesson
Excluded: any other host, any scan, any change
Stop: the grant is unclear, private data appears, or a link leaves the card
Scrambled cards
Card look: observe only what the grant names
Card tell: write the verified claim for the person who can act
Card grant: the permission above
Card note: a verified claim, the evidence, the harm, and a change that would address it
Card list: make the list the grant allows, and no other list
Card check: decide whether a lead is true
Order for this card
1 grant
2 look
3 list
4 check
5 note
6 tell
Check: grant is first.
A sentence that says "missing access check" stays a lead until it is compared with the stored role.
If a link points at a school portal, stop. The grant does not name that portal.
- Copy the grant's target, action, time, exclusions, and stop.
- Order the six cards. Match them to scope, recon, enumeration, validation, finding, and reporting.
- Check: grant is first. A school-portal link is a stop.
- Do not run a command. The cards are the whole test.
04Optional challenge
Allow about fifteen minutes. A tool claims that a reader can edit users. Write a plan for checking that claim from an authorized role matrix and response record. Your rubric is the claimed failure, evidence needed, possible harm and a narrower permission rule; leave unconfirmed facts marked unknown.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Test case A: independent planning cardsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Grant: read supplied role and response cards for the owned plum-note model from 10:00–11:00 UTC. No connections, scans, changes or other targets.
Stages to arrange: establish scope; observe granted evidence; enumerate permitted details; validate a lead; prepare a supported finding; report to the responsible owner.
Test case B: independent evidence qualityOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Lead L: a banner says reader edits may be possible; no permission or behavior comparison yet.
Record M: the role card denies reader edits; the supplied response says the reader’s edit was accepted; the stored-entry card confirms the changed value. These cards support the particular permission failure only.
Proposal: read an unrelated school portal at 10:30 UTC.
06Explain your prediction
Optional written self-check: Separate permission, observation, lead, validation, supported claim and report. Keep the finding’s harm and proposed change tied to evidence, and label planned checks as plans.
07Common mistakes
If you put a tool card before the grant, you skipped planning. The bulletin's execution phase uses the plan that already exists.
If you called a lead a finding, you skipped validation. The card says a missing check stays a lead until it is compared.
If you followed a link to a school portal, you left the target named in the grant.
References
- NIST ITL Bulletin, December 2008: Guide to Information Security Testing and Assessment
It summarizes SP 800-115. Planning includes scope. Rules of engagement are the constraints set before a test. Execution identifies vulnerabilities and validates them when appropriate. Post-execution recommends actions and a report. The bulletin names password cracking as a validation example. This lesson does not practice it.
- NIST SP 800-115 publication page
Final, September 2008, superseding SP 800-42. The abstract says the guide helps organizations plan tests, analyze findings, and develop mitigation. It is not a current tool manual.