Doporučení pro testování zabezpečení
Platí pro toto doporučení kontrolního seznamu zabezpečení architektury Azure Well-Architected Framework:
| SE:11 | Vytvořte komplexní testovací režim, který kombinuje přístupy k prevenci problémů se zabezpečením, ověřování implementací prevence hrozeb a testování mechanismů detekce hrozeb. |
|---|
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
| Semestr | Definice |
|---|---|
| Testování zabezpečení aplikací (AST) | Technika SDL (Microsoft Security Development Lifecycle), která používá metodologie testování typu white-box a black-box ke kontrole ohrožení zabezpečení v kódu. |
| Černobílé testování | Testovací metodologie, která ověřuje externě viditelné chování aplikace bez znalostí vnitřních prvků systému. |
| Modrý tým | Tým, který se brání útokům červeného týmu ve válečném cvičení. |
| Testování průniku | Testovací metodologie, která používá etické techniky hackingu k ověření bezpečnostní ochrany systému. |
| Červený tým | Tým, který hraje roli nežádoucího člověka a snaží se hacknout systém ve válečném herním cvičení. |
| Security Development Lifecycle (SDL) | Sada postupů poskytovaných Microsoftem, která podporuje požadavky na zajištění zabezpečení a dodržování předpisů. |
| Životní cyklus vývoje softwaru (SDLC) | Multistage, systematický proces vývoje softwarových systémů. |
| Testování bílé skříňky | Testovací metodologie, ve které je struktura kódu známá pro odborníka. |
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.
Poznámka:
Tyto pokyny rozlišují mezi testováním a reakcí na incidenty. I když testování je mechanismus detekce, který ideálně řeší problémy před produkčním prostředím, nemělo by se zaměňovat s nápravou nebo vyšetřováním, které se provádí jako součást reakce na incidenty. Aspekt zotavení z incidentů zabezpečení je popsaný v doporučeních reakce na incidenty.
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.
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.
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ů.
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:
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í.