Rekommendationer för säkerhetstestning
Gäller för denna checklista för Azure Well-Architected Framework Security:
| SE:11 | Upprätta en omfattande testregim som kombinerar metoder för att förhindra säkerhetsproblem, validera implementeringar av hotskydd och testa hotidentifieringsmekanismer. |
|---|
Rigorös testning är grunden för en bra säkerhetsdesign. Testning är en taktisk form av validering för att se till att kontrollerna fungerar som avsett. Testning är också ett proaktivt sätt att identifiera sårbarheter i systemet.
Upprätta testningstakt genom takt och verifiering ur flera perspektiv. Du bör inkludera inifrån och ut-perspektiv som testar plattform och infrastruktur och externa utvärderingar som testar systemet som en extern angripare.
Den här guiden innehåller rekommendationer för att testa säkerhetsstatusen för din arbetsbelastning. Implementera dessa testmetoder för att förbättra arbetsbelastningens motstånd mot attacker och upprätthålla konfidentialitet, integritet och tillgänglighet för resurser.
Definitioner
| Period | Definition |
|---|---|
| Programsäkerhetstestning (AST) | En SDL-teknik (Microsoft Security Development Lifecycle) som använder white-box- och black box-testmetoder för att söka efter säkerhetsrisker i koden. |
| Black-box-testning | En testmetod som validerar det externt synliga programbeteendet utan kunskap om systemets interna funktioner. |
| Blått team | Ett lag som försvarar mot det röda lagets attacker i en krigsspelsövning. |
| Intrångstest | En testmetod som använder etiska hackningstekniker för att verifiera säkerhetsförsvaret i ett system. |
| Rött team | Ett team som spelar rollen som en angripare och försöker hacka systemet i en krigsspelsövning. |
| Security Development Lifecycle (SDL) | En uppsättning metoder från Microsoft som stöder säkerhetskrav och efterlevnadskrav. |
| Livscykel för programvaruutveckling (SDLC) | En multistage, systematisk process för utveckling av programvarusystem. |
| Testning med vit ruta | En testmetod där kodens struktur är känd av utövaren. |
Viktiga designstrategier
Testning är en icke-förhandlingsbar strategi, särskilt för säkerhet. Det gör att du proaktivt kan identifiera och åtgärda säkerhetsproblem innan de kan utnyttjas och kontrollera att de säkerhetskontroller som du implementerade fungerar som de är utformade.
Omfattningen av testningen måste omfatta program, infrastruktur och automatiserade och mänskliga processer.
Anteckning
Den här vägledningen skiljer mellan testning och incidenthantering. Även om testning är en identifieringsmekanism som helst åtgärdar problem före produktion, bör den inte förväxlas med reparationen eller undersökningen som utförs som en del av incidenthantering. Aspekten av återställning från säkerhetsincidenter beskrivs i rekommendationer för incidenthantering.
SDL innehåller flera typer av tester som fångar sårbarheter i kod, verifierar körningskomponenter och använder etisk hackning för att testa systemets säkerhetsresiliens. SDL är en viktig skift-vänster-aktivitet. Du bör köra tester som statisk kodanalys och automatisk genomsökning av infrastruktur som kod (IaC) så tidigt som möjligt i utvecklingsprocessen.
Delta i testplaneringen. Arbetsbelastningsteamet kanske inte utformar testfallen. Den uppgiften centraliseras ofta i företaget eller slutförs av externa säkerhetsexperter. Arbetsbelastningsteamet bör vara involverade i den designprocessen för att säkerställa att säkerhetsgarantier integreras med programmets funktioner.
Tänk som en angripare. Utforma testfallen med antagandet att systemet har attackerats. På så sätt kan du upptäcka potentiella sårbarheter och prioritera testerna i enlighet med detta.
Kör tester på ett strukturerat sätt och med en repeterbar process. Skapa din testtakt kring takt, typer av tester, körfaktorer och avsedda resultat.
Använd rätt verktyg för jobbet. Använd verktyg som är konfigurerade för att fungera med arbetsbelastningen. Om du inte har något verktyg kan du köpa verktyget. Skapa den inte. Säkerhetsverktyg är mycket specialiserade och att skapa ett eget verktyg kan medföra risker. Dra nytta av de kunskaper och verktyg som erbjuds av centrala SecOps-team eller på externa sätt om arbetsbelastningsteamet inte har den expertisen.
Konfigurera separata miljöer. Tester kan klassificeras som destruktiva eller icke-destruktiva. Icke-förstörande tester är inte invasiva. De anger att det finns ett problem, men de ändrar inte funktionaliteten för att åtgärda problemet. Destruktiva tester är invasiva och kan skada funktionaliteten genom att ta bort data från en databas.
Testning i produktionsmiljöer ger dig den bästa informationen men orsakar flest avbrott. Du brukar bara göra icke-förstörande tester i produktionsmiljöer. Testning i icke-produktionsmiljöer är vanligtvis mindre störande men kanske inte korrekt representerar produktionsmiljöns konfiguration på sätt som är viktiga för säkerheten.
Om du distribuerar med hjälp av IaC och automatisering bör du överväga om du kan skapa en isolerad klon av produktionsmiljön för testning. Om du har en kontinuerlig process för rutintester rekommenderar vi att du använder en dedikerad miljö.
Utvärdera alltid testresultaten. Testning är ett slöseri med arbete om resultaten inte används för att prioritera åtgärder och göra förbättringar överordnad. Dokumentera de säkerhetsriktlinjer, inklusive metodtips, som du hittar. Dokumentation som samlar in resultat och reparationsplaner utbildar teamet om de olika sätt som angripare kan försöka bryta mot säkerheten på. Genomför regelbunden säkerhetsutbildning för utvecklare, administratörer och testare.
När du utformar dina testplaner bör du tänka på följande frågor:
Hur ofta förväntar du dig att testet ska köras och hur påverkar det din miljö?
Vilka är de olika testtyper som du bör köra?
Hur ofta förväntar du dig att testerna ska köras?
Testa arbetsbelastningen regelbundet för att se till att ändringar inte medför säkerhetsrisker och att det inte finns några regressioner. Teamet måste också vara redo att svara på organisationens säkerhetsvalidering som kan utföras när som helst. Det finns också tester som du kan köra som svar på en säkerhetsincident. Följande avsnitt innehåller rekommendationer om testfrekvensen.
Rutintester
Rutintester utförs regelbundet, som en del av dina standardrutiner och för att uppfylla efterlevnadskraven. Olika tester kan köras i olika takt, men nyckeln är att de utförs regelbundet och enligt ett schema.
Du bör integrera dessa tester i ditt SDLC eftersom de ger skydd på djupet i varje steg. Diversifiera testpaketet för att verifiera identitets-, datalagrings- och överförings- och kommunikationskanaler. Utför samma tester vid olika tidpunkter i livscykeln för att säkerställa att det inte finns några regressioner. Rutintester hjälper till att upprätta ett första riktmärke. Men det är bara en utgångspunkt. När du upptäcker nya problem vid samma tidpunkter i livscykeln lägger du till nya testfall. Testerna förbättras också med upprepning.
I varje steg bör dessa tester verifiera kod som har lagts till eller tagits bort eller konfigurationsinställningar som har ändrats för att identifiera säkerhetspåverkan av dessa ändringar. Du bör förbättra testernas effektivitet med automatisering, balanserad med peer-granskningar.
Överväg att köra säkerhetstester som en del av en automatiserad pipeline eller schemalagd testkörning. Ju tidigare du upptäcker säkerhetsproblem, desto enklare är det att hitta koden eller konfigurationsändringen som orsakar dem.
Förlita dig inte bara på automatiserade tester. Använd manuell testning för att identifiera sårbarheter som endast mänsklig expertis kan fånga. Manuell testning är bra för undersökande användningsfall och för att hitta okända risker.
Improviserade tester
Improviserade tester ger validering till tidpunkt av säkerhetsskydd. Säkerhetsaviseringar som kan påverka arbetsbelastningen vid den tidpunkten utlöser dessa tester. Organisationsmandat kan kräva ett paus- och testtänk för att verifiera effektiviteten av försvarsstrategier om aviseringen eskalerar till en nödsituation.
Fördelen med improviserade tester är beredskap för en verklig incident. Dessa tester kan vara en tvingad funktion för att utföra UAT (User Acceptance Testing).
Säkerhetsteamet kan granska alla arbetsbelastningar och köra dessa tester efter behov. Som arbetsbelastningsägare måste du underlätta och samarbeta med säkerhetsteam. Förhandla tillräckligt med ledtid med säkerhetsteam så att du kan förbereda dig. Bekräfta och meddela ditt team och intressenter att dessa störningar är nödvändiga.
I andra fall kan du behöva köra tester och rapportera systemets säkerhetstillstånd mot det potentiella hotet.
Kompromiss: Eftersom improviserade tester är störande händelser förväntar du dig att omprioritera uppgifter, vilket kan försena annat planerat arbete.
Risk: Det finns risk för det okända. Improviserade tester kan vara engångsförsök utan etablerade processer eller verktyg. Men den dominerande risken är det potentiella avbrottet i affärsrytmen. Du måste utvärdera dessa risker i förhållande till fördelarna.
Tester av säkerhetsincidenter
Det finns tester som identifierar orsaken till en säkerhetsincident vid källan. Dessa säkerhetsluckor måste åtgärdas för att säkerställa att incidenten inte upprepas.
Incidenter förbättrar också testfall över tid genom att upptäcka befintliga luckor. Teamet bör tillämpa lärdomarna från incidenten och rutinmässigt införliva förbättringar.
Vilka är de olika typerna av tester?
Tester kan kategoriseras efter teknik och genom testningsmetoder. Kombinera dessa kategorier och metoder inom dessa kategorier för att få fullständig täckning.
Genom att lägga till flera tester och typer av tester kan du upptäcka:
Luckor i säkerhetskontroller eller kompenserande kontroller.
Felkonfigurationer.
Luckor i observerbarhets- och identifieringsmetoder.
En bra övning för hotmodellering kan peka på viktiga områden för att säkerställa testtäckning och frekvens. Rekommendationer om hotmodellering finns i Rekommendationer för att skydda en utvecklingslivscykel.
De flesta tester som beskrivs i de här avsnitten kan köras som rutintester. Repeterbarhet kan dock medföra kostnader i vissa fall och orsaka störningar. Tänk noga på dessa kompromisser.
Tester som validerar teknikstacken
Här är några exempel på typer av tester och deras fokusområden. Den här listan är inte fullständig. Testa hela stacken, inklusive programstacken, klientdelen, serverdelen, API:er, databaser och eventuella externa integreringar.
Datasäkerhet: Testa effektiviteten hos datakryptering och åtkomstkontroller för att säkerställa att data skyddas mot obehörig åtkomst och manipulering.
Nätverk och anslutning: Testa brandväggarna för att säkerställa att de endast tillåter förväntad, tillåten och säker trafik till arbetsbelastningen.
Program: Testa källkoden via TEKNIKER för programsäkerhetstestning (AST) för att se till att du följer säkra kodningsmetoder och för att fånga upp körningsfel som minnesskada och behörighetsproblem. Mer information finns i dessa community-länkar.
Identitet: Utvärdera om rolltilldelningar och villkorsstyrda kontroller fungerar som avsett.
Testmetod
Det finns många perspektiv på testmetoder. Vi rekommenderar tester som möjliggör hotjakt genom att simulera verkliga attacker. De kan identifiera potentiella hotaktörer, deras tekniker och deras kryphål som utgör ett hot mot arbetsbelastningen. Gör attackerna så realistiska som möjligt. Använd alla potentiella hotvektorer som du identifierar under hotmodellering.
Här är några fördelar med att testa genom verkliga attacker:
När du gör dessa attacker till en del av rutintestningen använder du ett externt perspektiv för att kontrollera arbetsbelastningen och se till att försvaret klarar en attack.
Baserat på de lärdomar de har lärt sig uppgraderar teamet sin kunskaps- och kompetensnivå. Teamet förbättrar situationsmedvetenheten och kan själv utvärdera sin beredskap att svara på incidenter.
Några exempel på simulerade tester är black-box- och white box-testning, penetrationstestning och krigsspelsövningar.
Testning i svart och vit ruta
Dessa testtyper erbjuder två olika perspektiv. I tester med svarta rutor visas inte systemets interna objekt. I white box-tester har testaren en god förståelse för programmet och har även åtkomst till kod, loggar, resurstopologi och konfigurationer för att utföra experimentet.
Tester som simulerar attacker genom intrångstestning
Säkerhetsexperter som inte ingår i organisationens IT- eller programteam utför intrångstester eller penntestning. De tittar på systemet på det sätt som skadliga aktörer omfång för en attackyta. Målet är att hitta säkerhetsluckor genom att samla in information, analysera sårbarheter och rapportera resultaten.
Utövarna kan behöva åtkomst till känsliga data i hela organisationen. Följ reglerna för åtagande för att säkerställa att åtkomsten inte missbrukas. Se resurserna i Relaterade länkar.
Tester som simulerar attacker genom krigsspelövningar
I den här metoden för simulerade attacker finns det två team:
Det röda teamet är den angripare som försöker modellera verkliga attacker. Om de lyckas hittar du luckor i säkerhetsdesignen och utvärderar sprängradie-inneslutningen av deras överträdelser.
Det blå teamet är det arbetsbelastningsteam som försvarar sig mot attackerna. De testar sin förmåga att identifiera, svara och åtgärda attackerna. De verifierar de försvar som har implementerats för att skydda arbetsbelastningsresurser.
Om de utförs som rutintester kan krigsspelövningar ge kontinuerlig insyn och försäkran om att ditt försvar fungerar som det är utformat. Krigsspelövningar kan potentiellt testas på olika nivåer i dina arbetsbelastningar.
Ett populärt val för att simulera realistiska attackscenarier är Microsoft Defender för Office 365 Övning av attacksimulering.
Mer information finns i Insikter och rapporter för Övning av attacksimulering.
Information om konfiguration av rött team och blått team finns i Microsoft Cloud Red Teaming.
Azure-underlättande
Microsoft Sentinel är en intern kontroll som kombinerar SIEM-funktioner (Security Information Event Management) och soAR-funktioner (Security Orchestration Automated Response). Den analyserar händelser och loggar från olika anslutna källor. Baserat på datakällor och deras aviseringar skapar Microsoft Sentinel incidenter och utför hotanalys för tidig identifiering. Med intelligent analys och frågor kan du proaktivt söka efter säkerhetsproblem. Om det uppstår en incident kan du automatisera arbetsflöden. Med arbetsboksmallar kan du också snabbt få insikter genom visualisering.
Produktdokumentation finns i Jaktfunktioner i Microsoft Sentinel.
Microsoft Defender for Cloud erbjuder sårbarhetsgenomsökning för olika teknikområden. Mer information finns i Aktivera sårbarhetsgenomsökning med Microsoft Defender – hantering av säkerhetsrisker – Microsoft Defender för molnet.
DevSecOps integrerar säkerhetstestning som en del av ett pågående och kontinuerligt förbättringstänk. Krigsspelövningar är en vanlig praxis som är integrerad i affärsrytmen på Microsoft. Mer information finns i Säkerhet i DevOps (DevSecOps).
Azure DevOps stöder verktyg från tredje part som kan automatiseras som en del av pipelines för kontinuerlig integrering/kontinuerlig distribution. Mer information finns i Aktivera DevSecOps med Azure och GitHub – Azure DevOps.
Relaterade länkar
Följ reglerna för engagemang för att se till att åtkomsten inte missbrukas. Vägledning om hur du planerar och kör simulerade attacker finns i följande artiklar:
Du kan simulera DoS-attacker (Denial of Service) i Azure. Se till att följa principerna som anges i Azure DDoS Protection-simuleringstestning.
Community-länkar
Testning av programsäkerhet: Verktyg, typer och metodtips – GitHub Resources beskriver de typer av testmetoder som kan testa programmets byggtids- och körningsskydd.
PTES (Penetration Testing Execution Standard) innehåller riktlinjer om vanliga scenarier och de aktiviteter som krävs för att upprätta en baslinje.
OWASP Top Ten | OWASP Foundation tillhandahåller rekommenderade säkerhetsmetoder för program och testfall som täcker vanliga hot.
Säkerhetskontrollista
Se den fullständiga uppsättningen rekommendationer.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för