Nulmeting en terugkerende pentesten: cruciaal voor de beveiliging van jouw organisatie.

Tegenwoordig is het geen vraag meer of je wordt getroffen door een cyberaanval, maar wanneer. Steeds meer organisaties worden hier slachtoffer van, zeker als ze hun basisbeveiliging niet op orde hebben. Aanvallers selecteren hun potentiële slachtoffers eerst op “kans” en kijken daarna pas welke “vis” ze binnen hebben gehaald. Gevolg is dat iedere organisatie slachtoffer kan worden, van ziekenhuis tot webwinkel en van havenbedrijf tot gemeente.

In december 2022 werd de stad Antwerpen slachtoffer van een grote cyberaanval met malware. Het Nieuwsblad kopte Stad Antwerpen zit met de handen in het haar na grote cyberaanval: “Als de deuren in het slot vallen, weten we niet of we ze nog open krijgen”. IT-voorzieningen zoals het aanvragen van vergunningen en het elektronisch betalen in musea waren niet meer mogelijk, en tot de dag van vandaag geeft de stad Antwerpen een dagelijkse update op haar website over welke IT-voorzieningen nog niet werken.

Hoewel Resillion (voorheen Eurofins Cyber Security) dit specifieke geval als buitenstaander niet inhoudelijk kan beoordelen, heeft het wel overeenkomsten met de situatie die wij in de praktijk bij onze klanten zien. Organisaties hebben geen overzicht van de informatiebeveiligingsrisico’s die zij lopen. Ze zijn zich ervan bewust maar weten niet tot een concreet en effectief verbeterplan te komen, of ze denken dat risico’s zijn verholpen zonder dit in de praktijk te (laten) checken. En waar dan te beginnen met dit te verbeteren?

Nulmeting

Vanuit het gedachtengoed dat een status van de beveiliging en de mutaties leiden tot een nieuwe status is het natuurlijk niet verkeerd om zowel de status als de mutaties te onderwerpen aan allerlei beheer- en wijzigingsprocessen die zijn vermeld in de good practices. Resillion adviseert organisaties dan ook hun hardware- en softwarewijzigingen regelmatig te laten testen door onafhankelijke interne en/of externe beveiligingsteams. Dit kan in de vorm van een penetratietest waarbij de scope de gehele infrastructuur omvat, maar de test kan zich ook richten op enkel een nieuw systeem dat wordt geïntroduceerd.

Voor organisaties die nog nooit of slechts sporadisch een penetratietest hebben laten uitvoeren, kan dit in de vorm van een nulmeting. Het doel hiervan is om een globaal overzicht te krijgen van de belangrijkste technische tekortkomingen in het design of de implementatie van een IT-infrastructuur.

Terugkerende penetratietesten kunnen zich richten op de volledige infrastructuur, maar ook op individuele systemen, bijvoorbeeld omdat deze nieuw worden opgeleverd. Eén klant van Resillion laat al haar systemen testen voordat deze “live” gaat of significant wijzigt. Door commitment vanuit de raad van bestuur gaan deze systemen niet “live” als er ook maar één gemiddeld, hoog of kritieke bevinding uit de test komt. Resillion constateert dat deze aanpak ervoor zorgt dat veel beveiligingsrisico’s al vroegtijdig worden weggenomen of gemitigeerd. In feite worden zo stapsgewijs delen van de infrastructuur vervangen door robuuste systemen.

Verbeterplan

De bevindingen uit een pentest zijn vaak niet op zichzelf staande problemen, maar veel vaker zijn zij het resultaat van meer generieke problemen: dat een groot aantal systemen niet up-to-date zijn qua security updates kan niet worden opgelost door enkel deze individuele systemen te gaan updaten, maar vereist ook dat de werking van het patch- en vulnerability managementbeleid wordt gecontroleerd.

Als dus uit een inventarisatie aan het licht komt dat niet alles in orde is, hoe zorg je er dan voor dat je beveiliging wel in orde komt en blijft? Dat is een vraag waar veel organisaties iedere dag mee bezig zijn en waarover veel raamwerken en good practices zijn gepubliceerd. Denk hierbij aan Cobit, ITIL, ISO 27001 en de NIST-standaarden. De gemeenschappelijke noemer is dat er in een organisatie processen aanwezig zijn die de techniek, organisatie en mensen verbinden en regelkringen zoals het plan-do-check-act model van Deming of het identify-protect-detect-response-recover model van NIST. Veel organisaties zijn in de nieuwe NIS2 richtlijn zelfs verplicht adequate maatregelen te nemen ten aanzien van het beheer van cyberrisico’s, penetratietesten, ‘incident response’ en herstel.

Meten is weten

Vervolgens is het zaak regelmatig de effectiviteit van maatregelen te controleren. Want werken het informatiebeveiligingsbeleid en de processen ook echt? Resillion ziet vaak dat op papier alles perfect lijkt ingeregeld, maar dat dit in de praktijk toch anders is. Een aantal voorbeelden:

