Wie TrustScope den Aufwand berechnet

0. What this estimate represents

There is no single "correct" duration for a penetration test, and TrustScope doesn't pretend otherwise. Each estimate represents the reasonable, standard effort to test a system to a professional level — using recognized testing methodologies (OWASP for applications, OSSTMM for infrastructure) and calibrated against the real recorded effort of 800+ engagements.

It is deliberately not an upper bound. A tester with unlimited time could always go further — deep research, novel exploit development, edge cases that stop being time-efficient and stop being standard practice. A motivated real-world attacker may spend far more time than any ethical engagement ever would. TrustScope estimates the standard, methodology-driven effort that converges on effective coverage in a sensible timeframe — not the theoretical maximum, and not the bare minimum a vendor might quote to win on price.

This is also why effort matters for compliance: regulations like NIS2 and DORA require testing but don't define its depth — an estimate grounded in methodology is what separates a real engagement from a box-tick that satisfies no one.

1. Core concepts

Every estimate is computed deterministically from the wizard inputs. There is no AI inference in the math — AI is only used to enrich free-text notes into structured signals before they feed the engine. The output is always a triple: min, recommended, and max man-days (MD), plus a per-scope breakdown.

Pipeline:

1. Wizard input → normalized ScopeInput (one per scope).
2. Per-scope rule → baseline + modifiers + discovery + approach + reporting.
3. Engine merge → cross-scope overlap adjustments, shared PM/workshop overhead, confidence score.
4. Final triple → min/recommended/max with a transparent line-item breakdown.

2. Standards & calibration

TrustScope combines two layers:

• Methodology layer — WHAT gets tested. Application scopes (web, API, mobile) follow the OWASP testing guides; infrastructure scopes (external, internal) follow OSSTMM. These define the coverage each engagement type is expected to achieve.
• Calibration layer — HOW LONG it takes. The man-day baselines and modifiers are derived from the recorded effort of 800+ real projects across industries and regions. This is what keeps the numbers grounded in practice rather than in one team's habits.

The methodology defines completeness; the calibration data defines effort. Together they make an estimate both defensible (anchored to recognized standards) and realistic (matched to what testing actually takes).

3. Confidence and ranges

Each line item carries a kind (baseline, modifier, discovery, compliance, reporting) and an MD value. min and max are derived from baseline tables per scope type and shrink as the confidence score increases (more answered questions, fewer "unknown" signals).

Missing critical info (e.g. unknown endpoint count, unknown AD presence) is recorded under missingInfo[] and visibly widens the range.

4. Web application (deterministic)

Web is the most opinionated rule because the wizard collects enough structural data to avoid AI guesses.

4.1 Black-box gating

Black-box engagements pass through a sequential gate before any baseline is applied. The gate has four outcomes, decided from two questions: is the whole app reachable without logging in? and (if not) is self-registration available? / is the tester allowed to continue internally if auth is broken?

• Whole app public (no auth wall) → standard sizing path, tested as a single anonymous role.
• Auth wall, self-registration available → tester signs up and exercises the full internal surface → standard sizing path, single role.
• Auth wall, no self-registration, no auth-break allowed → perimeter / auth-surface sanity check only (login, registration, password reset, brute-force throttling, account enumeration). No further modifiers.
• Auth wall, no self-registration, auth-break allowed → perimeter / auth-surface check + a fixed post-breach budget to validate the internal surface assuming a successful bypass. No sizing of the internal surface (it is unknown from outside).

The internal surface is only sized when the tester can actually reach it — either because the app is public or self-registration is open. Sizing a surface that no one can reach from outside would not be deterministic.

4.2 Sizing units (grey/white-box & auth-break path)

The user picks a sizing unit that matches how they think about the app:

All units share a single tiered baseline curve (XS → G) so the baseline never falls below realistic floor effort for a given surface area. Concrete MD values per tier are not published.

4.3 Role coverage multiplier

Role count is applied as a tiered percentage on top of the baseline (with a small minimum absolute add so it still matters for tiny baselines):

4.4 Multiple applications

Each application is scoped as a separate scope item. There is no aggregate "extra app" multiplier — assuming a fixed overlap between unrelated applications would be a guess, not a deterministic rule. If two apps genuinely share a codebase, auth layer, or test accounts, the overlap is captured explicitly through the cross-scope overlap rules (§11), not invented as a flat percentage.

4.5 Feature modifiers

• Complex RBAC — beyond a standard role matrix
• Multi-tenant isolation — cross-tenant data leakage tests
• Payment / financial flows — race conditions, transaction integrity
• Approval workflows, sensitive admin interface
• File upload / processing
• Federated SSO / SAML / OAuth
• Complex MFA flows
• Sensitive business workflows

