Doporučení pro testování zabezpečení

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

Důkladné testování je základem dobrého návrhu zabezpečení. Testování je taktická forma ověření, abyste měli jistotu, že ovládací prvky fungují podle očekávání. Testování je také proaktivní způsob detekce ohrožení zabezpečení v systému.

Stanovení rigorií testování prostřednictvím četnosti a ověřování z různých perspektiv. Měli byste zahrnout vnitřní pohledy, které testují platformu a infrastrukturu a vnější vyhodnocení, která testují systém jako externí útočník.

Tato příručka obsahuje doporučení pro testování stavu zabezpečení vaší úlohy. Implementujte tyto testovací metody, abyste zlepšili odolnost vašich úloh vůči útokům a zachovali důvěrnost, integritu a dostupnost prostředků.

Definice

Klíčové strategie návrhu

Testování je nezpochybnitelná strategie, zejména pro zabezpečení. Umožňuje proaktivně zjišťovat a řešit problémy se zabezpečením dříve, než je možné je zneužít, a ověřit, že kontrolní mechanismy zabezpečení, které jste implementovali, fungují tak, jak jsou navrženy.

Rozsah testování musí zahrnovat aplikace, infrastrukturu a automatizované a lidské procesy.

SDL obsahuje několik typů testů, které zachytají chyby zabezpečení v kódu, ověřují komponenty modulu runtime a používají k otestování odolnosti zabezpečení systému etický hacking. SDL je klíčová aktivita posunu vlevo. Testy, jako je statická analýza kódu a automatizované prohledávání infrastruktury jako kódu (IaC), byste měli spouštět co nejdříve v procesu vývoje.

Zapojte se do plánování testů. Tým úloh nemusí navrhovat testovací případy. Tento úkol je často centralizovaný v podniku nebo dokončen externími odborníky na zabezpečení. Tým úloh by se měl zapojit do procesu návrhu, aby se zajistilo, že se záruky zabezpečení integrují s funkcemi aplikace.

Představte si jako útočníka. Navrhněte testovací případy s předpokladem, že byl systém napaden. Tímto způsobem můžete odhalit potenciální ohrožení zabezpečení a odpovídajícím způsobem určit prioritu testů.

Spouštět testy strukturovaným způsobem a opakovatelným procesem. Sestavte si svoji gorii testování v oblasti tempa, typů testů, faktorů řízení a zamýšlených výsledků.

Použijte pro úlohu správný nástroj. Použijte nástroje, které jsou nakonfigurované pro práci s úlohou. Pokud nástroj nemáte, kupte si ho. Nevystavujte ho. Nástroje zabezpečení jsou vysoce specializované a vytváření vlastního nástroje může představovat rizika. Využijte znalosti a nástroje nabízené centrálními týmy SecOps nebo externími prostředky, pokud tým úloh tyto znalosti nemá.

Nastavte samostatná prostředí. Testy lze klasifikovat jako destruktivní nebo nedestruktivní. Nedestruktivní testy nejsou invazní. Indikují, že došlo k problému, ale nemění funkčnost, aby problém opravili. Destruktivní testy jsou invazní a mohou poškodit funkce odstraněním dat z databáze.

Testování v produkčních prostředích poskytuje nejlepší informace, ale způsobuje největší přerušení. Vprodukčních Testování v neprodukčních prostředích je obvykle méně rušivé, ale nemusí přesně představovat konfiguraci produkčního prostředí způsoby, které jsou pro zabezpečení důležité.

Pokud nasadíte pomocí IaC a automatizace, zvažte, jestli můžete vytvořit izolovaný klon produkčního prostředí pro testování. Pokud máte průběžný proces pro rutinní testy, doporučujeme použít vyhrazené prostředí.

Vždy vyhodnoťte výsledky testu. Testování je plýtvání úsilím, pokud se výsledky nepoužívají k určení priorit akcí a vylepšení upstreamu. Zdokumentujte bezpečnostní pokyny, včetně osvědčených postupů, které odhalíte. Dokumentace, která zachycuje výsledky a plány nápravy, seznámí tým s různými způsoby, kterými se útočníci mohou pokusit o porušení zabezpečení. Pravidelné školení zabezpečení pro vývojáře, správce a testery.

Při návrhu testovacích plánů se zamyslete nad následujícími otázkami:

