4. Methodologies, Frameworks and Threat Modeling

Introduction and Context

A penetration test is more than a collection of technical attacks. It is a controlled investigation designed to determine whether security controls protect assets against realistic threats, how an attacker might progress through an environment, and what the organization should do about the findings. Without a methodology, testing can become inconsistent, difficult to reproduce, and poorly aligned with business risk.

Methodologies and frameworks provide structure. They define the scope of an engagement, organize evidence collection, guide testing decisions, and support communication with technical and executive stakeholders. Threat modeling complements these methods by asking a prior question: what could an attacker attempt, against which assets, through which paths, and with what consequences?

This chapter examines the Penetration Testing Execution Standard (PTES), NIST SP 800-115, OWASP testing guidance, MITRE ATT&CK, the Cyber Kill Chain, and established threat-modeling approaches. These resources are related but not interchangeable. PTES and NIST primarily organize assessment activities; OWASP provides depth for application testing; ATT&CK describes adversary behavior; the Cyber Kill Chain represents attack progression; and threat modeling helps prioritize what should be tested and why.

Learning Objectives

After studying this chapter, students should be able to:

• distinguish between penetration-testing methodologies, technical knowledge bases, attack models, and threat-modeling methods;
• design a repeatable assessment using PTES or NIST SP 800-115;
• apply OWASP guidance to web and application security testing;
• use MITRE ATT&CK and the Cyber Kill Chain to analyze adversary behavior and defensive coverage;
• construct and interpret threat models using assets, trust boundaries, threats, vulnerabilities, and controls;
• prioritize testing according to likelihood, impact, exploitability, and business context; and
• recognize ethical, governance, evidence-handling, and reporting requirements in professional assessments.

Methodology as a Discipline of Testing

A methodology is a deliberate sequence of activities and decisions. It answers questions such as what authorization is required, how scope is defined, which test types are appropriate, how evidence is recorded, and how findings are communicated. A framework is a structured reference model that helps organize those activities. A knowledge base, such as MITRE ATT&CK, is different: it catalogs observed adversary tactics and techniques rather than prescribing a complete engagement workflow.

A mature assessment normally moves through six logical concerns:

1. Authorization and scope: identify the systems, identities, locations, time windows, prohibited actions, and emergency contacts.

2. Discovery and modeling: understand the organization, technology, business processes, trust relationships, and likely attack surfaces.

3. Validation: test whether vulnerabilities or control weaknesses can actually be used, while limiting harm.

4. Impact analysis: determine what access, data exposure, privilege, persistence, or business consequence is possible.

5. Evidence and interpretation: preserve sufficient evidence to support conclusions without collecting unnecessary sensitive data.

6. Reporting and remediation: explain risk, reproduce findings, assign ownership, and verify corrective action.

The objective is not to maximize the number of vulnerabilities. It is to produce defensible knowledge about material risk.

PTES: From Pre-Engagement to Reporting

The Penetration Testing Execution Standard organizes a penetration test into seven broad phases: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting.

Pre-engagement interactions

This phase establishes the contract and rules of engagement. Scope should identify targets by domain, network range, application, cloud account, physical site, or other unambiguous boundary. The agreement should also address test dates, permitted techniques, social-engineering permissions, denial-of-service restrictions, data handling, third-party authorization, communication procedures, and conditions for suspending the test.

A statement such as “test the corporate network” is inadequate. A useful scope might distinguish production systems from development systems, specify whether wireless networks are included, and identify systems that must not be touched. Authorization is both a legal safeguard and a technical control: it prevents testers from confusing an interesting opportunity with a permitted action.

Intelligence gathering

Intelligence gathering collects information about the target and its environment. Passive activities may include reviewing public records, DNS information, certificate transparency data, public documents, job advertisements, and exposed technology indicators. Active activities may include service discovery, web crawling, or controlled enumeration. The choice depends on authorization and the risk of detection or disruption.

