Rules of Engagement for Legal and Ethical Lab Exercises

The last lesson turned a technical scenario into a risk statement and rating. Before acting on that risk—especially by scanning, probing, or attempting to validate a weakness—you need a different kind of control: written authorization with clear boundaries.

This lesson focuses on writing rules of engagement (ROE) for an authorized security lab. An ROE is not paperwork added after the technical work; it is the document that defines what the work is. It specifies the objective, authorized people and systems, permitted methods, safety limits, data-handling rules, and the actions to take if something goes wrong. By the end, you will be able to produce a concise ROE for the isolated virtual-machine lab used throughout this course.

---

Why authorization must be specific

Many security-testing actions can look indistinguishable from an attack at the network or application level. A port scan, password-guessing attempt, exploit attempt, packet capture, or web-request fuzzing can produce logs, consume resources, expose data, or destabilize a service.

The ethical and legal distinction is not simply “my intent is educational.” It rests on valid authorization for a precisely bounded activity.

A defensible authorization answers questions such as:

• Who is allowed to perform the test?
• Who owns or controls the systems and data being tested?
• Which exact assets are in scope?
• When may the test occur?
• What techniques may be used?
• What actions are prohibited, even if they seem technically useful?
• What happens if the test causes an issue or uncovers a real security concern?

An ROE makes those answers unambiguous. It protects the system owner by limiting unwanted activity, and it protects the tester by documenting what the owner approved.

For a personal VM lab, you may be both the tester and the asset owner. That makes authorization simpler, but not limitless. You still must respect the terms of any cloud provider, learning platform, software license, or shared network involved. A VM that can reach your home network, employer network, public Internet, or third-party service is not automatically authorized for testing just because you created the VM.

A useful rule is:

If a target, account, network, or data set is not explicitly in scope, treat it as out of scope.

---

An ROE is a safety control, not merely a scope list

A good ROE is both an authorization document and an operational safety plan. It converts vague statements such as “test the lab” into decisions that can be followed under pressure.

Consider the difference:

Weak wording	Operationally useful wording
“Scan the test network.”	“Perform TCP service discovery only against 192.168.56.20 from 192.168.56.10; do not scan any other address.”
“Avoid disruption.”	“Do not conduct denial-of-service tests, high-rate fuzzing, or tests designed to exhaust CPU, memory, storage, or network capacity.”
“Handle data safely.”	“Use only synthetic lab accounts and test data. Do not copy secrets or records to third-party services. Store notes locally in the encrypted lab folder and delete temporary captures after reporting.”
“Tell someone if there is a problem.”	“Stop testing immediately if an unexpected host responds, the target becomes unavailable, or non-lab data appears. Record the time and command, then notify the designated contact.”

The second column is better because another person could carry it out without guessing your intent.

The core ethical principles behind these details are straightforward:

1. Authorization — obtain approval from the party with authority over the target.
2. Minimum necessary impact — use the least intrusive method that can meet the objective.
3. Respect for scope — do not expand targets, techniques, or access merely because an opportunity appears.
4. Protection of information — treat captured data, credentials, screenshots, logs, and vulnerability details as sensitive.
5. Accountability — keep a record of what was authorized, performed, observed, and changed.
6. Stop and report — pause rather than improvising when unexpected impact or a possible real incident occurs.

These principles apply whether the work is a vulnerability scan, an internal assessment, a red-team engagement, or a deliberately vulnerable local exercise.

---

The essential sections of a rules-of-engagement document

The National Institute of Standards and Technology (NIST) treats an assessment plan or ROE as a way to establish structure, accountability, and agreed boundaries. Its template is more extensive than a home lab normally needs, but it provides the right mental model: scope, people, logistics, communication, targets, allowed activities, data handling, reporting, and approvals.

A practical lab ROE can be short, provided it is specific. The following table is a compact structure suitable for this course.

Section	Decision it records	Why it matters
Purpose and objective	What question the test is intended to answer	Prevents unfocused “see what happens” testing
Authority	Asset owner, authorized tester, approval date	Shows who granted permission and who may act
Scope	Exact target names, IP addresses, applications, and test accounts	Prevents accidental testing of the wrong system
Exclusions	Hosts, networks, services, actions, and data that must not be touched	Makes “do not test” concrete
Schedule and location	Time window and authorized source systems or networks	Supports operational coordination and log review
Permitted methods	Allowed tools and categories of tests	Sets the level of intrusiveness deliberately
Prohibited methods	Disallowed actions, particularly disruptive ones	Reduces avoidable outages and unsafe behavior
Safety and stop conditions	Conditions that require stopping or pausing	Defines a safe response before an incident occurs
Contacts and escalation	Primary and alternate contact, notification method	Avoids uncertainty during a problem
Data handling	What may be collected, where it is stored, and when it is deleted	Protects evidence, credentials, and private information
Cleanup and reporting	Snapshot restoration, tool removal, deliverables, and deadlines	Leaves the environment understood and recoverable
Approval and change control	Signatures or recorded approval; process for scope changes	Prevents informal scope creep

