Arkitekturstrategier för säkerhetstestning

Gäller följande rekommendation i checklistan för säkerhet i Azure Well-Architected Framework:

Rigorös testning är grunden för en bra säkerhetsdesign. Testning är också ett proaktivt sätt att identifiera sårbarheter i systemet.

Etablera testdisciplin genom regelbundenhet och verifiering ur flera perspektiv. Ta med inifrån och ut synpunkter som testar plattform och infrastruktur och externa utvärderingar som testar systemet som en extern angripare.

De viktigaste strategierna i den här artikeln bygger på de grundläggande testmetoderna som beskrivs i OE:09-arkitekturstrategier för testning. Granska den artikeln först. 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.

Terminology

Samarbeta med säkerhetsexperter för att utforma tester

Delta i testplaneringen. Ofta centraliserar en organisation den här uppgiften. Se till att ditt team deltar i den designprocessen så att säkerhetsgarantierna överensstämmer med programmets funktioner.

Utveckla ett tankesätt som utgår från att ett intrång redan har skett. Utforma testfallen med antagandet att systemet är under attack och att angriparen arbetar i miljön. Simulera dina tester för att återspegla realistiska attackscenarier, till exempel validering av den laterala förflyttnings inneslutningen i en komprometterad virtuell programdator. På så sätt kan du upptäcka potentiella sårbarheter och prioritera testerna i enlighet med detta.

Dela arkitekturdiagram, hotmodell och annan relevant dokumentation för att testa arbetsbelastningen på ett meningsfullt sätt.

Prioritera tester baserat på hotmodellering och kritiska flöden

Hotmodellering är en viktig metod för att identifiera potentiella hot och sårbarheter i din arbetsbelastning. Använd allvarlighetsgradsklassificeringarna från hotmodellen för att prioritera och begränsa dina testinsatser. De högsta allvarlighetshoten mot dina mest kritiska flöden förtjänar mest täckning.

Täck hela attackytan för arbetsbelastningen. Utvärdera identitet, programkod, infrastrukturkontroller, komponenter från tredje part, bibliotek och tjänster samt automatiserade och mänskliga processer som arbetsflöden för godkännande och åtkomstgranskningar.

Börja med identitets- och åtkomstkontroller eftersom en komprometterad identitet kringgår de flesta underordnade skydd. Verifiera sedan nätverksgränser och slutligen skydd på programnivå.

Prioritera flöden som hanterar autentisering, känsliga data eller finansiella transaktioner. För varje kritiskt flöde identifierar du hoten med högsta allvarlighetsgrad i din hotmodell. Skapa riskdrivna testfall som mappar varje hot till kontrollen som är avsedd att minimera det.

En bra hotmodelleringsövning pekar på viktiga områden för testtäckning och frekvens. Rekommendationer om hotmodellering finns i Rekommendationer för att skydda en utvecklingslivscykel.

Risk: Inaktuella hotmodeller kan leda till felriktade testinsatser. Uppdatera regelbundet hotmodellen så att den återspeglar ändringar i arbetsbelastningen och det växande hotlandskapet.

Dra nytta av expertis från tredje part

Interna team kan ha blinda fläckar. Externa experter och crowdsourced-forskare ser din arbetsbelastning som en angripare gör. Ta in specialiserade experter för att testa din arbetsbelastning ur en angripares perspektiv och ge insikter om de senaste attackteknikerna och trenderna.

Undvik att ge övergiven åtkomst till din arbetsbelastning. Ge externa testare endast den åtkomst som deras specifika engagemang kräver. Ett intrångstest i svarta rutor behöver ingen kod eller intern åtkomst, medan en white box-granskning behöver källkod, designdokument eller loggar.

Utvärdera om ditt team har kapacitet att sortera externa rapporter innan du startar ett program. Upprätta sedan ett bug bounty-program eller en mekanism för communityn för att rapportera säkerhetsproblem. Sortera varje rapporterad sökning, mata tillbaka bekräftade sårbarheter till din hotmodell och lägg till ett testfall för att fånga upp eventuella regressioner.

Testa efterlevnadskontroller och generera granskningsklara bevis

Efterlevnad är inte en engångsgranskning. Behandla varje regelkontroll som ett testbart krav så att du alltid har nya bevis för revisorer.

