Het DMZ model is kapot

Als we het hebben over Zero Trust en micro segmenten, gaat het vaak over segmenten gebaseerd op data (kroonjuwelen). Zero Trust wordt echter vaak gepresenteerd als het segmenteren van elke individuele server. Het bekendste voorbeeld zijn de 3-niveaus van een applicatie; web-, applicatie- en databaseserver, waarvoor het dan geldt dat je op elk niveau zou moeten firewallen.

Alhoewel dit niet noodzakelijkerwijs een slecht voorbeeld is, is het alleen te managen als alles geautomatiseerd is. Wat vaak niet het geval is in ‘traditionele’ en bestaande omgevingen. Als dit verkeerd geïmplementeerd wordt, kan je beveiliging erop achteruitgaan.

In een bestaande omgeving is het vaak logischer om te beginnen met segmenten gebaseerd op data of DaaS vanuit het perspectief dat je juist wilt beschermen. Veelal is het niet de server die je wil beschermen, maar de data.

DMZ oorsprong

Het DMZ-model (Demilitarized zone) vindt zijn oorsprong in de fysieke wereld, waar de DMZ tussen Noord- en Zuid-Korea het bekendste voorbeeld is. Het idee achter deze DMZ is dat het een neutraal gebied is. Als er een discussie nodig is over iets waar beide partijen bij betrokken zijn, kunnen ze deze houden in dit gebied. Toen netwerkbeheerders het DMZ-model voor het eerst gingen implementeren, was het idee hetzelfde.

De webserver bevond zich in de DMZ en de website werd geüpload naar de webserver via FTP. De bezoekers gingen naar de webserver en de website werd weergegeven. Het is belangrijk dat deze twee connecties vanuit beide partijen worden geïnitieerd, net zoals in een DMZ in de fysieke wereld.

Vandaag de dag zijn websites vaak dynamisch en bieden ze toegang tot verschillende soorten dynamische data. Het resultaat van deze verandering is dat de webserver vaak nog in de DMZ staat en dat de database server zich bevindt in het interne bedrijfsnetwerk.  Om ervoor te zorgen dat de webserver de data kan benaderen, heeft de firewall een regel die de webserver laat ‘praten’ met de database server, en hopelijk is er een soort authenticatie vanuit de database server voordat deze de webserver toegang biedt.

De traditionele webserver connecties

Als we kijken naar de communicatie hebben we nog steeds twee verbindingen, maar ze zijn niet hetzelfde als voorheen.

De eerste verbinding is tussen de bezoeker en de webserver, de tweede van de webserver naar de database server. Als de webserver gehackt wordt dan is alle data op de database server in gevaar, omdat de webserver toegang tot deze data heeft.

Dit gebeurt omdat we ons vaak concentreren op waar het gevaar vandaan komt (attack vector), in plaats van op wat we proberen te beschermen (protect vector).

Op de traditionele manier werd de webserver geïsoleerd en liep alleen de data op de webserver gevaar. Het is extra gevaarlijk als het een gedeelde database server is, wat betekent dat deze server toegang tot meerdere databases biedt.

Het tweede probleem wat zich vaak voordoet is dat alle servers die via het Internet benaderd worden zich in dezelfde DMZ bevinden. Dit betekent dat als een server in de DMZ aangetast wordt, alle andere servers in de DMZ ook gevaar lopen.

Dit gebeurt omdat we ons vaak concentreren op waar het gevaar vandaan komt (attack vector), in plaats van op wat we proberen te beschermen (protect vector).

Het Zero Trust Perspectief

Vanuit een Zero Trust perspectief is het belangrijk om van binnen naar buiten te kijken; wat wil ik beschermen. Als het alleen de data is, dan is de web- en database servers in hetzelfde segment zetten prima verdedigbaar. Zeker als segmentatie op de traditionele manier gedaan wordt, door middel van subnetten of routing. Het is hierbij ook belangrijk dat deze applicaties (web- en databaseserver) hun eigen segment krijgen en niet in een gedeelde DMZ worden geplaatst!

Houd in gedachten dat Zero Trust geen technische oplossing is en dat het verschillende belanghebbenden betrekt.

Als de webserver nu gehacked wordt, dan zal dezelfde data als in het vorige voorbeeld in gevaar zijn (er van uit gaande dat de database server als enige de database voor de webserver bedient). Echter, het incident zelf is geïsoleerd en er is geen oost-west verkeer tussen andere applicaties.

Een gedeelde organisatorische inspanning

Het definiëren van deze segmenten zou een organisatorische inspanning moeten zijn, uitgevoerd door verschillende belanghebbenden en dus niet alleen de IT-afdeling. De IT-afdeling is er om te ondersteunen en kan zeker helpen met het definiëren van risico’s vanuit een technisch oogpunt. Risico- en beveiligingsmanagers zouden betrokken moeten zijn in dit proces om een duidelijk overzicht te krijgen. Uiteindelijk is het belangrijk om per segment een business/data-eigenaar aan te wijzen. Deze persoon is verantwoordelijk voor het afwegen van risico’s en het maken van beslissingen.

Het benoemen van een eigenaar per segment helpt deze discussies te beslechten. Het segmenteren van individuele servers is zeker haalbaar, maar komt tegen een hoge prijs en gaat risico’s niet per definitie tegen.

Vanuit security maatregelen bekeken is de DMZ een netwerk georiënteerde oplossing. In deze blogpost is een Zero Trust segment dan ook gelijk aan een netwerksegment. Normaal gesproken kan een (Zero Trust) segment uit meer security maatregelen bestaan dan alleen netwerksegmentatie.

Conclusie

De traditionele DMZ set up is niet meer veilig genoeg, het beschermt niet wat het zou moeten beschermen. Het is zelfs zo dat in veel gevallen er meerdere servers in de DMZ zijn die toegang tot verschillende soorten data bieden, elk met hun eigen risico’s. Binnen de DMZ is er geen beveiliging tegen laterale beweging van server tot server en dus geen mogelijkheid tot isolatie in het geval van succesvolle hack.

Zero Trust helpt met het overwinnen van deze beveiligingskwestie. Zero Trust is geen technische oplossing en betrekt verschillende belanghebbenden – niet alleen de IT-afdeling – om betekenisvolle segmenten te benoemen en beslissingen te nemen over waar maatregelen het meest nodig zijn. Dit zal de beveiliging zeker verbeteren en zorgen dat maatregelen (en dus kosten) ingezet worden waar deze het meest dringend zijn.

Rob Maas
Thought Leader

Rob Maas