Sdílet prostřednictvím


Doporučení pro analýzu hrozeb

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

SE:02 Udržujte zabezpečený vývojový životní cyklus pomocí posíleného, většinou automatizovaného a auditovatelného softwarového dodavatelského řetězce. Zabudování zabezpečeného návrhu pomocí modelování hrozeb k ochraně před implementacemi porazí zabezpečení.

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

Komplexní analýza pro identifikaci hrozeb, útoků, ohrožení zabezpečení a čítačů 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ěřování těchto omezení rizik. Tuto techniku můžete použít v jakékoli fázi vývoje nebo produkce aplikací, ale je nejúčinnější během fází návrhu nových funkcí.

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

Definice 

Semestr Definice
Životní cyklus vývoje softwaru (SDLC) Multistage, systematický proces vývoje softwarových systémů.
KROK Taxonomie definovaná Microsoftem pro kategorizaci typů hrozeb
Modelování hrozeb Proces identifikace 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íhrozebch 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ří chápou obchodní výsledky a mají zájem o zabezpečení.

Mezi vedením organizace a technickými týmy, které se týkají obchodních požadavků na důležité úlohy, často existuje odpojení. Toto odpojení může vést k nežádoucím výsledkům, zejména pro investice 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 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 bezpečnostní myšlení a být vytrénován v nástrojích pro modelování hrozeb.

Vysvětlení rozsahu cvičení

Jasné porozumění rozsahu je zásadní pro efektivní modelování hrozeb. Pomáhá soustředit úsilí a zdroje na nejdůležitější oblasti. Tato strategie zahrnuje definování hranic systému, inventarizaci prostředků, které je třeba chránit, a pochopení úrovně investic, které jsou vyžadovány v bezpečnostních prvcí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í reprezentaci systému. Diagram zvýrazňuje technické dimenze systému. Ukazuje například toky uživatelů, způsob, jakým se data procházejí sítí, úrovně citlivosti dat a typy informací a cesty přístupu k identitám.

Tato podrobná analýza často poskytuje 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 jednotlivé komponenty z vnější perspektivy. 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í, můžou se později přesunout nebo dokonce přistupovat nebo dokonce manipulovat s jinými prostředky? 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í společnosti Microsoft. Klasifikace hrozeb vám pomůže pochopit povahu každé hrozby a používat vhodné bezpečnostní prvky.

Zmírnění hrozeb

Zdokumentujte všechny zjištěné hrozby. Pro každou hrozbu definujte bezpečnostní prvky a odpověď na útok, pokud tyto kontroly selžou. Definujte proces a časovou osu, která minimalizují riziko ohrožení zabezpečení v úloze, aby tato ohrožení zabezpečení nemohla zůstat neoblečená.

Použijte přístup k předpokladu porušení zabezpečení . Může pomoct s identifikací kontrolních mechanismů potřebných v návrhu, které snižují riziko 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 podrobná opatření pro ochranu, která řeší potenciální selhání bezpečnostních prvků.

Tady je příklad:

Položte tuto otázku Určení ovládacích prvků, které...
Ověřují se připojení prostřednictvím protokolu MICROSOFT Entra ID, TLS (Transport Layer Security) se vzájemným ověřováním nebo jiným moderním protokolem zabezpečení, který tým zabezpečení schválil:

- Mezi uživateli a aplikací?

- Mezi komponentami aplikací a službami?
Zabraňte neoprávněnému přístupu k komponentám a datům aplikace.
Omezujete přístup jenom na účty, které potřebují zapisovat nebo upravovat data v aplikaci? Zabránit neoprávněným manipulacím nebo změnám dat
Protokoluje se aktivita aplikace a předává se do systému správy událostí (SIEM) zabezpečení prostřednictvím služby Azure Monitor nebo podobného řešení? Rychlé zjišťování a zkoumání útoků
Jsou důležitá data chráněná šifrováním, které tým zabezpečení schválil? Zabránit neoprávněnému kopírování neaktivních uložených dat
Jsou příchozí a odchozí síťový provoz šifrovaný přes protokol TLS? Zabránit neoprávněnému kopírování přenášených dat.
Je aplikace chráněná proti útokům DDoS (Distributed Denial of Service) prostřednictvím služeb, jako je Azure DDoS Protection? Detekce útoků navržených k přetížení aplikace, 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? Určete, jestli může útok použít vaši aplikaci k útoku na jiné systémy.
Umožňují 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í zprávu o všech identifikovaných hrozbách. Nezapomeňte sdělit výsledky všem zúčastněným týmům.

Sledujte výsledky jako součást backlogu týmu úloh, abyste umožnili včas odpovědnost. Přiřaďte úkoly jednotlivcům, kteří jsou zodpovědní za zmírnění konkrétního rizika zjištěného modelování hrozeb.

Když do řešení přidáte nové funkce, 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 určení priorit 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 příštím cyklu vydání nebo v rychlejší verzi).

Pravidelně kontrolujte požadavky na úlohy kritické pro chod firmy.

Pravidelně se seznamte se sponzory vedoucích pracovníků a definujte požadavky. Tyto kontroly poskytují příležitost k sladění očekávání a zajištění přidělování provozních prostředků iniciativě.

Usnadnění azure

Životní cyklus vývoje zabezpečení společnosti Microsoft 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é znalosti o hrozbách v různých scénářích IT.

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 Životní cyklus vývoje zahrnuje mnoho osob, včetně vývojářů, testerů, konečných uživatelů a správců. Všechny z nich mohou být ohroženy a ohrožené prostředí prostřednictvím ohrožení zabezpečení nebo hrozeb vytvořených úmyslně.

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

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

  4. Shromažďování protokolů. Do Azure Log Analytics se můžou odesílat protokoly z prostředků Azure a některé místní komponenty, takže možná pochopíte chování vyvinutého řešení a pokusíte se zachytit počáteční ohrožení zabezpečení.

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

  6. Microsoft Defender pro cloud může některé doporučení zabezpečení zlepšit stav 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í.