Penetration Test Types and Rules of Engagement

Pen Test vs Vulnerability Scan

A penetration test is an authorized, goal-oriented attempt to identify and validate exploitable weaknesses. It differs from a vulnerability scan, which only discovers and rates weaknesses without exploiting them. A pen test may chain several low findings into a high-impact compromise, test whether defenders detect the activity, and demonstrate concrete business impact. The objective is controlled proof, never uncontrolled disruption.

Security+ expects you to know the standard phases: planning/ROE, reconnaissance (passive open-source intelligence vs active scanning), scanning/enumeration, exploitation/gaining access, post-exploitation (lateral movement, privilege escalation, persistence), and reporting/cleanup. Cleanup matters legally and operationally: testers must remove any planted accounts, tools, shells, and persistence mechanisms so the engagement does not leave the environment more vulnerable than it found it.

Closely related but distinct exercises also appear on the exam. A red team simulates an adversary covertly over a longer campaign and is often goal-driven ("reach the customer database"). A blue team defends and detects. A purple team is a collaborative exercise where attackers and defenders share information in real time to improve detection. A bug bounty crowdsources external researchers under a published policy. Knowing which exercise fits a goal — covert adversary emulation versus broad coverage versus continuous external testing — is a common scenario question.

Knowledge and Environment Types

Reconnaissance splits into passive (WHOIS, public records, social media, certificate transparency logs — no packets to the target) and active (port scans, banner grabbing, service fingerprinting — detectable on the target). Black-box tests rely heavily on recon to build a picture of the attack surface; white-box tests skip much of it because the information is provided up front.

The trade-off is realism versus efficiency: black-box best simulates a real outsider but spends budget rediscovering facts a white-box tester already has, while white-box maximizes coverage of the actual codebase and configuration at the cost of attacker realism. Gray-box is the common compromise, mirroring an attacker who already phished one standard user account.

Rules of Engagement

Rules of engagement (ROE) set the boundaries that protect the organization, testers, customers, and production systems. Supporting agreements you should recognize include the statement of work (SOW), master service agreement (MSA), and non-disclosure agreement (NDA). Common ROE elements:

• Written authorization and the approving authority.
• In-scope and explicitly out-of-scope systems and IP ranges.
• Testing dates, time windows, and blackout periods.
• Allowed and prohibited techniques.
• Social engineering and phishing permissions or restrictions.
• Data handling for captured credentials and files.
• Safety limits for denial-of-service, destructive actions, and persistence.
• Emergency contacts and a stop-test ("abort") procedure.
• Evidence, report format, and remediation-meeting expectations.

The ROE should also define a deconfliction process so that real attacks during the test window are not mistaken for the testers, and vice versa. A get-out-of-jail-letter (signed authorization the tester carries) protects on-site personnel performing physical social engineering. Without these agreements, attempting access can violate computer-misuse and trespass laws regardless of intent.

Scenario

A regional bank hires a firm to assess its online loan portal. The ROE permits authentication, authorization, input-validation, and session testing, plus controlled exploitation in staging. Production is limited to non-destructive validation during a weekend window. Denial-of-service, customer-account modification, and persistence are prohibited, and testers must call the security operations bridge before each window.

During testing the team finds that an authenticated user can change a numeric account parameter and view another applicant's income document — an insecure direct object reference / broken object-level authorization. The report includes the affected endpoint, proof using test accounts, business impact, reproduction steps, log timestamps, and remediation to enforce object-level authorization checks server-side.

Reporting, Retesting, and Common Traps

A useful report includes an executive summary, scope and methodology, per-finding severity and business impact, technical evidence and reproduction steps, the exploitation chain, affected assets, remediation recommendations, and retest results after fixes. Severity often uses CVSS (Common Vulnerability Scoring System) scores mapped to business context — a critical CVSS finding on an isolated lab box may rate lower in business terms than a medium finding on an internet-facing payment system.

The executive summary is written for non-technical leadership and focuses on risk and required investment, while the technical body gives engineers enough detail to reproduce and fix each issue. After remediation, the retest (sometimes called validation testing) confirms the fix actually closed the issue rather than merely hiding the symptom, and closes the engagement loop.

• Running tests without written authorization.
• Performing destructive production actions without approval.
• Confusing a vulnerability scan with a penetration test.
• Reporting jargon with no business impact.
• Omitting data-handling rules for captured secrets.
• Letting scope creep happen informally mid-engagement.