Information should be interpreted rather than merely accumulated. A public hostname matters because it may reveal an externally reachable service; a job advertisement may indicate identity-management technology; a leaked document may disclose naming conventions. Intelligence becomes useful when it informs hypotheses about attack paths.

Threat modeling

PTES places threat modeling before detailed vulnerability analysis. The tester considers likely adversaries, valuable assets, attack surfaces, trust relationships, and business consequences. A criminal group seeking payment may follow a different path from a malicious insider or a politically motivated actor. Threat modeling therefore helps determine where effort should be concentrated.

Vulnerability analysis

Vulnerability analysis identifies weaknesses and evaluates their significance. It may include automated scanning, manual inspection, configuration review, authentication testing, code review, and analysis of exposed services. Scanners generate leads, not final conclusions. False positives, environmental controls, compensating safeguards, and exploit prerequisites must be considered.

Exploitation and post-exploitation

Exploitation validates whether a weakness can produce meaningful access or impact. Professional exploitation is constrained: a tester should use the minimum action needed to demonstrate the issue. Post-exploitation determines the realistic consequences of access, such as privilege escalation, access to sensitive data, lateral movement, or persistence. It should not become uncontrolled collection or unnecessary destruction.

Reporting

PTES emphasizes reporting as an integral phase rather than an administrative afterthought. A useful report contains an executive narrative, scope and limitations, methodology, prioritized findings, technical evidence, affected assets, risk explanation, remediation recommendations, and an appendix of supporting data. A finding should enable a responsible team to reproduce the result and understand how to reduce risk.

NIST SP 800-115 and Repeatable Security Testing

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, presents a structured approach to planning and conducting technical security tests. It distinguishes techniques such as review, target identification and analysis, vulnerability validation, and planning for penetration testing.

The NIST perspective is valuable because it places testing within a broader assessment program. A technical test should be selected according to objectives and risk, not because a particular tool is available. Reviews may examine documentation, policies, architecture, logs, or configuration. Target identification establishes what is exposed and how it behaves. Vulnerability validation determines whether a suspected weakness is credible. Penetration testing then combines information and controlled attack techniques to evaluate practical exploitability.

NIST also encourages a disciplined planning cycle:

• define objectives and scope;
• select appropriate assessment techniques;
• identify logistics, resources, and rules;
• conduct the assessment;
• analyze results and residual risk; and
• report findings and support remediation.

PTES is often more attack-execution oriented, whereas NIST provides a broader assessment and governance perspective. They can be combined: NIST can guide program planning and assurance, while PTES can structure the practical penetration-test workflow.

OWASP Guidance for Application Testing

Web applications require specialized testing because their security depends on business logic, identity flows, session management, APIs, browser behavior, server configuration, and third-party components. OWASP testing guidance provides a knowledge-rich basis for examining these areas.

A web assessment should begin with application mapping. Testers identify roles, workflows, entry points, API endpoints, parameters, file-handling functions, administrative interfaces, and state transitions. Authentication testing examines credential policy, multifactor implementation, account recovery, and resistance to abuse. Authorization testing asks whether one user can access another user’s objects or perform administrative actions. These tests are frequently more significant than a simple search for software versions.

Input and output handling should be assessed for injection risks, cross-site scripting, request forgery, unsafe deserialization, and other context-dependent weaknesses. Session testing examines token generation, expiration, fixation, invalidation, cookie attributes, and concurrent use. Configuration review considers debug features, security headers, error messages, exposed management interfaces, and insecure defaults.

OWASP guidance must not be treated as a checklist that guarantees security. A technically sound application may still contain a business-logic flaw, such as allowing a user to approve their own transaction or bypass a required workflow. Testing must therefore combine automated tools, manual reasoning, role-based analysis, and knowledge of the business process.

Modeling Adversary Behavior: ATT&CK and the Cyber Kill Chain

MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on observed behavior. Tactics represent goals, such as Initial Access, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact. Techniques describe how those goals may be pursued.

ATT&CK supports several assessment activities. A red team can map planned actions to techniques. A blue team can map telemetry and controls to techniques. A risk team can identify detection gaps. During reporting, ATT&CK references provide a common vocabulary, but they should supplement rather than replace a clear explanation of the actual weakness and business impact.

The Cyber Kill Chain, associated with Lockheed Martin, describes an attack as a progression through Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. Its strength is conceptual simplicity: defenders can seek interruption at multiple stages. Its limitation is that modern attacks are not always linear. Cloud compromise, credential abuse, insider activity, and living-off-the-land techniques may bypass or blur several stages.

ATT&CK is generally more detailed and behavior-oriented, while the Kill Chain provides a high-level narrative of progression. Used together, they help testers and defenders ask both “what stage is this activity associated with?” and “which specific technique or control is involved?”

Threat Modeling as a Basis for Risk-Based Testing

Threat modeling is a structured process for anticipating how systems may be attacked or misused. It begins with an understanding of assets, actors, entry points, trust boundaries, data flows, dependencies, and security objectives. The model should include confidentiality, integrity, availability, authenticity, accountability, and privacy where relevant.

A data-flow diagram is particularly useful. It represents external entities, processes, data stores, data flows, and trust boundaries. A boundary crossing deserves attention because authentication, authorization, validation, encryption, or monitoring may be required there. Threats can then be identified using approaches such as STRIDE:

• Spoofing: pretending to be another identity;
• Tampering: modifying data or code without authorization;
• Repudiation: denying an action where reliable evidence is absent;
• Information disclosure: exposing protected information;
• Denial of service: reducing availability;
• Elevation of privilege: obtaining unauthorized authority.

Other approaches emphasize assets and attack paths, misuse cases, abuse stories, or risk scenarios. No single model is universally sufficient. STRIDE is useful for design analysis, while attack trees are useful for expressing how multiple conditions may combine to achieve a goal.

Risk-based prioritization can be expressed conceptually as:

Risk = likelihood × impact

This is not a precise physical law. It is a decision aid. Likelihood may incorporate exposure, attacker capability, exploit maturity, required access, and existing controls. Impact may include financial loss, safety consequences, regulatory exposure, operational disruption, privacy harm, and reputational effects. A low-severity technical weakness may become important when it enables access to a high-value asset or combines with another weakness.

Integrating the Frameworks into an Assessment Workflow

An integrated assessment can proceed as follows. First, establish authorization, objectives, scope, contacts, and safety constraints. Second, create an asset and data-flow view, identify business-critical services, and record trust boundaries. Third, develop threat scenarios and map likely behaviors to ATT&CK tactics and techniques. Fourth, select technical procedures using NIST planning principles, PTES phases, and OWASP guidance where applications are involved. Fifth, execute tests in increasing order of intrusiveness, preserving evidence and monitoring impact. Sixth, analyze attack paths rather than isolated findings. Finally, report results in business language and technical detail, then conduct remediation verification.

This integration prevents a common failure: treating frameworks as competing checklists. A single scenario might be described as follows: an exposed application endpoint permits unauthorized object access; this is an OWASP authorization concern, an ATT&CK Initial Access or Valid Accounts-related opportunity depending on the path, a breach of a trust boundary in the threat model, and a finding discovered during PTES vulnerability analysis and validated through controlled exploitation. Each framework contributes a different perspective.

Illustrative Case Study: Municipal Service Portal

Background

The following is a fictional illustrative case. A municipal authority operates an online service portal through which residents submit applications, upload documents, and track case status. The portal is integrated with an internal case-management system and a cloud identity provider.

Situation and problem

The authority commissions an assessment after a routine review identifies several public API endpoints. The objective is to determine whether an authenticated resident can access another resident’s information and whether compromise of the portal could affect internal services.

Analysis

The team begins with authorization and excludes denial-of-service testing and destructive actions. A data-flow diagram identifies the browser, public API, identity provider, document store, and internal case-management connector. The trust boundary between the public API and internal connector is considered high risk because it carries personal information and privileged service credentials.

Using threat modeling, the team identifies spoofing, information disclosure, and elevation-of-privilege scenarios. OWASP-oriented testing focuses on authentication, authorization, object identifiers, session handling, file upload, and API behavior. ATT&CK mapping is used to describe possible follow-on behavior if valid credentials or sensitive records are obtained.

Approach and solution

The tester creates two authorized low-privilege test accounts and compares requests made by each account. An object identifier in a case-status request can be changed from one test value to another. The server returns another user’s record because authorization is checked at login but not consistently at the object level. The tester stops after retrieving only synthetic records and does not attempt access to real citizens’ data.

Further testing shows that uploaded file metadata is stored in a separate service, but no path to internal command execution is demonstrated. Logs record authentication events but not all object-level authorization failures. The finding is therefore reported as an authorization weakness with confirmed confidentiality impact, while the feared internal compromise remains an unverified scenario rather than a claimed result.

Outcome

The authority implements server-side authorization checks based on the authenticated user and object ownership, adds negative authorization tests to the development pipeline, improves logging, and reviews service-account permissions. A retest confirms that cross-account access is denied and that the event is logged. The assessment also leads to a broader review of API endpoints that share the same design pattern.

Learning points

The case demonstrates why threat modeling improves test selection, why a finding must distinguish demonstrated impact from speculation, and why a small authorization defect can represent substantial privacy risk. It also illustrates the value of synthetic data, controlled exploitation, and remediation verification.

Challenges, Limitations, and Common Errors

Frameworks can create false confidence when treated as complete checklists. A system may satisfy a checklist and still contain an undocumented business-logic flaw. Another risk is framework fragmentation: different teams may use different terms for the same activity and fail to share evidence.

Scope ambiguity is a frequent operational error. Testing a cloud environment without identifying tenant boundaries, managed services, provider restrictions, and shared responsibility can create legal and technical problems. Excessive reliance on scanners produces noisy findings, while excessive manual testing without documentation reduces repeatability. Testers also commonly overstate impact, retain unnecessary sensitive data, or fail to record negative results and limitations.

Threat models may become obsolete when architectures, APIs, suppliers, or identity flows change. They should be treated as living artifacts and reviewed during significant design or operational changes. Risk ratings also require judgment; a numerical score should not conceal uncertainty or replace discussion with asset owners.

Ethics, Governance, and Professional Practice

A penetration tester operates under delegated authority. The engagement must respect authorization boundaries, privacy obligations, data-minimization principles, and applicable law. Credentials, personal information, tokens, and proprietary code should be protected throughout collection, storage, transmission, and destruction.

Professional conduct requires transparency. Testers should disclose limitations, failed tests, environmental assumptions, and uncertainty. They should not claim compromise where only a theoretical path was identified. Rules for emergency communication should be agreed in advance, particularly for tests involving production systems, social engineering, wireless networks, or third parties.

Governance also includes independence, competence, quality review, evidence integrity, and remediation tracking. Findings should be assigned to accountable owners, prioritized according to organizational risk, and retested where appropriate. A technically impressive report that cannot support a management decision is an unsuccessful assessment.

Automation, Analytics, and Emerging Practice

Automation is useful for asset discovery, configuration comparison, API enumeration, evidence organization, attack-surface monitoring, and regression testing. Continuous integration pipelines can execute security tests whenever code or infrastructure changes. Security information and event-management platforms can correlate test activity with detection coverage, while attack-path analysis can connect identities, vulnerabilities, permissions, and assets.

