CH3: Frameworks, Methodologies, and Reporting

Introduction

A penetration test without structure is just sophisticated chaos. Frameworks and methodologies provide the scaffolding: a shared language for how to approach testing, which areas to prioritize, and how to classify what you find. This chapter covers the major testing frameworks (OSSTMM, CREST, PTES), threat modeling approaches (STRIDE, DREAD, OCTAVE), and how to translate your findings into a report that drives decision-making.

You will learn not just what to find, but how to categorize findings by risk, articulate impact, and present remediation options in ways that different audiences understand. The report is your deliverable. Everything else, the tools, the exploits, the hours spent hunting for vulnerabilities, is the journey to produce it. This chapter teaches you to be organized about that journey and to communicate findings in ways that matter.

By the end, you will understand how professional penetration testers use established frameworks to ensure consistency, manage scope, and deliver findings that clients can act on. You will also understand the limitations and assumptions that shape every assessment.

Learning Objectives

After completing this chapter, you will be able to:

Compare and contrast major penetration testing frameworks (OSSTMM, CREST, PTES) and select an appropriate framework for a given assessment context.
Apply threat modeling methodologies (STRIDE, DREAD, OCTAVE) to prioritize vulnerabilities and articulate risk.
Structure a penetration test report with executive summary, detailed findings, risk scoring, and remediation recommendations.
Calculate CVSS scores and interpret risk severity to communicate findings to technical and non-technical audiences.
Identify testing limitations and document assumptions that constrain the scope and confidence of findings.

3.1 Testing Frameworks and Methodologies

A testing framework is a structured approach to planning, executing, and documenting a penetration test. Multiple frameworks exist, each with different emphasis and rigor. Knowing the major ones allows you to select an approach that fits the engagement type and industry.

OSSTMM (Open Source Security Testing Methodology Manual)

OSSTMM is one of the most detailed and prescriptive frameworks. Developed by Pete Herzog, it emphasizes metrics, scope definition, and positive proof of security (rather than just finding vulnerabilities).

Key characteristics:

Extremely detailed guidelines for every testing phase.
Heavy emphasis on metrics and measurement.
Divides testing into channels (wireless, telecommunications, physical security, data networks, etc.).
Produces a "security test report" with specific metrics.
Free and open source.

Structure:

Scope definition: Explicit definition of assets, channels, and testing depth.
Test execution: Organized by channel with detailed procedures.
Metrics: Quantitative measures of security posture (success rate of exploits, control effectiveness, etc.).
Report: Security test report with graphs, metrics, and analysis.

When to use: Organizations that want detailed, comprehensive testing with measurable outcomes. Financial institutions, government, highly regulated environments. Engagements where the client wants to track improvement over time using consistent metrics.

Strength: Rigor and consistency. OSSTMM-certified testers follow the same methodology, so results are comparable across testers and time.

Limitation: Complexity and time investment. OSSTMM is more prescriptive than clients often need, especially for smaller organizations or shorter engagements.

Reference: See the latest OSSTMM v3 manual for the complete methodology and testing guidance.

CREST (Council of Registered Ethical Security Testers)

CREST is a UK-based certification and framework used heavily in UK and EU engagements. It emphasizes professional standards, credentials, and liability management.

Key characteristics:

Certification-based (CREST-registered testers, CREST-registered companies).
Defined standards for penetration testers, threat testers, and infrastructure testers.
Heavy emphasis on quality assurance, liability, and professional responsibility.
Aligned to ISO 27001 and other standards.
Often required by UK government, financial institutions, and large enterprises.

Structure:

Clear definition of roles (lead tester, support tester, quality assurer).
Defined testing methodology and scope.
Mandatory quality assurance and peer review.
Specific reporting standards.

When to use: UK and EU engagements, especially those requiring CREST certification. Government contracts, highly regulated organizations, engagements where certification is a contractual requirement.