Two distinctions are especially important.

Scope is not the same as objective

An objective says why you are testing:

Determine whether the deliberately vulnerable web application exposes unnecessary services or accepts insecure requests.

Scope says what you may touch to meet that objective:

The target is only the VM named vuln-web-01 at 192.168.56.20, accessed from security-tester-01 at 192.168.56.10 over the host-only lab network.

A compelling objective does not authorize testing a system that is absent from the scope list.

A prohibited activity is still prohibited if it would “prove the point”

Suppose a scan suggests that a lab service may be vulnerable to a denial-of-service condition. If denial-of-service testing is prohibited, you document the evidence and stop there. You do not run the disruptive validation because it might demonstrate impact more vividly.

In professional work, this restraint is a mark of competence. A finding can be valid even when its most damaging outcome was not executed.

---

Scope changes, stop conditions, and deconfliction

Testing rarely unfolds exactly as expected. You may discover another host, an unexpected service, or a route that seems to lead beyond the lab. This is the moment when a written ROE matters most.

The safe default is:

1. Stop interaction with the unexpected target.
2. Record minimal evidence needed to explain what occurred: time, source, command or tool action, and observed response.
3. Check the scope and exclusion list.
4. Request an explicit scope change from the asset owner if further testing is necessary.
5. Resume only after approval is recorded.

Do not interpret silence, convenience, or a technical opportunity as approval.

The UK National Cyber Security Centre also emphasizes maintaining contact, avoiding undue impact, and treating additional systems outside scope as a formal scope decision rather than an automatic new target.

A stop condition is an observable event that tells the tester to stop immediately. For this course’s VM labs, use stop conditions such as:

• a host, MAC address, IP address, or hostname appears that is not on the approved target list;
• the target VM becomes slow, unresponsive, or repeatedly restarts;
• the host machine or home network unexpectedly becomes involved;
• a tool attempts to contact an Internet address or download additional code;
• you encounter data that is not clearly synthetic lab data;
• you believe you may have found evidence of a real compromise outside the lab.

A deconfliction process explains how legitimate test traffic will not be mistaken for a real attack. In a personal lab, that may simply mean recording your source IP, time window, and major commands in a lab log. In an organization, it may include coordinating with the security operations center, network operations team, and incident-response team—without necessarily giving every operational detail to defenders if the test is designed to evaluate detection.

---

A worked ROE for the course VM lab

The following example is deliberately narrow. It assumes a forthcoming two-VM host-only lab:

• a tester VM, security-tester-01, at 192.168.56.10;
• an intentionally vulnerable target VM, vuln-web-01, at 192.168.56.20;
• no bridged adapter, no corporate network connection, and no Internet-routable target network.

The exact IP addresses and VM names are examples. Replace them with your actual values once the next lesson has configured and verified the isolated network.

Important: This example is a learning template, not blanket permission to test any environment. It becomes an authorization record only after the real asset owner, targets, dates, and approvals are completed.

Rules of Engagement: Isolated Vulnerable Web-Application Lab

Document version: 1.0
Date: [enter date]
Lab owner / authorizing party: [your name, if you own the physical host and VMs]
Authorized tester: [your name]

1. Purpose

The purpose of this exercise is to practice authorized reconnaissance, vulnerability identification, and later controlled validation against an intentionally vulnerable virtual machine. The exercise supports cybersecurity learning and evidence collection for a personal portfolio.

2. Objective

Determine which network services are exposed by the authorized target VM and document security observations using non-destructive techniques. Subsequent exercises may validate intentionally placed application vulnerabilities only when they are explicitly authorized by their own lab instructions.

3. Authorized target scope

Asset	Identifier	Authorized activity
Tester VM	security-tester-01, 192.168.56.10	Run approved assessment tools and store local test notes
Target VM	vuln-web-01, 192.168.56.20	Perform only the permitted technical activities below
Lab network	Host-only network 192.168.56.0/24	Exchange traffic only between the two specified VMs

4. Exclusions

The following are explicitly out of scope:

• the physical host operating system;
• the home router, home network, workplace network, and any public or cloud network;
• all IP addresses other than 192.168.56.10 and 192.168.56.20;
• any VM not specifically listed in the authorized target scope;
• Internet services, package repositories, public DNS resolvers, and third-party systems;
• real user accounts, real credentials, personal data, payment data, and employer data.

5. Time window and test location

• Authorized window: [start date and time] through [end date and time].
• Location: Local machine running the approved virtual lab.
• Authorized source: security-tester-01 only.
• Precondition: Before testing, verify that the lab network is isolated and that a recoverable snapshot of the target VM exists.

