1.1 The Penetration Testing Engagement Lifecycle & Scoping

1.1 The Penetration Testing Engagement Lifecycle & Scoping

Penetration testing is a structured, authorized, and methodical evaluation of an organization's security posture through the simulated execution of real-world adversarial attacks. Within the CREST Practitioner Security Analyst (CPSA) curriculum, technical testing cannot be divorced from its legal, operational, and managerial framework. Uncontrolled testing risks severe business disruption, legal liability, and invalid test results. A rigorous methodology ensures assessments deliver measurable security improvements while safeguarding system integrity.

---

The Penetration Testing Engagement Lifecycle

A professional penetration test progresses through three distinct, interdependent phases: Pre-Engagement, Engagement (Execution), and Post-Engagement. Each phase possesses defined inputs, activities, and deliverables governed by strict quality and governance standards.

+-----------------------------------------------------------------------------------+
|                           1. PRE-ENGAGEMENT PHASE                                 |
|  Scoping -> Statement of Work (SoW) -> Rules of Engagement (RoE) -> Legal Consent |
+-----------------------------------------------------------------------------------+
                                          |
                                          v
+-----------------------------------------------------------------------------------+
|                         2. ENGAGEMENT / EXECUTION PHASE                           |
|  Reconnaissance -> Enumeration -> Vulnerability Analysis -> Exploitation -> Post-Ex|
+-----------------------------------------------------------------------------------+
                                          |
                                          v
+-----------------------------------------------------------------------------------+
|                           3. POST-ENGAGEMENT PHASE                                |
|  Reporting -> Technical Debrief -> Remediation Verification -> Data Sanitization  |
+-----------------------------------------------------------------------------------+

1. Pre-Engagement Phase

The pre-engagement phase establishes the technical, operational, and legal foundations of the project before a single network packet is transmitted.

• Scoping Meetings: Consultants and client stakeholders identify the business drivers, regulatory requirements (such as PCI DSS, ISO/IEC 27001, or UK Cyber Essentials Plus), target environments, and test objectives.
• Contractual Instruments: Execution of the Non-Disclosure Agreement (NDA) to protect proprietary client information, the Master Services Agreement (MSA) defining commercial terms, and the Statement of Work (SoW) detailing specific deliverables, billable days, and milestones.
• Rules of Engagement (RoE): Formalization of operational constraints, testing windows, emergency contact protocols, and authorized methodologies.
• Third-Party Authorizations: Securing explicit written permission from Internet Service Providers (ISPs), colocation facilities, and managed cloud hosting providers.

2. Engagement (Execution) Phase

The execution phase comprises the technical assessment, executed methodically to identify and demonstrate vulnerabilities:

• Reconnaissance (Information Gathering):
  • Passive Reconnaissance: Gathering intelligence without direct packet interaction with target systems. Techniques include Open Source Intelligence (OSINT), analyzing WHOIS databases, DNS query records, certificate transparency logs (crt.sh), employee profiles on professional networks, and historical search engine caches.
  • Active Reconnaissance: Direct engagement with target systems through active DNS zone transfer requests (AXFR), port knocking, and network infrastructure path analysis (traceroute).
• Enumeration & Attack Surface Mapping: Active probing to discover open ports, query listening services, harvest banners, identify operating system fingerprints, and enumerate protocol-specific resources (such as SNMP communities via snmpwalk, Active Directory LDAP trees, SMB shares via crackmapexec/NetExec, and web directories via content discovery tools).
• Vulnerability Identification & Analysis: Combining automated vulnerability scanning (e.g., Nessus, OpenVAS, Burp Suite Professional) with rigorous manual inspection. Testers analyze scan outputs, eliminate false positives, evaluate service patch levels, and identify architectural and business logic flaws that automated tools miss.
• Exploitation: The controlled execution of technical exploits against verified vulnerabilities to prove reachability and real-world impact. Exploitation must be calibrated to remain within agreed scope and safety boundaries, avoiding unstable kernel exploits, system crashes, or uncontained payloads.
• Post-Exploitation: Evaluating the residual impact of unauthorized access. Key activities include local privilege escalation (elevating from low-privileged service accounts to root or SYSTEM), credential harvesting from memory or configuration files, safe lateral movement (pivoting through network segments via SSH tunnels or SOCKS proxies), and assessing data exposure risks without performing unnecessary bulk data extraction.

