Přeskočit na hlavní obsah

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

  1. Bezpečný kód už má na YouTube přes 100 odběratelů, děkuju!
  2. 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.
  3. 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.