Architectuurstrategieën voor beveiligingstests

Is van toepassing op deze aanbeveling voor de controlelijst voor Azure Well-Architected Framework Security:

Grondig testen is de basis van een goed beveiligingsontwerp. Testen is ook een proactieve manier om beveiligingsproblemen in het systeem te detecteren.

Stel de strengheid van testen in via regelmaat en verificatie vanuit diverse invalshoeken. Neem inside-out-perspectieven op waarmee het platform en de infrastructuur worden getest, en outside-in-evaluaties waarbij het systeem wordt getest zoals een externe aanvaller dat zou doen.

De belangrijkste strategieën in dit artikel zijn gebaseerd op de basisprocedures voor testen die worden beschreven in strategieën voor OE:09-architectuur voor testen. Lees eerst dat artikel. 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.

Terminology

Samenwerken met beveiligingsexperts om tests te ontwerpen

Wees betrokken bij de testplanning. Vaak centraliseert een organisatie deze taak. Zorg ervoor dat uw team betrokken is bij dat ontwerpproces, zodat beveiligingsgaranties zijn afgestemd op de functionaliteit van de toepassing.

Ontwikkel een mentaliteit waarin je uitgaat van een compromittering. Ontwerp uw testcases met de veronderstelling dat het systeem wordt aangevallen en de aanvaller in de omgeving werkt. Simuleer uw tests om realistische aanvalsscenario's weer te geven, zoals validatie van de laterale verplaatsingsinsluiting binnen een gecompromitteerde toepassings-VM. Op die manier kunt u potentiële beveiligingsproblemen ontdekken en de tests dienovereenkomstig prioriteren.

Deel de architectuurdiagrammen, het bedreigingsmodel en andere relevante documentatie om de workload zinvol te testen.

Prioriteit geven aan tests op basis van bedreigingsmodellering en kritieke stromen

Threat modeling is een belangrijke praktijk om potentiële bedreigingen en beveiligingsproblemen in uw workload te identificeren. Gebruik de ernstclassificaties van uw bedreigingsmodel om prioriteit te geven aan uw testinspanningen en deze te bepalen. De hoogste ernstbedreigingen voor uw meest kritieke stromen verdienen de meeste dekking.

Dek het volledige aanvalsoppervlak van de workload af. Evalueer identiteit, toepassingscode, infrastructuurcontroles, onderdelen van derden, bibliotheken en services en de geautomatiseerde en menselijke processen, zoals goedkeuringswerkstromen en toegangsbeoordelingen.

Begin met identiteits- en toegangsbeheer, omdat een aangetaste identiteit de meeste downstreambeveiligingen omzeilt. Valideer vervolgens netwerkgrenzen en ten slotte toepassingslaagbeveiligingen.

Prioriteit geven aan stromen die verificatie, gevoelige gegevens of financiële transacties verwerken. Identificeer voor elke kritieke stroom de bedreigingen met de hoogste ernstclassificatie in uw bedreigingsmodel. Maak risicogestuurde testcases die elke bedreiging toewijzen aan het besturingselement dat is bedoeld om deze te beperken.

Een goede threat modeling oefening verwijst naar belangrijke gebieden voor testdekking en frequentie. Zie Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus voor aanbevelingen over dreigingsmodellering.

Risico: Verouderde bedreigingsmodellen kunnen leiden tot verkeerd uitgelijnde testinspanningen. Werk uw bedreigingsmodel regelmatig bij om wijzigingen in de workload en het veranderende bedreigingslandschap weer te geven.

Profiteer van expertise van derden

Interne teams kunnen blinde vlekken hebben. Externe experts en crowdsourced onderzoekers zien uw workload zoals een aanvaller dat doet. Breng gespecialiseerde experts binnen om uw workload vanuit het perspectief van een kwaadwillende persoon te testen en inzicht te geven in de nieuwste aanvalstechnieken en trends.

Vermijd dat u te veel toegang krijgt tot uw workload. Geef externe testers alleen de toegang die hun specifieke betrokkenheid vereist. Een black-box penetratietest heeft geen code of interne toegang nodig, terwijl een white box-beoordeling broncode, ontwerpdocumenten of logboeken nodig heeft.