4.6 Discovery and missing-info penalties

• No test accounts → "Account self-provisioning" discovery overhead
• No documentation → surface-from-scratch overhead
• Unknown unit count → recorded as missing info and widens the range

5. API

Baseline driven by endpoint count and OpenAPI/spec availability:

• Small / Medium / Large baseline based on endpoint count and module density
• + GraphQL → schema/depth/batching tests
• + SOAP/XML → WSDL, XXE, SOAPAction abuse
• + Complex object-level authorization (BOLA / scopes)
• + Financial / transaction workflows
• Discovery overhead if spec is partial or missing

6. Mobile

First-platform baseline by size. Second platform adds:

• Native second platform: ~65% of first (separate binary, separate OS-level attack surface, but shared backend understanding and report)
• Shared codebase (React Native, Flutter, other cross-platform): ~45% of first (one codebase, but each platform still gets its own runtime, storage and OS-specific checks)

Modifiers: SSL pinning bypass, offline/sync surface, sensitive local storage, biometrics, root/jailbreak detection bypass, financial flows, MASVS L1/L2 mapping. Backend API is only covered as "basic support" — a real API assessment requires a dedicated API scope.

7. External infrastructure

External infra testing simulates an unauthenticated attacker reaching the organisation from the public internet. The job is not "scan a range of IPs" — it is to map the real perimeter, identify everything actually reachable, and validate what is exploitable. Effort scales with how much attack surface is exposed and how messy that surface is to enumerate.

What is actually tested

• Perimeter discovery — passive recon, DNS enumeration, subdomain discovery, certificate transparency, ASN/IP range expansion, shadow IT detection.
• Service identification — port scanning, service/version fingerprinting, banner analysis, technology stack mapping per host.
• Vulnerability validation — CVE matching against identified versions, manual verification of false positives, exploitation where authorised (default safety: read-only PoC, no destructive payloads).
• Exposed management interfaces — RDP, SSH, VPN portals, admin panels, database ports, Kubernetes API, Docker daemons, monitoring tools accidentally exposed.
• Authentication surface — credential stuffing risk, default credentials, weak crypto, exposed login portals, MFA bypass paths.
• Web/email security posture — TLS configuration, certificate hygiene, SPF/DKIM/DMARC, open mail relays, web server hardening.
• Information leakage — directory listings, exposed backups, .git/.env files, metadata in published documents, verbose error pages.

What influences the scope and why

• IP / host count — the primary driver. Effort grows non-linearly: doubling the IPs does not double the work (recon and tooling overhead is shared), but a large range still demands per-host validation and triage. That is why the baseline is a tiered curve, not a flat per-IP rate.
• Distinct exposed services — 50 IPs all running the same web stack are far less work than 50 IPs running a mix of HTTP, SSH, SMTP, RDP, ICS protocols and custom services. Each protocol family pulls in its own test methodology.
• Domain / subdomain footprint — wide-spread or acquisition-heavy organisations need real recon time before testing can even begin. Shadow IT, forgotten staging environments, and exposed cloud assets routinely appear here.
• Cloud perimeter complexity — multi-region, multi-account/subscription, CDN/WAF in front, ephemeral IPs, and managed services all change what "external" means and add enumeration overhead.
• Testing window restrictions — narrow time slots, change-freeze periods, business-hours-only rules, or customer-side rate limiting stretch calendar time and increase effort because work has to be replanned and re-validated.
• Access setup — VPN, jump hosts, allow-listed source IPs, customer-managed test laptops — each adds onboarding overhead and time-to-first-packet.
• Exploitation permission — if exploitation is forbidden, the engine cannot confirm true exploitability. Findings stay at "potentially vulnerable" and overall confidence drops; the range widens to reflect the unknown.
• WAF / IPS in the path — adds payload tuning, evasion attempts (where permitted), and re-validation when blocks fire mid-test.

8. Internal infrastructure

Internal infra testing simulates an attacker who has already landed inside the network — a phished employee, a compromised contractor laptop, a rogue device on a guest VLAN, or an explicit assumed-breach scenario. The objective is to measure how far that foothold can be expanded: lateral movement, privilege escalation, access to crown-jewel data, and domain dominance. Effort is driven by what the internal estate actually looks like, not just by the number of hosts.

What is actually tested

• Network reconnaissance — host discovery across subnets, service enumeration, identification of high-value targets (file servers, DCs, databases, backup systems, jump hosts).
• Active Directory attacks — Kerberoasting, AS-REP roasting, unconstrained / constrained / RBCD delegation abuse, ACL misconfigurations, GPO review, ADCS (certificate services) abuse, password spraying, LAPS/LSASS exposure.
• Credential attacks — LLMNR/NBT-NS/mDNS poisoning, NTLM relay, SMB signing weaknesses, hash extraction, ticket abuse (Golden/Silver/Diamond), cleartext credentials in shares and scripts.
• Lateral movement — pass-the-hash, pass-the-ticket, WMI/WinRM/PsExec/SMB exec, RDP hopping, abuse of legitimate admin tooling (living-off-the-land).
• Privilege escalation — local kernel/service exploits, misconfigured services, weak file permissions, unquoted service paths, scheduled task abuse, sudo/SUID issues on Linux.
• Segmentation validation — verifying that VLANs, firewalls and zero-trust policies actually contain traffic the way the network diagram claims.
• Data exposure — open SMB/NFS shares, exposed databases, weak backups, secrets in source repos and CI/CD systems reachable from inside.
• Endpoint / EDR posture — where in scope: AV/EDR bypass attempts, tampering protection, alerting coverage gaps.

What influences the scope and why

• Asset count — the primary driver, also a tiered curve. The work per host drops as count grows (a lot is repeated tooling), but coverage still has to be defensible — sampling alone is not a credible test for thousands of hosts.
• Active Directory in scope — adds a large, well-defined attack surface (Kerberos, ACLs, GPOs, ADCS, trusts). AD-heavy environments routinely double the meaningful work versus a flat workgroup network of the same size.
• Multiple AD forests / domains / trusts — each trust boundary multiplies enumeration and attack paths (forest trusts, SID history abuse, cross-forest delegation). Engagement effort grows with the number of trust relationships, not just user count.
• Segmentation testing — explicitly verifying segmentation (vs. just testing within one zone) requires positioning the tester in multiple network locations, each with its own setup overhead.
• Assumed-breach starting point — testing from an unprivileged user account inside the domain skips the initial-access step but expands every later step (full AD recon and lateral movement are now in play).
• Number of subnets / VLANs / sites — more network zones = more reconnaissance, more pivoting, more access coordination. Geographically distributed sites add VPN/jump-host setup per location.
• Production restrictions — "no DoS, no exploitation on prod, only between 22:00–04:00" constraints reduce what can be validated live and increase manual verification effort to stay safe.
• EDR / AV in scope — if the test must remain stealthy or evade detection, payload crafting, obfuscation and operational tradecraft add significant time. Loud testing in a noisy lab is much cheaper than purple-team-grade stealth.
• OT / ICS / legacy systems — fragile equipment requires extra caution, often read-only assessment, and specialist knowledge — all of which raise the per-asset cost.
• Credentials / documentation provided — a domain user account, network diagrams, and asset inventory shorten discovery dramatically. Their absence is logged as missing info and widens the range.

9. Cloud

Baseline by size. Modifiers: Kubernetes (cluster, RBAC, workloads, network policies), IAM complexity, multi-account/subscription paths, CI/CD security, IaC review. Without read-only access, discovery is external-enumeration only and confidence drops.

10. Social engineering (phishing / vishing / OSINT)

Phishing baseline scales with user count + scenarios. Modifiers: custom landing page, credential capture, malicious attachment simulation, awareness material.

Vishing: script complexity, scenarios, languages. OSINT: breached creds, social media, exposed assets, executive analysis, large brand footprint.

11. Cross-scope overlap

When multiple scopes share context, the engine deducts overlap to avoid double-charging:

• Web + API on the same app → shared discovery & consolidated report
• External + Internal infra → consolidated infrastructure report

12. Shared overhead (PM, workshop, reporting)

On top of the per-scope MDs the engine adds:

• Per-scope reporting — ~15% of technical effort, with a small floor per scope (executive summary + remediation guidance)
• Workshop / kickoff — fixed overhead for scoping alignment
• Project management — fraction of total technical effort

For single-scope estimates these rows are rendered inline in the scope card. For multi-scope estimates they appear in a collapsible "Shared overhead & adjustments" panel, and the reconciliation always equals: Σ per-scope MD + sharedOverhead + overlap adjustments = totalMdRecommended.

13. Training feedback loop

When real-world MDs are entered in the Training module, they are split into Technical / Discovery / Compliance / Reporting categories so the system can pinpoint which part of the estimation deviated, not just the total.

14. What is NOT included

• Travel, on-site presence, hardware shipping
• Customer-side fix implementation
• Re-scoping after the contract is signed
• Legal/contractual review