Penetration Testing Methodology and Execution Questions

Overview
Below is a compact KPI set to measure health/effectiveness of a multi‑team penetration testing program. For each metric: purpose, calculation, data sources, and sample target.

1) Coverage (% assets tested)

• Purpose: Ensure scope completeness and risk visibility.
• Calculation: (Unique assets tested in period / Total in asset inventory) × 100
• Data sources: Test management system, CMDB/asset inventory
• Target: ≥ 90% monthly for high‑risk asset groups; ≥ 75% overall quarterly

2) Time‑to‑Remediation (TTR)

• Purpose: Measure speed of fix after vulnerability disclosure.
• Calculation: Median(days from report to remediation) per severity tier
• Data sources: Issue tracker (ticket open/close), remediation verification logs
• Target: Critical ≤ 14 days; High ≤ 30; Medium ≤ 90

3) Severity‑Trend

• Purpose: Detect whether risk posture improves or worsens over time.
• Calculation: % change month-over-month in count of Critical/High findings (normalized by assets tested)
• Data sources: Historical findings database
• Target: Negative trend (decrease) of ≥ 10% QoQ in Critical/High

4) False‑Positive Rate

• Purpose: Assess quality of findings and testing efficiency.
• Calculation: (Findings marked false / Total findings) × 100
• Data sources: Triaged findings, verification notes
• Target: ≤ 5% (investigate if >10%)

5) Mean‑Time‑to‑Detect‑Exploit (MTTDE)

• Purpose: How long before an exploit is discovered/validated in environment
• Calculation: Average(days from vulnerability introduction or disclosure to verified exploit) — use discovery date if known
• Data sources: Change logs, vulnerability disclosure dates, exploit validation records
• Target: ≤ 30 days for public exploits on critical assets

6) Tester‑Efficiency

• Purpose: Measure throughput and productivity adjusted for quality.
• Calculation: (Verified actionable findings per tester per month) and average hours per validated finding
• Data sources: Time tracking, findings DB, verification status
• Target: 8–15 validated findings per tester/month with ≤ 10 hrs per validated finding (varies by scope)

Notes / Best practices

• Segment by asset risk, test type (IAST/blackbox/red team), and team.
• Use dashboards with drilldowns, SLA alerts for TTR, and trend lines for Severity‑Trend.
• Regularly recalibrate targets using historical baseline and business risk appetite.

Clarify requirements & constraints

• 3-month (12-week) program covering discovery, automated scanning, manual testing (by asset buckets), remediation validation, reporting. Goal: maximize coverage while minimizing rework and downtime.

High-level approach

• Build WBS, map dependencies, run critical-path analysis to find minimum duration, add buffers for fixes and retests, and identify parallelizable tasks.

Core components & dependencies

• Tasks (examples): Asset Inventory → Scope Approval → Automated Scanning → Triage → Manual Testing per Bucket (Web, Network, Cloud, AD) → Exploitation/Proofs → Remediation Validation → Reporting & Presentation.
• Dependencies: Scanning depends on inventory+scope; manual testing depends on triage results; remediation validation depends on remediation completion.
• Critical path likely: Inventory → Scanning → Triage → Manual Testing (longest bucket) → Report. Parallelize other buckets and report drafting while tests run.

Buffer strategies

• Add 1–2 week contingency across triage → manual testing for unexpected pivots.
• Timebox manual buckets (e.g., sprint per bucket) with 20% slack for pivot/exploit dev.

Parallel work opportunities

• Parallel scanning of asset classes.
• Multiple testers run separate buckets simultaneously.
• Report writing and remediation guidance drafted continuously (shift-left).

Example WBS fragment (weeks 1–12)

• Week 1: Asset Inventory & Scope Approval — Owner: PM / Lead Tester
• Week 2: Automated Scanning (all assets) — Owner: Scanner Engineer
• Week 3: Triage & Risk Prioritization — Owner: Lead Tester
• Weeks 4–7: Manual Testing per Bucket (Week4 Web, Week5 Network, Week6 Cloud, Week7 AD) — Owners: Tester A/B/C/D (parallel where staffing allows)
• Week 8: Exploitation & PoC Development (contingency for longest bucket) — Owner: Senior Tester
• Week 9: Draft Findings & Interim Remediation Advice — Owner: Report Author
• Week 10: Remediation Validation (re-scan & verify) — Owner: Tester Team
• Week 11: Final Report Writing & Internal Review — Owner: Lead Tester / QA
• Week 12: Presentation to Stakeholders & Close-out — Owner: PM

Trade-offs

• More parallelism shortens calendar time but requires more testers. Longer buffers increase schedule certainty but delay delivery.

This structure yields a clear WBS, a visible critical path (triage → longest manual bucket → validation), and practical buffers while maximizing parallel work.

Overview (brief)
As a penetration tester I rely on a mix of passive OSINT and selectively active techniques. Below I compare Amass, Sublist3r, and assetfinder by sources, strengths/limits, performance, and best-fit use-case.

Amass