Evalueer of uw team de capaciteit heeft om externe rapporten te classificeren voordat u een programma start. Stel vervolgens een bug bounty-programma of een mechanisme in voor de community om beveiligingsproblemen te melden. Sorteer elke gerapporteerde bevindingen, voer bevestigde beveiligingsproblemen terug in uw bedreigingsmodel en voeg een testcase toe om regressie te vangen.

Controles voor naleving testen en controle-gereed bewijs genereren

Naleving is geen eenmalige beoordeling. Behandel elke regelgeving als testbare vereiste, zodat u altijd een nieuw bewijs voor auditors hebt.

Identificeer de voorschriften waaraan uw workload moet voldoen. Wijs elk regelgevend besturingselement toe aan een specifieke testcase. Plan de tests die moeten worden uitgevoerd op een terugkerend ritme en vóór elke go-live. Sla de testuitvoer op een controleerbare locatie op, zodat u op aanvraag bewijs kunt produceren.

Afweging: Tests voor nalevingscontroles kunnen de operationele processen vertragen. Met predeploymenttests kunt u bijvoorbeeld pijplijnlatentie toevoegen. Er zijn ook extra kosten verbonden aan het uitvoeren van deze bewerkingen. Prioriteit geven aan tests voor controles met de hoogste impact op controles en risico's.

Risico: controle-bewijs is zelf gevoelig. Zonder integriteitsbeveiliging en logboekregistratie van toegang wordt het bewijsarchief zowel een aanvalsdoel als een mogelijke schending van de naleving.

Testassets beveiligen

Testassets vormen zelf een aanvalsoppervlak. Bescherm hun vertrouwelijkheid, integriteit en beschikbaarheid, zodat uw tests geen gevoelige informatie blootleggen of nieuwe aanvalsvectoren openen.

