Doporučení pro testování zabezpečení
Vztahuje se na toto doporučení Power Platform Dobře uspořádaného kontrolního seznamu zabezpečení:
| SE:09 | Vytvořte komplexní testovací režim, který kombinuje přístupy k prevenci bezpečnostních problémů, ověřuje implementace prevence hrozeb a testuje mechanismy detekce hrozeb. |
|---|
Přísné testování je základem dobrého návrhu zabezpečení. Testování je taktická forma ověřování, aby se zajistilo, že kontroly fungují tak, jak bylo zamýšleno. Testování je také proaktivní způsob odhalování chyb zabezpečení v systému.
Stanovte přísnost testování prostřednictvím kadence a ověřování z více perspektiv. Měli byste zahrnout hlediska zevnitř ven, která testují platformu a infrastrukturu, a vnější hodnocení, která testují systém jako externí útočník.
Tato příručka poskytuje doporučení pro testování pozice zabezpečení vaší úlohy. Implementujte tyto testovací metody ke zlepšení odolnosti vaší úlohy vůči útokům a zachování důvěrnosti, integrity a dostupnosti zdrojů.
Definice
| Pojem | definice |
|---|---|
| Testování zabezpečení aplikací (AST) | Technika Microsoft Security Development Lifecycle (SDL), která využívá testovací metodologie white-box a black-box pro kontrolu bezpečnostních zranitelností v kódu. |
| Testování typu černá skříňka | Metodika testování, která ověřuje chování aplikací viditelné zvenčí bez znalosti vnitřních částí systému. |
| Modrý tým | Tým, který se brání útokům červeného týmu během válečné hry. |
| Testování průniku | Metodika testování, která používá etické hackerské techniky k ověření bezpečnostní obrany systému. |
| Červený tým | Tým, který hraje roli protivníka a pokouší se hacknout systém během válečné hry. |
| Životní cyklus vývoje zabezpečení (SDL) | Sada postupů poskytovaných Microsoft , které podporují požadavky na zajištění bezpečnosti a shodu. |
| Životní cyklus vývoje softwaru (SDLC) | Vícestupňový systematický proces vývoje softwarových systémů. |
| Testování typu bílé krabice | Metodika testování, kde je struktura kódu známa specialistovi. |
Klíčové strategie návrhu
Testování je nesmlouvavá strategie, zejména z hlediska zabezpečení. Umožňuje vám proaktivně zjišťovat a řešit problémy se zabezpečením dříve, než je lze zneužít, a ověřit, zda vámi implementovaná bezpečnostní opatření fungují tak, jak byla navržena.
Rozsah testování musí zahrnovat aplikaci, infrastrukturu a automatizované i lidské procesy.
Poznámka:
Tyto pokyny rozlišují mezi testováním a reakcí na incidenty. Ačkoli je testování detekčním mechanismem, který v ideálním případě řeší problémy před započetím provozu, nemělo by být zaměňováno s nápravou nebo vyšetřováním, které se provádí jako součást reakce na incident. Aspekt obnovy po bezpečnostních incidentech je popsán v části Doporučení pro reakci na bezpečnostní incidenty.
Zapojte se do plánování testů. Tým úlohy nemusí navrhovat testovací případy. Tento úkol je často centralizován v podniku nebo prováděn externími experty na zabezpečení. Tým úlohy by měl být zapojen do tohoto procesu návrhu, aby bylo zajištěno, že se bezpečnostní záruky integrují s funkčností aplikace.
Myslete jako útočník. Navrhněte své testovací případy s předpokladem, že systém byl napaden. Tímto způsobem můžete odhalit potenciální chyby a podle toho upřednostnit testy.
Testy provádějte strukturovaným způsobem s opakovatelným procesem. Přísnost testování stavějte na kadenci, typech testů, hnacích faktorech a zamýšlených výsledcích.
Použijte správný nástroj. Použijte nástroje, které jsou nakonfigurovány pro práci s danou úlohou. Pokud nástroj nemáte, zakupte jej. Nevytvářejte jej. Nástroje zabezpečení jsou vysoce specializované a vytváření vlastního nástroje může představovat rizika. Využijte odborných znalostí a nástrojů nabízených centrálními týmy SecOps nebo externími zdroji, pokud tým úlohy takovou odbornost nemá.
Vytvořte oddělená prostředí. Testy lze klasifikovat jako destruktivní nebo nedestruktivní. Nedestruktivní testy nejsou invazivní. Ukazují, že je problém, ale nemění funkčnost za účelem nápravy problému. Destruktivní testy jsou invazivní a mohou poškodit funkčnost odstraněním dat z databáze.
Testování v provozních prostředích vám poskytne nejlepší informace, ale způsobí největší narušení. V provozním prostředí je lepší provádět pouze nedestruktivní testy. Testování v neprovozních prostředích je obvykle méně rušivé, ale nemusí přesně reprezentovat konfiguraci provozního prostředí způsoby, které jsou důležité pro zabezpečení.
Pomocí funkce kopírování prostředí můžete vytvořit izolovaný klon vašeho provozního prostředí. Pokud máte vytvořeny kanály nasazení, můžete svá řešení nasadit také do vyhrazeného testovacího prostředí.
Vždy vyhodnocujte výsledky testu. Testování je zbytečná námaha, pokud se výsledky nepoužijí k upřednostnění akcí a provedení upstreamových zlepšení. Zdokumentujte bezpečnostní pokyny, včetně osvědčených postupů, které odhalíte. Dokumentace, která zachycuje výsledky a plány nápravy, informuje tým o různých způsobech, kterými by se útočníci mohli pokusit narušit zabezpečení. Provádějte pravidelná bezpečnostní školení vývojářů, správců a testerů.
Při navrhování plánů testování přemýšlejte o následujících otázkách:
- Jak často očekáváte spouštění testu a jak to ovlivní vaše prostředí?
- Jaké jsou různé typy testů, které byste měli spustit?
Jak často očekáváte, že budou testy probíhat?
Úlohu pravidelně testujte, abyste se ujistili, že změny nepředstavují bezpečnostní rizika a nedochází k žádným regresím. Tým musí být také připraven reagovat na ověření zabezpečení organizace, která mohou být provedena kdykoli. Existují také testy, které můžete spustit v reakci na bezpečnostní incident. Následující části obsahují doporučení ohledně četnosti testů.
Rutinní testy
Rutinní testy jsou prováděny v pravidelném rytmu jako součást standardních provozních postupů a kvůli naplnění požadavků na dodržování předpisů. Různé testy mohou být prováděny s různými kadencemi, ale klíčové je, že jsou prováděny pravidelně a podle plánu.
Tyto testy byste měli integrovat do svého SDLC, protože poskytují hlubokou ochranu v každé fázi. Diverzifikujte testovací sadu, abyste ověřili záruky identity, uchovávání a přenosu dat, a komunikačních kanálů. 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í stanovit počáteční benchmark. To je však jen výchozí bod. Jak odhalujete nové problémy ve stejných bodech životního cyklu, přidáváte nové testovací případy. Testy se také zlepšují opakováním.
V každé fázi by tyto testy měly ověřit kód, který je přidán nebo odebrán, nebo konfigurační nastavení, která se změnila, aby bylo možné zjistit dopad těchto změn na zabezpečení. Účinnost testů byste měli zlepšit pomocí automatizace vyvážené vzájemným hodnocením.
Zvažte spouštění testů zabezpečení jako součásti automatizovaného kanálu nebo plánovaného testovacího běhu. Čím dříve problémy se zabezpečením objevíte, tím snazší je vyhledat kód nebo změnu konfigurace, která je způsobuje.
Nespoléhejte pouze na automatizované testy. Použijte ruční testování k odhalení chyb, které dokáže zachytit pouze lidský specialista. Ruční testování je dobré pro průzkumné případy použití a hledání neznámých rizik.
Improvizované testy
Improvizované testy poskytují okamžitou validaci bezpečnostní obrany. Tyto testy aktivují bezpečnostní výstrahy, které by mohly v daném okamžiku ovlivnit úlohu. Organizační mandáty mohou vyžadovat přístup „pauza a testování“, aby se ověřila účinnost obranných strategií, pokud výstraha eskaluje do stavu nouze.
Přínosem improvizovaných testů je připravenost na skutečný incident. Tyto testy mohou představovat funkci vynucující provedení uživatelského akceptačního testování (UAT).
Bezpečnostní tým může provést audit všech úloh a podle potřeby tyto testy spustit. Jako vlastník úlohy musíte pomáhat a spolupracovat s týmy zabezpečení. Vyjednejte s nimi dostatek času na svou přípravu. Sdělte svému týmu a účastníkům, že tato narušení jsou nezbytná.
V jiných případech můžete být požádáni o provedení testů a vykázání stavu zabezpečení systému ohledně potenciální hrozby.
Kompromis: Protože improvizované testy jsou rušivé události, počítejte s tím, že změníte priority úkolů, což může zpozdit další plánovanou práci.
Riziko: Existuje riziko neznámého. Improvizované testy mohou být jednorázovou akcí bez zavedených procesů nebo nástrojů. Převládajícím rizikem je však potenciální přerušení rytmu podnikání. Musíte vyhodnotit tato rizika ve vztahu k přínosům.
Testy bezpečnostních incidentů
Existují testy, které odhalí příčinu bezpečnostního incidentu u jeho zdroje. Tyto bezpečnostní nedostatky musí být vyřešeny, aby se zajistilo, že se incident nebude opakovat.
Incidenty v průběhu času zlepšují testovací případy, protože dochází k odhalování stávajících nedostatků. Tým by měl využít ponaučení z incidentu a rutinně zavádět zlepšení.
Jaké jsou různé typy testů?
Testy lze kategorizovat podle technologie a podle metodiky testování. Kombinujte tyto kategorie a přístupy v rámci těchto kategorií, abyste dosáhli úplného pokrytí.
Přidáním více testů a jejich typů můžete odhalit:
- Nedostatky bezpečnostních nebo kompenzačních opatření.
- Nesprávná konfigurace.
- Nedostatky v pozorovatelnosti a metodách detekce.
Dobré cvičení pro modelování hrozeb může poukázat na klíčové oblasti, aby bylo zajištěno správné pokrytí a četnost testů. Doporučení, jak modelovat hrozby, naleznete v části Doporučení pro zabezpečení životního cyklu vývoje.
Většinu testů popsaných v těchto částech lze spustit jako rutinní. Opakovatelnost však může v některých případech způsobit náklady a narušení. Pečlivě zvažte tyto kompromisy.
Testy, které ověřují sadu technologií
Zde je několik příkladů typů testů a jejich oblastí zaměření. Tento seznam není vyčerpávající. Otestujte celou sadu, včetně sad aplikací, frontendu, backendu, rozhraní API, databází a veškerých externích integrací.
- Zabezpečení dat: Otestujte efektivitu šifrování dat a řízení přístupu, abyste zajistili, že jsou data náležitě chráněna před neoprávněným přístupem a manipulací.
- Síť a konektivita: Otestujte své brány firewall a ujistěte se, že umožňují pouze očekávaný, povolený a bezpečný provoz na pracovní zátěž.
- Aplikace: Otestujte zdrojový kód pomocí technik testování zabezpečení aplikací (AST), abyste se ujistili, že dodržujete postupy bezpečného kódování a zachytíte chyby za běhu, jako je poškození paměti a problémy s oprávněními.
- Identita: Vyhodnoťte, zda přiřazení rolí a podmíněné kontroly fungují podle plánu.
Metodologie testování
Existuje mnoho pohledů na metodiku testování. Doporučujeme testy, které umožňují vyhledávání hrozeb prostřednictvím simulace reálných útoků. Mohou identifikovat potenciální činitele hrozeb, jejich techniky a jejich zneužití, které představují hrozbu pro úlohu. Udělejte útoky co nejrealističtější. Využijte všechny potenciální vektory hrozeb, které identifikujete během modelování hrozeb.
Zde jsou některé výhody testování prostřednictvím simulací reálných útoků:
- Když tyto útoky zařadíte do rutinního testování, použijete perspektivu zvenčí dovnitř, abyste zkontrolovali úlohu a zajistili, že obrana odolá útoku.
- Na základě naučených lekcí tým zvyšuje úroveň svých znalostí a dovedností. Tým zlepšuje situační povědomí a může sám zhodnotit svou připravenost reagovat na incidenty.
Mezi simulované testy patří například testování typu černá a bílá skříňka, testování průniku a válečné hry.
Testování typu černá a bílá skříňka
Tyto typy testů nabízejí dvé odlišné perspektivy. V testech typu černá skříňka není viditelný vnitřek systému. V testech typu bílá skříňka tester dobře rozumí aplikaci a má dokonce přístup ke kódu, protokolům, topologii prostředků a konfiguraci pro provádění experimentu.
Testy, které simulují útoky prostřednictvím testování průniku
Bezpečnostní experti, kteří nejsou součástí IT nebo aplikačních týmů organizace, provádějí testování průniku neboli pentesting. Dívají se na systém způsobem, jakým zlomyslní činitelé zkoumají povrch, kam zaútočí. Jejich cílem je najít bezpečnostní mezery shromažďováním informací, analýzou chyb zabezpečení a vykazováním výsledků.
Specialisté mohou potřebovat přístup k citlivým datům v celé organizaci. Dodržujte pravidla zapojení, abyste zajistili, že přístup nebude zneužit. Prohlédněte si zdroje uvedené v části Související informace.
Testy, které simulují útoky prostřednictvím válečných her
V této metodice simulovaných útoků existují dva týmy:
- Červený tým je protivníkem, který se pokouší modelovat reálné útoky. Pokud je úspěšný, objevíte nedostatky v návrhu zabezpečení a vyhodnotíte okruh škod při jejich narušení.
- Modrý tým je vlastník úlohy, kterou brání před útoky. Testuje svou schopnost detekovat, reagovat a napravit útoky. Ověřují obranu, která byla implementována k ochraně prostředků úloh.
Pokud jsou válečné hry prováděny jako rutinní testy, mohou poskytnout průběžný přehled a jistotu, že vaše obrana funguje tak, jak byla navržena. Válečné hry mohou provádět potenciální testy napříč úrovněmi úlohy.
Oblíbenou volbou pro simulaci realistických scénářů útoku je Microsoft Defender for Office 365 Trénink simulace útoku.
Další informace najdete v části Přehledy a sestavy pro školení simulace útoku.
Informace o nastavení červeného a modrého týmu najdete v části Microsoft Cloud Red Teaming.
Usnadnění dáky Power Platform
Microsoft Řešení Sentinel for Microsoft Power Platform umožňuje zákazníkům detekovat různé podezřelé aktivity, jako jsou:
- Provádění Power Apps z neautorizovaných geografických oblastí
- Podezřelé zničení dat z Power Apps
- Hromadné odstranění Power Apps
- Phishingové útoky provedené přes Power Apps
- Aktivita toků Power Automate odcházejícími zaměstnanci
- Konektory Microsoft Power Platform používané do prostředí
- Aktualizace nebo odstranění zásad prevence ztráty dat Microsoft Power Platform
Další informace naleznete v části Microsoft Řešení Sentinel pro Microsoft Power Platform přehled.
Dokumentaci k produktu najdete v části Možnosti lovu v Microsoft Sentinel.
Microsoft Defender for Cloud nabízí skenování zranitelnosti pro různé technologické oblasti. Další informace najdete v části Povolení skenování zranitelností pomocí Microsoft Defender Vulnerability Management.
DevSecOps integruje testování zabezpečení jako součást průběžného, neustálého zlepšování. Cvičení ve válečných hrách jsou běžnou praxí, která je integrována do rytmu podnikání na Microsoft. Další informace najdete v tématu Zabezpečení v DevOps (DevSecOps).
Azure DevOps podporuje nástroje třetích stran, které lze automatizovat jako součást kanálů kontinuální integrace / průběžného doručování (CI/CD). Další informace najdete v tématu Povolení DevSecOps s Azure a GitHub.
Související informace
Nejnovější penetrační testy a bezpečnostní hodnocení lze nalézt na Microsoft Service Trust Portal.
Microsoft provádí rozsáhlé testování Microsoft Cloudových služeb. Toto testování zahrnuje testování průniku s výsledky zveřejněnými na portálu Service Trust Portal pro vaši organizaci. Vaše organizace může provést vlastní test průniku u služeb Microsoft Power Platform a Microsoft Dynamics 365. Veškeré penetrační testování se musí řídit Microsoft Pravidla pro testování penetrace do cloudu pro zapojení. Je důležité si uvědomit, že v mnoha případech Microsoft Cloud využívá sdílenou infrastrukturu k hostování vašich aktiv a aktiv patřících jiným zákazníkům. Všechny testy průniku musíte omezit na svůj majetek a vyhnout se tak nezamýšleným následkům pro ostatní zákazníky.
Dodržujte pravidla zapojení, abyste zajistili, že přístup nebude zneužit. Pokyny k plánování a provádění simulovaných útoků naleznete v části:
V Azure můžete simulovat útoky DoS (odmítnutí služby). Nezapomeňte dodržovat zásady uvedené v části Simulační testování Azure DDoS Protection.
Kontrolní seznam zabezpečení
Podívejte se na úplný soubor doporučení.