Strength: Professionalism, standardization, and quality assurance. CREST certification is recognized as a high standard in the industry.

Limitation: Certification is expensive and time-intensive. Not as widely used in North America as PTES.

PTES (Penetration Testing Execution Standard)

PTES is a collaborative effort (created by the PTES organization) to define a standard methodology for penetration testing. It is practical, widely adopted, and forms the basis for CompTIA PenTest+ objectives.

Key characteristics:

Practical and less prescriptive than OSSTMM.
Organized into seven phases (pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting).
Emphasis on methodology repeatability without over-specification.
Free and open.
Aligned to real-world practice.

Structure:

Pre-Engagement: Define scope, agreements, rules of engagement.
Intelligence Gathering: Reconnaissance and OSINT.
Threat Modeling: Identify potential attack paths based on reconnaissance.
Vulnerability Analysis: Active scanning and enumeration.
Exploitation: Execute attacks; test controls.
Post-Exploitation: Maintain access, gather evidence, test data protection.
Reporting: Document findings and provide remediation guidance.

When to use: Most commercial engagements. PTES is the de facto standard for penetration testing in North America and globally. It is practical, well-documented, and widely understood.

Strength: Balance of rigor and practicality. PTES is comprehensive without being overwhelming.

Limitation: Less specific than OSSTMM on metrics; not a certification standard like CREST.

Reference: See the PTES website for the complete Penetration Testing Execution Standard.

MITRE ATT&CK Framework

While OSSTMM, CREST, and PTES are testing methodologies, MITRE ATT&CK is a adversary behavior framework. It documents known attack techniques used by real-world threat actors, organized by tactic (reconnaissance, execution, persistence, lateral movement, etc.).

Reference: Visit the MITRE ATT&CK website for the current knowledge base of adversary tactics and techniques.

Key characteristics:

Comprehensive taxonomy of attacker techniques (thousands of techniques across 14 tactics).
Mapped to real-world campaigns and threat actors.
Useful for red teaming and strategic testing.
Helps prioritize which vulnerabilities matter most (those exploited by known threat actors).

Structure:

Tactics: High-level attack goals (Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact).
Techniques: Specific methods to accomplish each tactic.
Sub-techniques: Variations or specific implementations.

When to use: To understand which vulnerabilities align with known attacker behavior. If ATT&CK identifies that a threat actor targeting your industry exploits a specific vulnerability, that vulnerability becomes a higher priority.

Using ATT&CK in a Penetration Test Report

A thorough penetration test report can map the tester's observed tactics, techniques, and procedures (TTPs) to MITRE ATT&CK. This gives the client more than a list of vulnerabilities: it shows how an attacker could move through the environment and which defensive controls should have detected or prevented each step.

For each mapped behavior, the report should identify:

The observed action and the evidence supporting it.
The ATT&CK tactic, technique, and sub-technique, when one exists.
The affected asset, account, or control.
The security impact and recommended detection or remediation.
Relevant threat groups or campaigns that use similar behavior against the client's industry or sector.

Threat-group references provide threat-informed context, not proof that a particular group conducted the test or would be the attacker. The report should avoid attributing activity based only on a technique. Instead, compare the finding with current ATT&CK group profiles and the client's sector threat intelligence, and explain why the comparison affects prioritization.

Example finding: Successful password spraying against an external VPN

During testing of the healthcare organization's internet-facing VPN, the testers performed the explicitly authorized password-spraying checks defined in the ROE. One test account accepted a commonly reused password, allowing the testers to authenticate to the VPN. No patient data was accessed, and testing stopped after access was verified.

The report could map this finding as follows:

Observed behavior	ATT&CK mapping	Report significance
Repeated a small set of passwords across many accounts	Credential Access: T1110.003, Password Spraying	Weak password controls enabled credential compromise without targeting one account with repeated guesses.
Authenticated to the internet-facing VPN with the discovered account	Initial Access: T1133, External Remote Services; Defense Evasion/Credential Access: T1078, Valid Accounts	An attacker could use the valid account to enter the environment through a remote access service.