Identifiera de regler som din arbetsbelastning måste uppfylla. Mappa varje regelkontroll till ett specifikt testfall. Schemalägg testerna så att de körs på en återkommande takt och före varje livesändning. Lagra testutdata på en granskningsbar plats så att du kan skapa bevis på begäran.

Kompromiss: Tester för regelkontroller kan göra åtgärderna långsammare. Till exempel ökar tester före driftsättning fördröjningen i pipeline. Det tillkommer också en extra kostnad för att driva de här operationerna. Prioritera tester för kontroller med störst gransknings- och riskpåverkan.

Risk: Granskningsbevis är i sig känsliga. Utan integritetsskydd och åtkomstloggning blir bevislagret både en måltavla för attacker och ett potentiellt regelbrott.

Skydda testtillgångar

Testtillgångar är själva en attackyta. Skydda deras konfidentialitet, integritet och tillgänglighet så att testningen inte exponerar känslig information eller öppnar nya attackvektorer.

• Använd sanerade eller syntetiska data som inte innehåller någon personligt identifierbar information (PII) eller produktionsdata.
• Behåll endast testdata så länge som det behövs och ta bort dem på ett säkert sätt.
• Bekräfta att regler för gränsöverskridande datahemvist tillämpas i testmiljöer som sträcker sig över regioner.
• Generera dedikerade testautentiseringsuppgifter, API-nycklar och certifikat. Lagra dem i en separat key vault-instans med egna åtkomstprinciper.
• Konfigurera isolerade testmiljöer som speglar säkerhetskontroller för produktion, till exempel nätverkssäkerhetsgrupper (NSG), rollbaserade åtkomstkontrollprinciper (RBAC), brandväggs- och dataförlustskyddsregler (DLP). Använd samma segmenteringsvägledning som produktion. Mer information finns i Rekommendationer för segmenteringsstrategi.

Utföra regelbundna sårbarhetsgenomsökningar på testtillgångar

Genomsök testtillgångar efter sårbarheter i samma takt som produktionstillgångar, inklusive testkod, infrastruktur som kod (IaC), container- och VM-avbildningar, lagringsplatser och pipelines. Använd verktyg som integreras med dina arbetsflöden för utveckling och distribution för att automatisera dessa kontroller.

Upprätta en kontinuerlig testrytm för arbetsbelastningen

Behandla säkerhetstestning som en kontinuerlig aktivitet som håller arbetsbelastningens säkerhetsstatus aktuell när hot, kod och konfigurationer utvecklas. Kör tester enligt ett schema så att ändringar inte medför säkerhetsrisker eller regressioner. Var redo för organisationssäkerhetsvalidering som kan ske när som helst och för tester som utlöses av en säkerhetsincident. I följande avsnitt beskrivs de kadenser som du ska planera för.

Rutintester

Rutintester anger baslinjen för din arbetsbelastnings säkerhetsstatus. Utför dem regelbundet som en del av dina standardrutiner och för att uppfylla efterlevnadskraven. Du kan köra olika tester vid olika tidpunkter, men nyckeln är att du utför dem regelbundet och enligt ett schema.

Diversifiera testpaketet för att verifiera garantier för identitet, datalagring och överföring samt kommunikationskanaler. När du upptäcker nya problem vid samma tidpunkter i livscykeln lägger du till nya testfall.

Förlita dig inte bara på automatiserade tester. Använd manuell testning för att hitta sårbarheter som endast mänsklig expertis kan fånga upp och för undersökande arbete med okända risker.

Improviserade tester

Improviserade tester ger validering vid en given tidpunkt av säkerhetsåtgärder. Säkerhetsaviseringar som kan påverka arbetsbelastningen vid den tidpunkten utlöser dessa tester. Organisationsmandat kan kräva ett paus-och-test-tänkesätt för att verifiera effektiviteten i försvarsstrategier om aviseringen eskalerar till en nödsituation.

Fördelen med improviserade tester är beredskapen för en verklig incident. Dessa tester kan vara en tvingad funktion för att utföra användargodkännandetestning (UAT).

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.

Avvägning: Eftersom improviserade tester är störande händelser kan du förvänta 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. Utvärdera dessa risker i förhållande till fördelarna.

