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. Brána má čtyři výstupy, rozhodované ze dvou otázek: je celá aplikace dostupná bez přihlášení? a (pokud ne) je dostupná self-registrace? / smí tester pokračovat dovnitř při prolomení autentizace?

• Celá aplikace veřejná (žádná auth zeď) → standardní sizing, testuje se jako jeden anonymní role.
• Auth zeď, self-registrace dostupná → tester se zaregistruje a projde celou vnitřní plochu → standardní sizing, jeden role.
• Auth zeď, bez self-registrace, bez povoleného prolomení → pouze perimeter / auth-surface sanity check (login, registrace, reset hesla, brute-force throttling, enumerace účtů). Žádné další modifikátory.
• Auth zeď, bez self-registrace, prolomení autentizace povoleno → perimeter / auth-surface check + fixní post-breach rozpočet na ověření vnitřní plochy za předpokladu úspěšného bypassu. Vnitřní plocha se nesizuje (z venku není známá).

Vnitřní plocha se sizuje jen tehdy, když se k ní tester reálně dostane — buď je aplikace veřejná, nebo je otevřená self-registrace. Sizovat plochu, ke které se z venku nikdo nedostane, by nebylo deterministické.

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

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

Všechny jednotky sdílejí jednu stupňovitou baseline křivku (XS → G). Konkrétní MD hodnoty per tier nejsou veřejné.

4.3 Multiplikátor podle počtu rolí

4.4 Více aplikací

Každá aplikace se scopuje jako samostatná položka. Žádný paušální „+X % za další aplikaci“ multiplikátor neexistuje — fixní procento by byl odhad, ne deterministické pravidlo. Pokud aplikace reálně sdílí codebase, auth vrstvu nebo testovací účty, odečet se řeší explicitně přes pravidla překryvu mezi scope (§11), ne plošně.

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 → 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á platforma: ~65 % první (samostatný binárek, samostatný OS-level útočný povrch, ale sdílené pochopení backendu a reportu)
• Sdílený codebase (React Native, Flutter, jiné cross-platform): ~45 % první (jeden codebase, ale každá platforma má vlastní runtime, úložiště a OS-specific kontroly)

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

Externí infra test simuluje neautentizovaného útočníka, který se k organizaci dostává z veřejného internetu. Cílem není „proskenovat rozsah IP“ — je to zmapovat reálný perimetr, identifikovat vše skutečně dostupné a ověřit, co je zneužitelné. Pracnost roste s tím, kolik útočné plochy je vystaveno a jak nepřehledná je k enumeraci.

Co se reálně testuje

• Discovery perimetru — pasivní recon, DNS enumerace, hledání subdomén, certificate transparency, rozšíření ASN/IP rozsahů, detekce shadow IT.
• Identifikace služeb — port scanning, service/version fingerprinting, analýza bannerů, mapování technologického stacku per host.
• Validace zranitelností — CVE matching proti identifikovaným verzím, manuální ověření false positives, exploitation tam, kde je povolen (default safety: read-only PoC, žádné destruktivní payloady).
• Vystavená management rozhraní — RDP, SSH, VPN portály, admin panely, databázové porty, Kubernetes API, Docker daemony, monitoring nástroje omylem vystavené ven.
• Autentizační surface — credential stuffing, default credentials, slabá kryptografie, vystavené login portály, MFA bypass cesty.
• Web/email security posture — TLS konfigurace, hygiena certifikátů, SPF/DKIM/DMARC, otevřené mail relays, hardening webserverů.
• Information leakage — výpisy adresářů, vystavené zálohy, .git/.env soubory, metadata v publikovaných dokumentech, ukecané error stránky.

Co ovlivňuje scope a proč

• Počet IP / hostů — primární faktor. Pracnost roste nelineárně: zdvojnásobení IP nezdvojnásobí práci (recon a tooling režie je sdílená), ale velký rozsah pořád vyžaduje per-host validaci a triáž. Proto je baseline stupňovitá křivka, ne plochá sazba za IP.
• Počet různých vystavených služeb — 50 IP s jedním web stackem je výrazně méně práce než 50 IP s mixem HTTP, SSH, SMTP, RDP, ICS protokolů a custom služeb. Každá rodina protokolů přitáhne vlastní test metodiku.
• Doménový / subdoménový footprint — rozsáhlé nebo akviziční organizace potřebují reálný recon time než vůbec test začne. Shadow IT, zapomenutá staging prostředí, vystavené cloud assety se objeví právě tady.
• Složitost cloud perimetru — multi-region, multi-account/subscription, CDN/WAF před aplikací, dočasné IP a managed služby mění to, co „externí“ vůbec znamená, a přidávají režii enumerace.
• Restrikce testovacích oken — úzká časová okna, change-freeze, pravidla „jen v pracovní době“ nebo rate limiting ze strany zákazníka prodlužují kalendář a zvyšují pracnost, protože práce se musí přeplánovat a znovu ověřovat.
• Setup přístupu — VPN, jump hosty, allow-listed source IPs, zákaznicky řízené test laptopy — každý přidává onboarding režii a čas k prvnímu paketu.
• Povolení exploitation — pokud není exploitation povolen, engine nedokáže ověřit reálnou zneužitelnost. Nálezy zůstanou na „potenciálně zranitelné“ a celková confidence klesá; rozsah se rozšiřuje, aby tu neznámou odrážel.
• WAF / IPS v cestě — přidává ladění payloadů, evasion (kde je povolen) a re-validaci, když uprostřed testu spadne block.

