Doporučení pro analýzu hrozeb

Platí pro toto doporučení kontrolního seznamu zabezpečení azure Well-Architected Framework:

Z:02 Vytvořte standardní hodnoty zabezpečení, které odpovídají požadavkům na dodržování předpisů, oborovým standardům a doporučením platformy. Pravidelně měřte architekturu a operace úloh na základě standardních hodnot, abyste udrželi nebo zlepšili stav zabezpečení v průběhu času.

Související příručka: Doporučení pro zabezpečení životního cyklu vývoje

Komplexní analýza k identifikaci hrozeb, útoků, ohrožení zabezpečení a protiopatření je zásadní během fáze návrhu úlohy. Modelování hrozeb je technické cvičení, které zahrnuje definování požadavků na zabezpečení, identifikaci a zmírnění hrozeb a ověření těchto zmírnění rizik. Tuto techniku můžete použít v jakékoli fázi vývoje nebo produkce aplikací, ale je nejúčinnější ve fázích návrhu nových funkcí.

Tato příručka popisuje doporučení pro modelování hrozeb, abyste mohli rychle identifikovat nedostatky zabezpečení a navrhnout ochranu zabezpečení.

Definice 

Období Definice
Životní cyklus vývoje softwaru (SDLC) Vícestupňový, systematický proces vývoje softwarových systémů.
KROK Taxonomie definovaná Microsoftem pro kategorizaci typů hrozeb
Modelování hrozeb Proces pro identifikaci potenciálních ohrožení zabezpečení v aplikaci a systému, zmírnění rizik a ověřování kontrolních mechanismů zabezpečení.

Klíčové strategie návrhu

Modelování hrozeb je zásadní proces, který by organizace měla integrovat do svého SDLC. Modelování hrozeb není výhradně úkolem vývojáře. Je to sdílená odpovědnost mezi:

  • Tým úloh, který zodpovídá za technické aspekty systému.
  • Obchodní účastníci, kteří rozumí obchodním výsledkům a mají zájem o zabezpečení.

Mezi vedením organizace a technickými týmy často dochází k neshodě, pokud jde o obchodní požadavky na kritické úlohy. Toto odpojení může vést k nežádoucím výsledkům, zejména u investic do zabezpečení.

Když tým úloh provádí cvičení modelování hrozeb, měl by zvážit obchodní i technické požadavky. Tým úloh a obchodní účastníci se musí dohodnout na potřebách úloh specifických pro zabezpečení, aby mohli odpovídajícím způsobem investovat do protiopatření.

Požadavky na zabezpečení slouží jako vodítko pro celý proces modelování hrozeb. Aby to bylo efektivní cvičení, tým úloh by měl mít přístup k zabezpečení a měl by být vytrénován v nástrojích pro modelování hrozeb.

Vysvětlení rozsahu cvičení

Jasná znalost rozsahu je pro efektivní modelování hrozeb zásadní. Pomáhá zaměřit úsilí a zdroje na nejdůležitější oblasti. Tato strategie zahrnuje definování hranic systému, inventarizaci prostředků, které je potřeba chránit, a pochopení úrovně investic vyžadované v bezpečnostních kontrolách.

Shromáždění informací o jednotlivých komponentách

Diagram architektury úloh je výchozím bodem pro shromažďování informací, protože poskytuje vizuální znázornění systému. Diagram znázorňuje technické rozměry systému. Zobrazuje například toky uživatelů, pohyb dat v síti, úrovně citlivosti dat a typy informací a přístupové cesty identit.

Tato podrobná analýza může často poskytnout přehled o potenciálních ohroženích zabezpečení v návrhu. Je důležité porozumět funkcím jednotlivých komponent a jejich závislostem.

Vyhodnocení potenciálních hrozeb

Analyzujte každou komponentu z vnější perspektivy. Například jak snadno může útočník získat přístup k citlivým datům? Pokud útočníci získají přístup k prostředí, mohou se pohybovat laterálně a potenciálně přistupovat k jiným prostředkům nebo s nimi dokonce manipulovat? Tyto otázky vám pomůžou pochopit, jak může útočník zneužít prostředky úloh.

Klasifikace hrozeb pomocí oborové metodologie

Jednou z metod pro klasifikaci hrozeb je STRIDE, kterou používá životní cyklus vývoje zabezpečení Microsoftu. Klasifikace hrozeb vám pomůže pochopit povahu každé hrozby a použít odpovídající bezpečnostní prvky.

Zmírnění hrozeb

Zdokumentujte všechny zjištěné hrozby. Pro každou hrozbu definujte bezpečnostní prvky a reakci na útok, pokud tyto kontroly selžou. Definujte proces a časovou osu, která minimalizuje riziko identifikovaných ohrožení zabezpečení v úloze, aby tato ohrožení zabezpečení nezůstala neřešitelná.

Použijte přístup k předpokladu porušení zabezpečení . Může pomoct identifikovat ovládací prvky potřebné v návrhu ke zmírnění rizika v případě selhání primárního ovládacího prvku zabezpečení. Vyhodnoťte, jak pravděpodobné je selhání primárního ovládacího prvku. Pokud selže, jaký je rozsah potenciálního organizačního rizika? Jaká je také účinnost kompenzační kontroly? Na základě vyhodnocení použijte hloubková opatření ochrany k řešení potenciálních selhání bezpečnostních mechanismů.

