Week 1: Engagement Lifecycle, Authorization, and Professional Ethics

What you authorize before you touch a tool matters more than what you do with the tool. By the end of Week 1 you can draft a Rules of Engagement document for a hypothetical client, recite the seven PTES phases in order, and articulate why "I was just looking" is not a legal or ethical defense in any jurisdiction with a computer-crime statute.

Reading (~1.5 hr)

Required:

• Weidman, Penetration Testing, Penetration Testing Primer (before Chapter 1). ~30 pages. This is the seven-phase lifecycle introduction the course follows. Read it before the lecture.
• PTES, Pre-Engagement section (pentest-standard.org/Pre-engagement). ~20 min. Read the scope, authorization, and payment-terms subsections.

Supplementary:

• NIST SP 800-115, "Technical Guide to Information Security Testing and Assessment" (csrc.nist.gov; free PDF), Section 2.1-2.3. The U.S. government framework that many client organizations reference when they commission penetration tests.

Lecture outline (~1 hr)

Part 1: The engagement lifecycle (20 min)

The seven phases of the Penetration Testing Execution Standard are the backbone of this course. Learn them in order; they will be the grammar you use for every technique in weeks 2-11.

The seven PTES phases:

Weidman frames the lifecycle this way in the Penetration Testing Primer: "Pentesting begins with the pre-engagement phase, which involves talking to the client about their goals for the pentest, mapping out the scope (the extent and parameters of the test), and so on." Everything before that conversation is preparation; everything after the report is the client's problem to solve.

The PTES phases are not waterfall stages -- experienced testers iterate. A finding in vulnerability analysis might send you back to intelligence gathering to look for related attack surface. Post-exploitation often reveals new targets that extend the engagement scope (with client approval). The phases give you a label for what you are doing at any moment; they do not constrain the sequence absolutely.

Part 2: Authorization is the bright line (25 min)

Authorization is not a formality. It is the legal and ethical distinction between penetration testing and unauthorized computer access.

The Computer Fraud and Abuse Act (CFAA), 18 U.S.C. 1030: The primary U.S. computer crime statute. It criminalizes accessing a computer "without authorization" or "exceeding authorized access." The CFAA does not require that you find anything, cause damage, or have malicious intent. Unauthorized access is the crime. Federal misdemeanor for a first offense; felony for subsequent offenses or damages above a threshold.

Equivalent statutes in other jurisdictions: the Computer Misuse Act (UK), the Criminal Code Act (Australia), the Strafgesetzbuch Section 202a (Germany). If you conduct a penetration test that crosses a border, multiple statutes may apply simultaneously.

What "authorized" means in practice:

Written authorization takes three forms in professional engagements:

1. Statement of Work (SOW) -- the contract between the pentesting firm and the client. Defines the project, timeline, and payment. Not sufficient on its own for authorization.
2. Rules of Engagement (ROE) -- the technical document specifying the exact IP ranges in scope, the testing window, the types of tests authorized, the emergency contact chain, and what is explicitly prohibited.
3. Authorization letter -- a signed letter from an executive with authority to authorize the test, specifying the scope and the testing firm. This is the document you carry if law enforcement arrives.

All three are required for a professional engagement. An ROE without an authorization letter is an agreement; an authorization letter without an ROE leaves the scope undefined. Weidman is explicit on this: "Make sure you have authorization to perform a penetration test on the target... Regardless, make sure your contract includes a statement that limits your liability in case something unexpected happens, and get written permission to perform the test."

Edge cases the lecture must cover:

• Third-party hosted systems: If the client's website runs on AWS, the ROE from the client does not authorize testing AWS infrastructure. You need the cloud provider's own penetration testing authorization form.
• "It's public": A system that responds on a public IP address is not authorized for testing. "Public" means accessible; it does not mean authorized to probe.
• CTF and training ranges: TryHackMe, HackTheBox, and VulnHub machines are authorized when accessed through those platforms' interfaces. They grant explicit authorization as part of account creation and platform terms. The authorization is the platform's account agreement, not the fact that an IP address responds.

Part 3: The engagement planning document (15 min)

Walk through the components of a real ROE document using the following structure. Lab 1 asks you to draft this for a fictional client.

ROE components:

• Contact information: Client technical contact, client executive contact, pentesting firm lead, emergency escalation chain (24-hour if authorized)
• Authorized IP ranges: CIDR notation; explicit exclusions; third-party systems that require separate authorization
• Testing window: Dates, times, and time zones
• Authorized test types: Port scanning, vulnerability scanning, exploitation, social engineering, physical, wireless -- list each explicitly as authorized or prohibited
• Fragile systems: Any system the client flags as sensitive to disruption (medical devices, production databases, real-time control systems)
• Incident escalation: What happens if you find active compromise? What if you accidentally crash a service?
• Deliverables and timeline: Report format, report due date, oral debrief
• Data handling: How sensitive data encountered during the test is handled and destroyed after the engagement

Lab 1: ROE Drafting (~2 hr, graded)

See labs/lab-1-roe-drafting.md for the full lab.

Setup: No tools required. This is a written exercise.

Scenario: You have been retained by a fictional client, Meridian Financial Partners, a small investment advisory firm with 12 employees, a single-office LAN, a public-facing website hosted by a managed provider, and an on-premises file server. They have never had a penetration test. Your engagement start date is next Monday.

Deliverable: A 1-2 page ROE document covering all components listed in Part 3 of the lecture. Write it as if it is a real document you will hand to the client for a signature.

Grading: See INSTRUCTOR-GUIDE.md labs rubric. Key criteria: is the IP scope defined precisely enough that a second tester could determine in under 30 seconds whether any given target IP is in or out of scope?

Independent practice (~3 hr)

• Reading (1.5 hr): PTES Pre-engagement section (pentest-standard.org/Pre-engagement); read all subsections including Scope Creep and Legal Agreements. Note: some language is dated (the site has not been updated regularly since 2012), but the framework is still the professional standard.
• Reflection (1 hr): Work through the three reflection prompts below before Week 2.
• Toolchain Diary (0.5 hr): Add the first PEN-101 entry. Week 1's "tool" is the ROE document itself -- describe why a written scope document is a practitioner tool in the same sense that Nmap is.

Reflection prompts

1. Weidman notes that a penetration test against a client's website may require separate authorization from the hosting provider, not just the client. Walk through a fictional scenario: your client's web server is on AWS. Describe the specific authorization documents you would need, who issues each, and how long obtaining them might take. What does this tell you about the pre-engagement timeline for a well-scoped engagement?

2. The CFAA has a "exceeds authorized access" clause, not just "without authorization." Look up the case United States v. Nosal (Ninth Circuit, 2011 and 2016). The case turns on whether an employee who accesses systems they are technically authorized to use, for purposes their employer did not authorize, violates the CFAA. What does this precedent imply for a penetration tester who has authorization to scan a network but decides to run additional tests the SOW did not specify?

3. A potential client contacts you and says: "We have a competitor we think is stealing our trade secrets through their website. Can you test their website and see?" Write the one-paragraph response you send. What legal exposure does this request create, and why does the answer not change if the client says "I'll pay double"?

What's next

Week 2 is the first intelligence-gathering phase: OSINT and passive reconnaissance. You will collect everything about the lab target that is publicly available without touching their systems -- WHOIS records, certificate transparency logs, DNS, GitHub, email addresses, job postings. The principle is that an attacker who has not yet decided whether to proceed will spend hours on OSINT before running a single tool. This week's discipline carries forward through every engagement in the course.