De grondbeginselen van stresstests voor cloudbeveiliging

“Verdedigers denken in lijsten, aanvallers denken in grafieken”, zegt John Lambert van Microsoft, waarmee hij het fundamentele verschil in mentaliteit distilleert tussen degenen die IT-systemen verdedigen en degenen die deze proberen te compromitteren.

De traditionele aanpak voor verdedigers is om beveiligingslekken op te sommen die rechtstreeks verband houden met hun assets in het netwerk en er zoveel mogelijk te elimineren, te beginnen met de meest kritieke. Tegenstanders daarentegen beginnen met het einddoel voor ogen en concentreren zich op het in kaart brengen van de weg naar een doorbraak. Ze zullen over het algemeen op zoek gaan naar de zwakste schakel in de beveiligingsketen om in te breken en de aanval van daaruit tot aan de kroonjuwelen voortzetten.

Beveiligingsteams moeten het perspectief van de aanvaller omarmen om ervoor te zorgen dat de cyberbeveiligingsverdediging van hun organisatie adequaat is. Om een ​​analogie te maken met een voorbeeld uit het dagelijks leven: de standaardmanier om ons huis tegen inbraak te beschermen is ervoor te zorgen dat alle deuren op slot zijn. Maar om te valideren dat uw huis beveiligd is, moet u uw beveiliging testen als een inbreker: proberen de sloten te kraken, door ramen te klimmen en te zoeken naar plaatsen waar huissleutels 'veilig' kunnen worden bewaard.

Penetratietests voorzien precies in deze behoefte: het biedt een aanvaller inzicht in wat er kan worden aangetast. De praktijk van penetratietesten bestaat al tientallen jaren en helpt onthullen hoe veerkrachtig onze netwerken zijn tegen kwaadaardige aanvallen. Nu moderne ondernemingen echter steeds meer gebruik maken van clouddiensten, is het net zo noodzakelijk om het concept van traditionele penetratietesten op de cloud toe te passen.

De cloud is geen veilige haven: weet wat u moet beschermen

Cloud-architecturen omvatten bronnen, identiteiten en configuraties die programmatisch worden gedefinieerd en in een snel tempo veranderen. Als gevolg hiervan kan de cloud een pandora-box zijn met extra complexiteit op het gebied van cyberbeveiliging. Hoewel de toonaangevende aanbieders van clouddiensten rigoureuze beveiligingspraktijken implementeren, kan dit een vals gevoel van veiligheid opleveren voor organisaties, die zich mogelijk niet bewust zijn van hun verantwoordelijkheid voor het beveiligen van hun cloudactiva, zoals gedefinieerd door het gedeelde verantwoordelijkheidsmodel voor de cloud. Om deze redenen is pentesten in de cloud net zo belangrijk als traditionele netwerkpenetratietesten, en in sommige gevallen zelfs nog belangrijker.

In deze blogpost onderzoeken we de basisbouwstenen voor pentesting in de cloud, waarbij we ons concentreren op de manier waarop aanvallers beveiligingslekken in uw cloud zoeken en benutten.

Wat uw cloud-pentest moet omvatten

Afhankelijk van het door u gekozen leveringsmodel voor cloudservices kunnen de grenzen van uw verantwoordelijkheid voor beveiliging variëren. Over het algemeen eindigt de verantwoordelijkheid van de cloudserviceproviders waar uw verantwoordelijkheid begint. De cloudaanbieder is verantwoordelijk voor het beveiligen van de hardware en de onderliggende software die zijn dienstverlening mogelijk maakt. U bent verantwoordelijk voor het beschermen van alles wat u in de cloud maakt: uw gegevens, sleutels, middelen, services, applicaties en configuraties. Beschouw een voorbeeld van het gebruik van Lambda-functies om cloud-native applicaties te ontwikkelen in Amazon Web Services (AWS). Hoewel AWS de beveiliging van de reken- en opslaginfrastructuur en de Lambda-service zelf aanpakt, is het uw verantwoordelijkheid om ervoor te zorgen dat de toegang tot de code en bronnen van uw organisatie veilig is. Het is dus aan u om ervoor te zorgen dat uw ontwikkelaars geen inloggegevens opslaan in de code van de functies of in omgevingsvariabelen die kunnen worden gebruikt om gevoelige gegevens in gevaar te brengen of zich lateraal in het netwerk te verplaatsen als ze worden onderschept door kwaadwillende actoren.

Ter voorbereiding op verschillende inbreukscenario's moeten penetratietests verschillende uitgangspunten gebruiken:

  • Black Box – de tester heeft geen initiële toegang binnen de cloudomgeving.
  • Gray Box – de tester heeft de inloggegevens van een geselecteerde gebruiker of rol als initiële invoer om de potentiële impact (ook wel “ontploffingsradius” genoemd) weer te geven als een identiteit wordt aangetast.

