Užitečný model hrozeb vysvětluje, co chráníte, kdo nebo co to může ovlivnit, kde se mění důvěra a jak snížíte a otestujete nejdůležitější rizika. Začněte skutečným projektem, nikoli obecným seznamem nástrojů.
Definujte rozsah dostatečně malý, abyste o něm mohli uvažovat
Začněte jednou fungující službou: zákaznickým portálem, publikačním webem nebo interní aplikací. Zapište komponenty, které provozujete, a externí systémy, na které se spoléháte. Model hrozeb by měl zviditelnit předpoklady, nikoli naznačovat, že byl vyřešen každý možný útok. Udržujte první verzi dostatečně malou, aby ji lidé nasazující aplikaci dokázali vysvětlit bez samostatného konzultanta, který by interpretoval diagram.
Vypište cenné výsledky a aktiva. Může jít o zákaznická data, administrátorský přístup, stav plateb, zveřejněný obsah a schopnost obnovit službu. Dostupnost může být aktivem, i když jsou informace veřejné. Rozhodněte, které poruchy by byly nepříjemné a které by poškodily lidi nebo organizaci. Toto rozlišení vám pomůže stanovit priority opatření, místo abyste ke každému varování přistupovali stejně.
Nakreslete místa, kde se mění důvěra
Pokyny OWASP pro modelování hrozeb používají datové toky a hranice důvěry, aby byl návrh srozumitelný. Pro malou hostovanou aplikaci nakreslete prohlížeč, webový proces, databázi, administrátora, cíl záloh a externí integrace. Označte informace, které mezi nimi proudí. Požadavek přecházející z nedůvěryhodného klienta do privilegované operace serveru si zaslouží výslovné ověření a autorizaci.
Nepředpokládejte, že být na stejném stroji činí všechny komponenty stejně důvěryhodnými. Veřejný proces nahrávání by neměl mít stejná oprávnění jako správa databáze. Úloha zálohování může potřebovat přístup pro čtení bez možnosti měnit živé záznamy aplikace. Oddělení těchto rolí usnadňuje omezení dopadu kompromitované komponenty a revizi požadovaných oprávnění.
Zvolte konkrétní scénáře selhání
Použijte několik věrohodných událostí k prověření návrhu. Útočník ukradne administrátorské heslo; uživatel požaduje záznam jiného uživatele; nahrávání zaplní disk; nasazení odhalí konfigurační soubor; kopii pro obnovu nelze obnovit. Popište výchozí podmínku, dotčenou komponentu a následek. Konkrétní scénář se snáze testuje než široký pokyn ke zlepšení zabezpečení.
Zahrňte chyby a zneužití legitimních postupů stejně jako vnější proniknutí. Opakování může vytvořit dvě cenné operace nebo dva požadavky mohou soupeřit o změnu stejného objektu. Pokyny OWASP k obchodní logice upozorňují na tyto předpoklady procesů. Zkontrolujte, kdo smí posunout pracovní postup do dalšího stavu a zda opakování nebo změna pořadí požadavku neočekávaně změní výsledek.
| Scénář | Opatření k prošetření | Důkazy ke shromáždění |
|---|---|---|
| Ukradené administrátorské přihlašovací údaje | Omezený přístup a druhý faktor, pokud je podporován | Neoprávněné přihlášení nelze dokončit |
| Požadavek na objekt jiného uživatele | Autorizace objektu na straně serveru | Izolovaný test vrátí výsledek odepřeno |
| Disk vyčerpán nahráváním | Omezení velikosti, kvóty a retence | Limit je vynucen před selháním služby |
| Duplicitní požadavek pracovního postupu | Idempotence a hranice transakcí | Opakovaný požadavek vytvoří jeden výsledek |
Stanovte priority podle dopadu a věrohodné cesty
U každého scénáře zaznamenejte jeho možný dopad a podmínky potřebné k tomu, aby nastal. Vyhněte se předstírání, že odhadnuté číselné skóre je přesná pravděpodobnost. Stále můžete odlišit slabé heslo vystavené internetu od vysoce podmíněné místní události. Přiřaďte vlastníka a praktický další krok důležitým rizikům, aby model vytvářel práci, kterou někdo skutečně dokáže dokončit.
Zvažte životní cyklus informací i kompromitaci aplikace. Diagnostický export může během jinak běžného provozu odhalit nepotřebná data. Uchovávané pole účtu může vytvářet vystavení dlouho po skončení svého účelu. Revize soukromí proto může odstranit informace nebo zkrátit retenci, zatímco bezpečnostní revize omezí přístup k tomu, co zůstává. Obě změny patří do modelu, pokud chrání projekt.
Otestujte opatření v autorizovaném prostředí
Vytvořte testovací prostředí s reprezentativními oprávněními a smyšlenými záznamy. Otestujte odepřený přístup, limity požadavků, opakování pracovních postupů a obnovu. Nepoužívejte skutečná zákaznická data, když lze chování prokázat syntetickými daty. Cílem je ověřit kontrolu, nikoli vytvářet působivý útočný provoz. Zůstaňte v rámci systémů, které vlastníte nebo k jejichž posouzení máte výslovné oprávnění.
Zaznamenejte, co prošlo, co selhalo a co zůstává neznámé. Výsledek skeneru může přispět důkazy, ale nenahrazuje test obchodních pravidel aplikace. Stejně tak volba síťové ochrany neověřuje autorizaci objektů ani zacházení s tajnými soubory. Přiložte užitečné výsledky ke scénáři, aby budoucí správci pochopili, proč konkrétní kontrola existuje.
Udržujte model propojený se změnami
Příslušné části zkontrolujte, když přidáte integraci, zpřístupníte nový koncový bod, změníte oprávnění nebo přesunete data do jiného cíle. U drobné textové úpravy nemusíte překreslovat celou architekturu. Spouštěčem je změněný předpoklad o přístupu, informacích nebo chování systému. Uchovávejte model vedle dokumentace nasazení a obnovy, místo abyste jej nechali jako jednorázový výstup z workshopu.
SwissOctet poskytuje katalog možností infrastruktury, nikoli hotový model hrozeb aplikace. Zvolte konfiguraci a možnosti, které podporují vaše kontroly, a poté ověřte nasazení, které vytvoříte. Malý, udržovaný model s otestovanými akcemi je užitečnější než velká sbírka bezpečnostních produktů bez jasného vysvětlení rizik, která řeší.
Váš praktický kontrolní seznam.
- Vypište aktiva a důsledky selhání.
- Nakreslete toky dat a hranice důvěry.
- Zvolte konkrétní scénáře vniknutí, chyby a pracovního postupu.
- Přiřaďte kontroly a vlastníky k důležitým rizikům.
- Testujte se syntetickými daty v autorizovaném prostředí.
- Zkontrolujte model, když se změní příslušný předpoklad.
Podrobnosti, na kterých záleží.
Potřebuji k zahájení formální rámec?+
Ne. Malý diagram a zdokumentovaná sada scénářů mohou být užitečné. Rámec pomáhá zajistit, abyste rizika posuzovali konzistentně.
Nahrazuje skener zranitelností modelování hrozeb?+
Ne. Skenery mohou najít technické slabiny, zatímco model hrozeb zkoumá také předpoklady návrhu, oprávnění a obchodní pracovní postupy.
Jak často mám model aktualizovat?+
Aktualizujte dotčené části, když se změní toky dat, integrace, oprávnění nebo vystavená funkčnost, a pravidelně kontrolujte nevyřešená rizika.
Jděte ke zdroji.
Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.
- OWASP: Tahák pro modelování hrozeb cheatsheetseries.owasp.org
- OWASP: Modelování hrozeb v praxi devguide.owasp.org
- OWASP: Zabezpečení obchodní logiky cheatsheetseries.owasp.org
Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.