Regelmatig ontwikkel ik software of bouw ik een netwerk. Dit doe ik voor het werk, mijn hobby, ter lering of gewoon vermaak. Voor welk doel ik het ook bouw, ik probeer hierbij altijd security als integraal onderdeel mee te nemen. Meerdere malen heb ik opgemerkt: het is niet altijd zo eenvoudig én security kan je nog weleens uit het oog verliezen.
Offensief & defensief
Zelf heb ik heel veel jaren gewerkt (en dit doe ik nog steeds met veel plezier) in het offensieve gedeelte van het security vakgebied. Dit bestaat voornamelijk uit het uitvoeren van penetratietesten, het blootleggen van kwetsbaarheden binnen IT-oplossingen van organisaties.
In die jaren heb ik geleerd dat de positie van een aanvaller over het algemeen makkelijker is dan die van iemand die veilige netwerken bouwt, applicaties ontwikkeld of een omgeving moet beschermen tegen aanvallen.
Waarom? Een aanvaller heeft vaak slechts één goede ingang nodig om het volledige netwerk over te kunnen nemen. Terwijl de systeembeheerder / software ontwikkelaar of het blue team alle mogelijke ingangen moet dichten of monitoren. Je kunt wel stellen dat dat zo goed als een onmogelijke taak is.
Werk samen
Over het algemeen hebben IT professionals veelal een eigen specialisme. Een systeembeheerder is geen security specialist. En een security specialist is ook geen systeembeheerder. Daarom ben ik ervan overtuigd dat het belangrijk is om de juiste personen bij elkaar te krijgen om het optimale resultaat te behalen.
Bij het bouwen van een netwerk kan een systeembeheerder zijn kennis over het goed opbouwen van een netwerk gebruiken. Terwijl de security specialist er vanuit het perspectief van de aanvaller kan kijken wat er fout kan gaan.
Ook niet onbelangrijk: als deze specialismen met elkaar samenwerken kunnen ze van elkaar leren.
De basis
Tijdens mijn werk als pentester heb ik heel vaak gezien dat een veilige basis ontbreekt. Laten we als voorbeeld het ontwerpen van netwerken gebruiken: één van de belangrijke oorzaken van het ontbreken van deze veilige basis is in mijn optiek de snelle groei van IT.
De eerste stappen in onze netwerken zijn 10-tallen jaren geleden gezet, toen was security minder belangrijk. De jaren erop zijn we alleen maar systemen gaan toevoegen, IT werd belangrijker en de netwerken groeiden enorm. Dit allemaal bovenop die onveilige basis. Het netwerk herbouwen om het onveilige fundament te verhelpen is vaak geen optie, dat kost teveel geld voor de gemiddelde organisatie.
Bij het bouwen van een netwerk bedoel ik met de basis bijvoorbeeld: segmentatie, updates en lokale firewalls. Het is helaas nog steeds de standaard: netwerken bevatten geen segmentatie noch ingestelde firewall rules, updates worden niet structureel uitgevoerd en lokale firewalls staan volledig uit. Een ander voorbeeld is dat veel netwerken op iedere server hetzelfde lokale administrator wachtwoord hebben. Bij het compromitteren van één server, heb je ze dus allemaal.
Denk bij het bouwen van een nieuw netwerk dus goed na over deze basis. Segmentatie speelt hierbij een belangrijke rol. Zorg ervoor dat beveiligingsmaatregelen volgens het defense-in-depth principe geïmplementeerd worden. Mocht één van de beveiligingsmaatregelen falen, dan loopt een aanvaller weer tegen de volgende beperking op wat zijn aanval bemoeilijkt.
Wees realistisch
Wat ik regelmatig opmerk als het gaat om IT-security is dat we ons druk kunnen maken om heel veel zaken (ook ikzelf). Maar de vraag is: is het daadwerkelijk een realistisch risico en voegt het oplossen wat toe? En overdrijven we niet? Bij het bouwen van iets nieuws heb je namelijk altijd te maken met een afweging tussen security én functionaliteit. Het moet werkbaar én zo veilig mogelijk zijn. Dat wordt nog weleens vergeten.
Om een voorbeeld te nemen. Ik heb ooit gewerkt voor een klant die nagenoeg verplicht werd om enorm veel zaken van de CIS Controls te implementeren. Dit is een enorm waardevolle baseline. Maar het is wel noodzakelijk om te controleren of de acties in CIS daadwerkelijk relevant zijn voor jouw situatie, in plaats van deze zomaar te verplichten / implementeren. Het is dus nog maar de vraag in hoeverre die organisatie hier ook daadwerkelijk veiliger van geworden is. Misschien was het beveiligen van de organisatie met de denkwijze van een paar security specialisten veel goedkoper én effectiever geweest.
Monitoring
Veel organisaties monitoren niet actief op eventueel kwaadaardig gedrag op het netwerk. Of er vindt wel signalering plaats, maar volgen de alarmen niet effectief op (kijken er nooit naar of met onvoldoende kennis). Dit veroorzaakt het probleem dat een organisatie niet door heeft dat ze gecompromitteerd is, of wordt. Volgens het laatste DBIR 2020 rapport duurt het bij meer dan 20% van de aanvallen nog steeds één maand of meer voordat deze opgemerkt wordt.
Het monitoren van een netwerk is ook niet makkelijk, het is nou eenmaal niet mogelijk om alle denkbare aanvallen zomaar te detecteren. Tijdens een aanval gebruikt een aanvaller heel veel methodes en tools. In mijn optiek hoeven niet al deze methodes en tools gezien te worden, zolang de aanvaller maar tegen minimaal één van de detecties aanloopt. Dit kan dan aanleiding zijn om verder te kijken en te onderzoeken wat er plaatsvindt. Canary tools kunnen hierin bijvoorbeeld al een hele mooie eerste stap zijn.
Opbouwen infrastructuur voor onze app
De aanleiding voor dit blog is het opzetten van onze eigen netwerk infrastructuur van Zolder.App. Wij proberen dit netwerk uiteraard zo secure mogelijk neer te zetten. Tijdens het ontwerpen van het netwerk liepen wij tegen vraagstukken aan die helemaal niet zo exotisch zijn. Toch moesten wij er even goed over nadenken hoe die zaken zo veilig mogelijk neer te zetten. Dat herinnerde mij er wederom aan dat het opzetten van netwerken met security in mind niet zo makkelijk is.
Om weer een concreet voorbeeld te geven: bij het bedenken van een infrastructuur loop je bij een Demilitarized Zone (DMZ) vaak tegen dilemma’s aan. In de ideale wereld (vanuit beveiligingsperspectief) wil je vanuit de DMZ géén verbindingen naar interne netwerken. Maar in de praktijk zijn er heel veel situaties waar dit zo goed als onmogelijk is.
Een systeem in de DMZ heeft namelijk vaak informatie nodig over wat aanwezig is op het interne netwerk. Dan kom je dus op het dilemma: ga ikmijn gevoelige informatie op een of andere manier naar de DMZ verplaatsen (inclusief een sync) of sta ik die ene verbinding toe naar mijn interne netwerk?
Conclusie
Het ontwerpen en opbouwen van iets nieuws op een veilige manier is niet makkelijk. En het veilig maken van iets dat al bestaat al helemaal niet. Ook in 2020 is dat nog steeds niet het geval. Het is momenteel nog steeds veel maatwerk. Je koopt een firewall, maar dan ben je nog niet beschermd. Je zult die zelf op een goede manier moet configureren voordat je zo veilig mogelijk bent.
Innovaties zoals de cloud zullen dit verminderen omdat meer zaken generiek worden. Maar alsnog dienen zaken, bijvoorbeeld multi-factor authentication, ingeschakeld te worden door de afnemer zelf. In de ideale wereld zou alles out-of-the-box veilig moeten zijn. Maar dat gaat niet altijd want dan bijt het mogelijk weer met de gebruiksvriendelijkheid.
Het is belangrijk dat de verschillende expertises met elkaar samenwerken om zo tot een functioneel én veilige oplossing te komen. Ik vind het dan ook fijn te merken dat we als Zolder al best regelmatig gevraagd worden om een security rol in te nemen in het ontwikkelingsproces van digitale producten van onze klanten.
Om het efficiënt te houden is het ook zaak om alleen de issues aan te pakken die er daadwerkelijk toe doen. Het is belangrijk om van eventuele risico’s op de hoogte te zijn, zodat deze op een bewuste manier geaccepteerd kunnen worden.