Aanbevelingen voor beveiligingstests
Van toepassing op deze aanbeveling voor de controlelijst voor beveiliging van Azure Well-Architected Framework:
| SE:11 | Stel een uitgebreid testschema in dat benaderingen combineert om beveiligingsproblemen te voorkomen, implementaties voor preventie van bedreigingen te valideren en mechanismen voor het detecteren van bedreigingen te testen. |
|---|
Grondig testen is de basis van een goed beveiligingsontwerp. Testen is een tactische vorm van validatie om ervoor te zorgen dat besturingselementen naar behoren werken. Testen is ook een proactieve manier om beveiligingsproblemen in het systeem te detecteren.
Stel de test strikt in door middel van cadans en verificatie vanuit meerdere perspectieven. U moet inside-out standpunten opnemen die het platform en de infrastructuur testen en externe evaluaties die het systeem als een externe aanvaller testen.
Deze handleiding bevat aanbevelingen voor het testen van de beveiligingspostuur van uw workload. Implementeer deze testmethoden om de weerstand van uw workload tegen aanvallen te verbeteren en de vertrouwelijkheid, integriteit en beschikbaarheid van resources te behouden.
Definities
| Termijn | Definitie |
|---|---|
| Application Security Testing (AST) | Een SDL-techniek (Microsoft Security Development Lifecycle) die gebruikmaakt van white-box- en black-box-testmethoden om te controleren op beveiligingsproblemen in code. |
| Black-box testen | Een testmethodologie die het extern zichtbare toepassingsgedrag valideert zonder kennis van de interne kenmerken van het systeem. |
| Blauw team | Een team dat zich verdedigt tegen de aanvallen van het rode team in een oorlogsspeloefening. |
| Penetratietesten | Een testmethodologie die gebruikmaakt van ethische hacktechnieken om de beveiligingsbeveiliging van een systeem te valideren. |
| Rood team | Een team dat de rol van een aanvaller speelt en probeert het systeem te hacken in een oorlogsspeloefening. |
| Security Development Lifecycle (SDL) | Een reeks procedures van Microsoft die ondersteuning bieden voor vereisten voor beveiligingscontrole en naleving. |
| Levenscyclus van softwareontwikkeling (SDLC) | Een meertraps, systematisch proces voor het ontwikkelen van softwaresystemen. |
| White-box testen | Een testmethodologie waarbij de structuur van de code bekend is bij de praktijk. |
Belangrijke ontwerpstrategieën
Testen is een niet-af te voeren strategie, met name voor beveiliging. Hiermee kunt u proactief beveiligingsproblemen detecteren en oplossen voordat ze kunnen worden misbruikt en om te controleren of de beveiligingscontroles die u hebt geïmplementeerd, naar behoren functioneren.
Het bereik van het testen moet de toepassing, infrastructuur en geautomatiseerde en menselijke processen omvatten.
Notitie
In deze richtlijnen wordt een onderscheid gemaakt tussen testen en reageren op incidenten. Hoewel testen een detectiemechanisme is dat idealiter problemen vóór productie oplost, moet het niet worden verward met het herstel of onderzoek dat wordt uitgevoerd als onderdeel van de reactie op incidenten. Het aspect van het herstellen van beveiligingsincidenten wordt beschreven in Aanbevelingen voor reactie op incidenten.
SDL bevat verschillende soorten tests die beveiligingsproblemen in code ondervangen, runtime-onderdelen verifiëren en ethische hacking gebruiken om de beveiligingstolerantie van het systeem te testen. SDL is een belangrijke shift-left-activiteit. U moet zo vroeg mogelijk in het ontwikkelingsproces tests uitvoeren, zoals statische codeanalyse en automatisch scannen van infrastructuur als code (IaC).
Betrokken zijn bij de testplanning. Het workloadteam ontwerpt de testcases mogelijk niet. Deze taak wordt vaak gecentraliseerd in de onderneming of uitgevoerd door externe beveiligingsexperts. Het workloadteam moet worden betrokken bij dat ontwerpproces om ervoor te zorgen dat beveiligingsgaranties worden geïntegreerd met de functionaliteit van de toepassing.
Denk als een aanvaller. Ontwerp uw testcases met de veronderstelling dat het systeem is aangevallen. Op die manier kunt u de potentiële beveiligingsproblemen blootleggen en de tests dienovereenkomstig prioriteren.
Voer tests op een gestructureerde manier en met een herhaalbaar proces uit. Bouw uw testgereedheid op basis van cadans, typen tests, factoren en beoogde resultaten.
Gebruik het juiste hulpprogramma voor de taak. Gebruik hulpprogramma's die zijn geconfigureerd voor gebruik met de workload. Als u geen gereedschap hebt, koopt u het gereedschap. Bouw het niet. Beveiligingshulpprogramma's zijn zeer gespecialiseerd en het bouwen van uw eigen hulpprogramma kan risico's met zich meebrengen. Profiteer van de expertise en hulpprogramma's die worden aangeboden door centrale SecOps-teams of door externe middelen als het workloadteam die expertise niet heeft.
Stel afzonderlijke omgevingen in. Tests kunnen worden geclassificeerd als destructief of niet-destructief. Niet-destructieve tests zijn niet invasief. Ze geven aan dat er een probleem is, maar ze veranderen de functionaliteit niet om het probleem op te lossen. Destructieve tests zijn invasief en kunnen de functionaliteit beschadigen door gegevens uit een database te verwijderen.
Testen in productieomgevingen biedt u de beste informatie, maar veroorzaakt de meeste onderbrekingen. In productieomgevingen voert u meestal alleen niet-destructieve tests uit. Testen in niet-productieomgevingen is doorgaans minder verstorend, maar vertegenwoordigt mogelijk niet nauwkeurig de configuratie van de productieomgeving op manieren die belangrijk zijn voor de beveiliging.
Als u implementeert met behulp van IaC en automatisering, moet u overwegen of u een geïsoleerde kloon van uw productieomgeving kunt maken om te testen. Als u een doorlopend proces voor routinetests hebt, raden we u aan een toegewezen omgeving te gebruiken.
Evalueer altijd de testresultaten. Testen is een verspilde inspanning als de resultaten niet worden gebruikt om prioriteit te geven aan acties en verbeteringen upstream aan te brengen. Documenteer de beveiligingsrichtlijnen, inclusief aanbevolen procedures, die u ontdekt. Documentatie die resultaten en herstelplannen vastlegt, informeert het team over de verschillende manieren waarop aanvallers kunnen proberen de beveiliging te schenden. Regelmatig beveiligingstrainingen uitvoeren voor ontwikkelaars, beheerders en testers.
Wanneer u uw testplannen ontwerpt, moet u nadenken over de volgende vragen:
Hoe vaak verwacht u dat de test wordt uitgevoerd en hoe heeft deze invloed op uw omgeving?
Wat zijn de verschillende testtypen die u moet uitvoeren?
Hoe vaak verwacht u dat de tests worden uitgevoerd?
Test de workload regelmatig om ervoor te zorgen dat wijzigingen geen beveiligingsrisico's met zich meebrengen en of er geen regressies zijn. Het team moet ook klaar zijn om te reageren op beveiligingsvalidaties van de organisatie die op elk gewenst moment kunnen worden uitgevoerd. Er zijn ook tests die u kunt uitvoeren als reactie op een beveiligingsincident. De volgende secties bevatten aanbevelingen voor de frequentie van tests.
Routinetests
Routinetests worden regelmatig uitgevoerd, als onderdeel van uw standaard bedrijfsprocedures en om te voldoen aan de nalevingsvereisten. Verschillende tests kunnen met verschillende frequenties worden uitgevoerd, maar het belangrijkste is dat ze periodiek en volgens een schema worden uitgevoerd.
U moet deze tests integreren in uw SDLC, omdat ze diepgaande verdediging bieden in elke fase. Diversifiëren van de testsuite om de garanties voor identiteit, gegevensopslag en -overdracht en communicatiekanalen te verifiëren. Voer dezelfde tests uit op verschillende punten in de levenscyclus om ervoor te zorgen dat er geen regressies zijn. Routinetests helpen bij het vaststellen van een eerste benchmark. Maar dat is slechts een beginpunt. Wanneer u nieuwe problemen ontdekt op dezelfde momenten van de levenscyclus, voegt u nieuwe testcases toe. De tests verbeteren ook met herhaling.
In elke fase moeten deze tests code valideren die is toegevoegd of verwijderd of configuratie-instellingen die zijn gewijzigd om de beveiligingsimpact van deze wijzigingen te detecteren. U moet de effectiviteit van de tests verbeteren met automatisering, afgewogen met peer reviews.
Overweeg beveiligingstests uit te voeren als onderdeel van een geautomatiseerde pijplijn of geplande testuitvoering. Hoe eerder u beveiligingsproblemen ontdekt, hoe gemakkelijker het is om de code of configuratiewijziging te vinden die deze veroorzaakt.
Vertrouw niet alleen op geautomatiseerde tests. Gebruik handmatige tests om beveiligingsproblemen te detecteren die alleen door menselijke expertise kunnen worden ondervangen. Handmatig testen is goed voor verkennende gebruiksscenario's en het vinden van onbekende risico's.
Geïmproviseerde tests
Geïmproviseerde tests bieden een point-in-time-validatie van beveiligingsbeveiligingen. Beveiligingswaarschuwingen die van invloed kunnen zijn op de workload op dat moment activeren deze tests. Organisatiemandaten vereisen mogelijk een pauze-en-test-instelling om de effectiviteit van verdedigingsstrategieën te controleren als de waarschuwing escaleert naar een noodgeval.
Het voordeel van geïmproviseerde tests is voorbereiding op een echt incident. Deze tests kunnen een geforceerde functie zijn om gebruikersacceptatietests (UAT) uit te voeren.
Het beveiligingsteam kan alle workloads controleren en deze tests indien nodig uitvoeren. Als eigenaar van een workload moet u beveiligingsteams faciliteren en samenwerken. Onderhandelen over voldoende doorlooptijd met beveiligingsteams, zodat u zich kunt voorbereiden. Erken en communiceer met uw team en belanghebbenden dat deze onderbrekingen noodzakelijk zijn.
In andere gevallen moet u mogelijk tests uitvoeren en de beveiligingsstatus van het systeem rapporteren tegen de mogelijke bedreiging.
Compromis: Omdat geïmproviseerde tests verstorende gebeurtenissen zijn, kunt u verwachten dat taken opnieuw worden gepriritiseerd, waardoor ander gepland werk mogelijk wordt vertraagd.
Risico: er is een risico op het onbekende. Geïmproviseerde tests kunnen eenmalige inspanningen zijn zonder vastgestelde processen of hulpprogramma's. Maar het overheersende risico is de mogelijke onderbreking van het bedrijfsritme. U moet deze risico's evalueren ten opzichte van de voordelen.
Tests voor beveiligingsincidenten
Er zijn tests waarmee de oorzaak van een beveiligingsincident bij de bron wordt gedetecteerd. Deze beveiligingsproblemen moeten worden opgelost om ervoor te zorgen dat het incident zich niet herhaalt.
Incidenten verbeteren ook testcases in de loop van de tijd door bestaande hiaten aan het licht te brengen. Het team moet de lessen van het incident toepassen en regelmatig verbeteringen opnemen.
Wat zijn de verschillende soorten tests?
Tests kunnen worden gecategoriseerd op technologie en door testmethoden. Combineer deze categorieën en benaderingen binnen deze categorieën om volledige dekking te krijgen.
Door meerdere tests en typen tests toe te voegen, kunt u het volgende ontdekken:
Hiaten in beveiligingscontroles of compenserende controles.
Onjuiste configuraties.
Hiaten in waarneembaarheid en detectiemethoden.
Een goede bedreigingsmodelleringsoefening kan verwijzen naar belangrijke gebieden om de dekking en frequentie van de test te garanderen. Zie Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus voor aanbevelingen over threat modeling.
De meeste tests die in deze secties worden beschreven, kunnen worden uitgevoerd als routinetests. Herhaalbaarheid kan in sommige gevallen echter kosten met zich meebrengen en onderbrekingen veroorzaken. Houd rekening met deze compromissen.
Tests die de technologiestack valideren
Hier volgen enkele voorbeelden van typen tests en hun aandachtsgebieden. Deze lijst is niet volledig. Test de volledige stack, inclusief de toepassingsstack, front-end, back-end, API's, databases en eventuele externe integraties.
Gegevensbeveiliging: Test de effectiviteit van gegevensversleuteling en toegangsbeheer om ervoor te zorgen dat gegevens goed worden beschermd tegen onbevoegde toegang en manipulatie.
Netwerk en connectiviteit: test uw firewalls om ervoor te zorgen dat ze alleen verwacht, toegestaan en veilig verkeer naar de workload toestaan.
Toepassing: Test broncode via AST-technieken (Application Security Testing) om ervoor te zorgen dat u de procedures voor veilig coderen volgt en runtimefouten zoals geheugenbeschadiging en problemen met bevoegdheden op te sporen. Zie deze communitykoppelingen voor meer informatie.
Identiteit: Evalueer of de roltoewijzingen en voorwaardelijke controles werken zoals bedoeld.
Testmethodologie
Er zijn veel perspectieven op testmethoden. We raden tests aan die het opsporen van bedreigingen mogelijk maken door echte aanvallen te simuleren. Ze kunnen potentiële bedreigingsactoren, hun technieken en hun aanvallen identificeren die een bedreiging vormen voor de workload. Maak de aanvallen zo realistisch mogelijk. Gebruik alle mogelijke bedreigingsvectoren die u tijdens het maken van bedreigingsmodellen identificeert.
Hier volgen enkele voordelen van testen via echte aanvallen:
Wanneer u deze aanvallen een onderdeel maakt van routinetests, gebruikt u een extern perspectief om de workload te controleren en ervoor te zorgen dat de verdediging bestand is tegen een aanval.
Op basis van de lessen die ze hebben geleerd, verbetert het team hun kennis- en vaardigheidsniveau. Het team verbetert het situationele bewustzijn en kan zelf beoordelen of ze gereed zijn om te reageren op incidenten.
Enkele voorbeelden van gesimuleerde tests zijn black-box- en white-box-tests, penetratietests en oorlogsspeloefeningen.
Black-box en white-box testen
Deze testtypen bieden twee verschillende perspectieven. In black box-tests zijn de interne functies van het systeem niet zichtbaar. In white box-tests heeft de tester een goed inzicht in de toepassing en heeft hij zelfs toegang tot code, logboeken, resourcetopologie en configuraties voor het uitvoeren van het experiment.
Tests die aanvallen simuleren via penetratietests
Beveiligingsexperts die geen deel uitmaken van de IT- of toepassingsteams van de organisatie voeren penetratietests of pentests uit. Ze kijken naar het systeem op de manier waarop kwaadwillende actoren een aanvalsoppervlak bereiken. Hun doel is om beveiligingsproblemen te vinden door informatie te verzamelen, beveiligingsproblemen te analyseren en de resultaten te rapporteren.
De beoefenaars hebben mogelijk toegang nodig tot gevoelige gegevens in de hele organisatie. Volg de regels voor betrokkenheid om ervoor te zorgen dat de toegang niet wordt misbruikt. Zie de resources die worden vermeld in Gerelateerde koppelingen.
Tests die aanvallen simuleren via oorlogsspeloefeningen
In deze methodologie van gesimuleerde aanvallen zijn er twee teams:
Het rode team is de kwaadwillende poging om echte aanvallen te modelleren. Als ze succesvol zijn, vindt u hiaten in uw beveiligingsontwerp en evalueert u de insluiting van de explosieradius van hun schendingen.
Het blauwe team is het workloadteam dat zich verdedigt tegen de aanvallen. Ze testen hun vermogen om de aanvallen te detecteren, te reageren en te herstellen. Ze valideren de verdedigingen die zijn geïmplementeerd om workloadresources te beveiligen.
Als ze worden uitgevoerd als routinetests, kunnen oorlogsspeloefeningen doorlopend zichtbaarheid bieden en zekerheid bieden dat uw verdediging werkt zoals ontworpen. Oorlogsspeloefeningen kunnen mogelijk worden getest op verschillende niveaus binnen uw workloads.
Een populaire keuze voor het simuleren van realistische aanvalsscenario's is de Microsoft Defender voor Office 365 training voor aanvalssimulatie.
Zie Inzichten en rapporten voor training voor aanvalssimulatie voor meer informatie.
Zie Microsoft Cloud Red Teaming voor informatie over het instellen van red-team en blue-team.
Azure-facilitering
Microsoft Sentinel is een systeemeigen besturingselement dat SIEM-mogelijkheden (Security Information Event Management) en SOAR-mogelijkheden (Security Orchestration Automated Response) combineert. Het analyseert gebeurtenissen en logboeken van verschillende verbonden bronnen. Op basis van gegevensbronnen en de bijbehorende waarschuwingen maakt Microsoft Sentinel incidenten en voert een bedreigingsanalyse uit voor vroege detectie. Met intelligente analyses en query's kunt u proactief beveiligingsproblemen opsporen. Als er een incident is, kunt u werkstromen automatiseren. Met werkmapsjablonen kunt u ook snel inzichten verkrijgen via visualisatie.
Zie Opsporingsmogelijkheden in Microsoft Sentinel voor productdocumentatie.
Microsoft Defender for Cloud biedt scannen op beveiligingsproblemen voor verschillende technologiegebieden. Zie Scannen op beveiligingsproblemen inschakelen met Microsoft Defender Vulnerability Management - Microsoft Defender for Cloud voor meer informatie.
De praktijk van DevSecOps integreert beveiligingstests als onderdeel van een doorlopende en continue verbeteringsmentaliteit. Oorlogsspeloefeningen zijn een gangbare praktijk die is geïntegreerd in het ritme van het zakendoen bij Microsoft. Zie Beveiliging in DevOps (DevSecOps) voor meer informatie.
Azure DevOps ondersteunt hulpprogramma's van derden die kunnen worden geautomatiseerd als onderdeel van de pijplijnen voor continue integratie/continue implementatie. Zie DevSecOps inschakelen met Azure en GitHub - Azure DevOps voor meer informatie.
Verwante koppelingen
Volg de regels voor betrokkenheid om ervoor te zorgen dat de toegang niet wordt misbruikt. Zie de volgende artikelen voor hulp bij het plannen en uitvoeren van gesimuleerde aanvallen:
U kunt DoS-aanvallen (Denial of Service) simuleren in Azure. Zorg ervoor dat u het beleid volgt dat is beschreven in Azure DDoS Protection-simulatietests.
Communitykoppelingen
Toepassingsbeveiligingstests: hulpprogramma's, typen en best practices: GitHub Resources beschrijft de typen testmethoden waarmee de build- en runtime-verdediging van de toepassing kan worden getest.
PenetratietestUitvoeringsstandaard (PTES) biedt richtlijnen over veelvoorkomende scenario's en de activiteiten die nodig zijn om een basislijn op te stellen.
Top tien van OWASP | OWASP Foundation biedt aanbevolen beveiligingsprocedures voor toepassingen en testcases die betrekking hebben op veelvoorkomende bedreigingen.
Controlelijst voor beveiliging
Raadpleeg de volledige set aanbevelingen.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor