Aanbevelingen voor beveiligingstests
Is van toepassing op deze aanbeveling voor de controlelijst voor Azure Well-Architected Framework Security:
| SE:11 | Stel een uitgebreid testschema in dat methoden combineert om beveiligingsproblemen te voorkomen, implementaties voor bedreigingspreventie 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 werken zoals bedoeld. Testen is ook een proactieve manier om beveiligingsproblemen in het systeem te detecteren.
Stel de test rigor in via cadans en verificatie vanuit meerdere perspectieven. U moet binnenuit oogpunten opnemen die het platform en de infrastructuur testen en evaluaties van buiten die het systeem testen, zoals een externe aanvaller.
Deze handleiding bevat aanbevelingen voor het testen van de beveiligingspostuur van uw workload. Implementeer deze testmethoden om de weerstand van uw workload op aanvallen te verbeteren en vertrouwelijkheid, integriteit en beschikbaarheid van resources te behouden.
Definities
| Term | Definitie |
|---|---|
| Toepassingsbeveiligingstests (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 werking van het systeem. |
| Blauw team | Een team dat zich verdedigt tegen de aanvallen van het rode team in een oorlogsspeloefening. |
| Indringingstests | 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 biedt voor beveiligingscontrole- en nalevingsvereisten. |
| Levenscyclus van softwareontwikkeling (SDLC) | Een multistage, systematisch proces voor het ontwikkelen van softwaresystemen. |
| White-box testen | Een testmethodologie waarbij de structuur van de code bekend is bij de arts. |
Belangrijke ontwerpstrategieën
Testen is een niet-verantwoordelijke strategie, met name voor beveiliging. Hiermee kunt u proactief beveiligingsproblemen detecteren en oplossen voordat ze kunnen worden misbruikt en om te controleren of de beveiligingsmaatregelen die u hebt geïmplementeerd, werken zoals ontworpen.
Het bereik van testen moet de toepassing, infrastructuur en geautomatiseerde en menselijke processen omvatten.
Notitie
Deze richtlijnen maken onderscheid tussen testen en incidentrespons. Hoewel het testen een detectiemechanisme is dat in het ideale geval problemen vóór de productie oplost, moet dit niet worden verward met het herstel of onderzoek dat wordt uitgevoerd als onderdeel van incidentrespons. Het aspect van het herstellen van beveiligingsincidenten wordt beschreven in aanbevelingen voor het reageren 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 tests uitvoeren zoals statische codeanalyse en geautomatiseerd scannen van infrastructuur als code (IaC) zo vroeg mogelijk in het ontwikkelingsproces.
Wees betrokken bij de testplanning. Het workloadteam ontwerpt mogelijk niet de testcases. Deze taak wordt vaak gecentraliseerd in de onderneming of voltooid door externe beveiligingsexperts. Het workloadteam moet betrokken zijn bij dit 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 ontdekken en de tests dienovereenkomstig prioriteren.
Voer tests op een gestructureerde manier uit en met een herhaalbaar proces. Bouw uw test rigor rond cadans, typen tests, rijfactoren en beoogde resultaten.
Gebruik het juiste hulpprogramma voor de taak. Gebruik hulpprogramma's die zijn geconfigureerd voor gebruik met de workload. Als u geen hulpprogramma hebt, koopt u het hulpprogramma. Bouw het niet. Beveiligingshulpprogramma's zijn zeer gespecialiseerd en het bouwen van uw eigen hulpprogramma kan risico's veroorzaken. Profiteer van de expertise en hulpprogramma's die worden aangeboden door centrale SecOps-teams of via externe middelen als het workloadteam die expertise niet heeft.
Afzonderlijke omgevingen instellen. 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 functionaliteit beschadigen door gegevens uit een database te verwijderen.
Testen in productieomgevingen geeft u de beste informatie, maar veroorzaakt de meeste onderbrekingen. U voert doorgaans alleen niet-destructieve tests uit in productieomgevingen. Testen in niet-productieomgevingen is doorgaans minder verstorend, maar vertegenwoordigt mogelijk niet nauwkeurig de configuratie van de productieomgeving op manieren die belangrijk zijn voor beveiliging.
Als u implementeert met behulp van IaC en automatisering, kunt 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 speciale 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 te maken. 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. Voer regelmatig beveiligingstrainingen uit 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 beïnvloedt deze uw omgeving?
Wat zijn de verschillende testtypen die u moet uitvoeren?
De workload regelmatig testen
Test de workload regelmatig om ervoor te zorgen dat wijzigingen geen beveiligingsrisico's veroorzaken en dat er geen regressies zijn. Het team moet ook gereed 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 standaardbedrijfsprocedures en om te voldoen aan de nalevingsvereisten. Verschillende tests kunnen met verschillende frequenties worden uitgevoerd, maar de sleutel 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. De testsuite diversifiëren 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 initiële benchmark. Maar dat is slechts een uitgangspunt. Wanneer u nieuwe problemen ontdekt op dezelfde punten 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 werkzaamheid van de tests verbeteren met automatisering, evenwichtig met peerbeoordelingen.
Overweeg beveiligingstests uit te voeren als onderdeel van een geautomatiseerde pijplijn of geplande testuitvoering. Hoe sneller u beveiligingsproblemen ontdekt, hoe eenvoudiger het is om de code of configuratiewijziging te vinden die ervoor zorgt.
Vertrouw niet alleen op geautomatiseerde tests. Gebruik handmatige tests om beveiligingsproblemen te detecteren die alleen door menselijke expertise kunnen worden gedetecteerd. Handmatig testen is handig voor experimentele gebruiksvoorbeelden en het vinden van onbekende risico's.
Geïmproviseerde tests
Geïmproviseerde tests bieden point-in-time validatie van beveiligingsbeveiligingen. Beveiligingswaarschuwingen die op dat moment van invloed kunnen zijn op de workload, activeren deze tests. Organisatiemandaten vereisen mogelijk een onderbrekings- en testmentaliteit 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 afdwingingsfunctie 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 het vergemakkelijken en samenwerken met beveiligingsteams. Onderhandelen over voldoende doorlooptijd met beveiligingsteams, zodat u zich kunt voorbereiden. Bevestig en communiceer met uw team en belanghebbenden dat deze onderbrekingen nodig 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, verwacht u taken te herpriritiseren, waardoor andere geplande werkzaamheden kunnen worden vertraagd.
Risico: Er bestaat een risico op het onbekende. Geïmproviseerde tests kunnen eenmalige inspanningen zijn zonder vastgestelde processen of hulpprogramma's. Maar het overheersende risico is de potentiële onderbreking van het ritme van het bedrijf. U moet deze risico's evalueren ten opzichte van de voordelen.
Tests voor beveiligingsincidenten
Er zijn tests die de oorzaak van een beveiligingsincident bij de bron detecteren. Deze beveiligingsproblemen moeten worden opgelost om ervoor te zorgen dat het incident niet wordt herhaald.
Incidenten verbeteren ook testcases in de loop van de tijd door bestaande hiaten te ontdekken. Het team moet de lessen van het incident toepassen en regelmatig verbeteringen opnemen.
Gebruik verschillende tests
Tests kunnen worden gecategoriseerd op technologie en door methodologieën te testen. 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 als routinetests worden uitgevoerd. Herhaalbaarheid kan echter in sommige gevallen kosten met zich meebrengen en onderbrekingen veroorzaken. Houd rekening met deze compromissen zorgvuldig.
Tests waarmee de technologiestack wordt gevalideerd
Hier volgen enkele voorbeelden van typen tests en hun focusgebieden. Deze lijst is niet volledig. Test de hele 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 correct 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 veilige coderingsprocedures volgt en runtimefouten ondervangt, zoals problemen met geheugenbeschadiging en bevoegdheden. Zie deze communitykoppelingen voor meer informatie.
Identiteit: Evalueer of de roltoewijzingen en voorwaardelijke controles werken zoals bedoeld.
Testmethodologie
Er zijn veel perspectieven op het testen van methodologieën. We raden u aan tests uit te voeren die opsporing 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 identificeert tijdens het modelleren van bedreigingen.
Hier volgen enkele voordelen van het testen via echte aanvallen:
Wanneer u deze aanvallen een onderdeel van routinetests maakt, gebruikt u een buiten-in 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, werkt het team hun kennis- en vaardigheidsniveau bij. Het team verbetert het situatiebewustzijn en kan zelf beoordelen of ze gereed zijn om te reageren op incidenten.
Enkele voorbeelden van gesimuleerde tests zijn black-box en white-box testen, penetratietests en oorlogsspeloefeningen.
Black-box en white-box testen
Deze testtypen bieden twee verschillende perspectieven. In zwarte doostests zijn de interne functies van het systeem niet zichtbaar. In white box-tests heeft de tester een goed begrip van de toepassing en heeft ze 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 pentesting uit. Ze kijken naar het systeem op de manier waarop kwaadwillende actoren een kwetsbaarheid voor aanvallen 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 van 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 aanvaller die probeert echte aanvallen te modelleren. Als ze succesvol zijn, vindt u hiaten in uw beveiligingsontwerp en evalueert u de radius-insluiting van hun schendingen.
Het blauwe team is het workloadteam dat zich verdedigt tegen de aanvallen. Ze testen hun vermogen om de aanvallen te detecteren, erop te reageren en te herstellen. Ze valideren de beveiligingen die zijn geïmplementeerd om workloadresources te beveiligen.
Als ze worden uitgevoerd als routinetests, kunnen oorlogsspeloefeningen doorlopend zichtbaarheid 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 een rood team en een blauw team.
Azure-facilitering
Microsoft Sentinel is een systeemeigen besturingselement waarin siem-mogelijkheden (Security Information Event Management) en SOAR-mogelijkheden (Security Orchestration Automated Response) worden gecombineerd. Het analyseert gebeurtenissen en logboeken van verschillende verbonden bronnen. Op basis van gegevensbronnen en hun waarschuwingen maakt Microsoft Sentinel incidenten en voert bedreigingsanalyse uit voor vroege detectie. Met intelligente analyses en query's kunt u proactief zoeken naar beveiligingsproblemen. Als er een incident is, kunt u werkstromen automatiseren. Met werkmapsjablonen kunt u ook snel inzicht krijgen via visualisatie.
Zie Opsporingsmogelijkheden in Microsoft Sentinel voor productdocumentatie.
Microsoft Defender voor Cloud biedt scannen op beveiligingsproblemen voor verschillende technologiegebieden. Zie Scannen op beveiligingsproblemen inschakelen met Microsoft Defender Vulnerability Management - Microsoft Defender voor 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 zaken 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 van 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) in Azure simuleren. Zorg ervoor dat u het beleid volgt dat is vastgelegd in azure DDoS Protection-simulatietests.
Communitykoppelingen
Toepassingsbeveiligingstests: hulpprogramma's, typen en best practices: GitHub-resources beschrijven de typen testmethoden waarmee de build-time- 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 vast te stellen.
OWASP Top Tien | OWASP Foundation biedt aanbevolen beveiligingsprocedures voor toepassingen en testcases die betrekking hebben op veelvoorkomende bedreigingen.
Controlelijst voor beveiliging
Raadpleeg de volledige set aanbevelingen.