Tady je příklad:

Položit tuto otázku Určení ovládacích prvků, které...
Jsou připojení ověřená prostřednictvím Microsoft Entra ID, protokolu TLS (Transport Layer Security) se vzájemným ověřováním nebo jiného moderního protokolu zabezpečení schváleného bezpečnostním týmem:

- Mezi uživateli a aplikací?

- Mezi komponentami aplikace a službami?
Zabraňte neoprávněnému přístupu ke komponentám a datům aplikace.
Omezujete přístup jenom na účty, které potřebují zapisovat nebo upravovat data v aplikaci? Zabránění neoprávněné manipulaci s daty nebo jejich změnám.
Je aktivita aplikace protokolována a odesílána do systému pro správu událostí a informací o zabezpečení (SIEM) prostřednictvím služby Azure Monitor nebo podobného řešení? Rychle detekovat a vyšetřovat útoky.
Jsou důležitá data chráněná šifrováním, které schválil bezpečnostní tým? Zabránění neoprávněnému kopírování neaktivních uložených dat.
Je příchozí a odchozí síťový provoz šifrovaný prostřednictvím protokolu TLS? Zabránění neoprávněnému kopírování přenášených dat.
Je aplikace chráněná před distribuovanými útoky dos (DDoS) prostřednictvím služeb, jako je Azure DDoS Protection? Detekujte útoky navržené tak, aby aplikaci přetížily, aby ji nebylo možné použít.
Ukládá aplikace přihlašovací údaje nebo klíče pro přístup k jiným aplikacím, databázím nebo službám? Zjistěte, jestli může útok použít vaši aplikaci k útoku na jiné systémy.
Umožňují vám ovládací prvky aplikací splnit zákonné požadavky? Chraňte soukromá data uživatelů a vyhněte se pokutám za dodržování předpisů.

Sledování výsledků modelování hrozeb

Důrazně doporučujeme použít nástroj pro modelování hrozeb. Nástroje můžou automatizovat proces identifikace hrozeb a vytvořit komplexní sestavu všech identifikovaných hrozeb. Nezapomeňte výsledky sdělit všem týmům, které mají zájem.

Sledujte výsledky v rámci backlogu týmu úloh, abyste včas umožnili odpovědnost. Přiřaďte úkoly jednotlivcům, kteří zodpovídají za zmírnění konkrétního rizika, které modelování hrozeb identifikovalo.

Při přidávání nových funkcí do řešení aktualizujte model hrozeb a integrujte ho do procesu správy kódu. Pokud zjistíte problém se zabezpečením, ujistěte se, že existuje proces pro posouzení problému na základě závažnosti. Tento proces by vám měl pomoct určit, kdy a jak problém napravit (například v dalším cyklu vydávání verzí nebo v rychlejší verzi).

Pravidelné kontroly požadavků na úlohy pro důležité obchodní informace

Pravidelně se schovávejte s výkonnými sponzory a nadefinujte požadavky. Tyto kontroly poskytují příležitost k sladění očekávání a zajištění přidělení provozních prostředků iniciativě.

Usnadnění Azure

Životní cyklus vývoje zabezpečení Microsoftu poskytuje nástroj pro modelování hrozeb, který pomáhá s procesem modelování hrozeb. Tento nástroj je k dispozici bez dalších poplatků. Další informace najdete na stránce Modelování hrozeb.

Příklad

Tento příklad vychází z prostředí informačních technologií (IT) vytvořeného ve standardních hodnotách zabezpečení (SE:01). Tento přístup poskytuje široký přehled o hrozbách v různých it scénářích.

Diagram znázorňující příklad standardních hodnot zabezpečení organizace s prostředím hrozeb

  1. Osoby životního cyklu vývoje. Do životního cyklu vývoje se podílí mnoho osob, včetně vývojářů, testerů, konečných uživatelů a správců. Všechny z nich můžou být ohrožené a ohrozit vaše prostředí prostřednictvím záměrně vytvořených ohrožení zabezpečení nebo hrozeb.

  2. Potenciální útočníci. Útočníci zvažují širokou škálu nástrojů, které lze kdykoli snadno použít k prozkoumání ohrožení zabezpečení a zahájení útoku.

  3. Kontrolní mechanismy zabezpečení. V rámci analýzy hrozeb identifikujte služby zabezpečení Azure, které se mají použít k ochraně vašeho řešení, a zjistěte, jak jsou tato řešení efektivní.

  4. Shromažďování protokolů. Protokoly z prostředků Azure a některých místních komponent se můžou odesílat do Azure Log Analytics, abyste pochopili chování vyvinutého řešení a zkusili zachytit počáteční ohrožení zabezpečení.

  5. Řešení pro správu událostí informací o zabezpečení (SIEM). Microsoft Sentinel je možné přidat i v rané fázi řešení, abyste mohli vytvářet analytické dotazy ke zmírnění hrozeb a ohrožení zabezpečení a předvídání prostředí zabezpečení v produkčním prostředí.

  6. Microsoft Defender for Cloud může k vylepšení stavu zabezpečení použít několik doporučení zabezpečení.

Projekt OWASP (Open Web Application Security Project) zdokumentoval přístup k modelování hrozeb pro aplikace.

Kontrolní seznam zabezpečení

Projděte si kompletní sadu doporučení.