Because ransomware and intrusion groups have targeted healthcare and other high-value sectors using stolen or weak credentials and external remote services, the client should compare this path with relevant ATT&CK group profiles and sector intelligence. Recommended remediation might include phishing-resistant multifactor authentication for VPN access, password screening, rate and reputation controls, disabling unnecessary accounts, and alerts for unusual VPN logins. The report should clearly label these as defensive priorities, not as evidence that a named threat group performed the activity.

Framework	Best For	Prescriptive	Free	Certification
OSSTMM	Comprehensive metrics; regulated industries	Very	Yes	No
CREST	UK/EU; government; highly regulated	High	No	Yes
PTES	Commercial engagements; North America	Moderate	Yes	No
MITRE ATT&CK	Threat-focused testing; red teaming	Low	Yes	No

3.2 Threat Modeling: Prioritizing Vulnerabilities

Not all vulnerabilities are equally dangerous. Threat modeling helps you identify which vulnerabilities matter most based on likelihood of exploitation and impact.

Threat Modeling Overview

Threat modeling is a structured way to examine a system from an attacker's perspective before deciding which security tests deserve attention. It connects the environment, potential attack paths, security controls, and business impact. A threat model is not a vulnerability scan; it is a reasoned picture of what could go wrong and why.

The OWASP Threat Modeling Process describes four core steps:

Scope your work: First understand the environment. Identify the applications, infrastructure, data stores, users, external dependencies, entry points, assets, and trust or privilege boundaries. A data flow diagram (DFD) is especially useful here: it shows how data moves between users, services, processes, and stores, and where it crosses a trust boundary. Without this picture, testers may overlook an important attack path, spend time on irrelevant components, or misunderstand which system owns a security control. The agreed scope should identify which of these components and flows are included in the penetration test.
Determine threats: Examine each component, data flow, and trust boundary from an attacker's perspective. Ask what could be spoofed, tampered with, disclosed, disrupted, or abused to gain privilege. STRIDE (which we cover next), MITRE ATT&CK, threat trees, and abuse cases can provide a repeatable way to identify and organize these threats.
Determine countermeasures and mitigation: Identify the controls that prevent or reduce each threat, such as multifactor authentication, authorization checks, encryption, logging, segmentation, and rate limiting. This is what would eventually go into your report.
Assess your work: Review whether the model is complete and useful. Confirm that the diagram, threat list, controls, assumptions, and remaining risks are documented, reviewed by the appropriate owners, and connected to testing and remediation priorities.

For a penetration tester, this process turns reconnaissance and architecture information into a prioritized test plan. The DFD and threat model also make the report easier to explain: a finding can be tied to a specific entry point, data flow, asset, trust boundary, threat, and control rather than presented as an isolated technical defect.

STRIDE Threat Modeling

STRIDE is a threat modeling methodology developed by Microsoft. It identifies six categories of threats:

Spoofing: Attacker impersonates a legitimate user or system (authentication bypass).
Tampering: Attacker modifies data in transit or at rest (data integrity attack).
Repudiation: Attacker denies performing an action and cannot be proven to have done so (audit bypass).
Information Disclosure: Attacker gains unauthorized access to sensitive data (confidentiality breach).
Denial of Service: Attacker disrupts availability (system crash, overload).
Elevation of Privilege: Attacker gains unauthorized higher-level access (privilege escalation).

How to apply STRIDE:

Map the application or system architecture.
For each component, ask: "What STRIDE threats apply?"
Identify vulnerabilities that enable each threat.
Prioritize based on likelihood and impact.

Example (web application):