• Jak často očekáváte, že se test spustí a jak to ovlivní vaše prostředí?

• Jaké jsou různé typy testů, které byste měli spustit?

Pravidelné testování úloh

Pravidelně otestujte úlohu, abyste měli jistotu, že změny nezavádějí bezpečnostní rizika a že nedojde k žádným regresím. Tým musí být také připravený reagovat na ověření zabezpečení organizace, která se můžou provádět kdykoli. Existují také testy, které můžete spustit v reakci na incident zabezpečení. Následující části obsahují doporučení týkající se četnosti testů.

Rutinní testy

Rutinní testy se provádějí pravidelně, jako součást standardních provozních postupů a pro splnění požadavků na dodržování předpisů. Různé testy se můžou spouštět v různých intervalech, ale klíčem je, že se provádějí pravidelně a podle plánu.

Tyto testy byste měli integrovat do SDLC, protože poskytují hloubkovou ochranu v každé fázi. Rozšiřte testovací sadu a ověřte záruky pro identitu, ukládání dat a přenos a komunikační kanály. Proveďte stejné testy v různých bodech životního cyklu, abyste zajistili, že nedojde k žádným regresím. Rutinní testy pomáhají vytvořit počáteční srovnávací test. To je ale jen výchozí bod. Když odhalíte nové problémy ve stejných bodech životního cyklu, přidáte nové testovací případy. Testy se také zlepšují s opakováním.

V každé fázi by tyto testy měly ověřit kód, který se přidal nebo odebral nebo změnil nastavení konfigurace, aby bylo možné zjistit dopad těchto změn na zabezpečení. Měli byste zlepšit účinnost testů s automatizací, vyváženou s partnerskými recenzemi.

Zvažte spuštění testů zabezpečení jako součást automatizovaného kanálu nebo naplánovaného testovacího spuštění. Čím dříve zjistíte problémy se zabezpečením, tím jednodušší je najít kód nebo změnu konfigurace, která je způsobuje.

Nespoléhejte jenom na automatizované testy. Pomocí ručního testování můžete detekovat ohrožení zabezpečení, která můžou zachytit pouze lidské znalosti. Ruční testování je vhodné pro případy průzkumného použití a zjištění neznámých rizik.

Improvizované testy

Improvizované testy poskytují ověřování bezpečnostní obrany k určitému bodu v čase. Výstrahy zabezpečení, které můžou mít vliv na úlohu v daném okamžiku, tyto testy aktivují. Organizační mandáty můžou vyžadovat pozastavení a testování myšlení k ověření účinnosti strategií obrany, pokud výstraha eskaluje na nouzový stav.

Výhodou improvizovaných testů je připravenost na skutečný incident. Tyto testy můžou být vynucenou funkcí k testování přijetí uživatelem (UAT).

Bezpečnostní tým může auditovat všechny úlohy a podle potřeby tyto testy spustit. Jako vlastník úlohy musíte usnadnit týmy zabezpečení a spolupracovat s nimi. Vyjednávejte s bezpečnostními týmy dostatek předstihu, abyste se mohli připravit. Potvrďte a komunikujte s vaším týmem a zúčastněnými stranami, že tyto přerušení jsou nezbytné.

V jiných případech může být nutné spouštět testy a hlásit stav zabezpečení systému proti potenciální hrozbě.

Kompromis: Vzhledem k tomu, že improvizované testy jsou rušivé události, počítejte s tím, že přepíšete úkoly, které mohou zpozdit další plánovanou práci.

Riziko: Existuje riziko neznámého. Improvizované testy mohou být jednorázové úsilí bez zavedených procesů nebo nástrojů. Ale převládajícím rizikem je potenciální přerušení rytmu podnikání. Tato rizika musíte vyhodnotit vzhledem k výhodám.

Testy incidentů zabezpečení

Existují testy, které zjistí příčinu incidentu zabezpečení ve svém zdroji. Tyto mezery zabezpečení je potřeba vyřešit, aby se zajistilo, že se incident neopakuje.

Incidenty také v průběhu času vylepšují testovací případy tím, že odhalí stávající mezery. Tým by měl využít poznatky získané z incidentu a pravidelně začleňovat vylepšení.

Použití různých testů

Testy je možné kategorizovat podle technologií a metodik testování. Zkombinujte tyto kategorie a přístupy v rámci těchto kategorií, abyste získali úplné pokrytí.