8. Interní infrastruktura

Interní infra test simuluje útočníka, který už uvnitř sítě je — phishnutý zaměstnanec, kompromitovaný contractor laptop, rogue zařízení na guest VLANu, nebo explicitní assumed-breach scénář. Cílem je změřit, jak daleko se dá ten foothold rozšířit: lateral movement, eskalace privilegií, přístup k crown-jewel datům a domain dominance. Pracnost řídí to, jak interní prostředí reálně vypadá, ne jen počet hostů.

Co se reálně testuje

• Síťový reconnaissance — host discovery napříč subnety, enumerace služeb, identifikace high-value cílů (file servery, DCs, databáze, backup systémy, jump hosty).
• Active Directory útoky — Kerberoasting, AS-REP roasting, zneužití unconstrained / constrained / RBCD delegation, ACL misconfigurace, GPO review, zneužití ADCS (certificate services), password spraying, expozice LAPS/LSASS.
• Credential útoky — LLMNR/NBT-NS/mDNS poisoning, NTLM relay, slabiny SMB signing, hash extraction, zneužití ticketů (Golden/Silver/Diamond), cleartext credentials ve sharech a skriptech.
• Lateral movement — pass-the-hash, pass-the-ticket, WMI/WinRM/PsExec/SMB exec, RDP hopping, zneužití legitimních admin nástrojů (living-off-the-land).
• Eskalace privilegií — lokální kernel/service exploity, špatně nakonfigurované služby, slabá file permissions, unquoted service paths, zneužití scheduled tasků, sudo/SUID issues na Linuxu.
• Validace segmentace — ověření, že VLANy, firewally a zero-trust politiky reálně oddělují provoz tak, jak tvrdí síťový diagram.
• Datová expozice — otevřené SMB/NFS share, vystavené databáze, slabé zálohy, secrets v source repos a CI/CD systémech dostupných zevnitř.
• Endpoint / EDR posture — kde je ve scope: AV/EDR bypass pokusy, ochrana proti tamperingu, mezery v alerting pokrytí.

Co ovlivňuje scope a proč

• Počet assetů — primární faktor, opět stupňovitá křivka. Práce per host klesá s rostoucím počtem (hodně se opakuje tooling), ale pokrytí musí být obhajitelné — samotné vzorkování není u tisíců hostů kredibilní test.
• Active Directory ve scope — přidává velkou, dobře definovanou útočnou plochu (Kerberos, ACLs, GPOs, ADCS, trusts). AD-heavy prostředí běžně zdvojnásobí smysluplnou práci oproti ploché workgroup síti stejné velikosti.
• Víc AD forestů / domén / trustů — každá hranice trustu násobí enumeraci i útočné cesty (forest trusts, SID history abuse, cross-forest delegation). Pracnost roste s počtem trust relationships, ne jen s počtem uživatelů.
• Testování segmentace — explicitní ověření segmentace (vs. test jen v jedné zóně) vyžaduje umístit testera na víc síťových pozic, každá s vlastní setup režií.
• Assumed-breach startovní pozice — test z neprivilegovaného doménového účtu zevnitř přeskočí initial-access krok, ale rozšíří každý další krok (najednou je v hře plná AD recon a lateral movement).
• Počet subnetů / VLANů / lokalit — víc síťových zón = víc reconnaissance, víc pivotování, víc koordinace přístupů. Geograficky distribuované lokality přidávají VPN/jump-host setup per lokalita.
• Produkční restrikce — omezení „bez DoS, žádný exploitation v prod, jen 22:00–04:00“ omezují, co lze živě ověřit, a zvyšují manuální verifikaci, aby se zůstalo v bezpečí.
• EDR / AV ve scope — pokud má být test stealth nebo má obcházet detekci, crafting payloadů, obfuskace a operational tradecraft přidávají výrazný čas. Hlasitý test v hlučné laboratoři je mnohem levnější než purple-team stealth.
• OT / ICS / legacy systémy — křehké zařízení vyžaduje extra opatrnost, často jen read-only assessment a specialistické znalosti — to vše zvyšuje cenu per asset.
• Poskytnuté přístupy / dokumentace — doménový uživatel, síťové diagramy a asset inventář discovery dramaticky zkrátí. Jejich absence se loguje jako missing info a rozšiřuje rozsah.

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, s malým spodním limitem 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