Voor organisaties met hybride cloud- en on-premise-netwerken kan een volledig en accuraat inzicht in de risicoblootstelling alleen worden bereikt met de mogelijkheid om aanvalspaden te testen die deze omgevingen kruisen. Een computer op locatie wordt bijvoorbeeld gehackt en de aanvaller voert een RCE uit om inloggegevens van de machine te verzamelen. Met behulp van browserwachtwoordextractie verkrijgt de aanvaller de inloggegevens van een ontwikkelaar met bevoegdheden op een Azure VM. Van daaruit is de weg om de cloud te doorbreken geplaveid, en dit proces wordt herhaald op verschillende machines totdat de aanvaller de hoogste rechten in de omgeving in handen krijgt en naar believen alle bronnen kan inzetten. Daarom moeten cloudpenetratietests scenario's omvatten waarin initiële toegang op locatie ertoe kan leiden dat een aanvaller cloudbronnen in gevaar brengt, en omgekeerd.

Hier zijn vijf belangrijke bouwstenen voor het testen van cloudpenetratie:

1. Verkenning en ontdekking

Deze eerste stap houdt in dat alle assets binnen de cloudomgeving van uw organisatie in kaart worden gebracht; werklasten, opslag, databases en identiteiten. De informatie die in deze fase wordt verzameld, biedt de reikwijdte van de middelen die kunnen worden gebruikt of waarop een test kan worden gericht, en een basislijn voor het initiëren van aanvalsacties.

Bij traditionele netwerk-pentesting wordt de testscope doorgaans gedefinieerd door de IP-adressen van de eindpunten die in de test moeten worden opgenomen. Cloudbronnen worden daarentegen geïdentificeerd aan de hand van unieke identificatiegegevens, en toegang daartoe wordt mogelijk gemaakt via API's. Daarom is de typische aanpak voor verkenning bij cloud-pentests het verzamelen van de asset-informatie aan het begin van een test door verbinding te maken met de cloud-API van de organisatie.

2. Kwetsbaarheidsbeoordeling