Authentication module: Risk of Spoofing (weak password policy), Elevation of Privilege (session fixation), Information Disclosure (password not hashed).
Database: Risk of Information Disclosure (SQL injection), Tampering (unencrypted updates), Denial of Service (unbounded queries).
API: Risk of Elevation of Privilege (broken authorization), Tampering (unsigned requests), Information Disclosure (API keys in logs).

STRIDE helps organize threat thinking by category rather than random vulnerability hunting.

DREAD Risk Scoring

DREAD is a risk scoring model that rates each threat across five dimensions:

Damage: How severe is the impact if exploited? (1–10 scale)
Reproducibility: How easily can an attacker reproduce the exploit? (1–10)
Exploitability: How much skill/effort is required to exploit? (1–10)
Affected users: How many users are impacted? (1–10)
Discoverability: How easily can an attacker find the vulnerability? (1–10)

Calculate DREAD score:

DREAD Score = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5

Interpretation:

Score 1–3: Low risk. Might not be worth fixing immediately.
Score 4–6: Medium risk. Should be addressed in routine patching cycles.
Score 7–8: High risk. Should be prioritized.
Score 9–10: Critical risk. Fix immediately.

These severity bands are illustrative rather than universal. Organizations should define their own thresholds and apply them consistently. Because DREAD ratings depend on human judgment, use the result as a discussion and prioritization aid rather than the sole basis for remediation decisions.

Example (SQL Injection vulnerability):

Damage: 10 (attacker can access all database records, including customer PII)
Reproducibility: 9 (once exploited, consistent results)
Exploitability: 7 (requires some SQL knowledge but tools exist)
Affected users: 10 (all users on the system)
Discoverability: 9 (easy to find with automated scanners or manual testing)

DREAD Score = (10 + 9 + 7 + 10 + 9) / 5 = 9.0 (Critical)

DREAD is useful because it forces you to think about multiple dimensions of risk, not just impact. However, some practitioners consider it a legacy risk model because its ratings can be subjective and different assessors may produce inconsistent results.

Exam Objective vs. Current Practice

DREAD is still listed as an exam objective for CompTIA PenTest+, so you should understand the acronym, dimensions, formula, and interpretation for exam purposes. In professional practice, teams may supplement or replace DREAD with the Common Vulnerability Scoring System (CVSS). CVSS base metrics describe intrinsic vulnerability severity, while temporal metrics account for factors such as exploit maturity and remediation status, and environmental metrics adjust the score for the specific organization's assets, controls, and business context. Those adjustments can produce a more useful vulnerability-prioritization score than a generic DREAD rating, but neither model replaces documented business-impact analysis.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

OCTAVE is a threat modeling framework that focuses on organizational context. Instead of starting with technical vulnerabilities, you start with:

Assets: What does the organization care about most? (customer data, proprietary code, operational availability?)
Threats: What real-world threats target those assets? (state actors, competitors, opportunistic criminals?)
Vulnerabilities: Which vulnerabilities enable those threats?

When to use: Strategic assessments, red teaming, or when you need to align testing to organizational risk appetite rather than just finding all vulnerabilities.

Advantage: Ensures testing focuses on what matters to the business, not just comprehensive vulnerability lists.

Comparative Example: One Vulnerability, Three Models

Vulnerability: Unpatched Apache server running on the web tier (CVE-2022-XXXX, remote code execution).

STRIDE perspective: - Enables Execution (remote code execution) and Elevation of Privilege (if web server runs as root).

DREAD perspective: - Damage: 10 (full server compromise). - Reproducibility: 10 (public exploit exists). - Exploitability: 8 (requires sending malicious request; tools available). - Affected users: 5 (impacts web application, not all users directly; depends on application architecture). - Discoverability: 9 (banner grabbing reveals version immediately). - Score: (10+10+8+5+9)/5 = 8.4 (High/Critical)

OCTAVE perspective: - Asset: Web application and customer data. - Threat: External attacker seeking customer data access. - Vulnerability: Unpatched Apache enables entry point. - Priority: Critical (direct threat to core business asset).

