Jak modelovat hrozby, jak zařadit bezpečnost do firemní kultury a další
Proč byste neměli používat prohlížečový správce hesel? Víte, co je threat modeling? A využíváte ho? S modelováním hrozeb vám pomůže přiložený checklist.
🏆 Téma: Modelování hrozeb (threat modeling)
Modelování hrozeb je činnost, kterou byste měli dělat pokaždé, když začínáte s vývojem nové aplikace nebo funkcionality.
Cílem threat modelingu je zjistit, jakým hrozbám je aplikace vystavena a jak jim efektivně předcházet.
Ve firmách se tato činnost často přeskakuje, protože je časově náročná a není na ni budget.
Osobně s tím nesouhlasím.
Pokud se vyvíjí nová aplikace, je potřeba udělat softwarový návrh, který by měl pojmout i činnost modelování hrozeb.
Pokud architekt nezná hrozby, není schopen navrhnout dostatečně kvalitní architekturu a zvolit vhodné technologie.
Pokud se vyvíjí nová funkcionalita, modelování hrozeb je otázka deseti minut.
Ne vždy se musí vytvářet model hrozeb. Důležité je zjistit, jakým způsobem se bude hrozbám předcházet a vhodně se doplní zadání dané funkcionality.
Nejjednodušší způsob, jak se s modelováním hrozeb dá vypořádat, je zeptat se sám sebe, zda je aplikace potenciálně náchylná na některou z OWASP Top 10 zranitelností.
Stačí se u každé z nich zeptat: “Týká se mě to?” a pokud je na některou z nich odpověď ANO, konkrétní hrozbě / zranitelnosti se patřičně věnujte.
Pokud se potýkáme s nějakou hrozbou, máme 4 způsoby, jak se k ní postavit:
Zmírnění - učiníme ochranná opatření (například implementujeme autorizaci pomocí rolí).
Převod - převedeme hrozbu na někoho jiného (typicky forma pojištění).
Vyhnutí se - danou funkcionalitu vůbec nebudeme dělat, čímž se zranitelnosti kompletně vyhneme.
Přijetí - přijmeme riziko takové, jaké je.
Tato varianta by měla být jako poslední a měla by být dostatečně obhájena, zejména pokud jde o funkcionalitu důležitou například pro byznys.
V ideálním případě je model hrozeb dokument, který obsahuje:
Diagram s funkcionalitou (aplikací), kde jsou vyznačené vstupy, výstupy, komunikační kanály a cesty, interní a externí služby.
Tabulku zjištěných hrozeb, která se sestaví na základě diagramu. Ptáme se jednoduše: “Co se může pokazit?”
Tabulku s vyhodnocením jak se k jednotlivým hrozbám postavíme (Přijmeme je? Zmírníme je?), prioritizací / hodnocením, návrhem, jak to udělat.
Soupis jednotlivých rozhodnutí, kdo a kdy je učinil.
STRIDE
Stride je asi nejznámější model hrozeb, který se používá k hledání zranitelností daného systému.
Používá se ve spojení se software návrhem aplikace.
STRIDE je zkratka oblastí (kategorií), kterým věnovat pozornost:
S = Spoofing (autentizace), T = Tampering (integrita), R = Repudiation (nepopiratelnost), I = Information disclosure (důvěrnost), D = Denial of service (dostupnost), E = Elevation of privilege (autorizace)
Checklist pro modelování hrozeb
Identifikujte aktiva, která potřebují zabezpečit.
Pochopte architekturu systému.
Aplikujte STRIDE nebo jinou kategorizaci (OWASP Top 10…) - pro každou komponentu nebo datový tok zvažte potenciální hrozby ze STRIDE kategorií.
Ohodnoťte hrozby a prioritizujte je na základě jejich dopadu a pravděpodobnosti.
Zvažte strategie, jak hrozbám předcházet.
Udělejte review s byznys ownerem a zvalidujte návrh.
Opakujte proces - threat modeling je nikdy nekončící proces, jak se vyvíjí aplikace, vyvíjí se i model hrozeb.
🎓 Učíme se společně
Co jsme se dozvěděli z přednášek, školení, čtení knih a dalších aktivit?
Proč nepoužívat prohlížečový správce hesel?
Autor: Štefan Prokop
Prohlížeče mají integrovaný správce hesel, který je nainstalovaný spolu s nimi.
Hesla jsou v tomto správci ukládána na lokální filesystem (do našeho PC).
Soubor je snadné najít a zjistit údaje ohledně šifrování hesel včetně privátního klíče.
Databáze s hesly je většinou SQLite, kterou jde snadno otevřít.
Kombinací privátního klíče a databáze je možné získat původní přihlašovací údaje.
Na GitHubu existuje spousta nástrojů, které dokážou údaje rozšifrovat automaticky.
Nástroje je možné distribuovat pomocí různých počítačových virů na koncové stanice obětí a získat tak jejich přihlašovací údaje.
Master Application Security, Threat Modeling, & Security Resilience
Přednášející: Dustin Lehr
Startupy nemusí prioritně řešit bezpečnost, protože dokud nemají produkt a market fit, tak nic neriskují.
Bezpečnost by měli řešit, až budou mít produkt a market fit, problém je, že to startupy nedělají a stále pokračují ve vývoji, aniž by řešili bezpečnost.
Měli bychom přesvědčovat zákazníky, aby chtěli mít svá data v bezpečí, nikoli firmy, které vytvářejí produkty.
Pokud chcete zajistit bezpečnost aplikací, musíte zjistit, jak se daří současné produkci (IDR, monitoring, pentesty, CI/CD) a na základě toho pak implementovat best practices.
Abyste zajistili nejen aplikační bezpečnost ve firmě, musí se zapojit lidi.
Lidi jsou často bráni jako největší hrozba, ale měli by být bráni jako největší příležitost.
Měli byste sestavit security champions tým, kam pozvete lidi na různých pozicích, kteří se zajímají o bezpečnost nebo k ní mají blízko.
Cílem je, aby tito lidé pak dál dělali osvětu ve firmě a propagovali zájem o bezpečnost.
Pořádejte s nimi pravidelné mítinky, na které pozvěte hosty z praxe.
Security champions dostávají drobné úkoly, na kterých pracují, a jejich práce se pravidelně vyhodnocuje (musí se stanovit cíle programu).
Jde o zařazení kybersecurity do firemní kultury.
Lidi často vidí bezpečnost jako nějaký blocker, security experti mají tendence dělat v organizaci změny, ale jejich cílem by mělo být dostat se na stranu ostatních lidí a vysvětlit jim, že hledáme společné řešení.
Security expert by neměl přicházet s řešením často, ale měl by vytvořit prostředí, kde pracovníci různých oddělení přijdou s řešením - svému prostředí lépe rozumí a ví, co je časově efektivní atp.
O jejich návrhu se dá potom dále diskutovat.
Security expert by měl s každým komunikovat jeho jazykem - s lídry se řeší byznys, s vývojáři vývoj atd., musí pochopit svoje publikum a jejich motivace.
Díky tomu dokáže předat svoji zprávu v závislosti na tom, na čem záleží.
📰 Co je nového
Bezpečný kód už má na YouTube přes 100 odběratelů, děkuju!
Najdete tam nová #haxing videa: Jak hacknout uživatelské heslo, jak zneužít SQL injection a cross site scripting (XSS) a veřejné stack traces = únik citlivých údajů.
Ke každému #haxing videu postupně tvořím i články na webu, které se dané problematice věnují.
Tento rok se na YouTube můžete těšit na spoustu videí nového formátu a nová videa týkající se hackování a opravy frontend zranitelností v Reactu, Angularu, Vue a dalších.
Nezapomeňte Bezpečný kód na YouTube sledovat, ať vám tento obsah neunikne.
OWASP vydal novou developer guide.
Developer guide popisuje, jak začlenit bezpečnost do životního cyklu vývoje software (SDLC).
Najdete zde základy bezpečnosti a popis bezpečnostních činností, které byste měli dělat v jednotlivých fázích vývoje - sběru požadavků, návrhu, implementaci, atd.
Kurz aplikační bezpečnosti a psaní bezpečného kódu pro vývojáře.
Začínám pracovat na online kurzu pro vývojáře, kde se budeme věnovat častým aplikačním zranitelnostem.
Kurz bude praktický a plný case studies, bude obsahovat ukázky zdrojového kódu a postupy, jak jednotlivým zranitelnostem efektivně předcházet.
Měli byste o takový kurz zájem, ať už ve firmě nebo jako jednotlivec? Pokud ano, odepište na tento e-mail. Stačí dát do zprávy: “takový kurz by mě zajímal”.
! Nic si tím neobjednáváte, jen mi dáváte zpětnou vazbu, že má tento kurz smysl dělat.
Toto téma taky nabízím jako jedno ze svých firemních školení, ty si můžete objednat na stefan@stefanprokop.dev.
😂 Závěrečný ftípek: Why did the football team fumble the handoff? They didn’t use a secure transfer method.
🙏 Vyplňte prosím zpětnou vazbu k newsletteru, ať je s každým vydáním lepší a lepší.
🔔 Sledujte Bezpečný kód na LinkedInu, kam pravidelně sdílím další novinky a know-how.