• Organisatie X beschreef in zijn beleid precies aan welke beveiligingseisen systemen moeten voldoen. Bij een penetratietest door Resillion bleek dit ook grotendeels zo te zijn, maar bleken er ook ongedocumenteerde systemen aanwezig te zijn in het netwerk die door individuele afdelingen werden beheerd (zogenaamde “shadow-IT”). Deze systemen waren zeer slecht beveiligd en binnen een paar minuten konden beheerrechten worden verkregen. De gebruikerswachtwoorden op deze systemen bleken overeen te komen met het centrale (identity & access management) Active Directory (AD) domein, en er op het interne netwerk van de organisatie werd geen gebruik gemaakt werd van Multi-Factor Authentication . Zodoende kon Resillion uiteindelijk toch toegang krijgen tot het centrale AD domein, en daarmee de file servers met allerlei bedrijfsgevoelige informatie.

De resultaten van de penetratietest werden nadien niet alleen gebruikt om de individuele bevindingen op te lossen, maar ook om in breder verband “shadow-IT” binnen de organisatie te gaan opsporen.

• Organisatie Y had bij het afnemen van een softwarepakket de leverancier gevraagd naar het beveiligingsniveau van het product. De leverancier gaf aan jaarlijks een pentest te laten uitvoeren, en dat bij de vorige pentest was gebleken dat de software “veilig” was. Tijdens het uitvoeren van een penetratietest door Resillion op de software op verzoek van Organisatie Y bleek dat er toch allerlei lekken aanwezig waren in de software. Achteraf bleek dat de leverancier zijn pentests had laten uitvoeren met enkel automatische tools en zonder de testers toegang te geven “achter de login”.

Hoewel Organisatie Y voldaan had aan wat er in haar beveiligingsbeleid stond bleek het ontbreken van een kwaliteitscheck op de statements van de leverancier toch geresulteerd te hebben in een behoorlijk risico.

Dit laat zien dat het in brede zin testen van een IT-infrastructuur van belang is om blinde vlekken te vinden in de opzet of uitvoering van beleid. Een terugkerende jaarlijkse penetratietest met brede scope en het uiteindelijk hertesten van de bevindingen uit die test kan daarbij helpen.

Aanbevelingen

Op basis van voorgaande beveelt Resillion het volgende aan:

• Voer tenminste jaarlijks security audits uit op de pijlers “techniek”, “organisatie”, “proces” en “mens”. Controleer daarbij de effectiviteit van de informatiebeveiliging binnen een organisatie in de praktijk, dus door middel van penetratietests en security-awareness tests (zoals phishing).
• Zelfs als een organisatie bewust is van structurele problemen, kan een technische nulmeting (nog) meer inzicht geven in waar de grootste risico’s zitten. Dus de resultaten van een pentest kunnen gebruikt worden om een triage uit te voeren en priorisering in het verbeterplan aan te brengen.
• Zorg dat de jaarlijkse pentest vanuit verschillende invalshoeken wordt uitgevoerd:
• Vanuit het perspectief “anonieme individu”, bijvoorbeeld vanaf het internet of “vanaf de stoep“, (denk aan WiFi-hacking);
• Vanaf het perspectief “klant”, als de klanten van een organisatie directe toegang tot systemen hebben.
• Vanaf het perspectief “leverancier”. Een leverancier met VPN-toegang of een monteur die zijn laptop aan het netwerk koppelt kan een risico vormen.
• Vanaf het perspectief “medewerker”. Besef als organisatie dat het merendeel van de aanvallen tegenwoordig via medewerkers loopt, dus door hen te verleiden een malafide bestand te openen of website te bezoeken.
• Pak de bevindingen uit een pentest niet enkel als individueel probleem aan, maar zoom uit en kijk naar het bredere verband. Individuele bevindingen aanpakken is meestal weinig effectief in het voorkomen van vergelijkbare bevindingen bij vervolgtests.
• Hertesten zijn belangrijk om vast te stellen of de aanpak/oplossing van bevindingen doorgevoerd, effectief en volledig is. Ga er niet zondermeer vanuit dat een bevinding uit een pentest volledig is opgelost, de oplossing kan onvolledig zijn of nieuwe risico’s opgeleverd hebben.
• Neem informatiebeveiliging mee in het aanbestedingsproces met leveranciers. Welke garanties geeft een leverancier over beveiliging en hoe zien die er concreet uit? Is er bewijs dat er penetratietests zijn uitgevoerd? Wat was de scope?

Ons aanbod

Hulp nodig bij het laten uitvoeren van penetratietests, verbeterplannen of het opzetten van informatiebeveiliging binnen uw organisatie? Resillion biedt haar klanten een breed gamma aan van diensten om de kwetsbaarheden in wijzigingen en status van de informatievoorziening inzichtelijk te maken. Dit betreft onder meer het testen van complete IT-infrastructuren of applicaties door middel van security assessments (specifieke scope) of penetratietests (brede scope), het monitoren van de beveiliging van de IT-infrastructuur, consultancy en het leveren van privacy en (chief) information security officers.