StrikePoint · Methodology Architecture Guide
The methodology that underpins every StrikePoint engagement. Its organizing idea: published testing frameworks are dynamically-loaded library checklists, bound by the engagement agreement, that pass or fail through defined acceptance & surrender levels. Standards-based, outside-in, and productizable as a service.
StrikePoint's methodology is not a single checklist. It is a linker model: the industry frameworks are versioned libraries of checks, the signed agreement is what binds a chosen subset of them to a specific target, and the surrender levels are the assertions that grade the result. This is the organizing principle every later section is an instance of.
PTES phases, OWASP WSTG/MASTG test categories, OSSTMM channels, per-surface MITRE ATT&CK technique sets. Versioned. Load only what scope calls for.
Resolves which modules load, against which assets, up to which ceiling. An unbound check is unauthorized access — so binding is the legal firewall, not a formality.
Each loaded check resolves on the S0–S4 ladder. The Pass Threshold decides pass/fail; the Authorization Ceiling is the hard bound the run cannot exceed.
The modules StrikePoint composes. PTES is the lifecycle spine, ATT&CK the technique taxonomy, the Cyber Kill Chain the narrative, PCI/NIST the compliance-grade structure, OSSTMM the measurable channel model, and TIBER-EU the threat-led authorization model. OWASP's WSTG page is the canonical index of recognized methodologies.1
| Framework | Owner | Phase / structure | Role in StrikePoint | Status |
|---|---|---|---|---|
| PTES | Pen Testing Execution Standard | 7 phases: Pre-engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting1 | Master engagement lifecycle | Verified |
| MITRE ATT&CK | MITRE | Matrix of tactics (TA####) × techniques (T####), outside-in from Reconnaissance to Impact5 | Technique taxonomy & citable ID system | Verified |
| NIST SP 800-115 | NIST (Sept 2008) | 4 phases: Planning, Discovery, Attack, Reporting; written authorization required before testing2 | US federal baseline; authorization gate | Verified |
| OSSTMM 3 | ISECOM | 5 channels (Human, Physical, Wireless, Telecommunications, Data Networks) + RAV metric (exposure/visibility/trust/controls)7 | Measurable channel & attack-surface scoring | Verified |
| Cyber Kill Chain | Lockheed Martin | 7 stages: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, C2, Actions on Objectives6 | Adversary-progression narrative for reports | Contested |
| PCI DSS Pentest Guidance | PCI SSC | 3-phase lifecycle: Pre-engagement, Engagement, Post-engagement8 | Compliance structure for cardholder-data clients | Verified |
| TIBER-EU | European Central Bank | 3 phases: Preparation, Testing, Closure — live production, full consent9 | Threat-led red-team + authorization model | Verified |
| OWASP WSTG / MASTG | OWASP | Test-category checklists for web (WSTG) & mobile (MASTG) surfaces1 | Depth checklists for web & mobile | Verified |
| CREST | CREST (int'l body) | Accreditation for firms + certification for individuals; recognized by UK NCSC CHECK10 | Industry accreditation / trust reference | Verified |
| ISSAF | OISSG | Assessment framework linking pentest steps to tools; last updated 2006, no longer maintained11 | Historical reference only — not a live standard | Contested |
PTES supplies the master spine (most complete lifecycle1); ATT&CK tactics overlay each execution phase so every action carries a citable ID; NIST's four-phase model2 is the compliance-grade compression of the same shape. The engagement runs outside-in.
| StrikePoint phase | PTES | NIST 800-115 | ATT&CK tactic(s) |
|---|---|---|---|
| 0 · Authorize | Pre-engagement | Planning | — (guardrail layer, §06) |
| 1 · Recon | Intelligence Gathering | Discovery | TA0043 Reconnaissance |
| 2 · Model | Threat Modeling | Discovery | TA0042 Resource Development |
| 3 · Analyze | Vulnerability Analysis | Discovery | (pre-access assessment) |
| 4 · Access | Exploitation | Attack | TA0001 Initial Access, TA0002 Execution |
| 5 · Advance | Post-Exploitation | Attack | TA0004 PrivEsc, TA0008 Lateral Movement, TA0003 Persistence, TA0010 Exfil |
| 6 · Report | Reporting | Reporting | — (remediation & retest) |
The categorized technique set, phase by phase, with verified ATT&CK IDs. Tactic-level IDs (TA####) are stable; technique-level IDs (T####) are cited from the live ATT&CK Enterprise matrix (see version note, §08).
"The adversary is trying to gather information they can use to plan future operations" — active and passive.3
Turning the map into a service inventory. PCI draws the line here: a scan identifies & ranks; a pentest attempts to exploit.12
Correlating discovered services against known weaknesses, prioritizing by exploitability and impact — before any exploit fires.
Exploitation, organized by attack surface. Each is a scope opt-in.
Demonstrating real impact by moving inward and laterally. MITRE defines Lateral Movement (TA0008) as "the adversary is trying to move through your environment."15
TA0004"Gain higher-level permissions" — 13 techniques incl. Exploitation for PrivEsc T1068, Abuse Elevation Control T1548.16TA0008Remote Services T1021, Exploitation of Remote Services T1210, Use Alternate Auth Material T1550, Internal Spearphishing T1534.15TA0003"Maintain their foothold" — 22 techniques incl. Boot/Logon Autostart T1547, Create Account T1136.17TA0010"Steal data" — 9 techniques incl. Exfil Over C2 T1041, Over Alternative Protocol T1048. Controlled proof-of-impact only.18Findings ranked by risk, mapped to ATT&CK IDs, with a prioritized remediation list and a retest — where PTES and the PCI post-engagement phase converge.8
A methodology says how we test; it does not say what counts as a win. StrikePoint closes that with a pre-agreed, contractual threshold of customer surrender — the depth of compromise at which a control is deemed to have failed. Crucially, the agreed level is both the success bar and the authorization stop-line: acceptance criteria and rules of engagement are one dial.
The vector exists & is reachable. No interaction.
Would-surrender proven — clicked / exploitable — nothing taken.
Secret / access actually obtained; held, not yet used.
Access used for a safe, reversible proof-action.
Crown-jewel / flag reached. Full chained impact.
Each in-scope surface is assigned two values in the Statement of Work: a Pass Threshold (the level at which the test authenticates as successful / the control is deemed failed) and an Authorization Ceiling (the maximum level StrikePoint may reach; always ≥ the threshold, and the mandatory stop line). Consent scales with the ceiling — S3–S4 add action-specific written authorization, a named approver, and stop conditions. DoS normally caps at S1.
This layer wraps every phase and is what makes the whole thing lawful. Authorization is the legal dividing line: under the CFAA (18 U.S.C. §1030), accessing a computer "without authorization" or in a way that "exceeds authorized access" is a federal crime — identical technical actions are lawful with explicit permission and criminal without it.19
| Guardrail control | What it fixes | Status |
|---|---|---|
| Signed scope agreement | Defines exactly which assets, ranges, and vectors are in-bounds before any packet is sent. | Verified |
| Written authorization | NIST 800-115: "written authorization or rules of engagement should be obtained and documented before testing begins."2 | Verified |
| Rules of Engagement | Timing windows, permitted exploitation depth (the surrender ceiling), escalation contacts, stop conditions. | Verified |
| Full consent, live-production | TIBER-EU: activities "under a contractual agreement with the full consent of the entity," mitigating legal concerns beforehand.9 | Verified |
| CFAA & equivalents | US CFAA §1030; UK Computer Misuse Act 1990 (unauthorised access); EU Directive 2013/40/EU on attacks against information systems.1920 | Verified |
The linker model is not just lawful — it is the natural architecture for a productized service. TIBER-EU's Preparation → Testing → Closure, on live systems under consent,9 is effectively a three-stage workflow behind an authorization gate, which a SaaS platform expresses well.
Because the frameworks are versioned libraries, the guide manages drift explicitly rather than pretending the standards are static.