All three models arrive at the same conclusion (this is critical), but they frame the reasoning differently. Use the model that fits your engagement and stakeholder expectations.

3.3 Report Structure and Deliverables

The report is your primary deliverable. Everything else (reconnaissance, scanning, exploitation) is work that produces the report. A good report:

Is clear and actionable.
Separates technical detail from business impact.
Prioritizes findings by severity.
Provides remediation guidance.
Supports different audiences (CTO, CISO, CFO, developers).

Report Components

Executive Summary (1–3 pages, non-technical)

The executive summary is read by leadership who do not need technical depth. Include:

Test objective: What were you testing and why?
Testing scope: High-level (production web application, internal network, etc.).
Overall risk posture: Based on findings, is the organization at high, medium, or low risk?
Key findings summary: 3–5 most critical findings in business terms (customer data exposure, regulatory violation risk, operational disruption risk).
High-level remediation: Investment estimate, timeline, priority.

Example opening paragraph:

"This engagement tested the security posture of Company XYZ's web application and internal network infrastructure. During a two-week assessment, we identified 23 vulnerabilities, including five critical issues that could allow an attacker to access customer data, escalate privileges, or disrupt operations. Remediation of critical findings is recommended within 30 days."

Notice: No technical jargon. Clear impact. Clear timeline. Ready for a board presentation.

Methodology Section (1–2 pages)

Briefly describe your approach:

Framework: PTES, OSSTMM, or custom methodology.
Phases: Intelligence gathering, scanning, exploitation, post-exploitation.
Tools used: Nmap, Burp Suite, Metasploit, etc.
Scope: Systems tested, exclusions, constraints.
Timeline: Dates, duration.
Type: Black box, white box, gray box.

This establishes credibility and allows the client to understand your approach.

Detailed Findings Section (5–20 pages, depending on complexity)

This is the technical core. For each finding:

Finding ID and Title: "F-001: SQL Injection in User Registration Form"
Severity: Critical, High, Medium, Low (use CVSS or similar).
CVSS Score: (see section 3.4).
Description: What the vulnerability is, in clear language.
Proof of concept: How you found it and reproduced it. Include screenshots or command output (sanitized if necessary).
Impact: What an attacker could do. Business impact.
Affected systems: Which specific systems, versions, or paths.
Remediation: How to fix it, with references to CWE/CVE if applicable.
Verification: How to test that the fix works.

Example finding:

FINDING F-001: SQL Injection in User Registration Form
Severity: CRITICAL (CVSS 9.1)

DESCRIPTION:
The user registration form at https://app.company.com/register does not sanitize
user input before passing it to the database. An attacker can inject arbitrary SQL
to extract data, modify records, or execute administrative commands.

PROOF OF CONCEPT:
When submitting the registration form with Username: ' OR '1'='1
the application returns all users from the database, confirming SQL injection.

IMPACT:
An attacker can:
- Extract all customer records (names, emails, password hashes)
- Modify user accounts (privilege escalation)
- Execute database-level commands (potential full database compromise)
This represents a direct threat to customer data confidentiality and integrity.

AFFECTED SYSTEMS:
- Production: app.company.com /register endpoint
- Also present in /login, /password-reset endpoints

REMEDIATION:
Use parameterized queries (prepared statements) for all database interactions.
Example (Python): cursor.execute("SELECT * FROM users WHERE email = %s", (user_email,))
Do NOT concatenate user input into SQL queries.

VERIFICATION:
After remediation, retry the injection payload ' OR '1'='1'. The application
should reject the input or return no results rather than returning the full user list.

This format is clear, technical, and actionable. A developer can read it and know exactly what to fix.

Attack Narrative (optional but valuable)

For complex engagements, include a narrative showing how vulnerabilities chain together:

