Jak TrustScope počítá pracnost

0. Co tento odhad reprezentuje

Neexistuje žádná jediná „správná“ doba penetračního testu a TrustScope to ani nepředstírá. Každý odhad reprezentuje rozumnou, standardní pracnost potřebnou k otestování systému na profesionální úrovni — podle uznávaných metodik (OWASP pro aplikace, OSSTMM pro infrastrukturu) a kalibrovanou proti skutečně zaznamenané pracnosti 800+ zakázek.

Záměrně to není horní hranice. Tester s neomezeným časem by se dostal vždy ještě dál — hluboký výzkum, vývoj nových exploitů, okrajové případy, které přestávají být časově efektivní a běžnou praxí. Reálný útočník s motivací prolomit konkrétní systém může strávit mnohem víc času než jakákoli etická zakázka. TrustScope odhaduje standardní, metodicky vedenou pracnost, která v rozumném čase konverguje k efektivnímu pokrytí — ne teoretické maximum a ne minimum, jaké by dodavatel nasadil, aby vyhrál na ceně.

Proto pracnost hraje roli i pro compliance: regulace jako NIS2 a DORA testování vyžadují, ale jeho hloubku nedefinují — odhad ukotvený v metodice je to, co odděluje skutečnou zakázku od formálního „box-ticku“, který nikoho neuspokojí.

1. Základní koncepty

Každý odhad se počítá deterministicky z vstupů ve wizardu. V matematice není žádná AI — AI se používá jen k extrakci strukturovaných signálů z volného textu, než se to dostane do enginu. Výstupem je vždy trojice: min, doporučené, max člověkodny (MD), plus rozpad po scope.

Pipeline:

1. Vstup z wizardu → normalizovaný ScopeInput (jeden na scope).
2. Pravidlo pro daný scope → baseline + modifikátory + discovery + přístup + reporting.
3. Engine merge → cross-scope překryvy, sdílená režie (PM/workshop), confidence skóre.
4. Finální trojice → min/doporučené/max s plně transparentním rozpadem.

2. Standardy & kalibrace

TrustScope kombinuje dvě vrstvy:

• Metodická vrstva — CO se testuje. Aplikační scope (web, API, mobil) následují OWASP testing guides; infrastrukturní scope (externí, interní) následují OSSTMM. Tyto definují pokrytí, které má daný typ zakázky dosáhnout.
• Kalibrační vrstva — JAK DLOUHO to trvá. Baseline a modifikátory v MD jsou odvozeny ze zaznamenané pracnosti 800+ reálných projektů napříč obory a regiony. Právě to drží čísla v praxi, ne ve zvycích jednoho týmu.

Metodika definuje úplnost; kalibrační data definují pracnost. Společně dělají odhad jak obhajitelným (ukotvený v uznávaných standardech), tak realistickým (odpovídající tomu, kolik testování opravdu zabere).

3. Confidence a rozsahy

Každá položka rozpadu nese typ (baseline, modifier, discovery, compliance, reporting) a hodnotu v MD. min a max se odvozují z baseline tabulek a zužují se podle confidence (víc zodpovězených otázek a méně „neznámých“ signálů = užší rozsah).

Chybějící klíčové informace (např. neznámý počet endpointů, neznámá přítomnost AD) se evidují v missingInfo[] a viditelně rozšiřují rozsah.

4. Webová aplikace (deterministicky)

Web je nejvíc opinionated pravidlo — wizard sbírá dost strukturálních dat, aby se AI nemuselo nic dohadovat.

4.1 Black-box gating

Black-box prochází sekvenční bránou před aplikací baseline:

• Žádný veřejný vstupní vektor (login ani registrace nedostupné) → jen 0.5 MD perimeter sanity check. Žádné další modifikátory.
• Veřejný login, žádná self-registrace, žádné prolomení autentizace → 2.5 MD „pouze auth surface“ (login, registrace, reset hesla, zapomenuté heslo, brute-force throttling, enumerace účtů). Testuje se jako jeden anonymní role.
• Prolomení autentizace povoleno → standardní výpočet + fixní +5 MD post-breach interní addon.

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

Uživatel volí jednotku, ve které o aplikaci přemýšlí:

4.3 Multiplikátor podle počtu rolí

4.4 Další aplikace

