Security Penetration Testing

# Penetration Testing

> Hire skilled attackers to find the vulnerabilities your automated tools and internal reviews
> miss -- then fix what they find and verify the fixes

## When to Use

- Preparing for the first penetration test of a new application or infrastructure
- Scoping a penetration test engagement and writing the rules of engagement document
- Evaluating whether to use black box, gray box, or white box testing methodology
- Building a remediation tracking process for penetration test findings
- Deciding between penetration testing, vulnerability assessment, and red teaming
- Establishing a bug bounty program as a complement to periodic penetration testing
- Meeting compliance requirements that mandate periodic penetration testing (PCI-DSS, SOC2)

## Threat Context

Automated security tools (SAST, DAST, SCA) catch known vulnerability patterns but cannot find
business logic flaws, complex multi-step attack chains, or novel attack techniques. A DAST
scanner can find reflected XSS in a search field but cannot discover that an attacker can
escalate from a customer account to an admin account by manipulating the order of API calls in
a checkout flow. Penetration testers think like adversaries -- they chain vulnerabilities,
exploit business logic, and find attack paths that no automated tool can model.

The 2023 MOVEit Transfer zero-day (CVE-2023-34362) was a SQL injection vulnerability in a file
transfer application used by thousands of organizations. It was exploited at scale by the Cl0p
ransomware group before a patch was available. Organizations that had conducted thorough
penetration testing of their MOVEit deployments (including testing of the file transfer API
endpoints) had a better chance of discovering the SQL injection vector and implementing WAF rules
or compensating controls before the mass exploitation.

PCI-DSS Requirement 11.3 mandates annual penetration testing and retesting after significant
infrastructure or application changes. SOC2 Trust Services Criteria CC4.1 requires the entity to
evaluate and communicate internal control deficiencies, which penetration testing directly
supports. These are not just compliance checkboxes -- they are minimum expectations for security
assurance.

## Instructions

1. **Define the scope clearly and explicitly.** Scope determines the value of the test. Specify:
   target systems (URLs, IP ranges, APIs, mobile apps), testing methodology (black box: tester
   has no prior knowledge; gray box: tester has user-level credentials and API documentation;
   white box: tester has source code, architecture diagrams, and admin access), in-scope
   vulnerability classes (OWASP Top 10, business logic, API security, authentication bypass,
   privilege escalation), and explicitly out-of-scope systems (production databases with real
   customer data, third-party services, physical security). Gray box testing provides the best
   balance of realism and coverage for most applications.

2. **Establish rules of engagement before testing begins.** The rules of engagement are a legal
   and operational document that protects both parties. Include: written authorization from the
   system owner (without this, penetration testing is a criminal offense in most jurisdictions),
   testing window (dates and hours), communication channels (who to contact if a critical
   vulnerability is found or if the tester causes an outage), data handling requirements
   (how the tester handles any sensitive data encountered during testing -- it should be
   reported but not exfiltrated or retained), rate limits and intensity (to avoid causing
   denial of service), and escalation procedures.

3. **Choose a methodology appropriate to the engagement.** Established methodologies: OWASP
   Testing Guide (comprehensive web application testing methodology, 90+ test cases organized by
   category), PTES (Penetration Testing Execution Standard -- covers pre-engagement through
   reporting), OSSTMM (Open Source Security Testing Methodology Manual -- broad scope including
   human, physical, and digital security). For web applications, the OWASP Testing Guide is the
   most actionable. For comprehensive infrastructure testing, PTES provides better coverage. The
   methodology ensures systematic coverage and prevents the tester from spending all their time
   on one interesting finding while missing other critical vulnerabilities.