"An attacker could gain initial access by exploiting the SQL injection in the login form (F-001), extracting password hashes, then using an offline dictionary attack (supported by weak password policy, F-005). Once logged in, the attacker could exploit the directory traversal vulnerability (F-008) to access the admin panel, then escalate privileges using the unpatched kernel vulnerability (F-012) to gain full server access."

This shows how vulnerabilities compound and helps justify why seemingly minor issues matter.

Recommendations Section (1–2 pages)

Summarize remediation by priority:

Critical (fix within 30 days): List all critical findings with order of operations (some fixes depend on others).
High (fix within 90 days): Medium-term roadmap.
Medium/Low: Routine patching and development cycles.

Include investment estimate: "Critical findings will require approximately 40 developer hours to remediate, estimated at $X cost."

Appendices

Finding summary table: One-page table listing all findings with severity, affected systems, status.
CVSS scoring methodology: Explain how you scored findings.
Tools and techniques used: References for reproducibility.
Scope and limitations: What you tested, what you did not, and why (see section 3.5).

Report Formats and Distribution

Format:

PDF for formal distribution (executive summary, recommendations, some findings).
Word document for technical team (detailed findings, appendices, full technical depth).
Sometimes an online portal or dashboard (for larger organizations managing multiple assessments).

Distribution:

Executive summary: Board, C-suite, customer-facing stakeholders.
Technical details: IT, security team, development team.
Sensitive findings (specific CVEs, exploitation techniques): Limited distribution, need-to-know basis.

Confidentiality:

All reports should be marked "Confidential" and watermarked with recipient information. Do not email unencrypted reports through public email. Deliver via secure channel (encrypted email, secure file transfer, in-person handoff).

Information Security

A penetration test report contains detailed information about vulnerabilities, exploitation techniques, and system architecture. If the report is leaked, it becomes a roadmap for attackers. Treat it with the same confidentiality as you would financial records or customer data.

3.4 Risk Scoring: CVSS

CVSS (Common Vulnerability Scoring System) is the industry standard for vulnerability severity. It produces a score from 0.0–10.0 and a rating (None, Low, Medium, High, Critical).

Reference: See the official FIRST.org CVSS resources for the current specifications, calculators, and guidance for CVSS v3.1 and v4.0.

CVSS v3.1 Components

CVSS v3.1 scores vulnerabilities across three groups:

Base Score (what the vulnerability is): - Attack Vector (AV): Can the attack be launched over the network (N) or does it require physical access (P)? Ranges from N (network) to P (physical). - Attack Complexity (AC): Is the attack simple (L) or complex (H)? - Privileges Required (PR): Does the attacker need no privileges (N), low privileges (L), or high privileges (H)? - User Interaction (UI): Is user interaction required (R) or not (N)? - Confidentiality/Integrity/Availability (C/I/A): Does the vulnerability impact confidentiality, integrity, or availability of data/systems? High (H), Low (L), or None (N).

Temporal Score (how the vulnerability evolves): - Exploit Code Maturity: Is working exploit code available? - Remediation Level: Has the vendor issued a patch? - Report Confidence: How confident are you that the vulnerability exists?

Environmental Score (organization-specific impact): - Modified base score for your specific systems. - Security requirements (do you have extra-high confidentiality/integrity/availability requirements?).

CVSS v4.0: What Changed?

CVSS v4.0 is the newer version of the Common Vulnerability Scoring System. This chapter focuses on v3.1 because it remains important for exam preparation and because many vulnerability databases and organizational processes still use it. However, testers should recognize v4.0 when reading current advisories or preparing new reports.

The most important changes from v3.1 are:

