Rekommendationer för säkerhetstestning
Gäller för den här Power Platform rekommendationen för checklista för Well-Architected Security:
| SE:09 | Upprätta ett omfattande testprogram som kombinerar metoder för att förhindra säkerhetsproblem, validera implementeringar av hotförebyggande och testa mekanismer för hotidentifiering. |
|---|
Rigorösa tester är grunden för en bra säkerhetsdesign. Tester är en verifieringsform som ser till att kontrollerna fungerar som de ska. Testning är också ett proaktivt sätt att identifiera säkerhetsproblem i systemet.
Skapa testmetoder med hjälp av kadens och verifiering ur flera perspektiv. Du bör inkludera perspektiv inifrån och ut som testar plattformen och infrastrukturen och utvärderingar utifrån och in som testar systemet som en extern angripare.
Den här guiden ger rekommendationer för att testa säkerhetsställningen för din arbetsbelastning. Implementera dessa testmetoder för att förbättra din arbetsbelastnings motståndskraft mot angrepp och bibehålla konfidentialitet, integritet och tillgänglighet av resurser.
Definitioner
| Begrepp | Definition |
|---|---|
| Säkerhetstester av program (AST) | En Microsoft SDL-teknik (Security Development Lifecycle) som använder white box- och black box-testmetoder för att kontrollera säkerhetsbrister i kod. |
| Black box-tester | En testmetod som verifierar det externt synliga programbeteendet utan kunskap om systemets interna funktioner. |
| Blått team | Ett team som försvarar mot angrepp från det röda teamet i en krigsspelsövning. |
| Intrångstest | En testmetod som använder etiska hackningstekniker för att validera ett systems säkerhetsförsvar. |
| Rött team | Ett team som spelar rollen som en motståndare och försöker hacka systemet i en krigsspelsövning. |
| Security Development Lifecycle (SDL) | En uppsättning praxis tillhandahållen av Microsoft som stöder säkerhetsförsäkring och efterlevnadskrav. |
| Software development lifecycle (SDLC) | En systematisk process för utveckling av programvarusystem i flera steg. |
| White box-tester | En testmetod där kodens struktur är känd för utövaren. |
Viktiga designstrategier
Testning är en icke förhandlingsbar strategi, särskilt för säkerhet. Du kan proaktivt upptäcka och åtgärda säkerhetsproblem innan de kan åtgärdas och kontrollera att de säkerhetskontroller du implementerar fungerar som de är utformade för.
Testningens omfattning måste omfatta program- och infrastrukturprocesser samt automatiserade och mänskliga processer.
Kommentar
Den här vägledningen gör skillnad mellan testning och incidentsvar. Även om tester är en detekteringsmekanism som åtgärdar problem innan de tas fram bör de inte förväxlas med de åtgärder eller åtgärder som har utförts som en del av incidentsvaret. Återställningsaspekten av säkerhetsincidenter beskrivs i Rekommendationer för svar på säkerhetsincidenter.
Var delaktig i testplaneringen. Arbetsbelastningsteamet kanske inte utformar testfallen. Den uppgiften centraliseras ofta i företaget eller av externa säkerhetsexperter. Arbetsbelastningsteamet bör vara delaktigt i designprocessen för att säkerställa att säkerhetssäkerheter integreras med programmets funktioner.
Tänk som en angripare. Designa dina testfall med antagandet att systemet har blivit angripet. På så sätt kan du identifiera de potentiella säkerhetsproblemen och prioritera testerna därefter.
Kör tester på ett strukturerat sätt och med en repeterbar process. Bygg testmetoderna kring kadens, testtyper, drivande faktorer och avsedda resultat.
Använd rätt verktyg för jobbet. Använd verktyg som är konfigurerade för att hantera arbetsbelastningen. Om du inte har något verktyg köper du verktyget. Bygg det inte. Säkerhetsverktygen är mycket specialiserade och om du bygger ett eget verktyg kan det leda till risker. Dra nytta av de expertområden och verktyg som erbjuds av centrala SecOps-team eller med hjälp av externa metoder om arbetsbelastningsteamet inte har den expertisen.
Konfigurera separata miljöer. Tester kan klassificeras som destruktiva eller icke-destruktiva. Icke-destruktiva tester är inte invasiva. De anger att det finns ett problem, men de ändrar inte funktionerna för att kunna åtgärda problemet på nytt. Destruktiva tester är invasiva och kan leda till att funktionerna kan tas bort från en databas.
Testning i produktionsmiljöer ger dig den bästa informationen men orsakar flest avbrott. Du brukar bara göra destruktiva tester i produktionsmiljöer. Testning i icke-produktionsmiljöer är vanligtvis mindre störande men återspeglar kanske inte konfigurationen av produktionsmiljön på sätt som är viktiga för säkerheten.
Du kan skapa en enstaka kloning av produktionsmiljön med hjälp av funktionen för miljökopiering. Om du har angett distributionspipelines kan du även distribuera lösningarna till en dedikerad testmiljö.
Utvärdera alltid testresultaten. Testning är en slöseri med arbete om resultaten inte används för att prioritera åtgärder och göra förbättringar. Dokumentera de säkerhetsriktlinjer, inklusive affärspraxis, som du hittar. Dokumentation som samlar in resultat och reparationsplaner ger information till teamet om de olika sätten att förbättra säkerheten. Genomför regelbundna säkerhetsutbildningar för utvecklare, administratörer och testare.
Tänk på följande frågor när du utformar testplaner:
- Hur ofta ska testet köras och hur påverkar det miljön?
- Vilka olika testtyper bör du köra?
Hur ofta ska testerna köras?
Testa arbetsbelastningen regelbundet för att försäkra dig om att ändringar inte innebär någon säkerhetsrisk och att det inte uppstår 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. I följande avsnitt finns rekommendationer om hur ofta tester utförs.
Rutintester
Rutintester utförs regelbundet, som en del av standardrutinerna och för att uppfylla krav på regelefterlevnad. Olika tester kan köras på olika nivåer, men nyckeln är att de utförs regelbundet och enligt ett schema.
Du bör integrera dessa tester i din SDLC eftersom de ger djupgående försvar i varje stadium. Diversifiera testsviten för att verifiera garantier för identitet, datalagring och överföring samt kommunikationskanaler. Genomför samma tester på olika platser under livscykeln för att se till att inga regressioner utförs. Rutinmässiga tester hjälper till att fastställa ett första riktmärke. Det är dock bara en utgångspunkt. När du upptäcker nya problem på samma punkter i livscykeln lägger du till nya testfall. Testerna förbättras också med upprepning.
I varje stadium 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 ändringarna. Du bör förbättra testerna genom att använda automatisering och balansera dem med expertgranskningar.
Överväg att köra säkerhetstester som en del av en automatisk pipeline eller en schemalagd testkörning. Ju fortare du upptäcker säkerhetsproblem, desto lättare ä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 upptäcka sårbarheter som endast mänsklig expertis kan identifiera. Manuell testning är bra för explorativa användningsfall och för att hitta okända risker.
Improviserade tester
Improviserade tester ger en tidpunktsvalidering av säkerhetsförsvar. Säkerhetsaviseringar som kan påverka arbetsbelastningen utlöser dessa tester. Organisatoriska mandat kan kräva ett tänkesätt där man pausar och testar för att verifiera effektiviteten i försvarsstrategier om larmet skulle eskalera till en nödsituation.
Fördelen med improviserade tester är att de förbereds för en verklig incident. Dessa tester kan vara en tvingande funktion för att använda acceptanstester (UAT).
Säkerhetsteamet kan granska alla arbetsbelastningar och köra dessa tester efter behov. Som ägare av arbetsbelastningen måste du underlätta och samarbeta med säkerhetsteam. Förhandla fram tillräckligt med förberedelsetid med säkerhetsteam så att du kan förbereda dig. Bekräfta och meddela ditt team och intressenter att dessa avbrott är nödvändiga.
I andra fall kan du behöva köra tester och rapportera säkerhetstillståndet för systemet mot det potentiella hotet.
Kompromiss: 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: Dit risk för det okända. Improviserade tester kan vara engångsinsatser utan etablerade processer eller verktyg. Men den dominerande risken är potentiella avbrott i affärsrytmen. Du måste utvärdera dem som är av betydelse 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 lösas för att säkerställa att incidenten inte upprepas.
Incidenter förbättrar också testfallen med tiden genom att befintliga problem upptäcks. 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 att testa olika metoder. Om du kombinerar de här kategorierna och arbetssätten inom de kategorierna blir de fullständigt tillgängliga.
Genom att lägga till flera tester och typer av tester kan du avslöja:
- Säkerhetskontroller och kompenseringskontroller är inte helt i sin ordning.
- Felkonfigurationer.
- Luckor i observerbarhet och detektionsmetoder.
En bra hotmodell kan peka ut nyckelområden för att säkerställa testdisponering och frekvens. Rekommendationer om hotmodeller finns i Rekommendationer för att säkerställa en livscykel för utveckling.
De flesta tester som beskrivs i avsnitten kan köras som rutintester. Repeterbarhet kan emellertid leda till kostnader i vissa fall och orsaka avbrott. Överväg dessa avvägningar noggrant.
Tester som verifierar teknikstacken
Här följer några exempel på typer av tester och deras fokusområden. Den här listan är inte uttömmande. Testa hela stacken, inklusive programstapeln, 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 är korrekt skyddade mot obehörig åtkomst och manipulering.
- Nätverk och anslutning: Testa dina brandväggar för att se till att de endast tillåter förväntad, tillåten och säker trafik till arbetsbelastningen.
- Program: Testa källkoden via AST-tekniker (Application Security Testing) för att se till att du följer säkra kodningsmetoder och för att fånga upp körningsfel som minneskorruption och behörighetsproblem.
- Identitet: Utvärdera om rolltilldelningarna och villkorsstyrda kontrollerna fungerar som avsett.
Testmetod
Det finns många olika perspektiv på att testa olika metoder. Vi rekommenderar tester som möjliggör hotjakt genom att simulera verkliga angrepp. De kan identifiera potentiella hot mot belastningen, deras tekniker och metoder som utgör ett hot mot arbetsbelastningen. Se till att angreppen är så realistiska som möjligt. Använd alla potentiella hotbildsobjekt som du identifierar vid modellering av hot.
Här är några fördelar med att testa verkliga angrepp:
- När du gör de här angreppen till en del i rutintester använder du ett perspektiv utifrån för att kontrollera arbetsbelastningen och se till att belastningen kan användas vid ett angrepp.
- Utifrån de erfarenheter de har lärt sig uppgraderar teamet sin kunskap och kompetens. Teamet ökar situationsmedvetenheten och kan själv utvärdera om de är redo att svara på incidenter.
Några exempel på simulerade tester är bland annat black box- och white box-tester, intrångstest och krigsspelsövningar.
Black box- och white box-testning
Dessa testtyper har två olika perspektiv. I black box-tester visas inte systemets interna delar. I white box-tester har testarna en god förståelse av programmet och har även tillgång till kod, loggar, resurstopologi och konfigurationer för att utföra experimentet.
Tester som simulerar angrepp med hjälp av intrångstester
Säkerhetsexperter som inte är en del av organisationens IT- eller appteam genomför intrångstest, eller pentest. De undersöker systemet på det sätt som skadliga aktörer skulle bedöma en angreppsyta. Deras mål är att hitta säkerhetsluckor genom att samla in information, analysera sårbarheter och rapportera resultaten.
Utövarna kan behöva tillgång till känslig information i hela organisationen. Följ reglerna för engagemang för att säkerställa att åtkomsten inte missbrukas. Se resurserna som anges i Relaterad information.
Tester som simulerar angrepp med hjälp av krigsspelsövningar
I den här metoden för simulerade angrepp finns det två team:
- Det röda teamet är motståndaren som försöker skapa modeller för verkliga angrepp. Om de lyckas, upptäcker du luckor i din säkerhetsdesign och utvärderar inneslutningen av skadeområdet från deras intrång.
- Det blå teamet är det arbetsbelastningsteam som förser sig med åtgärder mot angreppen. De testar sin förmåga att upptäcka, svara och åtgärda angreppen. De verifierar de implementerade åtgärderna för att skydda arbetsbelastningsresurser.
Om de utförs som rutintester kan testerna ge kontinuerlig synlighet och säkerhet för att dina säkerhetssystem fungerar som de ska. Krigsspelsövningar kan potentiellt testas på olika nivåer inom dina arbetsbelastningar.
Ett populärt val för att simulera realistiska attackscenarier är Microsoft Defender för Office 365 Träning i angreppssimulering.
Mer information finns i Insikter och rapporter för utbildning om angrepp.
För information om inställning av rött team och blått team, se Microsoft Cloud rött team.
Underlätta Power Platform
Med Microsoft Sentinel-lösningen kan Microsoft Power Platform kunderna upptäcka olika typer av aktiviteter, till exempel:
- Power Apps-körning från obehöriga geografiska områden
- Misstänkt dataförstörelse i Power Apps
- Massborttagning av Power Apps
- Nätfiskeangrepp genom Power Apps
- Flödesaktivitet i Power Automate från avgående anställda
- Microsoft Power Platform-anslutningsprogram tillagda i en miljö
- Uppdatering eller borttagning av Microsoft Power Platform-principer som förhindrar dataförlust
Mer information finns i Översikt till Microsoft Sentinel-lösning för Microsoft Power Platform.
För produktdokumentation, se Jaktfunktioner i Microsoft Sentinel.
Microsoft Defender för molnet erbjuder sårbarhetsskanning för olika teknikområden. Mer information finns i Aktivera sårbarhetsskanning med Microsoft Defender sårbarhetshantering.
DevSec integrerar säkerhetstester som en del i en pågående och kontinuerlig förbättring. Krigsspelsövningar är en vanlig praxis som är integrerad i affärsrytmen hos Microsoft. Mer information finns i Säkerhet i DevOps (DevSecOps).
Azure DevOps har stöd för tredjepartsverktyg som kan automatiseras som en del av pipelinerna för kontinuerlig integrering/kontinuerlig distribution (CI/CD). Mer information finns i Aktivera DevSecHub med Azure och GitHub.
Relaterad information
De senaste genomslagstester och säkerhetsbedömningar kan hittas på Microsoft Service Trust Portal.
Microsoft utför omfattande tester av Microsoft Cloud-tjänsterna. Testerna inkluderar tester med resultat som publicerats på Service Trust Portal för organisationen. Organisationen kan utföra ett eget intrångstest på Microsoft Power Platform och Microsoft Dynamics 365-tjänster. Alla intrångstester måste följa Regler för engagemang för Microsoft Cloud intrångstester. Det är viktigt att komma ihåg att i många fall använder Microsoft Cloud delad infrastruktur för att vara värd för dina tillgångar och andra kunders tillgångar. Du måste begränsa alla intrångstester till dina tillgångar och undvika oavsiktliga konsekvenser för andra kunder runt om dig.
Följ reglerna för engagemang för att säkerställa att åtkomsten inte missbrukas. Mer information om hur du planerar och genomför simulerade angrepp finns i:
Du kan simulera överbelastningsattacker (DoS) i Azure. Följ policyerna som finns i Simuleringstester för Azure DDoS Protection.
Checklista för säkerhet
Se den fullständiga uppsättningen med rekommendationer.