Aanbevelingen voor beveiligingstests
Van toepassing op deze aanbeveling voor de Well-Architected Security-checklist: Power Platform
| ZEE:09 | Stel een uitgebreid testregime op dat benaderingen combineert om beveiligingsproblemen te voorkomen, implementaties voor bedreigingspreventie te valideren en mechanismen voor bedreigingsdetectie te testen. |
|---|
Strenge tests vormen de basis van een goed beveiligingsontwerp. Testen is een tactische vorm van validatie om ervoor te zorgen dat de controles werken zoals bedoeld. Testen is ook een proactieve manier om kwetsbaarheden in het systeem te detecteren.
Zorg voor testnauwkeurigheid door middel van cadans en verificatie vanuit meerdere perspectieven. U moet gezichtspunten van binnen naar buiten opnemen waarmee het platform en de infrastructuur worden getest en evaluaties van buitenaf naar binnen toe waarmee het systeem wordt getest als 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 tegen aanvallen te verbeteren en de vertrouwelijkheid, integriteit en beschikbaarheid van resources te behouden.
Definities
| Term | Definitie |
|---|---|
| Toepassingsbeveiligingstests | Een Security Development Lifecycle (SDL)-techniek die gebruikmaakt van white-box- en black-box-testmethodologieën om te controleren op beveiligingskwetsbaarheden in code. Microsoft |
| Blackboxtests | Een testmethodologie waarmee het extern zichtbare toepassingsgedrag wordt gevalideerd zonder kennis van de interne werking van het systeem. |
| Blauwe team | Een team dat zich verdedigt tegen de aanvallen van het rode team in een oorlogsspeloefening. |
| Penetratietests | Een testmethodologie waarin ethische hacktechnieken worden gebruikt om de beveiligingsverdediging van een systeem te valideren. |
| Rode team | Een team dat de rol van tegenstander speelt en het systeem probeert te hacken in een oorlogsspeloefening. |
| Security Development Lifecycle (SDL) | Een reeks praktijken die worden aangeboden door Microsoft ter ondersteuning van beveiligingsgaranties en nalevingsvereisten. |
| Software Development Lifecycle (SDLC) | Een uit meerdere fasen bestaand, systematisch proces voor het ontwikkelen van softwaresystemen. |
| Whiteboxtests | Een testmethodologie waarbij de structuur van de code bekend is bij de expert. |
Belangrijke ontwerpstrategieën
Testen is een niet-onderhandelbare strategie, vooral als het om beveiliging gaat. Met testen kunt u proactief beveiligingsproblemen ontdekken en aanpakken voordat deze kunnen worden misbruikt, en kunt u verifiëren dat de beveiligingsmaatregelen die u hebt geïmplementeerd naar behoren functioneren.
De reikwijdte van het testen moet de toepassing, infrastructuur en geautomatiseerde en menselijke processen omvatten.
Notitie
In deze richtlijn wordt onderscheid gemaakt tussen testen en incidentrespons. Hoewel testen een detectiemechanisme is dat idealiter problemen vóór de productie oplost, mag het niet worden verward met het herstel of onderzoek dat wordt uitgevoerd als onderdeel van de respons op incidenten. Het aspect van het herstellen van beveiligingsincidenten wordt beschreven in Aanbevelingen voor de respons op beveiligingsincidenten.
Wees betrokken bij de testplanning. Het workloadteam ontwerpt mogelijk niet de testcases. Die taak wordt vaak gecentraliseerd in de onderneming of uitgevoerd door externe beveiligingsexperts. Het workloadteam moet bij dat ontwerpproces worden betrokken om ervoor te zorgen dat beveiligingsgaranties worden geïntegreerd met de functionaliteit van de toepassing.
Denk als een aanvaller. Ontwerp uw testcases in de veronderstelling dat het systeem is aangevallen. Op die manier kunt u de potentiële kwetsbaarheden ontdekken en de tests dienovereenkomstig prioriteren.
Voer tests gestructureerd en met een herhaalbaar proces uit. Bouw uw testnauwkeurigheid op rond cadans, soorten tests, drijvende factoren en beoogde resultaten.
Gebruik de juiste tool voor de taak. Gebruik tools die zijn geconfigureerd om met de workload te werken. Als u geen tool hebt, koop die dan. Bouw de tool niet zelf. Beveiligingstools zijn zeer gespecialiseerd en het bouwen van uw eigen tool kan risico's met zich meebrengen. Profiteer van de expertise en tools die worden aangeboden door centrale SecOps-teams of via externe middelen als het workloadteam die expertise niet heeft.
Stel aparte 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 veranderen de functionaliteit niet om het probleem te verhelpen. Destructieve tests zijn invasief en kunnen de functionaliteit beschadigen door gegevens uit een database te verwijderen.
Testen in productieomgevingen geeft u de beste informatie, maar veroorzaakt de meeste verstoring. In productieomgevingen voert u meestal alleen niet-destructieve tests uit. Testen in niet-productieomgevingen is doorgaans minder verstorend, maar geeft mogelijk niet accuraat de configuratie van de productieomgeving weer op manieren die belangrijk zijn voor de beveiliging.
U kunt een geïsoleerde kloon van uw productieomgeving maken met behulp van de kopieerfunctie voor de omgeving. Als u implementatiepijplijnen hebt ingesteld, kunt u uw oplossing(en) ook implementeren in een speciale testomgeving.
Evalueer altijd de testresultaten. Testen is verspilde moeite als de resultaten niet worden gebruikt om acties te prioriteren en stroomopwaarts verbeteringen aan te brengen. Documenteer de beveiligingsrichtlijnen, zoals best practices, die u ontdekt. Documentatie waarin de resultaten en herstelplannen worden vastgelegd, informeert het team over de verschillende manieren waarop aanvallers kunnen proberen de beveiliging te schenden. Geef regelmatig beveiligingstrainingen voor ontwikkelaars, beheerders en testers.
Denk bij het ontwerpen van uw testplannen na over de volgende vragen:
- Hoe vaak verwacht u dat de test wordt uitgevoerd en welke invloed heeft dit 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 er zeker van te zijn dat wijzigingen geen beveiligingsrisico's met zich meebrengen en dat er geen achteruitgang optreedt. Het team moet ook gereed zijn om te reageren op organisatorische beveiligingsvalidaties die op elk moment kunnen worden uitgevoerd. Er zijn ook tests die u kunt uitvoeren als reactie op een beveiligingsincident. In de volgende gedeelten worden aanbevelingen gegeven over de frequentie van tests.
Routinematige tests
Routinetests worden met regelmatige tussenpozen uitgevoerd als onderdeel van uw standaardwerkprocedures en om aan de nalevingsvereisten te voldoen. Er kunnen verschillende tests met verschillende frequenties worden uitgevoerd, maar het belangrijkste is dat ze periodiek en volgens een schema worden uitgevoerd.
U moet deze tests in uw SDLC integreren, omdat ze in elke fase diepgaande verdediging bieden. Diversifieer 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 optreden. Routinematige tests helpen bij het vaststellen van een eerste benchmark. Maar dat is slechts een startpunt. Naarmate u op dezelfde punten in de levenscyclus nieuwe problemen ontdekt, voegt u nieuwe testcases toe. De tests verbeteren ook door ze te herhalen.
In elke fase moeten deze tests code valideren die is toegevoegd of verwijderd, of configuratie-instellingen die zijn gewijzigd om de beveiligingsimpact van die wijzigingen te detecteren. U moet de effectiviteit van de tests verbeteren door middel van automatisering in combinatie met peer reviews.
Overweeg om 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 waardoor deze problemen worden veroorzaakt.
Vertrouw niet alleen op geautomatiseerde tests. Gebruik handmatige tests om kwetsbaarheden te detecteren die alleen met menselijke expertise kan worden ontdekt. Handmatig testen is goed voor exploratieve gebruiksscenario's en het vinden van onbekende risico's.
Geïmproviseerde tests
Geïmproviseerde tests bieden point-in-time validatie van beveiligingsmaatregelen. Beveiligingswaarschuwingen die op dat moment van invloed kunnen zijn op de workload, activeren deze tests. Organisatorische mandaten kunnen vereisen dat er wordt onderbroken en getest om de effectiviteit van defensiestrategieën te verifiëren als de waarschuwing escaleert tot een noodsituatie.
Het voordeel van geïmproviseerde tests is dat men hierdoor voorbereid is op een echt incident. Deze tests kunnen ervoor zorgen dat gebruikersacceptatietests (UAT) worden afgedwongen.
Het beveiligingsteam kan alle workloads controleren en deze tests indien nodig uitvoeren. Als eigenaar van een workload moet u beveiligingsteams faciliteren en ermee samenwerken. Onderhandel over voldoende doorlooptijd met beveiligingsteams zodat u zich kunt voorbereiden. Erken en communiceer naar uw team en belanghebbenden dat deze verstoringen noodzakelijk zijn.
In andere gevallen moet u mogelijk tests uitvoeren en de beveiligingsstatus van het systeem ten opzichte van de potentiële bedreiging rapporteren.
Afweging: Omdat geïmproviseerde tests verstorende gebeurtenissen zijn, moet u rekening houden met het opnieuw prioriteren van taken, wat vertraging kan veroorzaken bij ander gepland werk.
Risico: Er is een risico van het onbekende. Geïmproviseerde tests kunnen eenmalige inspanningen zijn zonder gevestigde processen of tools. Maar het grootste risico is de mogelijke onderbreking van het bedrijfsritme. U moet die risico's evalueren ten opzichte van de voordelen.
Beveiligingsincidenttests
Er zijn tests waarmee de oorzaak van een beveiligingsincident bij de bron wordt opgespoord. Deze beveiligingslacunes moeten worden opgelost om ervoor te zorgen dat het incident zich niet herhaalt.
Met incidenten worden testcases ook verbeterd in de loop van de tijd doordat bestaande hiaten worden blootgelegd. Het team moet de lessen die uit het incident zijn geleerd, toepassen en routinematig verbeteringen aanbrengen.
Er zijn de verschillende typen tests?
Tests kunnen worden gecategoriseerd op technologie en op testmethodologieën. Combineer deze categorieën en benaderingen binnen deze categorieën voor een volledige dekking.
Door meerdere tests en typen tests toe te voegen, kunt u het volgende ontdekken:
- Hiaten in de beveiligingscontroles of compenserende controles.
- Onjuiste configuraties.
- Hiaten in waarneembaarheid en detectiemethoden.
Een goede oefening in het modelleren van bedreigingen kan wijzen op belangrijke gebieden om de dekking en frequentie van tests te garanderen. Zie voor aanbevelingen over het modelleren van bedreigingen Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus.
De meeste tests die in deze gedeelten worden beschreven, kunnen als routinetests worden uitgevoerd. Herhaalbaarheid kan in sommige gevallen echter kosten met zich meebrengen en verstoring veroorzaken. Denk goed na over deze afwegingen.
Tests waarmee de technologiestapel wordt gevalideerd
Hier volgen enkele voorbeelden van soorten tests en de aandachtsgebieden ervan. Deze lijst is niet uitputtend. 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 toegangscontroles om ervoor te zorgen dat gegevens goed worden beschermd tegen ongeautoriseerde toegang en manipulatie.
- Netwerk en connectiviteit: Test uw firewalls om er zeker van te zijn dat ze alleen verwacht, toegestaan en veilig verkeer naar de workload toestaan.
- Toepassing: Test de broncode met behulp van AST-technieken (Application Security Testing) om ervoor te zorgen dat u veilige coderingspraktijken toepast en runtime-fouten zoals geheugenbeschadiging en problemen met bevoegdheden opspoort.
- Identiteit: Evalueer of de roltoewijzingen en voorwaardelijke controles werken zoals bedoeld.
Testmethodologie
Er zijn veel perspectieven op testmethodologieën. We raden tests aan die het opsporen van bedreigingen mogelijk maken door aanvallen uit de echte wereld te simuleren. Ze kunnen potentiële bedreigingsactoren, de technieken en exploits ervan identificeren die een bedreiging vormen voor de workload. Maak de aanvallen zo realistisch mogelijk. Gebruik alle potentiële bedreigingsvectoren die u identificeert tijdens het modelleren van bedreigingen.
Hier zijn enkele voordelen van testen via aanvallen uit de echte wereld:
- Wanneer u deze aanvallen onderdeel maakt van routinematige tests, gebruikt u perspectief van buitenaf naar binnen toe om de workload te controleren en ervoor te zorgen dat de verdediging een aanval kan weerstaan.
- Op basis van de geleerde lessen wordt het kennis- en vaardigheidsniveau van het team verbeterd. Het team verbetert het situationele bewustzijn en kan zelf beoordelen of ze klaar zijn om op incidenten te reageren.
Enkele voorbeelden van gesimuleerde tests zijn blackbox- en whiteboxtests, penetratietests en oorlogsspeloefeningen.
Blackbox- en whiteboxtests
Deze testtypen bieden twee verschillende perspectieven. In blackboxtests zijn de interne onderdelen van het systeem niet zichtbaar. In whiteboxtests heeft de tester een goed inzicht in de toepassing en heeft zelfs toegang tot code, logboeken, resourcetopologie en configuraties voor het uitvoeren van het experiment.
Tests die aanvallen simuleren door middel van penetratietests
Beveiligingsexperts die geen deel uitmaken van de IT- of toepassingsteams van de organisatie, voeren penetratietests oftewel pentests uit. Ze kijken naar het systeem op de manier waarop kwaadwillende actoren een aanvalsoppervlak bestrijken. Hun doel is om gaten in de beveiliging te vinden door informatie te verzamelen, kwetsbaarheden te analyseren en de resultaten te rapporteren.
De praktijkmensen hebben mogelijk toegang nodig tot gevoelige gegevens in de gehele organisatie. Volg de spelregels om ervoor te zorgen dat er geen misbruik wordt gemaakt van de toegang. Zie de bronnen die vermeld staan in Gerelateerde informatie.
Tests die aanvallen simuleren door middel oorlogsspeloefeningen
In deze methodologie van gesimuleerde aanvallen zijn er twee teams:
- Het rode team is de tegenstander die probeert aanvallen uit de echte wereld te modelleren. Bij succes vindt u gaten in uw beveiligingsontwerp en evalueert u de explosieradius van de inbreuken ervan.
- 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 deze te verhelpen. Ze valideren de verdedigingen die zijn geïmplementeerd om workloadresources te beschermen.
Als ze worden uitgevoerd als routinetests, kunnen oorlogsspeloefeningen voortdurende zichtbaarheid en zekerheid bieden dat uw verdediging werkt zoals ontworpen. Oorlogsspeloefeningen kunnen mogelijk op verschillende niveaus binnen uw workload worden getest.
Een populaire keuze om realistische aanvalsscenario's te simuleren is de Microsoft Defender voor Office 365 aanvalssimulatietraining.
Zie Inzichten en rapporten voor aanvalssimulatietraining voor meer informatie.
Voor informatie over de opstelling van het rode en blauwe team, zie Microsoft Cloud Red Teaming.
Power Platform-facilitering
Microsoft Met de Sentinel-oplossing voor Microsoft Power Platform kunnen klanten verschillende verdachte activiteiten detecteren, zoals:
- Power Apps-uitvoerbewerking vanuit ongeautoriseerde geografische gebieden
- Verdachte gegevensvernietiging door Power Apps
- Massale verwijdering van Power Apps
- Phishing-aanvallen die via Power Apps worden uitgevoerd
- Power Automate stroomt activiteit op vertrekkende werknemers
- Microsoft Power Platform-connectors die aan een omgeving zijn toegevoegd
- Bijwerken of verwijderen van Microsoft Power Platform-beleid ter voorkoming van gegevensverlies
Voor meer informatie, zie de Microsoft Sentinel-oplossing voor Microsoft Power Platform een overzicht.
Voor productdocumentatie, zie Jachtmogelijkheden in Microsoft Sentinel.
Microsoft Defender for Cloud biedt kwetsbaarheidsscans voor verschillende technologische gebieden. Zie Kwetsbaarheidsscans inschakelen met Microsoft Defender Vulnerability Management voor meer informatie.
Met de praktijk van DevSecOps worden beveiligingstests geïntegreerd als onderdeel van een voortdurende en continue verbeteringsmentaliteit. Oorlogsspeloefeningen zijn een veelvoorkomende praktijk die deel uitmaakt van het bedrijfsritme Microsoft. Zie Beveiliging in DevOps (DevSecOps) voor meer informatie.
Azure DevOps ondersteunt tools van derden die kunnen worden geautomatiseerd als onderdeel van de pijplijnen voor continue integratie/continue implementatie (CI/CD). Zie DevSecOps inschakelen met Azure en GitHub voor meer informatie.
Gerelateerde informatie
De nieuwste penetratietests en beveiligingsbeoordelingen vindt u op de Microsoft Service Trust Portal.
Microsoft voert uitgebreide tests uit op de Microsoft Cloud-services. Deze tests omvatten penetratietesten, waarbij de resultaten worden gepubliceerd op de Service Trust Portal voor uw organisatie. Uw organisatie kan uw eigen penetratietest uitvoeren op Microsoft Power Platform- en Microsoft Dynamics 365-services. Alle penetratietesten moeten voldoen aan de Microsoft Cloud Penetration Testing Rules of Engagement. Houd er rekening mee dat de Cloud in veel gevallen gebruikmaakt van gedeelde infrastructuur om uw activa en activa van andere klanten te hosten. Microsoft U moet alle penetratietests beperken tot uw activa en onbedoelde gevolgen voor andere klanten om u heen vermijden.
Volg de spelregels om ervoor te zorgen dat er geen misbruik wordt gemaakt van de toegang. Zie voor richtlijnen over 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 uiteengezet in Azure DDoS Protection-simulatietests.
Controlelijst voor beveiliging
Raadpleeg de volledige reeks aanbevelingen.