Integrace modelování hrozeb s DevOps
Tento příspěvek je autorem Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez a Ben Hanson
Úvod
Modelování hrozeb je důležitá metoda zabezpečení, která pomáhá identifikovat a určit prioritu nejdůležitějších rizik pro aplikaci nebo systém. Tento dokument obsahuje některé úvahy o tom, jak je možné efektivněji a efektivněji přijmout modelování hrozeb, integrovat ho s moderními metodologiemi a nástroji DevOps a zaměřit se na hodnotu poskytnutou všem různým subjektům zapojeným do životního cyklu vývoje softwaru.
Je to pro tebe papír?
Tento dokument je výsledkem práce malého týmu odborníků na modelování zabezpečení a hrozeb od Microsoftu a zahrnuje vstupy a nápady některých nejvýznamnějších odborníků mimo Microsoft. Snaží se vyřešit jednoduchou, ale urgentní otázku: co bychom měli udělat, abychom zajistili, že se proces modelování hrozeb, který používáme, aktualizuje na moderní požadavky, které jsou kladeny metodologiemi a DevOps, abychom poskytli požadovanou hodnotu za nejnižší cenu?
Pokud jste vlastníkem produktu, členem týmu zabezpečení nebo jednoduše vývojářem, který v rámci životního cyklu vývoje uvažuje o modelování hrozeb, je tento dokument určený pro vás.
Podobně platí, že pokud jste už přijali modelování hrozeb, můžete stále najít praktické nápady ke zlepšení procesu.
Dokument je však navržený tak, aby představil nápady na zlepšení aktuálních procesů nebo úspěšného přijetí modelování hrozeb jako součást procesu DevOps. Nezavádí konkrétní nástroje nebo produkty, i když doufáme, že tyto nápady implementované některými nástroji nebo produkty v budoucnu uvidíme. Proto zde nenajdete oznámení o nových nástrojích nebo náhledech nadcházejících funkcí.
Proč je modelování hrozeb důležité?
Modelování hrozeb je jedním z primárních přístupů k bezpečnému navrhování softwarových řešení. Prostřednictvím modelování hrozeb analyzujete systém, který identifikuje vektory útoku, a vyvíjíte akce pro zmírnění rizik, která tyto útoky přinesly. Vhodným způsobem je modelování hrozeb skvělou součástí jakéhokoli procesu řízení rizik. Může také pomoct snížit náklady tím, že včas identifikuje a opraví problémy s návrhem. Stará studie z NIST odhadla náklady na opravu problému návrhu v produkčním kódu přibližně 40krát vyšší než oprava během fáze návrhu. Šetří také náklady způsobené incidenty zabezpečení pro případné problémy s návrhem. Vezměte v úvahu, že náklady na únik dat ze společnosti IBM Security a Ponemon Institute odhadnou průměrné náklady na porušení zabezpečení dat v roce 2022 na 4,35 M. U takzvaných mega porušení, zahrnující ohrožení více než 50 milionů záznamů, průměrné náklady dosahuje 387 milionů DOLARŮ!
Modelování hrozeb je první aktivitou, kterou můžete udělat pro zabezpečení řešení, protože pracuje s návrhem řešení. Díky této vlastnosti je nejúčinnějším postupem zabezpečení, který můžete použít na SDLC.
Microsoft má dlouhou historii modelování hrozeb. V roce 1999 napsali dva (poté) zaměstnanci Microsoftu Loren Kohnfelder a Praerit Garg dokument, hrozby pro naše produkty. Tento dokument představil přístup STRIDE, což je synonymum pro proces modelování hrozeb Microsoftu.
Modelování hrozeb je vývojový proces
Modelování hrozeb není statický proces; vyvíjí se, jak se mění potřeby a technologie.
Útoky dodavatelského řetězce, jako je nedávný model, který cílí na SolarWinds , ukazují potřebu pokrýt více scénářů modelování hrozeb než samotné řešení, včetně vývoje a nasazení.
Ohrožení zabezpečení open source, jako je nedávné řešení pro Log4j , ukázalo, že je potřeba doplnit aktuální přístup na základě přijetí nástrojů pro analýzu složení softwaru ke kontrole ohrožených komponent tak, že řešení navrhnete defenzivně tak, aby se omezilo jeho vystavení.
Použití nových technologií, jako je Machine Učení, zavádí nové vektory útoku, které musí být srozumitelné a řízené. Zvažte například možnost hrát škodlivé zvuky neschválné lidskými ušimi, aby způsobily provádění příkazů službami umělé inteligence, jak je popsáno v https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlinitématu .
V Microsoftu si různé produktové skupiny procvičují různé varianty modelování hrozeb na základě konkrétních požadavků na zabezpečení. Cílem každé varianty je zaručit odpovídající úroveň záruky zabezpečení pro scénáře, na které se vztahuje, ale to, na co "adekvátní" znamená změny v závislosti na konkrétním kontextu.
Zabezpečení Windows se například liší od zabezpečení služeb Azure Cognitive Services, protože tyto systémy mají velmi různé velikosti a charakteristiky. Klíčovým aspektem modelování hrozeb je vyvážení nákladů na odolnost vůči rizikům pro aplikaci. I když to může vést k rozhodnutí, že se v některých scénářích úplně vyhnete modelování hrozeb, je to tak efektivní, když to správně uděláte, že ho můžeme doporučit pouze pro jakoukoli iniciativu IT, včetně projektů pro vývoj softwaru a nasazení infrastruktury.
Význam zaměření na návratnost návratnosti
V posledních několika letech došlo k stabilnímu nárůstu zájmu o modelování hrozeb jako klíčového procesu vývoje softwaru. Tento zájem je způsoben exponenciálním nárůstem útoků na infrastrukturu a řešení. Iniciativy, jako je doporučený minimální standard NIST pro dodavatele nebo ověření kódu pro vývojáře, a manifest modelování hrozeb dále zvýšily poptávku na bod, kdy aktuální přístupy ukázaly určité limity. Například výsledky modelování hrozeb jsou vysoce závislé na přijatém procesu a na tom, kdo model hrozeb provádí. Proto je třeba mít obavy, že se konzistentně zkvalitní prostředí.
Co ale znamená kvalita modelování hrozeb? Pro nás musí mít model hrozeb pro kvalitu následující charakteristiky:
Musí identifikovat akceovatelné zmírnění rizik, aktivity, které můžete udělat, abyste snížili potenciální ztráty vyplývající z útoků. To znamená, že tato omezení rizik musí být dobře definovaná, což znamená, že získáte dostatek informací k jejich implementaci a pak otestujete implementaci. To také znamená, že musí být poskytovány, aby bylo možné snadnou spotřebu od vývojového týmu. U DevOps a agilního přístupu to znamená, že existuje snadná cesta k importu omezení rizik do backlogu.
U každého zmírnění rizik musí identifikovat svůj stav. Některá omezení rizik jsou nová, zatímco jiné už existují. Model hrozeb musí rozpoznat, co už existuje, a zaměřit se na aktuální riziko, aby bylo možné identifikovat, jak situaci zlepšit.
Musí jasně určit, proč je každé zmírnění rizik vyžadováno tím, že je propojí s příslušnými hrozbami.
Omezení rizik navíc mají relativní sílu pro každou hrozbu. Například šifrování TLS může být silným zmírněním rizika, že se data během přenosu zveřejní, a zároveň může být téměř kompletním zmírněním rizika falšování serveru.
Hrozby musí být důvěryhodné, dobře definované a specifické pro řešení.
Hrozby musí mít přidruženou závažnost, která by měla zvážit pravděpodobnost i dopad. Závažnost musí být rozumná a ideálně nestranná.
Mělo by být možné získat komplexní přehled o rizicích a jejich řešení. Toto zobrazení by bylo užitečné při řízení smysluplné konverzace s bezpečnostním týmem a s pracovníky s rozhodovací pravomocí a umožnilo by nám skrýt nepotřebné složitosti.
Tento seznam již ukazuje důležitý koncept: Modelování hrozeb může poskytnout hodnotu mnoha rolím zapojeným během životního cyklu softwaru, ale každá role má různé potřeby a požadavky. Vývojáři například potřebují získat jasné informace o tom, co potřebují implementovat, a o tom, jak ověřit, že se implementované chování chová podle očekávání. Na druhou stranu se bezpečnostní tým obvykle zabývá celkovým zabezpečením ekosystému infrastruktury a aplikací vlastněných organizací; proto musí obdržet informace, které umožňují rozhodnout, zda je systém v rozsahu dostatečně zabezpečený a splňuje jeho požadavky na dodržování předpisů. Nakonec musí vlastníci produktů a pracovníci s rozhodovací pravomocí pochopit, co je nezbytné k tomu, aby rizika byla pro organizaci přijatelná.
Takové různé potřeby vyžadují, aby poskytovaly různá zobrazení modelu hrozeb. Každý z nich se zaměřuje na konkrétní scénář použití.
Typickým problémem s modelováním hrozeb je, že čím více je úspěšné, tím více je pro několik dostupných odborníků obtížné pokrýt poptávku a zároveň zajistit vysokou kvalitu očekávanou z tohoto prostředí. V některých případech může být kvalita ovlivněna negativně. Vše je dobré, dokud modelování hrozeb nezastaví ve srovnání s investicí významnou hodnotu. Tento problém má vliv na více než několik organizací. Existuje několik zpráv o modelování hrozeb začínajících pracovníky s rozhodovací pravomocí, protože by se nepodařilo zajistit významnou hodnotu nákladů.
S hodnotou se podíváme na obchodní hodnotu, což je schopnost poskytnout informace potřebné k pochopení rizik představovaných systémem v oboru a řídit smysluplný rozhodovací proces pro výběr správných zmírnění rizik, která se mají implementovat. Kromě toho hodnota souvisí také s poskytováním správných informací vývojářům a testerům. Nakonec hodnota souvisí se sdělením zbytkového rizika se všemi zúčastněnými stranami. Můžeme například změřit hodnotu měřením dopadu procesu modelování hrozeb. Předpokládejme, že změříme celkové riziko řešení tím, že přiřadíme číslo závažnosti identifikované ke každé hrozbě. V takovém případě očekáváme, že celkové riziko se v průběhu času sníží podle účinku modelu hrozeb. Pokud celkové riziko zůstává konstantní nebo se zvyšuje, může dojít k problému. Čím větší je pokles, tím vyšší dopad modelu hrozeb. Model hrozeb by samozřejmě neovládl implementované zmírnění rizik. Je zodpovědností vlastníka produktu rozhodnout, co se musí implementovat. Výhodou propojení efektivity modelu hrozeb se skutečnou implementací zmírnění rizik je, že zvyšuje dopad na skutečné zabezpečení řešení a snižuje riziko, že model hrozeb zůstává teoretickou zátěží.
Místo toho náklady souvisejí s aktivitami nezbytnými k provedení samotného modelu hrozeb, což je čas potřebný všemi zúčastněnými stranami k vytvoření modelu hrozeb a jeho diskuzi.
Tato otázka se týká: Můžeme definovat proces modelování hrozeb zaměřený na maximalizaci obchodní hodnoty a minimalizaci nákladů?
Důležitost DevOps
Už jsme zdůraznili, jak důležité je zajistit, aby modelování hrozeb bylo cenným postupem integrovaným s procesem DevOps. To znamená, že proces musí být dostupný všem členům týmu, obvykle zjednodušením a automatizací. Nejdůležitější je, že zaměření na modelování hrozeb pro DevOps znamená, že musíme zajistit, aby prostředí bylo hluboce integrované se stávajícími procesy DevOps.
Modelování hrozeb by nemělo být ještě další zátěží, alemělo by to být prostředek, který by usnadnil požadavky na zabezpečení a shromažďování, návrh zabezpečených řešení, zahrnutí aktivit do nástroje Pro sledování chyb a vyhodnocení zbytkového rizika vzhledem k aktuálnímu a budoucímu stavu řešení.
Sladění s DevOps
K sladění modelování hrozeb s aktuálním postupem DevOps můžeme použít různé techniky.
Hrozby a zmírnění rizik
Nejprve musíme zaměřit proces modelování hrozeb na to, co je potřeba udělat. Hrozby, což jsou vzorce útoku a způsob jejich vzniku, jsou nezbytné k vysvětlení, proč tým potřebuje implementovat bezpečnostní kontrolu. Jsou také faktorem při určování, kdy je třeba provést zmírnění rizik. Skutečný cíl je přesto určit, co je potřeba udělat: zmírnění rizik. Proto musí přístup vést k rychlé identifikaci požadovaných zmírnění rizik a musí informovat rozhodovací proces, aby bylo snazší určit, co dělat a kdy. Hlavní dodávkou tohoto rozhodovacího procesu je vybrat zmírnění rizik v backlogu, aby je bylo součástí standardního procesu. V ideálním případě by se měl nástroj pro modelování hrozeb a nástroj pro sledování chyb a úloh synchronizovat tak, aby odrážely aktualizace stavu zmírnění rizik v modelu hrozeb. To by umožnilo dynamicky a automaticky revidovat reziduální riziko, což je nezbytné k podpoře informovaných rozhodnutí v rámci obvyklých tanečních metodik agilních metod, jako je například schůzka plánování sprintů.
Co můžete dnes dělat?
Jako odborník na modelování hrozeb byste měli zajistit implementaci procesu modelování hrozeb, který dokáže jasně identifikovat akce a zahrnout je do zvoleného úkolu a sledování chyb. Jedním ze způsobů, jak tento proces automatizovat, může být jeden z mnoha nástrojů pro modelování hrozeb.
Jako vývojář byste se měli zaměřit na bezpečnostní prvky, které jsou identifikovány podle potřeby. Proces by měl být navržený tak, aby vám je poskytl stejným způsobem, jakým očekáváte, že obdržíte jakoukoli jinou aktivitu.
Funkce, uživatelské scénáře a úkoly
Už jsme uvedli, že zmírnění rizik představuje nejdůležitější artefakt vytvořený modelem hrozeb, který se týká integrace DevOps. Proto je důležité jasně definovat typ objektů vytvořených z těchto omezení rizik v nástroji Pro sledování úloh a chyb podle výběru. Některá omezení rizik můžou trvat déle než sprint. Proto může být nejlepší je vytvořit jako funkce. Ale mnoho je jednodušší a lze je implementovat v jednom sprintu; proto by bylo možné je znázornit jako uživatelské scénáře nebo úkoly. I když může být možné generovat různé typy pracovních položek, může to vést ke složitému procesu, který může vést k chybám a nejasnostem. Z tohoto důvodu se zdá být praktičtější držet se s jedním typem pracovní položky. Vzhledem k tomu, že zmírnění rizik může být považováno za podřízené uživatelské scénáře, můžete zvážit jejich reprezentaci jako Úkoly, což znamená uvolnění požadavku na provedení uvedeného typu pracovní položky v jednom sprintu.
Co můžete dnes dělat?
Ujistěte se, že jsou v backlogu reprezentována zmírnění rizik identifikovaná modelem hrozeb. Identifikujte způsob, jak je jasně znázornit.
Uživatelské scénáře
Zmírnění rizik nejsou jedinými artefakty, které jsou součástí modelu hrozeb, které by mohly a měly by být v souladu s tím, co máte v nástroji Pro sledování úloh a chyb. Můžete například chtít představovat i hrozby. Tohoto cíle lze dosáhnout rozšířením uživatelských scénářů přidáním klauzule WITHOUT na obvyklé "Jako [kdo jsem] chci [co chci] tak, abych mohl [něco udělat]." Například: "Jako uživatel chci zaplatit platební kartou, abych si mohl koupit nějaké zboží bez odcizení údajů z platební karty". Klauzule WITHOUT může být namapována na jednu nebo více hrozeb a někdy je možné vyjádřit požadavky na zabezpečení. Tím, že zajistíme, aby toto zarovnání mezi hrozbami a klauzulemi WITHOUT bylo explicitně provedeno v rámci modelu hrozeb, můžeme zajistit, aby se případná rizika projevila a postarala se o ně tým, protože jsou součástí uživatelských scénářů. Tento vztah můžete také použít k mapování všech požadavků na zabezpečení identifikovaných jako součást uživatelských scénářů na alespoň hrozbu.
Je dobré vědět
Klauzule WITHOUT není původní myšlenkou týmu, který tuto stránku vytvořil. Nejsme si jistí, kdo ho poprvé představil, ale jsme vděční, kdo s touto myšlenkou přišel.
Obrázek 1: Sladění požadavků
Například předchozí obrázek ukazuje následující situace:
Hrozba A je propojena s uživatelským scénářem 1 prostřednictvím klauzule WITHOUT 1.
Hrozba B je propojena s uživatelským scénářem 2 prostřednictvím klauzule WITHOUT 2.
Hrozba B je také propojena s uživatelským scénářem 3. Uživatelské scénáře 3 se ale nepřiřazují k žádné klauzuli WITHOUT. Proč? Představuje potenciální anomálii, kterou byste měli prozkoumat.
Hrozba B je také propojena s uživatelským scénářem 1. Zatím není jasné, jestli bychom měli umožnit propojení uživatelských scénářů s více než jednou hrozbou.
Hrozba C je propojena s uživatelským scénářem 4, který je přidružený k WITHOUT 3 a 4. Zatím není jasné, jestli bychom měli povolit více než jednu klauzuli WITHOUT.
Hrozba D není propojená s žádným uživatelským scénářem. Chybí nám uživatelský příběh nebo klauzule WITHOUT?
User Story 5 je propojen s klauzulí WITHOUT, ale nemá žádnou přidruženou hrozbu. Chybí nám hrozba nebo prostě propojení mezi uživatelským scénářem a hrozbou?
V rámci modelu hrozeb zřídka identifikujeme požadavky na zabezpečení. Klauzule WITHOUT proto zavádí příležitost k další integraci prostředí rozšířením modelů hrozeb s požadavky na zabezpečení a jejich propojením se souvisejícími uživatelskými příběhy. Tento přístup by hrál významnou roli při vývoji prostředí pro modelování hrozeb, protože se v průběhu času opakuje hodnocení, aby se stal nástrojem pro návrh zabezpečení pro DevOps.
Co můžete dnes dělat?
Začněte používat klauzuli WITHOUT v rámci uživatelských scénářů.
Namapujte hrozby, které identifikujete, na uživatelské scénáře pomocí klauzulí WITHOUT a naopak.
Integrované prostředí
Stejný nápad můžete použít i v jiných scénářích. Model hrozeb může například propojit požadavky na zabezpečení s artefakty uvnitř samotného modelu hrozeb , jako jsou hrozby a zmírnění rizik , a ty v nástroji Sledování a sledování chyb. Například požadavek na implementaci monitorování pro identifikaci probíhajících útoků by se měl mapovat na všechna omezení rizik související s monitorováním a potom na odpovídající artefakty v nástroji Pro sledování úloh a chyb. V důsledku toho by bylo snadné identifikovat situace, kdy není dosažen požadavek na zabezpečení: ve skutečnosti by nebyla propojena s ničím.
Pomocí stejných propojení mezi artefakty v nástroji Pro sledování úloh a chyb a hrozbami a zmírněními rizik identifikovanými modelem hrozeb můžete usnadnit stanovení priorit aktivit zabezpečení. Zabezpečení se obvykle implementuje jako poslední, někdy kvůli řešení reaktivních ohrožení zabezpečení identifikovaných některým nástrojem nebo penetračním testem. Naopak by bylo nejúčinnější implementovat zmírnění rizik spolu se souvisejícími uživatelskými příběhy nebo funkcemi. Proč počkat na implementaci kontrolních mechanismů, abyste zajistili podrobnosti o platební kartě, když byste je měli implementovat spolu se souvisejícími platebními funkcemi? Model hrozeb by měl tyto relace zvýraznit a poskytnout jednoduchý způsob, jak určit, kdy během sprintu implementuje nějakou funkci zabezpečení, vyžaduje implementaci některé související funkce zabezpečení. Tyto informace je možné použít například během schůzky plánování sprintů, aby bylo možné smysluplně diskutovat a řídit informované stanovení priorit. Mechanismus je jednoduchý. Předpokládejme, že vlastník produktu pro projekt, na který pracujeme, se rozhodne naplánovat uživatelský scénář pro další sprint. Uvedený uživatelský příběh má klauzuli WITHOUT, která je propojena s hrozbou. Model hrozeb identifikuje několik omezení rizik pro stejnou hrozbu. Proto můžeme okamžitě odvodit, že bychom měli určit prioritu jednoho nebo více zjištěných zmírnění rizik.
Obrázek 2: Stanovení priority zabezpečení
Například na obrázku výše vidíme, že uživatelský scénář 1 je propojený s hrozbou 1, která je zase propojená se zmírněním rizik A a B. Proto bychom měli zvážit také implementaci jednoho nebo obou těchto omezení rizik.
Co můžete dnes dělat?
Propojte uživatelské scénáře s klauzulí WITHOUT s pracovními položkami odpovídajícími vybraným zmírněním rizik pomocí modelu hrozeb jako odkazu. Při plánování dalšího sprintu nezapomeňte určit prioritu propojených aktivit zabezpečení při implementaci jednoho z těchto uživatelských scénářů pomocí klauzulí WITHOUT.
Integrace s cílem zvýraznit chybné zarovnání
Jakmile začneme přemýšlet o tom, jak bychom mohli propojit artefakty, které vytváří model hrozeb, s artefakty v nástroji Pro sledování úloh a chyb, bude jednodušší identifikovat příležitosti ke zlepšení kvality obou. Klíčem je využít jejich vztahy ke zvýraznění nesrovnalostí a využití informací v jednom k doplnění, integraci a interpretaci toho, co se v druhém nachází. Jak je popsáno výše, můžete to udělat bez významného dopadu na to, jak už tým funguje. Je to proto, že přístup spoléhá na existující informace a vytváří vztahy mezi různými objekty v různých světech. Proto by se model hrozeb stal zdrojem pravdy pro zabezpečení řešení. Backlog je současně nepřetržitě v souladu se stavem řešení.
Co můžete dnes dělat?
Pravidelně ověřte, že neexistují žádné nenamapované hrozby ani uživatelské scénáře s klauzulí WITHOUT.
Modelování hrozeb a operace
Všechny tyto myšlenky se zaměřují hlavně na vývojovou stranu DevOps. Můžeme také udělat něco pro zlepšení provozu? Myslíme si to. Například by bylo možné použít modelování hrozeb jako nástroj pro usnadnění analýzy původní příčiny, protože poskytuje komplexní pohled na systém z hlediska zabezpečení, a tak může lépe porozumět důsledkům některých útoků. Aby toho bylo možné dosáhnout, bylo by nutné integrovat model hrozeb se stávajícími informačními kanály z vybraných monitorovacích nástrojů. Tento přístup může představovat doplněk pro zvolený siEM.
Další myšlenkou integrace modelování hrozeb s operacemi je použití první k řízení návrhu toho, jak by se mohlo stát. Příkladem je návrh událostí pro řešení. Modelování hrozeb identifikuje možné útoky a tyto znalosti můžeme použít k identifikaci událostí, které řešení v oboru může vyvolat, když tyto útoky selžou. Pokud provedete přísné ověření vstupu, bude útočník se zlými úmysly potřebovat několik pokusů, než bude úspěšný. Na začátku pokusy selžou a jeden z nich nakonec uspěje. Vyvoláním událostí pro každé selhání a aktivací výstrah při dosažení určité prahové hodnoty můžete detekovat útoky a provádět akce k jejich nápravě. Tyto situace se zřídka zjistí, pokud omezíte monitorování infrastruktury. Proto je nutné zahrnout vlastní události, které tým musí navrhnout a implementovat, aby je SOC mohl využít.
Kromě toho nemusí o řešení moc vědět. SoC proto nemusí být schopen určit, jak reagovat při selhání ověření vstupu. Když dojde k porušení zabezpečení dat, je bohužel nutné rychle reagovat, aby se snížila přímá poškození a pravděpodobnost a entita konečných pokut.
Proto musíme předem naplánovat, co je potřeba monitorovat, za jakých podmínek můžeme mít problém a co dělat, když k tomu dojde. Nejlepším způsobem, jak tyto události identifikovat, je spoléhat se na model hrozeb. Proto by bylo užitečné využít ho k vygenerování standardizovaných artefaktů, které vám umožní řídit a urychlit implementaci nezbytných konfigurací pro řízení monitorování a auditování a usnadnění reakce na incidenty.
Co můžete dnes dělat?
Aktivně používejte model hrozeb k identifikaci událostí, které můžete pro každou hrozbu vyvolat. Tyto události mohou poskytovat infrastruktura nebo něco, co aplikace musí vyvolat. Zahrňte do backlogu pracovní položky, abyste měli jistotu, že jsou tyto události implementované.
Aktivně spolupracujte s provozními a bezpečnostními týmy, včetně týmu SOC, a zajistěte, aby se události využívaly k vyvolání výstrah a identifikaci incidentů zabezpečení.
Dopad na návratnost návratnosti
Možná vás zajímá, proč tyto techniky mohou pozitivně ovlivnit návratnost návratnosti hrozeb modelování. Z našeho pohledu jsou zásadní pro zvýšení hodnoty modelování hrozeb pro týmy DevOps. Problémem, který jsme viděli opakovaně, je, že tyto týmy vnímají zabezpečení jako náklady, které poskytují omezenou hodnotu a vyžadují mnoho nepředvídatelné práce. Někdy není jasné, proč by měli investovat tolik času na opravu zabezpečení. V důsledku toho se zabezpečení stává problémem místo příležitosti. Modelování hrozeb má potenciál tyto problémy překonat, protože poskytuje důvody k implementaci zabezpečení. Kromě toho může být zahájen v rané fázi procesu vývoje a vyhnout se chybám návrhu, které mohou být nákladné, pokud nebyly brzy zjištěny. Výše uvedené techniky se zaměřují na lepší integraci modelování hrozeb s DevOps. Tím zajistíte, aby pracovníci s rozhodovací pravomocí a vývojáři vnímali modelování hrozeb jako přirozený doplněk k procesu vývoje a provozu. Proto se hodnota přijatá přijetím modelování hrozeb zvyšuje a její náklady se snižují kvůli integraci s různými nástroji, které už se používají.
Zjednodušení práce pro modelátory hrozeb
Dalším důležitým aspektem nezbytným ke zlepšení NÁVRATNOSTI modelování hrozeb souvisí se snížením nákladů a zvýšením počtu lidí, kteří ho mohou dodat a současně zachovat homogenní úroveň kvality.
Existuje mnoho pokusů o řešení nedostatku příslušných lidí. Některé z nich vycházejí z aktivního zapojení celého týmu DevOps do cvičení modelování hrozeb. Cílem je identifikovat vedoucího iniciativy, což je někdo s pokročilými znalostmi o procesu, ale nemusí být nutně odborníkem a vést diskuzi mezi ostatními členy týmu. Tento přístup aktivně podporuje signatáři manifestu modelování hrozeb.
Souhlasíme s tím, že tento přístup umožňuje získat dobrou hodnotu a představuje zlepšení oproti aktuální situaci. Poskytuje také dobré přehledy a umožňuje týmu rozvíjet svou kulturu zabezpečení. Nicméně to není bez nevýhod, protože se týká jen několika problémů, vynechává hodně. To vytváří problém konzistence, protože by bylo příliš snadné jít dolů do králík díry a ztrácet drahocenný čas na sekundární problémy, chybí důležité. Zkušenosti vedoucího procesu by hrály významnou roli při předcházení těmto situacím. Kromě toho tento přístup vyžaduje mnoho času od všech členů týmu, aby mohli prodiskutovat jednotlivé problémy.
Z tohoto důvodu může dokonce strávit několik hodin za sprint pro toto cvičení významnou investici. Každý ví, že většina týmů má tendenci ztrácet čas na velkých schůzkách zahrnujících všechny, a tyto relace modelování hrozeb by neprošly výjimkou. Přesto je tento přístup vynikající pro malé produkty, kde se tým skládá z několika starších členů.
Jiný přístup
Vzhledem k omezením předchozího přístupu dáváme přednost omezení počtu schůzek, jejich délky a počtu účastníků. Odpovědnost modelátora hrozeb by proto byla důležitější: nejen vést rozhovory, ale také vytvořit a udržovat samotný model hrozeb. Tento přístup vyžaduje významnější kompetence a odborné znalosti. Modelátoři hrozeb můžou být reprezentováni šampiony zabezpečení nebo členy interního bezpečnostního týmu. Většinaorganizacích
Šampioni zabezpečení jsou členy týmů DevOps s konkrétním zájmem o zabezpečení. Nejsou odborníky žádným způsobem, ale mají základní znalosti a ochotu zlepšit stav zabezpečení svého týmu. Cílem je vytvořit privilegované propojení mezi šampiony zabezpečení a interním týmem zabezpečení, aby první zmocněl svým týmům při provádění správné věci, zatímco bezpečnostní tým může snížit své úlohy. Při modelování hrozeb by šampioni zabezpečení fungovali jako modelátoři hrozeb a interní bezpečnostní tým by měl zodpovědnost je řídit a kontrolovat svou práci.
Co můžete dnes dělat?
Prozkoumejte možnost přijmout program Security Champions a využít ho k dalšímu posílení životního cyklu vývoje zabezpečeného softwaru.
Role znalostní báze
Důležitým problémem při modelování hrozeb je zajištění kvality prostředí a hodnoty týmu DevOps, ať už model hrozeb provádí, je vysoká. S bezpečnostními šampiony se tento problém stává ještě naléhavější. Cílem tohoto řešení je poskytnout znalostní báze k vytvoření modelu hrozeb. Znalostní báze pro modelování hrozeb jsou balíčky informací o konkrétním kontextu: obsahují definici entit souvisejících s tímto kontextem, možné vzory útoku nad těmito entitami a standardní omezení rizik, která je možné použít. Znalostní báze umožňují organizaci získat lepší a konzistentnější výsledky, protože představují referenční materiál, který vede modelátory hrozeb preskriptivním způsobem. Znalostní báze by měly mít pravidla, která nám umožňují automaticky aplikovat hrozby a zmírnění rizik na systém. Tato automatizace by nám umožnila překonat skutečnost, že někteří modelátoři hrozeb nemusí mít zkušenosti potřebné k určení, jestli by se měla hrozba použít nebo jestli je nějaké zmírnění účinné.
Znalostní báze nejsou novou myšlenkou: mnoho stávajících nástrojů pro modelování hrozeb je již v nějaké podobě podporuje. Mnoho aktuálních implementací má ale významné nevýhody. Měli byste být například schopni snadno udržovat znalostní báze. Jejich udržovatelnost je problém, který je stále nevyřešený. Například není snadné identifikovat nejlepší zdroje informací, které se mají použít k jejich vytváření. Údržba je navíc obvykle ruční. Vytvoření a údržba znalostní báze by měla být odpovědností interního bezpečnostního týmu organizace. Doufáme, že společnosti začnou poskytovat znalostní báze pro nejběžnější nástroje pro modelování hrozeb, aby v budoucnu zvedaly některé zátěže od svých zákazníků. Tyto znalostní báze by měly být flexibilní, aby podporovaly a usnadnily jejich přijetí i ty nejzralější organizace, které potřebují přizpůsobit uvedené znalostní báze svým postupům, zásadám a předpisům.
Co můžete dnes dělat?
Zvažte možnost věnovat část úsilí centralizovaného týmu zabezpečení pro vývoj znalostní báze, které mohou využívat různé vývojové týmy k urychlení modelování hrozeb.
Využívání znalostní báze
Dalším problémem s znalostní báze je, že někdy jsou příliš složité na využívání. Mnohé z nich se snaží být komplexní zahrnutím základních a méně kritických problémů. Bohužel, ne všechny jsou vyžadovány všemi systémy. Pokud je systém, který analyzujete, malý a nezpracuje citlivá data, měli byste použít jednodušší přístup. Naopak byste chtěli podrobněji projít, pokud je systém složitý a zpracovává PII a data s vysokou obchodní hodnotou. Proto by mělo být možné použít různé verze znalostí v závislosti na kontextu nebo označit některé vzory útoku a související zmírnění rizik jako TOP. V důsledku toho by se modelátoři hrozeb mohli rozhodnout, jestli chtějí komplexní prostředí, nebo snadno a minimalizovat požadovanou práci.
Když mluvíme o efektivitě, je nezbytné zajistit, aby byly aktivity co nejvíce zjednodušené a automatizované, aby se snížilo množství požadované práce. Myslíme si, že by pro model modelování hrozeb mělo být 1 den práce pro modelátora hrozeb. Tyto výsledky jsou možné pouze v případě, že nástroj podle výběru poskytuje akcelerátory, aby bylo možné vyříznout požadovaný čas. Pokud nástroj například použije 20 různých typů zmírnění rizik na 100 různých místech a požadujete, abyste pro každý z nich určili jejich stav, budete 5krát efektivnější tím, že se zaměříte na první místo na druhý. Nástroj, který si zvolíte, by měl tuto funkci poskytnout a zároveň poskytnout možnost provádět důkladnější práci v případě potřeby.
Co můžete dnes dělat?
Pokud znalostní báze, které dnes používáte, nepodporují koncept "TOP" hrozeb a zmírnění rizik, zvažte možnost odstranit to, co je zřídka nezbytné nebo užitečné, aby se mohli soustředit pouze na to, co je skutečně důležité.
Někdy je problém, že se přijatá znalostní báze snaží být obecná a pokrývají více scénářů. Situaci můžete zlepšit tím, že se na ně specializujete.
Kladení správných otázek
Během naší analýzy jsme zvážili možnost použití nástroje pro podporu architektury Otázek k řízení prvních fází analýzy. Všimli jsme si, že většina nezkušených modelátorů hrozeb nemůže klást správné otázky, aby získali informace potřebné pro jejich analýzu. Někteří z našich expertů ukázali, že je možné určit některé zásadní otázky na základě systémového diagramu v oboru. Tyto otázky se dají použít i automaticky s některými pravidly generování. Problémem je, že tento přístup nemusí poskytnout hodnotu, kterou se zdá slibovat. To by bylo proto, že potřebujete porozumět odůvodnění každé otázky. Jinak byste nemohli odpověď vyhodnotit a určit, jestli je uspokojivá. Generování automatizovaných otázek ale může přinést významné hodnoty méně zkušeným modelátorům hrozeb a zlepšit jejich porozumění systémům v rozsahu.
Co můžete dnes dělat?
Přijměte strukturovaný přístup k kladení otázek. Náš tým například měl dobré výsledky tím, že jako referenci přijal Microsoft STRIDE. Můžete to udělat tak, že požádáte o každou komponentu otázek řešení, jako jsou:
Falšování identity: jak se komponenta ověřuje ve službách a prostředcích, které používá?
Manipulace: Ověřuje komponenta zprávy, které přijímá? Je ověřování volné nebo přísné?
Repudiation: Je komponenta protokolování interakcí v protokolu auditu?
Zpřístupnění informací: Je příchozí a odchozí přenos, který komponenta šifruje? Jaké protokoly a algoritmy jsou povolené?
Odepření služby: Je komponenta nakonfigurovaná ve vysoké dostupnosti? Chrání se před útoky DDoS?
Zvýšení oprávnění: Mají uživatelé přiřazená nejnižší požadovaná oprávnění? Kombinuje řešení kód cílený na normální uživatele s tímto kódem pro vysoce privilegované uživatele?
Techniky, jako je tato, se dají naučit a dají se vylepšit s využitím zkušeností. Proto je důležité implementovat průběžný Učení přístup navržený ke shromažďování učení a jejich šíření v rámci organizace.
Dopad na návratnost návratnosti
V dolní části je možné identifikovat mnoho nápadů ke zlepšení efektivity prostředí modelování hrozeb, jeho kvality a nakonec zvýšit návratnost návratnosti. Toto úsilí by však mělo být považováno za probíhající proces, který by měl být směrován na průběžné vylepšování praxe.
Závěry
Modelování hrozeb je vynikající metodologie pro zlepšení zabezpečení vaší organizace. Pokud to uděláte správně, může poskytnout hodnotu za velmi rozumné náklady. Již jsme identifikovali různé techniky, které mohou být nezbytné pro zlepšení hodnoty modelování hrozeb pro zabezpečení moderních řešení, včetně:
Sladění modelu hrozeb s postupem DevOps
Zaměření na zmírnění rizik
Omezení rizik propojení s uživatelskými příběhy
Zvýrazněte nesrovnalosti mezi modelem hrozeb a backlogem.
Použití modelu hrozeb k zajištění komplexnějšího monitorování a auditování zabezpečení
Zjednodušení vytváření modelů hrozeb a zvýšení konzistence výsledků
Spoléhat se na šampiony zabezpečení
Přijetí znalostní báze k automatizaci identifikace hrozeb a zmírnění rizik
Vytváření lepších znalostní báze
Poskytnutí architektury pro otázky podporované automatizací
Doufáme, že některé z nich už najdete ve vašem nástroji pro modelování hrozeb podle vlastního výběru. Ostatní budou zahrnuti v budoucnu. Víme, že maximalizace NÁVRATNOSTI pro modelování hrozeb je dlouhodobé úsilí, které vyžaduje odpovědi, které ještě nemáme. Víme také, že některé otázky jsou stále neznámé. Tento dokument by měl poskytnout nějaké jídlo pro myšlenky a snad vám může pomoct zlepšit způsob modelování hrozeb. Doufáme, že to může být maják pro vás a nás, a že bude užitečné nasměrovat naše úsilí na další roky.