Ethical Security Testing In progress
Beginner 16 min read Ethical Security Testing
Authorization and Rules of Engagement
Before any packet flies: why written authorization, clear scope, and Rules of Engagement are not paperwork but the ethical and legal foundation of all testing.
rules of engagementscopeauthorizationlegalbug bountyresponsible disclosure
Introduction
What is this?
Rules of Engagement (RoE) is the written, signed agreement defining exactly what may be tested, when, with which techniques, and what is off-limits — the boundary that makes a test legal and ethical.
Motivation
Why do you need it?
- Testing without authorization is a crime in nearly every jurisdiction — scope is what separates a pentester from an intruder.
- A signed RoE protects you AND the client: both sides know the blast radius and the stops.
- Every professional engagement (bug bounty, offensive lab) rests on a scope contract; it is the professional habit.
Think about it
Mental model
Imagine
A demolition permit
Think of
The map of which walls are load-bearing
The permit authorizes the work; the map tells you which bricks you may actually knock out.
Mechanics
How it works
- The statement of work names targets, IP ranges, domains, time window, and testing methods.
- RoE adds constraints: no social engineering, no data exfiltration, do-not-test lists, emergency contacts.
- Special clauses cover data handling: masks, retention, and what to do when you stumble on real PII or a live incident.
- A breach of scope voids the authorization instantly — stopping and reporting is always the right move.
Anatomy of a scope contract
TargetsIPs, domains, apps, APIs
Windowtime + maintenance-day rules
Methodsallowed tools and techniques
Limitsno-dos, no-social proof, no-PII
Sign-offwritten, dated, and stored
Real world
In production
- A retailer's RoE bans any test touching the payment network; the tester discovers a do-not-touch list and honors it.
- A bug-bounty scope file lists exactly the *.example.com assets in-scope and excludes everything else.
- A pentest contract includes an emergency-stop contact and a 24h notification rule for discovered live incidents.
Guidelines
Best practices
- Document scope in writing, dated, with the exact assets and time windows — 'you said it on a call' is not scope.
- Keep the RoE on hand during the test; reassess whenever a new target appears.
- Stipulate that accidental damage and surprise discoveries are reportable, not coverable.
- Do a pre-engagement scoping call: the client's 'of course' often hides the do-not-test list.
Watch out
Common mistakes
- Starting to test from a sneaky 'security research' reading of a generic statement.
- Including production systems in scope without naming them explicitly in the RoE.
- Testing 'just this one more host' because it looks related — scope creep voids the badge.
- Sharing client findings, screenshots, or data outside the engagement without permission.
When things break
Debugging tips
- When a target is ambiguous, treat the unclear case as OUT of scope and write a question to the client.
- Keep a scope-checklist; tick it per asset before touching anything.
- Store the RoE with your evidence pack so a regulator or court can read the boundary.
Security
Security considerations
- Ethics and legality converge here: never test hosts you do not own or are not contracted to test.
- If you discover a live breach mid-test, follow the RoE's emergency pathway and preserve evidence — do not 'help' by changing things.
Interviews
Interview checkpoint
Practice
Hands-on lab
Draft Your Own Rules of Engagement and Stand Up a Lab
40 min · beginner
Objectives
- Write a scope document for a lab you will test.
- Name targets, window, methods, and do-not-test items.
- Deploy a local target and map it to the scope.
Draft Your Own Rules of Engagement and Stand Up a Lab
40 min · beginner
0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself
Quick quiz
0/2
1
The scope agreement's purpose in testing is...
2
You discover a live incident mid-test. Correct move:
Go deeper