Säkerhetsincidenttester

Använd tester som identifierar orsaken till en säkerhetsincident vid källan. Lös dessa säkerhetsluckor för att förhindra att incidenten upprepas.

Incidenter förbättrar också testfall över tid genom att upptäcka befintliga luckor. Teamet bör tillämpa de lärdomar som dragits av incidenten och rutinmässigt införliva förbättringar.

Verifiera säkerhetskontroller över attackytan

Använd en mängd olika testmetoder för att få fullständig täckning och upptäcka luckor i säkerhetskontroller, felkonfigurationer och svagheter i observerbarhet och identifiering. De flesta tester som beskrivs i det här avsnittet kan köras som rutintester. Repeterbarhet kan dock medföra kostnader och orsaka störningar. Tänk noga på dessa kompromisser.

Testa krypteringskontroller. Krypteringsfel är tysta. Data ser skyddade ut tills ett intrång avslöjar något annat.

• Verifiera att kryptering tillämpas, inte bara konfigurerat.
• Testa igen efter varje nyckelrotation, certifikatförnyelse och infrastrukturändring.

Testa nätverkskontroller. Nätverksgränser är där segmenteringen tillämpas.

• Testa dem efter ändringar i nätverkstopologin.
• Kontrollera att regler om att neka som standard efterlevs och att tillåtna trafikvägar överensstämmer med den avsedda arkitekturen.

Testa applikationskod. Skydd på programnivå är den sista gränsen innan en angripare når data.

• Verifiera att distribuerade program motstår vanliga attackmönster i stället för att bara genomsöka källkod vid bygget.
• Kör tekniker för programsäkerhetstestning (AST) i källkoden för att bekräfta säkra kodningsmetoder och för att fånga upp körningsfel som minnesskada och behörighetsproblem. Mer information finns i Community-länkar.

Simulera identitetsbaserade attacker och verifiera identifiering

Identitetsbaserade attacker är den vanligaste initiala attackvektorn. Simulera dessa attacker för att verifiera att dina identitetskontroller fungerar och att övervakningen samlar in händelserna.

Åtkomstkontroller är den första försvarslinjen. Testa dem efter varje roll eller principändring och enligt ett automatiserat schema. Simulera vanliga attackmönster och bekräfta att dina kontroller framtvingar minsta behörighet och motstår förbikopplingsförsök.

Tänk på dessa attackmönster när du utformar tester:

• Förbikoppling av auktorisering
• Tokenstöld och repris
• Lateral förflyttning mellan konton eller tjänster
• Eskalering av privilegier

Verifiera båda sidor av varje kontroll:

• Positiva fall: behöriga användare lyckas.
• Negativa fall: Obehöriga försök blockeras och loggas.

Testa hotidentifiering och aviseringar

Identifiering som inte utlöser en avisering ger lite värde. Testa övervakningen och aviseringen som en del av varje verifiering av säkerhetskontroll och kontrollera att de mekanismer som är utformade för att identifiera attacker fungerar som förväntat.

Kör slutpunkt till slutpunkt-simuleringar av attackerna och bekräfta sedan varje steg i identifieringspipelinen:

• Kontrollera att säkerhetshändelser som inloggningsförsök, behörighetsändringar och tokenåtgärder loggas med tillräckligt med information.
• Kontrollera att er SIEM-plattform (Security Information and Event Management) eller instrumentpanel för säkerhetsövervakning korrelerar relaterade händelser.
• Upprätta ett serviceavtal (SLA) för aviseringar och testa att aviseringar kan åtgärdas och visas inom den tidsramen.
• Kontrollera att loggar inte kan manipuleras eller tas bort av icke-administrativa konton.
• Kontrollera att detekteringsmekanismen för varje simulerad attack aktiveras. Om du till exempel simulerar en DDoS-attack (Distributed Denial-of-Service) med giltiga trafikmönster bekräftar du att hastighetsbegränsningen identifierar och minimerar den.

För mogna arbetsbelastningar validerar du styrningsramar som en del av rutinmässiga tester. Introducera avsiktligt osäkra konfigurationer och kontrollera att pipelinen identifierar och svarar. Bekräfta att Azure Policy- eller landningszonens begränsningar framtvingar det förväntade skyddet. Plattformen eller säkerhetsteamet utför vanligtvis den här testningen, inte arbetsbelastningsteamet.