4. **Require actionable reporting with severity ratings.** Each finding should include: a
   severity rating (use CVSS or a risk-based rating that considers exploitability and business
   impact), a clear description of the vulnerability, step-by-step reproduction instructions
   (proof of concept), the business impact if exploited, specific remediation guidance (not just
   "fix the vulnerability" but "implement parameterized queries in the getUserById function at
   line 42 of user-controller.js"), and affected systems. The report should distinguish between
   findings that require immediate remediation and those that can be scheduled.

5. **Implement a remediation tracking workflow with SLAs.** Define remediation SLAs by severity:
   critical (actively exploitable, data exposure): 24-72 hours. High (exploitable with some
   complexity): 1-2 weeks. Medium (requires chaining or specific conditions): 30 days. Low
   (informational, defense-in-depth): 90 days. Track remediation in your issue tracker (not in
   the penetration test report). Assign each finding to a team with a specific owner. After
   remediation, request a verification retest from the penetration tester to confirm the fix is
   effective and did not introduce new vulnerabilities. Fix the root cause, not just the symptom.

6. **Distinguish penetration testing from vulnerability assessment and red teaming.** Vulnerability
   assessment: automated scanning plus manual verification, broad coverage, identifies known
   vulnerabilities. Penetration testing: manual exploitation, attempts to chain vulnerabilities
   to achieve specific objectives (access admin panel, exfiltrate data, move laterally).
   Red teaming: extended engagement (weeks to months), simulates a real adversary with specific
   objectives, tests detection and response capabilities as well as prevention. Each serves a
   different purpose. Most organizations need regular vulnerability assessments (monthly),
   periodic penetration tests (annually or after major changes), and occasional red team
   exercises (annually for mature security programs).

7. **Consider a bug bounty program for continuous testing.** Bug bounty programs (HackerOne,
   Bugcrowd, Intigriti, or self-hosted) provide continuous security testing by a large pool of
   researchers. Define a clear scope, reward structure (pay by severity, not by volume), and
   response SLAs. Bug bounties complement but do not replace structured penetration testing --
   bounty hunters optimize for quick wins, not systematic coverage. Start with a private program
   (invited researchers only) and expand to public after the initial surge of findings is
   addressed.

## Details

- **Black box vs gray box vs white box tradeoffs**: Black box (no prior knowledge) simulates an
  external attacker but is inefficient -- the tester spends significant time on reconnaissance
  that the client could provide. Gray box (user credentials, API docs, architecture overview)
  balances realism with efficiency and maximizes vulnerability discovery per hour of testing.
  White box (full source code access) maximizes coverage and is appropriate for security-critical
  applications, but findings may include vulnerabilities that are not practically exploitable.
  For most engagements, gray box provides the best return on investment.

- **OWASP Testing Guide structure**: Organized by category: Information Gathering, Configuration
  and Deployment Management, Identity Management, Authentication, Authorization, Session
  Management, Input Validation, Error Handling, Cryptography, Business Logic, Client-Side.
  Each test case includes a description, how to test, and remediation guidance. Version 4.2 is
  the current release. Use it as a checklist to ensure systematic coverage.

- **CVSS scoring for penetration test findings**: CVSS (Common Vulnerability Scoring System)
  provides a standardized severity score from 0 to 10. CVSS v3.1 components: Attack Vector
  (Network, Adjacent, Local, Physical), Attack Complexity (Low, High), Privileges Required
  (None, Low, High), User Interaction (None, Required), plus Impact metrics (Confidentiality,
  Integrity, Availability). While CVSS is useful for standardization, supplement it with
  business context: a CVSS 7.0 finding in a payment processing system is more urgent than a
  CVSS 9.0 finding in an internal documentation wiki.

- **Remediation verification**: After fixes are deployed, request a targeted retest covering each
  remediated finding. Verify that the fix addresses the root cause (parameterized queries) not
  just the symptom (input filter that can be bypassed). Check for regression: did the fix
  introduce new vulnerabilities or break existing security controls? The retest should be
  included in the original engagement scope and budget.

## Anti-Patterns

1. **Penetration testing as the only security activity.** Relying solely on annual pen tests
   means vulnerabilities introduced between tests are unknown for up to a year. Penetration
   testing is one layer of a defense-in-depth security program that includes threat modeling,
   SAST/DAST in CI, security code review, and security monitoring. A pen test validates the
   effectiveness of these other controls, not replaces them.

2. **Annual pen tests with no interim security testing.** A penetration test is a point-in-time
   assessment. An application that deploys weekly introduces 52 versions between annual pen
   tests. Supplement annual pen tests with continuous automated testing (SAST, DAST, SCA in CI)
   and periodic lightweight assessments after significant changes.

3. **Scope so narrow it misses real attack paths.** Testing only the web application frontend
   while ignoring the API, mobile app, third-party integrations, and internal services. An
   attacker does not respect scope boundaries. If the API is out of scope, the tester cannot
   find the IDOR vulnerability that exposes customer data via a direct API call. Define scope
   based on attack surface, not organizational convenience.

4. **No remediation tracking after the report.** Receiving a penetration test report, reading it,
   and filing it away. Without a formal tracking process, findings are forgotten, remediation
   is never verified, and the next year's pen test finds the same vulnerabilities. Every finding
   must become a tracked issue with an owner, a severity-based SLA, and a verification retest.

5. **Treating the pen test as pass/fail.** A penetration test is a learning opportunity, not an
   exam. "No critical findings" does not mean the application is secure -- it means the tester
   did not find critical vulnerabilities in the time and scope allocated. Review medium and low
   findings for systemic patterns (all medium findings relate to missing input validation?
   That is a training opportunity). Use findings to improve the SDLC, not just to patch
   individual vulnerabilities.

6. **Choosing testers solely on price.** The cheapest penetration test is often an automated
   scan with a cover letter. A skilled tester who spends two weeks manually testing business
   logic will find vulnerabilities that a budget "pen test" running Nessus and OWASP ZAP will
   miss entirely. Evaluate testers on methodology, relevant experience, sample reports, and
   certifications (OSCP, OSCE, GPEN, GXPN), not just cost.