The lab exercise must not begin if the VM network is bridged to a physical network or if the target VM has an unintended route to the Internet.

6. Permitted technical activities

The authorized tester may perform the following only against 192.168.56.20:

• verify basic network reachability within the host-only lab;
• identify exposed TCP services using low-impact, rate-controlled discovery;
• inspect intentionally exposed web content and HTTP responses;
• perform configuration review and vulnerability identification appropriate to the course lab;
• capture screenshots, command output, and limited packet evidence needed for the lab report;
• use only synthetic accounts and values supplied by the lab.

7. Prohibited technical activities

The tester must not perform:

• denial-of-service, stress, resource-exhaustion, or intentionally destabilizing tests;
• high-volume fuzzing or scans that materially affect target availability;
• testing against targets outside the approved scope;
• phishing, social engineering, wireless attacks, or physical-access attempts;
• persistence, malware deployment, ransomware simulation, destructive payloads, or lateral movement beyond the listed target;
• password attacks against real credentials or accounts;
• copying real data from any system or uploading lab data to unapproved external services;
• changes to the host, router, network configuration, or target VM unless an exercise explicitly requires them.

8. Safety and stop conditions

Stop testing immediately if:

• an unapproved target responds;
• the target VM becomes unavailable, unstable, or unexpectedly reboots;
• test traffic appears to leave the host-only network;
• non-synthetic or potentially sensitive data is observed;
• a tool requests access beyond the approved lab or attempts an unapproved download;
• a suspected real compromise of the host or a non-lab system is discovered.

After stopping, record the time, activity, source, target, and observed effect. Do not continue investigating an out-of-scope or potentially real incident. Notify the lab owner or designated contact before resuming.

9. Communication and escalation

Situation	Required action	Contact
Routine test progress	Record actions and observations in the lab log	Tester
Target instability	Stop testing and restore only after documenting the issue	Lab owner
Scope question	Pause and obtain written scope clarification	Lab owner
Suspected non-lab impact	Stop, preserve minimal evidence, and follow the relevant local incident-reporting process	Lab owner / responsible administrator

For a solo personal lab, the tester and lab owner may be the same person. Record the decision in the lab log anyway; this reinforces the discipline needed when those roles are separate.

10. Data handling and evidence

• Use only synthetic data created for the lab.
• Store screenshots, terminal output, packet captures, and notes in a local folder under the tester’s control.
• Do not publish raw captures, credentials, access tokens, IP details, or exploit output if they contain sensitive material.
• Record vulnerability findings with enough detail to reproduce them safely, but do not include destructive instructions or unnecessary secrets.
• Delete temporary captures and downloaded artifacts after the lab report is complete, unless they are intentionally retained as protected evidence.

11. Cleanup and reporting

At the end of the exercise:

1. Stop testing tools and confirm no test process remains active.
2. Remove temporary files created solely for the exercise.
3. Restore the target VM to its approved snapshot when required by the lab.
4. Record the test date, target, permitted methods used, findings, limitations, and any unexpected behavior.
5. State clearly whether all actions stayed within scope.

12. Approval and scope changes

Testing is authorized only after the lab owner confirms the scope, schedule, and constraints in this document.

Any addition of a target, technique, time window, or data type requires an updated version of this ROE and recorded approval before the new activity begins.

Role	Name	Approval / date
Lab owner / authorizing party	[name]	[signature or recorded approval]
Authorized tester	[name]	[signature or recorded acknowledgement]

---

How to make this a useful portfolio artifact

Save your completed ROE beside your future lab notes, network diagram, screenshots, and final findings. For a portfolio repository, remove sensitive details such as real hostnames, IP addresses, usernames, and raw evidence. You can retain the structure while replacing those values with clearly labeled placeholders.

The value of the artifact is not that it claims you performed an aggressive test. It demonstrates that you can:

• define an objective before selecting tools;
• distinguish target scope from exclusions;
• plan for safety, escalation, and cleanup;
• handle potentially sensitive test data responsibly; and
• document authorization and limitations clearly.

Those are meaningful habits for vulnerability-management, application-security, security-operations, and penetration-testing roles alike.

---

Key takeaways

Rules of engagement establish the legal, ethical, and operational boundaries for authorized security testing.

• Written authorization must identify the authorized tester, asset owner, specific targets, time window, and permitted activities.
• An explicit exclusion list is as important as the target list.
• The ROE should prohibit disruptive or out-of-scope techniques even if they might produce stronger technical evidence.
• Define stop conditions, contacts, and a scope-change process before testing begins.
• Treat collected logs, screenshots, credentials, packet captures, and vulnerability details as sensitive data.
• For this course, your ROE should require network isolation and a recoverable snapshot before active VM-lab work begins.

Next, you will configure that isolated virtual-machine network and recovery snapshot, then verify that the environment is both separated from other systems and recoverable after a change.