Artificial intelligence may assist with log summarization, code review, test-case generation, and natural-language report drafting. Its outputs require human validation because models may hallucinate vulnerabilities, overlook business context, expose sensitive information, or generate unsafe test actions. AI-assisted testing should therefore operate within authorization, data-governance, and review controls.

Current practice is increasingly shaped by cloud-native architectures, APIs, software supply chains, identity-centric attacks, infrastructure as code, container orchestration, and continuous delivery. These environments favor continuous threat modeling and recurring validation rather than an annual, isolated penetration test. The underlying principle remains stable: testing should be evidence-based, proportionate, and connected to risk.

Best Practices for Designing an Assessment

A high-quality assessment should:

• define authorization, scope, exclusions, contacts, and stop conditions in writing;
• connect testing objectives to business assets and threat scenarios;
• combine manual reasoning with carefully interpreted automated results;
• prioritize identity, authorization, trust boundaries, and attack paths;
• use the least intrusive action that proves a point;
• maintain an evidence log with timestamps, targets, actions, and outcomes;
• separate confirmed impact from plausible but unverified consequences;
• map findings to useful standards without allowing mappings to replace explanation;
• communicate urgent risks during the test rather than waiting for the final report; and
• verify remediation and update the threat model after material changes.

Chapter Summary

Methodologies make penetration testing repeatable, defensible, and aligned with organizational risk. PTES provides an engagement-centered sequence from pre-engagement through reporting, while NIST SP 800-115 offers a broader planning and assessment perspective. OWASP guidance supplies application-testing depth, particularly for authentication, authorization, sessions, input handling, APIs, and business logic. MITRE ATT&CK describes adversary tactics and techniques, and the Cyber Kill Chain offers a high-level model of attack progression. Threat modeling connects these resources to assets, trust boundaries, attack paths, and consequences. Effective professionals integrate the frameworks rather than treating them as competing checklists, maintain ethical and governance controls, and validate remediation through evidence.

Key Terms

Attack path: A sequence of conditions and actions through which an attacker may reach an objective.

ATT&CK: A knowledge base describing adversary tactics, techniques, and procedures.

Authorization: Formal permission defining what testing may be conducted and against which targets.

Cyber Kill Chain: A model representing stages of an intrusion from reconnaissance to actions on objectives.

Data-flow diagram: A representation of processes, data stores, external entities, data flows, and trust boundaries.

Exploitability: The practical ease with which a weakness can be used under specified conditions.

Impact: The harm or consequence resulting from successful exploitation or control failure.

Methodology: A structured set of activities and decisions used to conduct an assessment.

OWASP: An open community and body of guidance focused extensively on application security.

Penetration test: An authorized, controlled assessment that validates security weaknesses through realistic testing.

PTES: The Penetration Testing Execution Standard, which organizes penetration testing into defined phases.

Risk: The combination of the likelihood of an adverse event and its potential impact.

Rules of engagement: Operational constraints, permissions, safety requirements, and communication procedures for a test.

STRIDE: A threat-modeling mnemonic for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Threat model: A structured representation of assets, actors, threats, attack paths, controls, and consequences.

Trust boundary: A point where data, authority, or assumptions change between components or security domains.

Vulnerability analysis: The process of identifying and evaluating weaknesses in systems, applications, or controls.

Vulnerability validation: Controlled confirmation that a suspected weakness is genuine and materially relevant.

Review Questions

Short Answer Questions

1. What is the principal difference between a penetration-testing methodology and the MITRE ATT&CK knowledge base?

2. Why are rules of engagement necessary before testing begins?

3. Identify the seven broad phases commonly associated with PTES.

4. What is the purpose of a trust boundary in a threat model?

5. State the six categories represented by the STRIDE mnemonic.

Long Answer Questions

1. Explain how PTES and NIST SP 800-115 can be combined in a professional penetration-testing program.

2. Discuss the contribution and limitations of OWASP guidance in testing modern web applications.

3. Compare MITRE ATT&CK with the Cyber Kill Chain in terms of purpose, level of detail, and practical use.

