Erik de Ruijter

Erik de Ruijter

Architect Infrastructure and Security

Infrastructuren van 10 jaar terug bieden niet altijd de veiligheid die vandaag de dag nodig is. Eén van de grote verbeterpunten is Zero Trust Networking. Een goed praktijkvoorbeeld is de infrastructuurmigratie die ik recent heb gedaan bij een klant van CGI. Hopelijk zijn de opgedane ervaringen, met o.a. het verschil tussen user-gerelateerde en netwerk-gerelateerde maatregelen, ook voor lezers die met andere netwerken en datacentra werken nuttig. Zero Trust Networking is een onderdeel van Zero Trust Architecture. Gezien het project gebruik ik de eerste term, hoewel er wel degelijk ook niet-networking maatregelen in scope zijn.

Wat is het?

Zero Trust Networking (ZTN) is een infrastructuur-benadering met vrij sterke cybersecurity-invloeden. Je zou het ook andersom kunnen stellen, namelijk als een implementatiemethode van beveiliging primair rondom infrastructuur. ZTN komt voort uit het ‘Jericho forum’, een in 2004 begonnen initiatief dat nu onder de Open Group valt. Kern van het Jericho forum was dat het klassieke vertrouwen in afscherming van het interne netwerk van de buitenwereld onvoldoende is, en dat je beter de data zelf kunt beveiligen. Net zoals de muren van het Bijbelse Jericho afbrokkelden bij de eerste klaroenstoot, blijken veelgebruikte netwerktechnologieën als DeMilitarizedZones (DMZ’s) en Virtual Private Networks (VPN’s) de laatste 20 jaar geen garantie meer te bieden op veilige datacentra. Dat wil niet zeggen dat we zonder DMZ en VPN moeten werken, maar het idee dat wie eenmaal het netwerk binnenkomt verder te vertrouwen is houdt helaas geen stand.

We moeten toe naar ‘defense in depth’, niet alleen maar bij de externe connecties. Dit is te vergelijken met een high-security kantoorgebouw waar je medewerkerspasje per specifieke ruimte opnieuw gescand wordt en al dan niet toegang krijgt tot die ruimte. Tegenwoordig is een enkele surfende eindgebruiker die op een enkele malware-link klikt al voldoende om een werkplek te infecteren, en vandaaruit kan een hacker al snuffelend en op-dataverkeer-meeliftend verder het netwerk binnendringen. De kunst is om de impact van threat events, te weten schade door lekken of zelfs wijzigen van data, zo klein mogelijk te houden; en de kans op betrappen zo groot mogelijk. ZTN kent in een veel gebruikte definitie vijf groepen maatregelen, die we in twee blokken bespreken.

User-gerelateerde maatregelen

Recent hebben wij als CGI een project afgerond om een overheidsorganisatie te migreren naar nieuwe datacentrum-hardware en daarna ook gedurende 10 jaar de applicaties te ondersteunen. Dit deden we gezamenlijk met een grote infrastructuurleverancier. Het grootste verschil tussen de oude en de nieuwe situatie was de overgang naar ZTN; Linux-, Windows en middlewareversies moesten 1-op-1 gelijk blijven om de migratie behapbaar te houden. Ik wil je een aantal principes en geleerde lessen uit die migratie niet onthouden.

Ik begin met de user-gerelateerde ZTN principes. De eerste is ‘sterke authenticatie, bij voorkeur multifactor’ voordat een sessie naar een bedrijfsmiddel tot stand wordt gebracht. Hieraan hoefden we voor gebruikersauthenticatie relatief weinig te doen, want de gebruikers bij de klant hebben i.h.a. al dubbele authenticatie met SMS- of Appverificatie en in zijn algemeenheid ook SSL-encryptie. Samen met een zogenaamde jumphost als schakelpunt naar de achterliggende omgeving was voldoende.

We hebben in het design wel gekeken naar producten die toegang ‘achter’ het SSL VPN kanaal meer fijnmazig maken, zoals Ivanti Zero Trust Access en Fortinet ZTNA; de CGI Global Technology organisatie heeft hier kennis opgebouwd. De nadruk bij deze klant ligt echter op de netwerk gerelateerde ZTN-issues, dus o.a. wat te doen als een hacker binnen wist te komen op een bepaalde server en vandaar verder aanvalt. Dat is niet de markt voor Ivanti/Fortinet met hun Policy Decision Points en Policy Enforcement Points en ook optioneel constante compliance checks op het endpoint, ze zijn gekoppeld aan het AD account van de gebruiker. En omdat er achter de SSL VPN bij de klant reeds een jumphost zit voegde het te weinig toe om hier ZTN-tooling te adviseren. Authenticatie en autorisatie per apparaat, vervolgens, is een ander deel van dit eerste ZTN-principe. Het vertaalt zich net als bij de user-kant naar encryptie (bijvoorbeeld tweezijdig SSL). Deze end-to-end encryptie zou je een extra ZTN-eis kunnen noemen.

