Neúčinný návrh architektury
- Nedostatky vyjádřené jako "chybějící nebo neúčinný návrh" architektury.
- Existuje rozdíl mezi nezabezpečeným návrhem a nezabezpečenou implementací.
- Nezabezpečený návrh nelze opravit dokonalou implementací, protože nebyly vytvořeny bezpečnostní kontroly.
- Jedním z faktorů je nedostatečné modelování a profilování rizik, díky čemuž není možné vyjádřit úroveň zabezpečení, která je pro systém nutná.
- Kategorie rizik vyzývá k využívání modelování hrozeb a bezpečných návrhových vzorů.
- Poukazuje na nutnost zavedení činností před kódováním - Secure by design.
Nejčastější zranitelnosti
- Citlivé údaje zobrazené v chybových hláškách.
- Nechráněné úložiště obsahující credentials.
- Porušení trust boundary (hranice důvěryhodnosti).
- Nedostatečně chráněné credentials.
Řízení požadavků a zdrojů
🔴 Shromážděte a projednejte se stakeholdery byznys požadavky na aplikaci a požadavky na ochranu důvěryhodnosti, integritu, dostupnost, autenticitu.
🔴 Vemte v úvahu, jak moc bude aplikace vystavena riziku.
- Je potřeba řídit přístup? Viz. (autorizace).
🔴 Sestavte funkční a nefunkční požadavky na zabezpečení.
🔴 Naplánujte a vyjednejte rozpočet pokrývající činnosti spojené s návrhem, implementací, testováním a provozem, včetně bezpečnostních činností.
Secure by Design
- Metodika, která neustále vyhodnocuje hrozby.
- Zajišťuje, že kód je navržen a testován tak, aby zabránil známým útokům.
🔴 Zapojte modelování hrozeb do vývojového cyklu (threat modeling).
🔴 Hledejte změny v datových tocích a řízení přístupu nebo jiných bezpečnostních kontrolách.
🔴 Určete správné toky a stavy selhání.
🔴 Zajistěte pochopení a odsouhlasení návrhu odpovědnými a ovlivněnými stranami.
🔴 Analyzujte předpoklady pro očekávané a poruchové toky.
🔴 Ujistěte se, že je model stále platný a přesný.
🔴 Určete ověření předpokladů a prosazení podmínek potřebných pro správné chování.
🔴 Zajistěte dokumentaci výsledků.
Životní cyklus bezpečného vývoje
- Bezpečný software vyžaduje určitou formu
- bezpečného návrhového vzoru,
- metodiky zpevněných cest (paved roads),
- knihovny zabezpečených komponent,
- nástrojů a modelování hrozeb.
🔴 Obraťte se na bezpečnostní odborníky na začátku softwarového projektu, v jeho průběhu i během údržby.
🔴 Využijte model OWASP SAMM, který pomáhá strukturovat snahy o bezpečný vývoj.
Jak zranitelnosti předcházet
🔴 Zaveďte a používejte bezpečný životní cyklus vývoje.
🔴 Oslovte AppSec profesionály, kteří pomáhají vyhodnocovat a navrhovat kontroly související se zabezpečením a ochranou soukromí.
🔴 Vytvořte a používejte knihovny bezpečných návrhových vzorů nebo zpevněných cest (paved roads) připravených k použití.
🔴 Použijte modelování hrozeb pro kritickou validaci, řízení přístupu, byznys logiku a klíčové toky.
🔴 Integrujte zabezpečení a kontroly do user stories.
🔴 Integrujte kontroly věrohodnosti na každé úrovni aplikace (od frontendu po backend).
🔴 Pište unit a integration testy a ověřte, zda jsou všechny kritické toky odolné proti modelu hrozeb.
🔴 Sestavte případy použití a špatného použití pro každou úroveň aplikace.
🔴 Omezte resources pro uživatele nebo služby (např. můžete nahrát maximálně 2 obrázky za den).
Příklad zneužití zranitelnosti
- Postup pro obnovu hesla může obsahovat "otázky a odpovědi", což je zakázáno normou (NIST 800-63b, OWASP ASVS a OWASP Top 10). Otázky a odpovědi nelze považovat za důkaz správné identity, protože odpovědi může znát více lidí. Takový kód by měl být odstraněn a nahrazen bezpečnějším designem.
- Webové stránky eshopu nemají ochranu proti botům provozovaným překupníky, kteří nakupují špičkové grafické karty. To dělá výrobcům karet a provozovateli eshopu špatnou pověst, protože zákazníci tyto karty nemohou za žádnou cenu získat. Pečlivý design proti botům a domain logic pravidla, jako jsou nákupy do několika sekund od dostupnosti by mohly identifikovat jako neautentické a odmítnout je.