• Data sources: CT logs, passive DNS, WHOIS, certificate transparency, third-party APIs, optional brute force/active DNS.
• Strengths/limits: Extremely comprehensive and configurable; supports graphing and active/passive modes. Slower by default, higher noise when brute-forcing. Requires API keys for best results.
• Performance: High coverage, can take minutes–hours depending on options.
• Best fit: Full-scope engagement where you need exhaustive inventory and correlation of assets.

Sublist3r

• Data sources: Public search engines, DNSDumpster, Netcraft, Virustotal, passive services (via plugins).
• Strengths/limits: Fast and simple, good passive discovery; fewer sources than Amass and less extensible. Low noise.
• Performance: Quick results (seconds–minutes).
• Best fit: Rapid reconnaissance during initial scoping where stealth and speed matter.

assetfinder

• Data sources: Simple OSINT lookups (search engines, common certificates), focuses on name permutations.
• Strengths/limits: Lightweight and fast, good at spotting candidate names and wildcard-ish domains; not as thorough with CT logs. Can be combined with wordlists for discovery.
• Performance: Very fast; low resource use.
• Best fit: Quick enumeration to seed brute-force lists or when chaining multiple lightweight tools in automation.

Choice depends on scope, allowed activity, and need for stealth versus coverage.

Scoring method (simple, repeatable)

• Map CVSS (0–10) directly. Map asset criticality to a 0–10 scale (low=2, high=9, critical=10).
• Weighted score = 0.4 * CVSS + 0.6 * AssetCriticality (weight favours business impact).

Example scores:

• A (SQLi on dev): 0.49.8 + 0.62 = 5.12
• B (stored XSS on payment): 0.46.5 + 0.69 = 8.0
• C (missing headers on auth ms): 0.44.3 + 0.610 = 7.72

Prioritization (highest score first)

1. B — Stored XSS on public-facing payment page (Score 8.0)

   • Why: public exposure + payment asset = high business/brand and financial risk; XSS can steal session/payment data or be chained to fraud.
   • Remediation plan (Immediate: 24–72 hrs): validate/encode output, implement input sanitization/whitelisting, Content Security Policy (CSP) as compensating control, WAF rule for payload patterns. Verify with re-test and monitoring.

2. C — Missing security headers on authentication microservice (Score 7.72)

   • Why: auth service is critical and used by multiple products; even low-severity header gaps can enable clickjacking, token leakage, or downgrade attacks at scale.
   • Remediation plan (Immediate: 48–72 hrs): add Strict-Transport-Security, X-Frame-Options / frame-ancestors, X-Content-Type-Options, Referrer-Policy; review cookie flags (Secure, HttpOnly, SameSite). Perform integration tests and staged rollout. Add runtime monitoring/alerts.

3. A — CVSS 9.8 SQL injection on dev server (Score 5.12)

   • Why: very high technical severity but constrained to corporate network and dev environment reduces immediate business impact. However risk exists if dev server is pivot point.
   • Remediation plan (Short-term: 1–2 weeks): fix parameterized queries/ORM usage, input validation, remove sample data with sensitive info. Hardening: network segmentation, restrict access via VPN and least-privilege, rotate creds. Re-scan and attempt exploit in controlled retest.

Validation & governance

• After fixes: retest (pen test / automated scans), CI pipeline checks (SAST/DAST), and ticketed SLAs: B & C = Emergency/High (48–72 hrs), A = Medium (1–2 weeks) with compensating controls until fixed.
• Rationale: scoring balances exploitability and business impact; mitigations emphasize quick controls + permanent fixes and validation.

Approach summary (what I do and why)
I start with a scoped, minimally disruptive enumeration using authenticated context if provided, then escalate depth while avoiding detection/impact. My goals: find hidden dirs/files, respect rate limits, and avoid IPS/IDS triggers.

Tools & wordlists

• Tools: gobuster (fast, flexible), wfuzz (advanced matching), ffuf (concurrency control), dirb/dirbuster for quick checks. Use Burp Intruder for authenticated or complex flows.
• Wordlists: SecLists (Discovery/Web-Content), commoncrawl-derived lists, medium-sized custom lists tuned to app tech (e.g., CMS, frameworks), and a small “low-noise” list for initial probing.

Technique & options

• Start low-noise: ffuf/gobuster with low threads (e.g., 5–10), short timeout, and delay between requests. Use recursion only after safe hits.
• Auth: load session cookies/HTTP auth in tool or use Burp session handling; test authenticated vs unauthenticated differences.
• Rate-limiting / backoff: implement randomized delays, exponential backoff on 429/503, rotate source IPs only if allowed by scope.
• Wildcard/custom error detection: request several random paths (UUIDs); if responses are same size/status, mark as wildcard. Use content matching (hash or regex) rather than just status/size.
• False positives: verify hits by requesting parent paths, checking for unique content, and testing with trailing slash/filename variations.

Safeguards

• Confirm scope and allowed hours; notify client of noisy phases. Monitor server response codes and stop/slow if latency increases or errors spike. Avoid automated high-rate scans, no credential stuffing, and record all actions for audit.