Přidáním několika testů a typů testů můžete odhalit:

• Mezery v kontrolních prvcích zabezpečení nebo kompenzačních kontrolách

• Chybné konfigurace.

• Mezery v pozorovatelnosti a metodách detekce

Dobré cvičení modelování hrozeb může odkazovat na klíčové oblasti, aby se zajistilo pokrytí testu a frekvence. Doporučení týkající se modelování hrozeb najdete v tématu Doporučení pro zabezpečení životního cyklu vývoje.

Většina testů popsaných v těchto částech se dá spustit jako rutinní testy. Opakovatelnost ale může v některých případech vzniknout náklady a způsobit přerušení. Zvažte tyto kompromisy pečlivě.

Testy, které ověřují zásobník technologií

Tady je několik příkladů typů testů a jejich oblastí zaměření. Tento seznam není vyčerpávající. Otestujte celý zásobník, včetně zásobníku aplikací, front-endu, back-endu, rozhraní API, databází a jakýchkoli externích integrací.

• Zabezpečení dat: Otestujte efektivitu šifrování dat a řízení přístupu, abyste měli jistotu, že jsou data řádně chráněná před neoprávněným přístupem a manipulací.

• Síť a připojení: Otestujte brány firewall, abyste zajistili, že povolují pouze očekávaný, povolený a bezpečný provoz do úlohy.

• Aplikace: Otestujte zdrojový kód prostřednictvím technik testování zabezpečení aplikací (AST), abyste se ujistili, že dodržujete postupy zabezpečeného kódování a zachytáváte chyby za běhu, jako jsou problémy s poškozením paměti a oprávněními. Podrobnosti najdete na těchto odkazech komunity.

• Identita: Vyhodnoťte, jestli přiřazení rolí a podmíněné kontroly fungují podle očekávání.

Metodologie testování

Na metodologie testování existuje mnoho perspektiv. Doporučujeme testy, které umožňují proaktivní vyhledávání hrozeb simulací skutečných útoků. Mohou identifikovat potenciální aktéry hrozeb, jejich techniky a jejich zneužití, které představují hrozbu pro úlohu. Udělejte útoky co nejrealističtější. Použijte všechny potenciální vektory hrozeb, které identifikujete při modelování hrozeb.

Tady jsou některé výhody testování prostřednictvím skutečných útoků:

• Když tyto útoky uděláte jako součást rutinního testování, použijete vnější perspektivu ke kontrole úlohy a zajištění, aby obrana vydržela útok.

• Na základě poznatků, které se naučili, tým upgraduje úroveň znalostí a dovedností. Tým zlepšuje situační povědomí a dokáže sama posoudit připravenost na reakce na incidenty.

Riziko: Obecné testování může ovlivnit výkon. Pokud destruktivní testy odstraní nebo poškodí data, může dojít k problémům provozní kontinuity. Existují také rizika spojená s expozicí informací; zajistit zachování důvěrnosti údajů. Po dokončení testování zajistěte integritu dat.

Mezi příklady simulovaných testů patří black-box a white-box testování, penetrační testování a war hry cvičení.

Testování černé skříňky a bílé skříňky

Tyto typy testů nabízejí dvě různé perspektivy. V černých testech nejsou vnitřní vlastnosti systému viditelné. V testech white-box má tester dobrý přehled o aplikaci a má dokonce přístup k kódu, protokolům, topologii prostředků a konfiguracím pro provádění experimentu.

Riziko: Rozdíl mezi těmito dvěma typy je počáteční náklady. Testování bílých krabic může být nákladné z hlediska času potřebného k pochopení systému. V některých případech vyžaduje testování white-boxu, abyste si koupili specializované nástroje. Testování v černém rámečku nepotřebuje čas na zvýraznění, ale nemusí být tak efektivní. Možná budete muset vynaložit větší úsilí k odkrytí problémů. Je to časový kompromis.

Testy simulované útoky prostřednictvím penetračního testování

Odborníci na zabezpečení, kteří nejsou součástí IT nebo aplikačních týmů organizace, provádějí penetrační testování nebo testování. Dívají se na systém způsobem, jakým zlými aktéry zasílají prostor pro útoky. Jejich cílem je najít mezery v zabezpečení shromažďováním informací, analýzou ohrožení zabezpečení a vykazováním výsledků.