Er moeten cloudconfiguratiebeoordelingen en kwetsbaarheidsscans worden uitgevoerd om verkeerde configuraties en bekende softwarekwetsbaarheden in uw cloudassets op te sporen. De beveiliging van cloudnetwerken moet bijvoorbeeld worden geëvalueerd door de configuratie van bedieningselementen zoals firewalls, virtuele particuliere netwerken (VPN's), toegang en netwerksegmentatie-instellingen te beoordelen. Dit proces is nodig om zwakke punten te identificeren, zoals openbaar toegankelijke bronnen of onveilige Virtual Private Cloud (VPC) peering-verbindingen, die ongeautoriseerde toegang, laterale verplaatsing, escalatie van bevoegdheden en gegevensexfiltratie mogelijk maken.

Een andere bron met een hoog risico zijn webapplicaties, die vaak het doelwit zijn van hackers, omdat ze door hun ontwerp open zijn voor internet. Om te valideren dat de beveiligingscontroles en softwarebeveiligingsimplementaties geen ongeoorloofde toegang tot services en gevoelige gegevens toestaan, moeten penetratietests betrekking hebben op in de cloud gehoste webapplicaties. Bij het testen moeten OWASP Top 10-beveiligingsrisico's worden meegenomen, zoals invoervalidatie, SQL-injectie, cross-site scripting (XSS) en Server-Side Request Forgery (SSRF).

Kwetsbaarheidsscans zijn echter nog maar het begin. Gedetecteerde verkeerde configuraties en kwetsbaarheden moeten worden getest op exploiteerbaarheid, met als doel een aanval te verspreiden precies zoals een tegenstander dat zou doen. Als er bijvoorbeeld een openbaar toegankelijke cloudopslagbucket wordt gedetecteerd, kan deze worden getest door de inhoud ervan te scannen op waardevolle geheimen of door te proberen gegevens te exfiltreren.

3. Escalatie van bevoegdheden

Met methoden voor escalatie van bevoegdheden kunnen kwaadwillenden toegang krijgen tot gevoeligere gegevens, applicaties en services. Aanvallers proberen hogere rechten te verkrijgen door:

  • Het misbruiken van kwetsbaarheden en verkeerde configuraties die zijn ontworpen om hogere rechten in het netwerk te verkrijgen
  • Hiaten in identiteits- en toegangsbeheer (IAM), zoals gebruikers die zich in groepen bevinden waar ze niet in mogen zitten en rollen die overdreven toegeeflijk zijn
  • Het compromitteren van identiteiten met hogere rechten door middel van het verzamelen van inloggegevens – een reeks technieken waarbij inloggegevens, sleutels en sessietokens worden gelokaliseerd en openbaar gemaakt die onjuist zijn opgeslagen in verschillende bronnen, inclusief maar niet beperkt tot bestanden, shell-geschiedenis, register, omgevingsvariabelen, implementatietools en browsers.

Hoewel escalatie van bevoegdheden een veelgebruikte aanvalstechniek is die wordt gebruikt in traditionele netwerken, is de uitdaging van het beveiligen van identiteiten en toegang om dergelijke aanvallen in de cloud te voorkomen exponentieel groter.

Ten eerste is de complexiteit van cloud IAM-architecturen veel groter. De overvloed aan menselijke en machine-identiteiten en het ingewikkelde toegangscontrolebeleid dat is ingevoerd om de geautomatiseerde orkestratie van cloudbronnen te ondersteunen, zal waarschijnlijk risico's met zich meebrengen die aanvallers gemakkelijk kunnen misbruiken. Niet alleen dat, maar de combinatie van cloud- en on-prem-toegangscontroles kan leiden tot een zeer complex regelsysteem, en aanvallers gedijen op complexiteit.

Ten tweede plaatsen ontwikkelaars die cloudinfrastructuur gebruiken om hun applicaties te maken vaak hardgecodeerde geheimen in hun code en kunnen ze vergeten of nalaten deze te verwijderen, waardoor ze worden blootgesteld aan kwaadwillende actoren.

4. Zijwaartse beweging

Testen moeten mogelijke paden tussen cloudbronnen identificeren, die kwaadwillenden kunnen gebruiken om aanvullende gevoelige gegevens of geheimen te verzamelen en hun aanvallen vooruit te helpen.

In testscenario's voor hybride omgevingen kunnen technieken voor laterale verplaatsing worden geprobeerd als middel om van on-premises naar de cloud te gaan of omgekeerd. Daarom zal het beschermen van de cloudomgeving als een silo niet werken. Organisaties kunnen worden getroffen door aanvallen die zich over het gehele aanvalsoppervlak verspreiden: het interne netwerk, externe middelen en cloudomgevingen. Tegenstanders beschouwen de aanvalsoppervlakken van de organisatie niet als losstaande entiteiten, maar eerder als één oppervlak. Daarom moeten verdedigers een vergelijkbare aanpak volgen, waarbij ze over domeinen heen werken om aanvallen te onderscheppen. Om de cloud te beveiligen, moet men alle wegen die ernaartoe leiden valideren.

5. Gegevensverzameling en exfiltratie

Gegevensverzameling bij cloud computing verwijst naar het verzamelen van gegevens uit meerdere bronnen, die voornamelijk gevoelig van aard zijn, zoals creditcards, persoonlijke gegevens, wachtwoorden enz. Dit is de belangrijkste reden waarom aanvallers inbreken in een netwerk om gevoelige informatie te bemachtigen. Soms slaan de tegenstanders de gegevens op een centrale locatie op, als eerste stap om de gegevens te concentreren die ze willen exfiltreren.

Een cloud-pentest moet het vermogen beoordelen om gegevens te verzamelen en vervolgens naar een externe locatie te exfiltreren en de netwerkbeveiligingscontroles valideren om te testen of ze exfiltratie naar bekende IOC's voorkomen.

Cloud-pentesten: sleutels tot succes

Wanneer u begint met het testen van de cloudpenetratie, is het van cruciaal belang dat u enige tijd besteedt aan het begrijpen van de reikwijdte van uw cloudservices en -middelen, en welke delen van het aanvalsoppervlak u moet beschermen volgens het gedeelde verantwoordelijkheidsmodel. Het is dan mogelijk om weloverwogen beslissingen te nemen over investeringen in cloud-pentesting binnen de context van de risico's van uw organisatie.

Als laatste opmerking: de effectiviteit van een cloud-pentestprogramma wordt niet alleen bepaald door de diepte en breedte van het testen, maar ook door de testfrequentie. Het tempo van de veranderingen in lokale netwerken heeft een negatieve invloed op de effectiviteit van langdurige handmatige penetratietestcycli. In de cloud is het een knock-out. Net zoals cloud- en R&D-teams hun cloudactiviteiten en -implementaties automatiseren, moeten beveiligingsteams overschakelen naar het automatiseren van hun cloudpenetratietestactiviteiten en uiteindelijk de Continuous Integration/Continuous Deployment-loop aanvullen met Continuous Validation.

Stresstesten voor cloudbeveiliging

Om met vertrouwen de veerkracht van uw bedrijf tegen cloud-native aanvallen te valideren, leest u meer over Pentera Cloud en luistert u naar de on-demand opname over Putting Cloud Security to the Stress Test.


Thijs Van der Does