- Het DMZ-model isoleert op netwerkzone; een gehackte webserver in die zone kan vaak nog steeds bij de database komen waarmee hij mag praten.
- Een DMZ delen tussen meerdere servers betekent dat een hack alle servers in gevaar brengt, niet alleen de server die geraakt werd.
- Zero Trust vervangt segmentatie niet, het verandert de basis ervoor: een Protect Surface gebouwd rond wat bescherming nodig heeft, niet de netwerkzone waar het toevallig in staat.
- Het definieren van die segmenten is een businessbeslissing, niet alleen een IT-beslissing: een business- of data-eigenaar moet de afweging per segment dragen.
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.
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.
De oude aanpak
Attack vector
Kijkt naar waar het gevaar vandaan komt. Alles dat vanaf internet bereikbaar is staat in dezelfde zone, en die zonegrens wordt verdedigd.
De Zero Trust-aanpak
Protect vector
Kijkt naar wat je eigenlijk wilt beschermen, meestal de data, en segmenteert daaromheen in plaats van rond de netwerkzone waar het toevallig in staat.
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.
| DMZ-model | Zero Trust-segmentatie | |
|---|---|---|
| Basis voor segmentatie | Netwerkzone / perimeter | Protect Surface: wat bescherming nodig heeft |
| Vertrouwensaanname | Alles binnen dezelfde zone wordt evenveel vertrouwd | Niets wordt standaard vertrouwd |
| Impact bij een hack | Vaak de hele gedeelde DMZ | Beperkt tot de ene getroffen Protect Surface |
| Wie bepaalt dit | IT-afdeling alleen | Business-/data-eigenaar, samen met IT en risico |
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.
FAQ
Wat is het DMZ-model in netwerkbeveiliging?
Een concept van een neutrale zone, geleend van fysieke gedemilitariseerde zones. In netwerktermen staat een internet-facing server, zoals een webserver, in de DMZ, geisoleerd van het interne netwerk erachter.
Waarom wordt het traditionele DMZ-model als kapot beschouwd?
Moderne dynamische websites hebben een webserver nodig die terugpraat met een database op het interne netwerk, waardoor een gehackte webserver bij die data kan komen. Vaak delen meerdere, losstaande servers dezelfde DMZ, waardoor een hack op een van hen ze allemaal in gevaar brengt.
Wat is het verschil tussen attack vector- en protect vector-denken?
Attack vector-denken vraagt waar het gevaar vandaan komt en segmenteert op netwerkzone. Protect vector-denken vraagt wat je eigenlijk wilt beschermen, meestal de data, en segmenteert daaromheen.
Vervangt Zero Trust netwerksegmentatie?
Nee, het verandert de basis ervoor. In plaats van te segmenteren op fysieke netwerklocatie groepeert Zero Trust assets rond een Protect Surface, wat bescherming nodig heeft, en krijgt elke groep een eigen segment in plaats van een gedeelde DMZ.
Wie moet bepalen hoe deze segmenten worden gedefinieerd?
Een business- of data-eigenaar per segment, samen met IT en risico-/securitymanagers, niet de IT-afdeling alleen. Iemand moet de afweging tussen risico en kosten per segment dragen.
Rob Maas is Field CTO bij ON2IT, onderdeel van het CTO Office onder CTO Lieuwe Jan Koning. Hij werkt aan productstrategie en architectuur voor AUXO, MDR en ZTaaS, en geeft vorm aan de Zero Trust customer journey en de AI-featureroadmap van ON2IT. Daarnaast is hij Palo Alto Networks Cyberforce Hero.