Kompromis: Penetrační testy jsou improvizované a mohou být nákladné z hlediska přerušení a peněžních investic, protože pentestování je obvykle placená nabídka odborníků třetích stran.

Riziko: Cvičení pro pentestování může mít vliv na běhové prostředí a může narušit dostupnost normálního provozu.

Odborníci můžou potřebovat přístup k citlivým datům v celé organizaci. Postupujte podle pravidel zapojení a ujistěte se, že přístup není zneužitý. Podívejte se na zdroje uvedené na odkazech Související.

Testy, které simulují útoky prostřednictvím cvičení war her

V této metodologii simulovaných útoků existují dva týmy:

• Červený tým je nežádoucí osoba, která se pokouší modelovat skutečné útoky. Pokud jsou úspěšné, najdete ve svém návrhu zabezpečení mezery a vyhodnotíte uzavření poloměru výbuchu jejich porušení.

• Modrý tým je tým úloh, který brání útokům. Testují schopnost detekovat, reagovat a opravovat útoky. Ověří ochranu, která byla implementována za účelem ochrany prostředků úloh.

Pokud se provádějí jako rutinní testy, můžou cvičení ve válečných hrách poskytovat průběžnou viditelnost a záruku, že vaše obrana funguje tak, jak je navržena. Cvičení war her mohou potenciálně testovat na různých úrovních v rámci vašich úloh.

Oblíbenou volbou pro simulaci realistických scénářů útoku je Microsoft Defender pro Office 365 Simulační nácvik útoku.

Další informace najdete v tématu Přehledy a sestavy pro Simulační nácvik útoku.

Informace o nastavení red-team a blue-team naleznete v tématu Microsoft Cloud Red Teaming.

Usnadnění azure

Microsoft Sentinel je nativní ovládací prvek, který kombinuje možnosti správy událostí zabezpečení (SIEM) a automatické orchestrace zabezpečení (SOAR). Analyzuje události a protokoly z různých připojených zdrojů. V závislosti na zdrojích dat a jejich upozorněních Microsoft Sentinel vytváří incidenty a provádí analýzu hrozeb pro včasné zjišťování. Prostřednictvím inteligentní analýzy a dotazů můžete proaktivně vyhledávat problémy se zabezpečením. Pokud dojde k incidentu, můžete automatizovat pracovní postupy. Pomocí šablon sešitů můžete také rychle získat přehledy prostřednictvím vizualizace.

Dokumentaci k produktu najdete v tématu Možnosti proaktivního vyhledávání v Microsoft Sentinelu.

Microsoft Defender for Cloud nabízí kontrolu ohrožení zabezpečení v různých technologických oblastech. Podrobnosti najdete v tématu Povolení kontroly ohrožení zabezpečení pomocí Microsoft Defender Správa zranitelností – Microsoft Defender for Cloud.

Postup DevSecOps integruje testování zabezpečení jako součást průběžného a průběžného zlepšování myšlení. Cvičení war her jsou běžnou praxí, která je integrovaná do rytmu podnikání v Microsoftu. Další informace najdete v tématu Zabezpečení v DevOps (DevSecOps).

Azure DevOps podporuje nástroje třetích stran, které je možné automatizovat jako součást kanálů kontinuální integrace nebo průběžného nasazování. Podrobnosti najdete v tématu Povolení DevSecOps pomocí Azure a GitHubu – Azure DevOps.

Související odkazy

Podle pravidel zapojení se ujistěte, že přístup není zneužitý. Pokyny k plánování a provádění simulovaných útoků najdete v následujících článcích:

• Pravidla penetračního testování

• Testování průniku

Můžete simulovat útoky doS (DoS) v Azure. Nezapomeňte dodržovat zásady stanovené v testování simulace služby Azure DDoS Protection.

Komunitní odkazy

Testování zabezpečení aplikací: Nástroje, typy a osvědčené postupy – Prostředky GitHubu popisují typy metodologií testování, které můžou testovat ochranu před sestavením a modulem runtime aplikace.

Standard PTES (Penetrační testování spouštění) obsahuje pokyny k běžným scénářům a aktivitám potřebným k vytvoření směrného plánu.

OWASP Top Ten | OWASP Foundation poskytuje osvědčené postupy zabezpečení pro aplikace a testovací případy, které pokrývají běžné hrozby.

Kontrolní seznam zabezpečení

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