~/tutorials/045-rules-of-engagement.md

045: Rules of engagement

The lesson before this one was the report. This one is the paper that makes all of it lawful, and it is a technical lesson in disguise, because scope is where real engagements are actually lost.

The letter

An authorization to test is a short document with specific sentences in it. What systems, by address and by name. What windows of time. What classes of testing are allowed and which are excluded. Who signs, with a title that binds the company, and a phone number for the emergencies.

You read it before you accept the work, line by line, and the reading is technical. Systems by address means you resolve every name and check the addresses against what you believe the scope is. Exclusions mean your scanner is configured to skip them, not that you remember to. The letter is not a feeling of permission. It is an interface, and you configure against it.

Where there is no letter, there is no test. A verbal yes from an administrator is not a yes from the company. A screenshot of a conversation is not a signature. This is not caution. It is the difference between a career and a felony, drawn in one document.

The questions that come up anyway

Somebody asks you to look at something adjacent. The answer is a new line in the letter or a no. Scope does not stretch verbally.

You find something serious outside scope in the data you lawfully collected. You stop touching it, document that you saw it, and report it in the finding that says: seen, not pursued, outside scope. Clients respect that sentence. It is the mark of somebody they can hire again.

A third party's equipment appears inside the client's address space. Cloud tenants, hosted services, a provider's router. Their box is not your client's to authorize. The letter's job was to tell you this before you scanned it.

The habit, before anybody pays you

Start now, in the lab. Write the authorization for your own exercises: what networks exist, what the rules are, when you tear it down. Machines state their rules in files, and this one's is public and short:

cat ~/robots.txt

A policy in plain lines: what is welcome, and what to be gentle with. Other machines state theirs elsewhere, and asking is cheap:

$ dig +short l1ackers.com

That one runs on your box. The shell below it has one zone and says why, and the shape of that refusal is the shape of every policy you will ever read: what it will not do, why, and what to do instead.

Try it

1. Read a real authorization letter. Bug bounty programs publish theirs, and the vocabulary is the same vocabulary.
2. Draft the letter for your own lab. Addresses, rules, teardown.
3. Run your next lab session strictly inside it. The muscle you are building is stopping, and it only trains by stopping with something you wanted to do.