Het tweede ZTN-principe is ‘granulaire least privilege regels’. Met andere woorden, zorgen dat een gebruiker alleen het hoogstnoodzakelijke in de systemen kan zodat een meeliftende hacker ook ingeperkt wordt. Binnen applicatieschermen had de klant dit al, maar wij hebben dit doorgetrokken naar semi-applicatieve componenten zoals fileshares en databases. Elke gebruikerstoegang die er in de oude omgeving was moest opnieuw door de risk acceptance procedure, en vaak hebben we commitment gekregen om de komende jaren de applicatie te laten aanpassen. I.h.a. in de richting van communicatie via service oriëntatie of een publish-subscribe messaging model, die zijn veel beter op least privilege in te stellen dan hele files of databases.

Netwerk gerelateerde maatregelen

Dan de netwerk-aandachtspunten binnen ZTN. Nummer drie is Layer 7 dreigingsbescherming. Ofwel het ‘scannen’ van alle passerende verkeer op correct gebruik van de protocollen en daardoor op eventueel meeliftende hackers; denk aan ODBC database of NFS fileshare of HTTPS. Dit miste gewoon in de, 10 jaar oude, architectuur. Samen met onze partner hebben we dit opgelost door geavanceerde Intrusion Detection/Prevention modules bij te prikken op de firewalls tussen alle Intranet netwerkzones.

ZTN-punten vier en vijf zijn ‘inbouwen van gedetailleerde netwerksegmentatie’ en ‘voorkom aanvallen via zijwaartse routes’ (lateral movement). Net zoals velen van ons als tieners brommers demonteerden en stuk voor stuk opbouwden, hebben we hiervoor het klant-Intranet van de grond af nieuw opgebouwd. Beide gebieden hebben veel overlap, dus hier geldt één aanpak voor beide ZTN issues.

De basis was de simpele Ontwikkel/Test/Acceptatie/Productie-inrichting die een klassiek Intranet heeft. Maar daarbovenop kwam de zone-indeling van NORA (overheidsreferentie architectuur), met zijn regels zoals ‘extern verkeer kan alleen de achterliggende lagen bereiken via de Front Office servers’. Vervolgens dan nog micro-zones; dat is een nóg fijnmaziger segmentatie, en gebruiken we als er bijvoorbeeld toegang nodig is in de richting tegen de normale flow in. Tot slot hebben we firewall-regels opgebouwd in het firewall-clustertool. Dus we hebben een firewall-equivalent van de Policy Decision Points en Policy Enforcement Points die we boven zagen; de Decisions gebeuren op clusterniveau, en enforcement gebeurt door de individuele Intranet firewalls.

Let wel: alle extra maatregelen in onze nieuwe architectuur zijn geheel transparant voor de eindgebruiker; zijn applicaties werken als voorheen. De nieuwe checks en regels kosten een klein stukje overhead in het dataverkeer, maar dat wordt ruimschoots teniet gedaan door inzet van de nieuwe en snellere generatie firewalls/intrusion prevention. En als een component gehackt zou zijn dan is de nieuwe architectuur stukken veiliger dan vroeger.

Lessen voor andere omgevingen

We hebben de vijf ZTN-principes de revue laten passeren:

  1. sterke authenticatie
  2. granulaire least privilege regels
  3. Layer 7 dreigingsbescherming
  4. gedetailleerde netwerksegmentatie
  5. het voorkomen van aanvallen via zijwaartse routes

Gelukkig heeft een niet als ZTN ontworpen netwerk meestal al een deel van deze functies geïmplementeerd, dus echt ‘van scratch beginnen’ zal zelden voorkomen. Verder geldt dat de implementatie van ZTN-principes altijd een afweging is tussen risico, kosten qua investering en beheer en complexiteit; alleen een spreekwoordelijke Fort Knox-situatie met bijbehorende budgetten kan 100% scoren.

Een ZTN mindset vraagt slechts om te erkennen dat de buitengrens-bewaking met pakweg een DMZ en een VPN niet waterdicht is, en je de hele binnen-zone moet voorzien van allerlei checks en binnengrenzen. Als je dit in fasen oppakt, dan toon je dat je de adviezen van het Jericho-forum serieus neemt. En wij van CGI staan graag klaar om dit alles te helpen uitwerken voor jouw situatie!

Over de auteur

Erik de Ruijter

Erik de Ruijter

Architect Infrastructure and Security

Erik is a passionate mediator between the various layers of an organisation: from high-level functional requirements up to security and infrastructure design. He is skilled in functional information analysis but also in architecture and in engineering/monitoring of technical platforms: physical, virtualised and cloud. He has ...