Metric groups were renamed and reorganized: The Base group remains the foundation. The v3.1 Temporal group is now the Threat group, which currently focuses on Exploit Maturity. Environmental metrics remain available for organization-specific adjustments. v4.0 also adds Supplemental metrics for additional context, such as safety, automation, recovery, and value density; these do not directly change the CVSS numeric score.
The Scope metric was removed: v3.1 used Scope to indicate whether an exploit crossed a security authority boundary. v4.0 instead separates impact on the directly vulnerable system (Vulnerable System Confidentiality, Integrity, and Availability) from impact on other affected systems (Subsequent System Confidentiality, Integrity, and Availability).
Attack Requirements were added: The AT metric captures whether a separate condition, such as a specific configuration or race condition, must exist for exploitation. This is distinct from Attack Complexity, which describes the complexity of carrying out the exploit.
User Interaction was expanded: v4.0 distinguishes None, Passive, and Active interaction. Passive interaction occurs without the user making a deliberate decision, while active interaction requires the user to take a specific action.
Terminology and scoring guidance were refined: v4.0 uses more precise metric definitions and vector notation to improve consistency between analysts. The score still ranges from 0.0 to 10.0, and the familiar None, Low, Medium, High, and Critical severity bands remain.

Example: A vulnerability in a web application might compromise the application server and expose its database. In CVSS v3.1, the analyst may represent the cross-boundary effect with Scope: Changed and score the overall Confidentiality, Integrity, and Availability impact. In CVSS v4.0, the analyst records the application's impact as Vulnerable System impact and the database impact separately as Subsequent System impact. This makes the attack path and affected systems more explicit.

When reporting a finding, state which CVSS version and vector you used. Do not compare a v3.1 score and a v4.0 score as if they were directly interchangeable; explain the version, assumptions, and environmental context behind each score. For a current assessment, v4.0 may provide a more descriptive model, while v3.1 may be required for a client's compliance process or exam context.

Calculating CVSS

The full calculation is complex (involves weighted formulas), but major vulnerability databases (CVE, NVD) publish pre-calculated CVSS scores. You typically use those rather than calculating from scratch.

However, understanding the components helps you interpret severity:

Example 1: SQL Injection (Critical) - AV: Network (attacker over internet) - AC: Low (straightforward to exploit) - PR: None (no authentication required) - UI: None (no user interaction required) - C/I/A: High/High/High (full database compromise possible) - CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Result: CVSS 9.8 (Critical)

Example 2: Local Privilege Escalation (High) - AV: Local (attacker already has shell access) - AC: Low - PR: Low (attacker has user-level access) - UI: None - C/I/A: High/High/High - CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - Result: CVSS 8.8 (High)

Example 3: Weak TLS Configuration (Medium) - AV: Network - AC: High (requires specific conditions or tools) - PR: None - UI: None - C: High (data in transit could be decrypted), I: Low, A: None - CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N - Result: CVSS 6.5 (Medium)

Interpreting CVSS Ratings

CVSS Score	Rating	Typical Response
0.0	None	Informational; no action required
0.1–3.9	Low	Document; fix during routine updates
4.0–6.9	Medium	Fix within 90 days
7.0–8.9	High	Fix within 30 days
9.0–10.0	Critical	Fix immediately (within days)

Use these as guidelines, not absolutes. An organization's risk tolerance may be different (some may fix all High-severity findings immediately; others may deprioritize based on business context).

Analyst Perspective

When presenting CVSS scores to non-technical stakeholders, translate: "This is a Critical vulnerability (9.8 score). It means an attacker can remotely compromise the system without any special access or user interaction. We recommend immediate remediation."

3.5 Testing Limitations and Assumptions

Every penetration test has limitations. A good report acknowledges them.

Common Limitations

Scope limitations: - "Testing was limited to in-scope systems. Systems outside the defined scope (production database, payment processing infrastructure) were not tested." - "Wireless testing was limited to the company's premises. Remote sites or traveling employees' devices were not assessed."

Time and resource limitations: - "This was a two-week assessment. Additional time would have allowed deeper exploration of identified attack paths." - "Testing focused on critical and high-risk systems. Medium and low-risk systems received lighter assessment."

Access limitations: - "As a gray box test, we operated from a user-level account. A full insider threat assessment would require testing from administrative access." - "Third-party systems (SaaS platforms, cloud providers) were tested only insofar as customer configuration; vendor infrastructure is outside of customer control."

Technical limitations: - "Some findings could not be fully exploited due to scope constraints. For example, privilege escalation was tested on staging systems, not production." - "Social engineering and phishing were not included in scope. Real-world attack chains often start with these techniques."

Assumptions

State what you assumed to be true:

"We assumed that all provided credentials were valid and represented the claimed privilege level."
"We assumed that systems would remain available and unchanged during the testing period."
"We assumed that network connectivity and DNS resolution would function normally."
"We assumed that legacy systems (Windows Server 2008, etc.) were intentionally retained and part of the testing scope."

Assumptions matter because if one is violated, the findings may not be reliable.

Example: "Our testing assumed that the company's internal network is isolated from the internet. If security appliances were misconfigured and internal systems are actually exposed to external internet traffic, the risk of the identified vulnerabilities would be higher than assessed."

What Negative Results Mean (and Don't Mean)

A clean report, no findings, does not mean the organization is perfectly secure. It means:

"Within the defined scope and testing methodology, no vulnerabilities of High severity or above were identified."
It does NOT mean there are no vulnerabilities (only that we did not find any).
It does NOT mean the organization is immune to all attacks (only that common attack paths were not successful).

Include language like: "The absence of identified vulnerabilities does not guarantee security. Vulnerabilities may exist outside of scope, in systems not tested, or using attack techniques not included in our methodology."

Putting It Together: From Findings to Report

You complete a two-week penetration test and have identified 18 vulnerabilities across network and web application infrastructure. You scored them using CVSS, organized them by severity, and now need to write the report.

Your process:

Create an executive summary (1 page):
"Testing identified 18 vulnerabilities, including two critical findings affecting customer data and system availability."
Recommend immediate patching of critical findings, 30-day remediation for high-severity issues.
Detail critical findings (2–3 pages):
SQL injection in web application (CVSS 9.8).
Unpatched RCE vulnerability in internal service (CVSS 9.2).
Each with proof of concept, impact, and remediation steps.
Create findings summary table:
One-page reference showing all 18 findings, severity, affected systems.
Write attack narrative (1 page):
"An external attacker could exploit the SQL injection to extract customer data, then use that data to compromise internal accounts, and escalate privileges to access operational systems."
Include recommendations (1 page):
Critical: 2 findings, 40 hours effort, $X cost, 30 days.
High: 5 findings, 60 hours effort, $Y cost, 90 days.
Medium/Low: 11 findings, routine patching.
Appendix:
Methodology: PTES phases, tools (Nmap, Burp, Metasploit).
Scope: What was tested, what was excluded, why.
Timeline: October 15–29, 2026; Monday–Friday, 9 AM–5 PM.
Deliver via secure channel.
Email (PDF watermarked and encrypted).
Presentation to IT team: Technical findings, remediation, timeline.

The report transforms your two weeks of work into a clear, actionable document that drives remediation decisions.

Chapter Summary

OSSTMM emphasizes metrics and comprehensive testing; CREST emphasizes professional standards and certification; PTES balances rigor with practicality. Choose based on engagement context and client expectations.
MITRE ATT&CK helps prioritize vulnerabilities based on real-world threat actor behavior.
STRIDE threat modeling identifies six categories of threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
DREAD scoring rates vulnerabilities across five dimensions (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) to prioritize remediation.
OCTAVE starts with organizational assets and threats rather than technical vulnerabilities, aligning testing to business context.
CVSS provides standardized severity scoring from 0.0–10.0, with ratings (Critical, High, Medium, Low, None) that guide remediation timeline.
Reports must serve multiple audiences: executive summary for leadership, technical details for developers and security teams.
Limitations and assumptions should be documented to set realistic expectations about what the test covered and what it did not.