Jak PentestPlanner počítá pracnost

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. 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.

3. Webová aplikace (deterministicky)

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

3.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.

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

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

3.3 Multiplikátor podle počtu rolí

3.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).

3.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

3.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

4. 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ý

5. 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.

6. 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).

7. 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.

8. 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.

9. Retest

baseline = max(0.5, originalMd × pct) kde pct roste s počtem a závažností nálezů (víc high/critical → vyšší pct). Plus modifikátory: discovery režie (když chybí fix dokumentace), update reportu.

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