4. Describe how threat modeling can influence the scope and priorities of a penetration test.

5. Explain the ethical, governance, and evidence-handling responsibilities of a penetration-testing team.

Analytical / Application Questions

1. A public API allows authenticated users to retrieve records by changing an object identifier. Design a test strategy using threat modeling, OWASP guidance, PTES, and ATT&CK, while minimizing exposure of real data.

2. An organization wants to test a production cloud environment but has not identified provider restrictions, third-party services, or emergency contacts. Analyze the risks and propose a pre-engagement plan.

3. A scanner reports a critical vulnerability on an internet-facing server, but exploitation requires a disabled service and a privileged account. Explain how you would validate, prioritize, and report the finding.

22. Multiple Choice Questions with Answers

Question 1

Which activity most directly belongs to the PTES pre-engagement phase?

A. Developing malware for persistence

B. Defining scope, exclusions, and emergency contacts

C. Exfiltrating production data

D. Assigning an ATT&CK technique after testing

Correct Answer: B. Defining scope, exclusions, and emergency contacts

Question 2

What is the main purpose of threat modeling in a penetration test?

A. To replace all technical testing with interviews

B. To identify likely attack paths, valuable assets, and consequences

C. To guarantee that no vulnerabilities exist

D. To generate only automated scanner findings

Correct Answer: B. To identify likely attack paths, valuable assets, and consequences

Question 3

Which framework is primarily a knowledge base of adversary tactics and techniques?

A. PTES

B. NIST SP 800-115

C. MITRE ATT&CK

D. STRIDE

Correct Answer: C. MITRE ATT&CK

Question 4

A tester changes an object identifier and accesses another user’s record. Which application-security issue is most directly demonstrated?

A. Broken object-level authorization

B. Denial of service

C. Insecure cryptographic hashing only

D. Physical tailgating

Correct Answer: A. Broken object-level authorization

Question 5

Which statement best describes the relationship between the Cyber Kill Chain and ATT&CK?

A. Both are identical vulnerability-scoring systems

B. The Kill Chain gives a high-level progression, while ATT&CK provides detailed behaviors

C. ATT&CK applies only to web applications

D. The Kill Chain replaces authorization and rules of engagement

Correct Answer: B. The Kill Chain gives a high-level progression, while ATT&CK provides detailed behaviors

Question 6

Why should a penetration tester stop after retrieving synthetic records in the illustrative case?

A. Because authorization never permits validation

B. Because minimum necessary action reduces privacy and operational harm

C. Because synthetic data cannot demonstrate a vulnerability

D. Because reporting is unnecessary after exploitation

Correct Answer: B. Because minimum necessary action reduces privacy and operational harm

Question 7

Which item is a trust-boundary concern in a data-flow diagram?

A. A point where data or authority crosses between security domains

B. A document’s page count

C. The brand of a tester’s laptop

D. The number of report recipients

Correct Answer: A. A point where data or authority crosses between security domains

Question 8

A scanner identifies a possible vulnerability, but environmental controls prevent exploitation. What should the tester do?

A. Report confirmed compromise without further analysis

B. Delete the result because scanners are never useful

C. Validate the condition and distinguish theoretical exposure from demonstrated impact

D. Exploit unrelated systems to increase severity

Correct Answer: C. Validate the condition and distinguish theoretical exposure from demonstrated impact

Question 9

Which STRIDE category concerns obtaining unauthorized authority?

A. Repudiation

B. Elevation of privilege

C. Information disclosure

D. Tampering

Correct Answer: B. Elevation of privilege

Question 10

Which practice most improves the repeatability of an assessment?

A. Relying on undocumented tester intuition

B. Recording scope, actions, timestamps, evidence, and outcomes

C. Avoiding all manual analysis

D. Using the same risk rating for every finding

Correct Answer: B. Recording scope, actions, timestamps, evidence, and outcomes