• Gebruik opgeschoonde of synthetische gegevens die geen persoonlijke gegevens (PII) of productiegegevens bevatten.
• Bewaar testgegevens zolang dat nodig is en verwijder deze veilig.
• Controleer of regels voor grensoverschrijdende gegevensopslag worden afgedwongen in testomgevingen die zich over meerdere regio's uitstrekken.
• Genereer toegewezen testreferenties, API-sleutels en certificaten. Sla ze op in een afzonderlijk Key Vault-exemplaar met eigen toegangsbeleidsregels.
• Stel geïsoleerde testomgevingen in die de besturingselementen voor productiebeveiliging spiegelen, zoals netwerkbeveiligingsgroepen (NSG's), op rollen gebaseerd toegangsbeheerbeleid (RBAC), firewall- en DLP-regels (Preventie van gegevensverlies). Pas dezelfde segmentatierichtlijnen toe als productie. Zie Aanbevelingen voor segmentatiestrategie voor meer informatie.

Regelmatige scans op beveiligingsproblemen uitvoeren op testassets

Scan testassets op kwetsbaarheden met dezelfde frequentie als productie-assets, waaronder testcode, infrastructuur als code (IaC), container- en VM-images, repositories en pipelines. Gebruik hulpprogramma's die kunnen worden geïntegreerd met uw ontwikkel- en implementatiewerkstromen om deze controles te automatiseren.

Een continu testritme instellen voor de werkbelasting

Beveiligingstests behandelen als een doorlopende activiteit die het beveiligingspostuur van de workload actueel houdt naarmate bedreigingen, code en configuraties zich ontwikkelen. Voer tests uit volgens een schema, zodat wijzigingen geen beveiligingsrisico's of regressies veroorzaken. Wees klaar voor beveiligingsvalidaties van organisaties die op elk gewenst moment kunnen plaatsvinden en voor tests die worden geactiveerd door een beveiligingsincident. In de volgende secties worden de ritmes beschreven waarmee u bij de planning rekening moet houden.

Routine tests

Met routinetests wordt de basislijn ingesteld voor de beveiligingspostuur van uw workload. Voer ze regelmatig uit, als onderdeel van uw standaardbedrijfsprocedures en om te voldoen aan de nalevingsvereisten. U kunt verschillende tests uitvoeren op verschillende frequenties, maar de sleutel is dat u ze periodiek en volgens een schema uitvoert.

De testsuite diversifiëren om de garanties voor identiteit, gegevensopslag en overdracht en communicatiekanalen te verifiëren. Wanneer u nieuwe problemen ontdekt op dezelfde punten van de levenscyclus, voegt u nieuwe testcases toe.

Vertrouw niet alleen op geautomatiseerde tests. Gebruik handmatig testen om kwetsbaarheden te vinden die alleen met menselijke expertise kunnen worden opgespoord, en voor verkennend onderzoek naar 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.

Afweging: 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. Evalueer deze risico's ten opzichte van de voordelen.

Tests voor beveiligingsincidenten

Gebruik tests die de oorzaak van een beveiligingsincident bij de bron detecteren. Los deze beveiligingsproblemen op om te voorkomen dat het incident terugkeert.

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.

Beveiligingscontroles valideren over het volledige aanvalsoppervlak

Gebruik verschillende testmethoden om volledige dekking te krijgen en hiaten in beveiligingscontroles, onjuiste configuraties en zwakke plekken in waarneembaarheid en detectie te ontdekken. De meeste tests die in deze sectie worden beschreven, kunnen als routinetests worden uitgevoerd. Herhaalbaarheid kan echter kosten met zich meebrengen en onderbrekingen veroorzaken. Houd zorgvuldig rekening met deze compromissen.

Besturingselementen voor versleuteling testen. Versleutelingsfouten blijven onopgemerkt. Gegevens lijken beschermd totdat een datalek het tegendeel aan het licht brengt.

• Controleer of versleuteling wordt afgedwongen, niet alleen geconfigureerd.
• Test opnieuw na elke sleutelrotatie, certificaatvernieuwing en infrastructuurwijziging.

Netwerkcontroles testen. Netwerkgrenzen zijn waar uw segmentatie wordt afgedwongen.

• Test deze na een wijziging in de netwerktopologie.
• Controleer of de standaard-weigerregels van kracht zijn en of toegestane verkeersstromen overeenkomen met wat in uw architectuur is beoogd.

Toepassingscode testen. Toepassingslaagbeveiliging is de laatste grens voordat een aanvaller gegevens bereikt.

• Controleer of geïmplementeerde toepassingen zich verzetten tegen veelvoorkomende aanvalspatronen in plaats van alleen broncode te scannen tijdens het bouwen.
• Voer AST-technieken (Application Security Testing) uit op broncode om beveiligingscoderingsprocedures te bevestigen en runtimefouten te ondervangen, zoals problemen met geheugenbeschadiging en bevoegdheden. Zie Community-koppelingen voor meer informatie.

Aanvallen op basis van identiteit simuleren en detectie controleren

Aanvallen op basis van identiteit zijn de meest voorkomende eerste aanvalsvector. Simuleer deze aanvallen om te controleren of uw identiteitscontroles werken en dat uw bewaking de gebeurtenissen vastlegt.

Besturingselementen voor toegang zijn de eerste verdedigingslinie. Test deze na elke rol of beleidswijziging en volgens een geautomatiseerd schema. Simuleer veelvoorkomende aanvalspatronen en bevestig dat uw besturingselementen minimale bevoegdheden afdwingen en bypasspogingen weerstaan.

Houd rekening met deze aanvalspatronen wanneer u tests ontwerpt:

• Autorisatieomzeiling
• Tokendiefstal en herhaling
• Laterale beweging tussen accounts of diensten
• Escalatie van bevoegdheden

Valideer beide zijden van elk besturingselement:

• Positieve gevallen: geautoriseerde gebruikers slagen.
• Negatieve gevallen: niet-geautoriseerde pogingen worden geblokkeerd en geregistreerd.

Detectie en waarschuwingen van bedreigingen testen

Detectie die geen waarschuwing activeert, biedt weinig waarde. Test uw bewaking en waarschuwingen als onderdeel van elke validatie van beveiligingscontrole en controleer of de mechanismen die zijn ontworpen om aanvallen te detecteren, werken zoals verwacht.

Voer end-to-end simulaties van de aanvallen uit en bevestig vervolgens elke fase van de detectiepijplijn:

• Controleer of beveiligingsgebeurtenissen zoals aanmeldingspogingen, machtigingswijzigingen en tokenbewerkingen met voldoende details worden vastgelegd.
• Controleer of uw SIEM-platform (Security Information and Event Management) of security operations-dashboard gerelateerde gebeurtenissen correleert.
• Stel een servicelevelovereenkomst (SLA) voor waarschuwingen op en test of waarschuwingen opvolgbaar zijn en binnen die termijn zichtbaar worden.
• Controleer of er niet met logboeken kan worden geknoeid of verwijderd door niet-beheerdersaccounts.
• Controleer of het detectiemechanisme voor elke gesimuleerde aanval wordt geactiveerd. Als u bijvoorbeeld een DDoS-aanval (Distributed Denial-of-Service) simuleert met geldige verkeerspatronen, controleert u of snelheidsbeperking detecteert en beperkt.

Voor volwassen workloads valideert u governancebeveiligingen als routinetests. Introduceer opzettelijk onveilige configuraties en controleer of de pijplijn detecteert en reageert. Bevestig dat Azure Policy of landing zone-beperkingen de verwachte beveiligingsmaatregelen afdwingen. Het platform- of beveiligingsteam voert deze tests doorgaans uit, niet het workloadteam.

Versterk de verdediging met op tegenstanders gebaseerde tests

Gebruik tests die opsporing van bedreigingen mogelijk maken door echte aanvallen te simuleren. Deze tests 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 leren, 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.

Risico: testen in het algemeen kan van invloed zijn op de prestaties. Destructieve tests kunnen gegevens verwijderen of beschadigen en problemen met bedrijfscontinuïteit veroorzaken. Er zijn ook risico's verbonden aan informatieblootstelling. Behoud de vertrouwelijkheid van gegevens. Zorg voor de integriteit van gegevens nadat u het testen hebt voltooid.

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.

Risico: Het verschil tussen de twee typen is de aanvangskosten. White-box testen kan duur zijn in termen van tijd die nodig is om het systeem te begrijpen. In sommige gevallen moet u gespecialiseerde tools aanschaffen. Black-box testen heeft geen opstarttijd nodig, maar het is misschien niet zo effectief. Mogelijk moet u extra moeite doen om problemen te ontdekken. Het is een afweging van tijdsinvestering.

Tests die aanvallen simuleren door middel van penetratietesten

Beveiligingsexperts die geen deel uitmaken van de IT- of toepassingsteams van de organisatie voeren penetratietests of pentesting uit. Ze bekijken het systeem zoals kwaadwillende actoren een aanvalsoppervlak verkennen. Hun doel is om beveiligingsproblemen te vinden door informatie te verzamelen, beveiligingsproblemen te analyseren en de resultaten te rapporteren.

Compromis: Penetratietests zijn geïmproviseerd en kunnen duur zijn in termen van verstoringen en monetaire investeringen, omdat pentest doorgaans een betaald aanbod is van externe beoefenaars.

Risico: Een pentesting-oefening kan van invloed zijn op de runtime-omgeving en kan de beschikbaarheid voor normaal verkeer verstoren.

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 nemen twee teams deel:

• Het rode team fungeert als aanvaller en probeert echte aanvallen te modelleren. Als ze succesvol zijn, vindt u hiaten in uw beveiligingsontwerp en evalueert u de controles voor insluiting van 'blast radius' van hun inbreuken.

• Het blauwe team is het werkbelastingteam 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 workloadresources beschermen.

Als u deze tests regelmatig uitvoert, 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 trainingstraining voor Microsoft Defender voor Office 365-aanvalssimulatie.

Zie Inzichten en rapporten voor aanvalssimulatietraining voor meer informatie.

Zie Microsoft Cloud Red Teaming voor informatie over het instellen van een rood team en een blauw team.

Azure-ondersteuning

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 behulp van werkmapsjablonen kunt u ook snel inzichten verkrijgen via visualisatie.

Zie voor productdocumentatie Opsporingsmogelijkheden in Microsoft Sentinel.

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 u kunt automatiseren 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:

• Spelregels voor penetratietesten

• Penetratietests

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.

Communityverwijzingen

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.