Každá aplikace navíc přidá ~60 % baseline (předpokládá se mírný překryv mezi appkami v rámci jedné zakázky).

4.5 Feature modifikátory

• Komplexní RBAC mimo standardní matici
• Multi-tenant izolace (cross-tenant data leaks)
• Platební / finanční workflow (race conditions, integrita transakcí)
• Schvalovací workflow, citlivý admin interface
• File upload / processing
• Federovaný SSO / SAML / OAuth
• Komplexní MFA toky
• Citlivé business workflow

4.6 Discovery a penalizace za chybějící info

• Bez testovacích účtů → režie na self-provisioning
• Bez dokumentace → discovery surface od nuly
• Neznámý počet jednotek / aplikací / veřejného loginu → evidováno jako missing info a rozšiřuje rozsah

5. API

Baseline řízen počtem endpointů a dostupností OpenAPI/spec:

• Small / Medium / Large baseline dle počtu endpointů a hustoty modulů
• + GraphQL → schema/depth/batching útoky
• + SOAP/XML → WSDL, XXE, SOAPAction zneužití
• + Komplexní object-level autorizace (BOLA / scopes)
• + Finanční / transakční workflow
• Discovery režie když spec chybí nebo je neúplný

6. Mobile

Baseline první platformy podle velikosti. Druhá platforma přidá:

• Nativní druhá: ~70 % první
• Sdílený codebase (React Native, Flutter): ~35 % první

Modifikátory: bypass SSL pinningu, offline/sync surface, citlivé lokální úložiště, biometrika, bypass detekce root/jailbreak, finanční toky, mapování MASVS L1/L2. Backend API je pokryto jen jako „basic support“ — plný API audit vyžaduje samostatný API scope.

7. Externí infrastruktura

Baseline podle počtu IP. Modifikátory: počet distinct exposed services, hodně domén/subdomén (recon režie), složitost cloud perimetru, omezená testovací okna, VPN/přístupový setup. Pokud není povolen exploitation, klesá confidence (engine nemůže ověřit reálnou exploitovatelnost).

8. Interní infrastruktura

Baseline podle počtu assetů. Modifikátory: AD ve scope (+kerberoasting, ACL abuse, GPO review), víc AD forestů, segmentace, assumed-breach scénář, lateral movement, hodně subnetů/VLAN, produkční restrikce, EDR/AV evasion režie.

9. Cloud

Baseline podle velikosti. Modifikátory: Kubernetes (cluster, RBAC, workloads, network policies), složitost IAM, multi-account/subscription, CI/CD security, IaC review. Bez read-only přístupu je discovery jen externí enumerací a klesá confidence.

10. Sociotechnika (phishing / vishing / OSINT)

Phishing baseline škáluje s počtem uživatelů + scénářů. Modifikátory: vlastní landing page, sběr credentials, malicious attachment simulace, awareness materiál.

Vishing: složitost scriptu, scénáře, jazyky. OSINT: breached creds, sociální sítě, exposed assets, analýza exekutivy, velký brand footprint.

11. Překryv mezi scope

Když víc scope sdílí kontext, engine odečítá překryv aby se to nedvojnásobilo:

• Web + API stejné app → sdílené discovery & konsolidovaný report
• Externí + Interní infra → konsolidovaný infra report

12. Sdílená režie (PM, workshop, reporting)

Nad per-scope MD engine přidává:

• Per-scope reporting — ~15 % technické pracnosti, min. 1 MD na scope (executive summary + remediation)
• Workshop / kickoff — fixní režie na scoping alignment
• Project management — frakce z celkové technické pracnosti

U jednoscope odhadů se tyto řádky zobrazí přímo v kartě scope. U více scope se schovají do rolovacího panelu „Sdílená režie & úpravy“, a rekonciliace vždy platí: Σ per-scope MD + sdílená režie + překryvy = totalMdRecommended.

13. Trénovací zpětná vazba

Když se v Training modulu zadají skutečné MD, dělí se na kategorie Technical / Discovery / Compliance / Reporting, aby systém viděl, ve které části odhad ujel, ne jen v součtu.

14. Co NENÍ zahrnuto

• Cestovné, on-site přítomnost, posílání HW
• Implementace fixů na straně zákazníka
• Re-scoping po podpisu smlouvy
• Právní / smluvní review