Stärk skyddet med motståndarbaserade tester

Använd tester som möjliggör hotjakt genom att simulera verkliga attacker. Dessa tester kan identifiera potentiella hotaktörer, deras tekniker och deras sårbarheter 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 kan motstå en attack.
• Baserat på de lärdomar de lär sig uppgraderar teamet sin kunskaps- och kompetensnivå. Teamet förbättrar situationsmedvetenheten och kan själv utvärdera sin beredskap att svara på incidenter.

Risk: Testning i allmänhet kan påverka prestanda. Destruktiva tester kan ta bort eller skada data och orsaka problem med affärskontinuitet. Det finns också risker i samband med informationsexponering. Bevara datasekretessen. Kontrollera dataintegriteten när du har slutfört testningen.

Några exempel på simulerade tester är black-box- och white box-testning, penetrationstestning och krigsspelsövningar.

Testning med svart låda och vit låda

Dessa testtyper erbjuder två olika perspektiv. I black-box-tester 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.

Risk: Skillnaden mellan de två typerna är startkostnad. White box-testning kan vara dyrt när det gäller den tid det tar att förstå systemet. I vissa fall kräver white-box-testning att du köper specialiserade verktyg. Black-box-testning behöver ingen inkörningstid, men det kanske inte är särskilt effektivt. Du kan behöva lägga extra arbete på att upptäcka problem. Det är en tidsinvesteringsavvägning.

Tester som simulerar attacker genom intrångstestning

Säkerhetsexperter som inte ingår i organisationens IT- eller programteam utför intrångstestning eller pentestning. De ser på systemet på samma sätt som illvilliga aktörer undersöker en attackyta. Deras mål är att hitta säkerhetsluckor genom att samla in information, analysera sårbarheter och rapportera resultaten.

Kompromiss: Intrångstester är improviserade och kan vara dyra när det gäller störningar och monetära investeringar eftersom pentesting vanligtvis är ett betalt erbjudande av tredjepartsutövare.

Risk: En pentestningsövning kan påverka körningsmiljön och störa tillgängligheten för normal trafik.

Utövare kan behöva åtkomst till känsliga data i hela organisationen. Följ reglerna för engagemang för att säkerställa att åtkomsten inte missbrukas. Se de resurser som anges i Relaterade länkar.

Tester som simulerar attacker genom krigsspelsövningar

I den här metoden för simulerade attacker deltar två team:

• Det röda teamet fungerar som motståndare och försöker modellera verkliga attacker. Om de lyckas med sitt intrång hittar du luckor i din säkerhetsdesign och utvärderar hur väl deras intrångs påverkansområde är inneslutet.

• 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 validerar skyddsåtgärderna som skyddar resurser för arbetslaster.

Om du utför dessa tester rutinmässigt kan krigsspelsövningar ge kontinuerlig synlighet och försäkran om att ditt försvar fungerar som det är utformat. Krigsspelsö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 utbildning i attacksimulering.

Mer information finns i Insikter och rapporter för träning av attacksimulering.

Information om konfiguration av red-team och blue-team finns i Microsoft Cloud Red Teaming.

Azure-stöd

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. Genom intelligent analys och frågor kan du proaktivt söka efter säkerhetsproblem. Om det uppstår en incident kan du automatisera arbetsflöden. Genom att använda arbetsboksmallar kan du också snabbt få insikter genom visualisering.

För produktdokumentation, se Jaktkapaciteter i Microsoft Sentinel.

Microsoft Defender för molnet 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 kontinuerligt och kontinuerligt förbättringstänk. Krigsspelsö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 du kan automatisera 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:

• Regler för intrångstestning

• Intrångstest

Du kan simulera DoS-attacker (Denial of Service) i Azure. Se till att följa de principer som anges i Azure DDoS Protection-simuleringstestning.

Communitylänkar

Programsäkerhetstestning: 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 metodtips för säkerhet för program och testfall som täcker vanliga hot.

Säkerhetschecklista

Se den fullständiga uppsättningen rekommendationer.