3. Post-Engagement Phase

The project concludes with communication, verification, and governance:

• Reporting: Authoring a comprehensive, defensible penetration test report featuring both an Executive Summary for leadership and detailed Technical Findings for engineering staff.
• Debriefing & Presentations: Conducting technical debriefs with systems administrators and executive briefings with management to explain findings, risk implications, and strategic remediation roadmaps.
• Remediation Verification (Re-Testing): Re-assessing target systems following client remediation efforts to confirm that reported vulnerabilities have been effectively patched without introducing regressions.
• Project Closure & Sanitization: Securely archiving engagement artifacts according to contractual retention periods, followed by the permanent cryptographic wiping of client evidence, temporary credentials, and local copies of sensitive findings.

---

Scoping Parameters & Complexities

Scoping defines the precise technical boundary separating authorized security testing from potential criminal activity. A scoping document must leave zero ambiguity regarding what assets are included and excluded.

Defining Attack Methodologies

Scoping agreements must define the testing approach:

• Black-Box (Zero-Knowledge) Testing: Testers receive minimal initial information (e.g., a corporate domain name or CIDR block). This simulates an external, opportunistic adversary but carries higher reconnaissance overhead and risks missing deeply buried internal vulnerabilities.
• White-Box (Full-Knowledge) Testing: Testers receive architectural diagrams, source code, network topologies, API documentation, and privileged credentials. This provides comprehensive assurance and maximizes vulnerability discovery within compressed engagement timelines.
• Grey-Box (Partial-Knowledge) Testing: Testers receive standard user-level credentials and high-level architectural outlines, reflecting an attack launched by a malicious insider or a compromised perimeter account.

Third-Party and Cloud Provider Authorizations

Modern enterprise infrastructures rely heavily on Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Penetration testers must understand cloud provider authorization models:

1. Shared Responsibility Model: The cloud service provider (CSP) manages the security of the cloud (physical facilities, virtualization hosts, hypervisors, and core networking), while the client manages security in the cloud (virtual machine configurations, operating systems, applications, data, and access controls).
2. Amazon Web Services (AWS): Under the AWS Customer Support Policy for Penetration Testing, customers and authorized testers may perform penetration tests against user-provisioned AWS services (such as EC2 instances, RDS databases, CloudFront, Lambda, and API Gateways) without prior approval. However, specific activities remain strictly prohibited:
   • Denial of Service (DoS) or Distributed Denial of Service (DDoS) simulations.
   • Stress testing or protocol fuzzing targeting AWS-managed endpoints.
   • Attacking AWS infrastructure, underlying hypervisors, or multi-tenant physical hardware.
   • Attacking Amazon Route 53 DNS servers.
3. Microsoft Azure: Azure's Rules of Engagement permit vulnerability testing against user-owned Azure resources without advance notification. Attacks must not target other tenants, exceed client-owned subscriptions, generate denial of service, or compromise Azure platform infrastructure.
4. Google Cloud Platform (GCP): GCP permits testing against user-deployed virtual resources without pre-authorization, provided tests comply with the GCP Acceptable Use Policy and Terms of Service. Denial of service testing against GCP infrastructure is prohibited.
5. Colocation & Third-Party ISPs: When clients lease physical rack space in colocation data centers or utilize shared hosting, testers must verify that the hosting agreement permits penetration testing over the shared upstream connection. If shared firewall or switching infrastructure sits inline, written authorization from the upstream provider is mandatory.

---

Rules of Engagement (RoE)

The Rules of Engagement (RoE) document operationalizes the project scope. It establishes the detailed procedural protocols that testers and client teams must abide by throughout the assessment window.

+-----------------------------------------------------------------------------------+
|                            RULES OF ENGAGEMENT (RoE)                              |
+-----------------------------------------------------------------------------------+
| 1. Testing Windows:       Permitted active testing hours (e.g., 20:00 - 04:00 UTC)|
| 2. Source IP Whitelist:   Designated static tester egress IPs (e.g., 198.51.100.2)|
| 3. Identification:        Custom HTTP Header: X-CREST-Tester: Audit-2026          |
| 4. Sensitive Thresholds:  Immediate pause if critical database locks or instability|
| 5. Emergency Contacts:    Primary, Secondary, Tertiary technical escalation tree  |
+-----------------------------------------------------------------------------------+

Testing Windows: Operational Trade-offs

The RoE must formally specify the hours during which active network traffic, vulnerability scanning, and exploitation may occur:

• Business Hours Testing (e.g., Monday-Friday, 09:00 - 17:00):
  • Advantages: Client systems administrators, network engineers, and application developers are on-site and readily available to respond immediately if an unstable system crashes. Additionally, internal security monitoring teams can evaluate real-time alerting under standard operating conditions.
  • Disadvantages: Potential production disruption during peak revenue-generating hours; risk of degraded application performance affecting end users.
• Out-of-Hours / Maintenance Windows (e.g., Weeknights 22:00 - 06:00 or Weekends):
  • Advantages: Minimal risk to business operations and active users; aggressive scanning or load testing can be conducted with negligible commercial impact.
  • Disadvantages: Slower response times if a critical server or database fails and requires physical hardware intervention or specialized developer knowledge; tester fatigue during nocturnal testing.
• Timezone Calibration: All testing windows must be explicitly recorded in a standardized reference timezone (e.g., UTC or BST) to prevent catastrophic misalignments across multinational organizations.

Emergency Contact & Escalation Procedures

The RoE must establish a formal, 24/7 communications protocol and call tree:

• Primary Technical Contact: Dedicated systems engineer or SOC analyst who monitors the assessment in real time.
• Secondary Technical Contact: Infrastructure manager or lead architect holding elevated administrative privileges.
• Executive / Management Contact: CISO or Head of Information Security authorized to make commercial and legal risk decisions (e.g., approving an emergency scope expansion or ordering an immediate testing halt).
• Emergency Triggers: The RoE must enumerate precise scenarios requiring immediate testing suspension and phone escalation:
  • Unplanned service outage, severe latency, or database deadlock on production systems.
  • Detection of indicators of compromise (IoC) suggesting an independent, unauthorized third-party threat actor is actively compromising the environment.
  • Discovery of an unauthenticated, critical remote exploit path exposing highly sensitive personal, medical, or financial records.

Source IP Whitelisting & Identification

To ensure auditability and prevent false-positive alert fatigue for the client's Security Operations Center (SOC), the RoE documents tester identification protocols:

• Static Public IP Whitelisting: Testing must originate strictly from static, pre-registered public IP addresses owned or leased by the security testing firm. This enables the client to verify that anomalous network traffic originates from authorized consultants rather than active adversaries.
• Defensive Device Coordination: In collaborative assurance or application-focused testing, the client may whitelist the tester's IP addresses on Web Application Firewalls (WAF), Intrusion Prevention Systems (IPS), and IP rate-limiting appliances. This prevents defensive controls from artificially masking underlying software vulnerabilities that could be discovered by an adversary with unlimited time.
• Custom Header Injection: For web application assessments, testers configure tools (such as Burp Suite) to inject a unique tracking header into all outgoing HTTP requests (e.g., X-Penetration-Tester: CREST-Audit-2026-Eng1). This allows SOC engineers reviewing application server logs to instantly distinguish testing traffic from internet noise.