Doporučení pro testování zabezpečení
Platí pro toto doporučení kontrolního seznamu zabezpečení azure Well-Architected Framework:
| Z: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í, aby se zajistilo, že ovládací prvky fungují podle očekávání. Testování je také proaktivní způsob zjišťování ohrožení zabezpečení v systému.
Zajistěte přísnost testování prostřednictvím četnosti a ověřování z více úhlů pohledu. Měli byste zahrnout vnitřní pohledy, které testují platformu a infrastrukturu a externí hodnocení, 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 úloh vůči útokům a zachovali důvěrnost, integritu a dostupnost prostředků.
Definice
| Období | Definice |
|---|---|
| Testování zabezpečení aplikací (AST) | Technika SDL (Microsoft Security Development Lifecycle), která používá metody testování white-box a black-box ke kontrole ohrožení zabezpečení v kódu. |
| Testování černou skříňkou | Metodologie testování, která ověřuje externě viditelné chování aplikace bez znalosti vnitřních prvků systému. |
| Modrý tým | Tým, který se brání útokům červeného týmu ve cvičení válečných her. |
| Testování průniku | Metodologie testování, která používá techniky etického hackingu k ověření bezpečnostní ochrany systému. |
| Červený tým | Tým, který hraje roli protivníka a pokouší se hacknout systém ve cvičení válečných her. |
| 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) | Vícestupňový, systematický proces vývoje softwarových systémů. |
| Testování bílé skříňky | Metodologie testování, kde je odborníkovi známa struktura kódu. |
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é zneužít, a ověřit, že implementované bezpečnostní prvky fungují podle návrhu.
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ž je testování mechanismus detekce, který v ideálním případě opravuje 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í v rámci reakce na incidenty. Aspekt zotavení z incidentů zabezpečení je popsaný v doporučeních reakce na incidenty.
SDL zahrnuje několik typů testů, které zachycují ohrožení zabezpečení v kódu, ověřují komponenty modulu runtime a používají etické hackování k testování odolnosti systému zabezpečení. SDL je klíčová aktivita shift-left. Co nejdříve v procesu vývoje byste měli spouštět testy, jako je analýza statického kódu a automatizovaná kontrola infrastruktury jako kódu (IaC).
Zapojit se do plánování testů. Tým úloh nemusí navrhnout testovací případy. Tato úloha je často centralizovaná v podniku nebo dokončena externími odborníky na zabezpečení. Do procesu návrhu by se měl zapojit tým úloh, aby se zajistilo, že se záruky zabezpečení integrují s funkcemi aplikace.
Mysli jako útočník. Navrhněte testovací případy s předpokladem, že systém byl 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ějte testy strukturovaným způsobem a s opakovatelným procesem. Vybudujte testovací přísnost na základě četnosti, typů testů, faktorů řízení a zamýšlených výsledků.
Použijte pro úlohu ten 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 vytvoř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 prostředky, pokud tým úloh tyto znalosti nemá.
Nastavte samostatná prostředí. Testy lze klasifikovat jako destruktivní nebo nedestruktivní. Nedestruktivní testy nejsou invazní. Značí, že došlo k problému, ale nemění funkčnost, aby se problém vyřešil. Destruktivní testy jsou invazní a odstraněním dat z databáze můžou poškodit funkčnost.
Testování v produkčních prostředích poskytuje nejlepší informace, ale způsobuje největší narušení. V produkčních prostředích máte tendenci provádět pouze nedestruktivní testy. 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ůsobem, který je důležitý pro zabezpečení.
Pokud nasazujete 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 zbytečné úsilí, pokud se výsledky nepoužívají ke stanovení priorit akcí a vylepšení upstreamu. Zdokumentujte pokyny k zabezpečení, včetně osvědčených postupů, které odhalíte. Dokumentace, která zachycuje výsledky a plány nápravy, vyučí tým o různých způsobech, jak se útočníci mohou pokusit o narušení zabezpečení. Pravidelně provádějte školení o zabezpečení pro vývojáře, správce a testery.
Při navrhování 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ý má vliv na vaše prostředí?
Jaké různé typy testů byste měli spustit?
Jak často očekáváte spouštění testů?
Pravidelně testujte úlohu, abyste se ujistili, že změny nezavádějí bezpečnostní rizika a že nedochází k žádným regresím. Tým také musí být připravený reagovat na ověření zabezpečení organizace, která se můžou kdykoli provést. 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í v pravidelném tempu v rámci standardních provozních postupů a za účelem 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. Diverzifikace testovací sady za účelem ověření záruk identity, úložiště a přenosu dat a komunikačních kanálů Proveďte stejné testy v různých bodech životního cyklu, abyste měli jistotu, ž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. Při odkrývání nových problémů 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 přidaný nebo odebraný kód nebo nastavení konfigurace, která se změnila, aby bylo možné zjistit dopad těchto změn na zabezpečení. Účinnost testů byste měli zlepšit automatizací, vyváženou pomocí peer reviews.
Zvažte spuštění testů zabezpečení v rámci automatizovaného kanálu nebo plánovaného testovacího běhu. Čí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. Ruční testování slouží k detekci ohrožení zabezpečení, které můžou zachytit pouze lidské znalosti. Ruční testování je vhodné pro průzkumné případy použití a zjišťování neznámých rizik.
Improvizované testy
Improvizované testy poskytují ověřování bezpečnostních obran k určitému bodu v čase. Tyto testy aktivují výstrahy zabezpečení, které můžou v daném okamžiku ovlivnit úlohu. Organizační mandáty můžou vyžadovat pozastavení a testování myšlení k ověření efektivity strategií obrany, pokud výstraha eskaluje do nouzové situace.
Výhodou improvizovaných testů je připravenost na skutečný incident. Tyto testy mohou být vynucenou funkcí k provedení akceptační testování uživatele (UAT).
Bezpečnostní tým může auditovat všechny úlohy a podle potřeby spouštět tyto testy. Jako vlastník úlohy potřebujete spolupracovat s bezpečnostními týmy. Vyjednávejte s bezpečnostními týmy dostatek času, abyste se mohli připravit. Potvrďte a informujte svůj tým a zúčastněné strany, že tato přerušení jsou nezbytná.
V jiných případech může být nutné spustit testy a nahlásit stav zabezpečení systému před potenciální hrozbou.
Kompromis: Vzhledem k tomu, že improvizované testy jsou rušivé události, počítejte s tím, že budou úkoly přeusvědčovat, což může zpozdit jinou plánovanou práci.
Riziko: Existuje riziko neznámého. Improvizované testy můžou být jednorázové 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 jejich výhodám.
Testy incidentů zabezpečení
Existují testy, které detekují příčinu incidentu zabezpečení v jeho zdroji. Tyto mezery zabezpečení je potřeba vyřešit, aby se zajistilo, že se incident nebude opakovat.
Incidenty také zlepšují testovací případy v průběhu času tím, že odkryjí stávající mezery. Tým by měl využít poznatky získané z incidentu a pravidelně vylepšovat.
Jaké jsou různé typy testů?
Testy lze kategorizovat podle technologie a testovacích metodologií. 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 bezpečnostních prvcích nebo kompenzačních prvcích
Chybné konfigurace.
Mezery v metodách pozorovatelnosti a detekce.
Dobré cvičení modelování hrozeb může ukazovat na klíčové oblasti, aby se zajistilo pokrytí a frekvence testů. Doporučení k modelování hrozeb najdete v tématu Doporučení pro zabezpečení životního cyklu vývoje.
Většinu testů popsaných v těchto částech lze spustit jako rutinní testy. Opakovatelnost však může v některých případech způsobit 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 všech externích integrací.
Zabezpečení dat: Otestujte efektivitu šifrování dat a řízení přístupu, abyste zajistili, že data jsou správně chráněná před neoprávněným přístupem a manipulací.
Síť a připojení: Otestujte brány firewall a ujistěte se, ž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 testu
Existuje mnoho pohledů na metodologie testování. Doporučujeme testy, které umožňují proaktivní vyhledávání hrozeb simulací reálných útoků. Mohou identifikovat potenciální aktéry hrozeb, jejich techniky a zneužití, která představují hrozbu pro úlohu. Zajistěte, aby útoky byly 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 reálných útoků:
Když tyto útoky nastavíte jako součást rutinního testování, použijete vnější perspektivu ke kontrole úlohy a zajištění, že obrana dokáže útok odolat.
Na základě poznatků, které se naučili, tým vylepšuje úroveň svých znalostí a dovedností. Tým zlepšuje situační povědomí a může sám posoudit svou připravenost na reakce na incidenty.
Mezi příklady simulovaných testů patří testování černých a bílých krabic, penetrační testování a cvičení ve válečných hrách.
Testování černou a bílou skříňkou
Tyto typy testů nabízejí dvě různé perspektivy. V testech typu černá skříňka nejsou uvnitř systému viditelné. V testech s prázdným rámečkem tester dobře rozumí aplikaci a dokonce má přístup ke kódu, protokolům, topologii prostředků a konfiguracím pro provedení experimentu.
Testy, které simulují ú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í testy nebo penetrační testy. Dívají se na systém způsobem, jakým aktéři se zlými úmysly vymešují prostor pro útok. Jejich cílem je najít nedostatky 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 se přístup nezneužije. Projděte si zdroje informací uvedené v části Související odkazy.
Testy, které simulují útoky prostřednictvím válečných herních cvičení
V této metodologii simulovaných útoků existují dva týmy:
Červený tým je nežádoucí osoba, která se pokouší modelovat útoky z reálného světa. Pokud budou úspěšné, najdete mezery v návrhu zabezpečení a vyhodnotíte poloměr výbuchu jejich porušení.
Modrý tým je tým úloh, který se brání útokům. Otestují svou schopnost detekovat útoky, reagovat na ně a napravit je. Ověřují obranu, která byla implementována za účelem ochrany prostředků úloh.
Pokud se provádí jako rutinní testy, můžou cvičení válečných her poskytovat průběžnou viditelnost a jistotu, že vaše obrana funguje tak, jak má. Válečná herní cvičení můžou potenciálně testovat na různých úrovních v rámci vašich úloh.
Oblíbenou volbou pro simulaci scénářů reálných útoků 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í červeného a modrého týmu najdete v tématu Red Teaming v Microsoft Cloudu.
Usnadnění Azure
Microsoft Sentinel je nativní ovládací prvek, který kombinuje možnosti správy událostí informací o zabezpečení (SIEM) a automatizované reakce na orchestraci zabezpečení (SOAR). Analyzuje události a protokoly z různých připojených zdrojů. Na základě zdrojů dat a jejich výstrah vytváří služba Microsoft Sentinel incidenty a provádí analýzu hrozeb pro účely včasné detekce. Prostřednictvím inteligentních analýz a dotazů můžete proaktivně vyhledávat problémy se zabezpečením. Pokud dojde k incidentu, můžete pracovní postupy automatizovat. Pomocí šablon sešitů můžete také rychle získat přehled prostřednictvím vizualizace.
Dokumentaci k produktu najdete v tématu Možnosti proaktivního vyhledávání ve službě Microsoft Sentinel.
Microsoft Defender for Cloud nabízí kontrolu ohrožení zabezpečení pro různé technologické oblasti. Podrobnosti najdete v tématu Povolení kontroly ohrožení zabezpečení pomocí Microsoft Defender Správa zranitelností – Microsoft Defender pro cloud.
Postupy DevSecOps integrují testování zabezpečení jako součást nepřetržitého a průběžného zlepšování myšlení. Cvičení ve válečných hrách jsou běžným postupem, který je integrován 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 v rámci kanálů kontinuální integrace nebo průběžného nasazování. Podrobnosti najdete v tématu Povolení DevSecOps v Azure a GitHubu – Azure DevOps.
Související odkazy
Postupujte podle pravidel zapojení a ujistěte se, že se přístup nezneužije. Pokyny k plánování a provádění simulovaných útoků najdete v následujících článcích:
V Azure můžete simulovat útoky DoS (DoS). Ujistěte se, že dodržujete zásady stanovené v simulačním testování služby Azure DDoS Protection.
Odkazy na komunitu
Testování zabezpečení aplikací: Nástroje, typy a osvědčené postupy – GitHub Resources popisuje typy testovacích metodologií, které můžou otestovat ochranu aplikace v době sestavení a za běhu.
Standard PTES (Penetrační testování spouštění standardu) poskytuje 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í.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro