Vulnerabilities in systemen, een bron van zorg

Vulnerabilities is zo’n woord dat je tegenwoordig dagelijks leest en hoort. Altijd in relatie tot Cyber Security. Maar in dit artikel gaan we nog een stap verder. Want er zijn andere vulnerabilities die minstens zo gevaarlijk zijn maar die we vaak over het hoofd zien.

Case: Een serieuze vulnerability

Dit intro brengt mij automatisch terug naar de dag waarop wij gebeld werden door de NCSC (Nationaal Cyber Security Centrum). Hoewel we op training waren moesten we onmiddellijk naar locatie X komen om te assisteren bij het verwijderen van malware die ze op één van onze servers hadden aangetroffen.

Nu hadden we in het verleden weleens virussen op werkstations gehad en gebruikers die ongeoorloofde acties uitvoerden, maar die problemen konden we allemaal wel tackelen. Dit was echter andere koek en klonk heel serieus.

Toen we daar aankwamen zaten er 3 jonge mannen met zwarte T-shirts en lang vettig haar gebogen over een scherm. Echte Nerds.

Op een beheerste maar indringende manier vertelden ze wat er aan de hand was. Er was malware geïnstalleerd op één van onze servers en deze was ontdekt toen het zich ook op een andere server wilde installeren. Zij hadden echter speciale voorzieningen op het netwerk getroffen die al het verkeer monitorde.  Nu waren onze servers verbonden met het overheidsnetwerk, dus security was van levensbelang. Ze vonden dit een zeer ernstig incident en zo voelde het ook. Als het de malware wel gelukt was om zich te verspreiden hadden ze het openbaar moeten maken, het was een close call.

Het wegnemen van de vulnerability

Wij vonden van onszelf dat we hele goeie systeembeheerders waren maar dit was een elite korps. Het leken nerds maar het waren NCSC frontsoldaten, de eerste in de linie voor de verdediging van ons land.

De malware werd ge-archiveerd en verwijderd en meer trackers werden in het netwerk rond onze servers geplaatst. Op de geplaagde server draaide een oude applicatie met 5 gebruikers die het soms nog raadpleegden. Omdat updates regelmatig tot problemen leidde hadden we de oude server niet meer gepatcht. Zie daar de kwetsbaarheid die we zelf geïntroduceerd hadden. Twee maanden later waren we zo ver dat we de server konden uitschakelen.

Voor hackers maakt het niet uit op welke server ze kunnen komen, ook oude vergeten servers kunnen voor hen een springplak naar een grotere vis zijn.

Technische schuld is de oorzaak van vulnerabilities

Deze case is illustratief voor wat de CE community bedoelt in hun CE-concept met het volgende:

“Door een cumulatie van technical debt in zowel het voortbrengingsproces als in de ICT-services die in productie zijn genomen is er een fragiliteit ontstaan. Bij de minste of geringste aanpassingen ontstaan grote incidenten die moeilijk op te lossen zijn.”

Niet alleen security

Deze stelling suggereert dat de kwetsbaarheden niet alleen met security te maken hebben. Het gaat inderdaad verder dan dat, ook door bugs en programmafouten kunnen grote incidenten ontstaan. Voor de eindgebruiker is het effect altijd altijd hetzelfde, hij kan zijn werk niet uitvoeren, want het systeem is onbereikbaar. Grosso modo kan een zeer kwetsbare situatie ontstaan door een cumulatie van de volgende problemen:

• Op niet goed beveiligde systemen en netwerken kan worden ingebroken.
• Ontwerpfouten staan toe dat ongeoorloofde transacties mogelijk zijn.
• Vergeten bugs, kunnen hackers gebruiken om het systeem binnen te dringen.
• Tijdens het testen, niet gevonden programmeerfouten kunnen leiden tot het down gaan van het systeem.
• Niet goed afgehechte open eindjes uit het ontwikkeltraject, kunnen fake transacties verwerken.
• Het laten zitten van dode code, niet meer in gebruik waar wel voor hackers te benaderen.
• Niet bijgehouden documentatie, waardoor niemand meer weet hoe het precies zit.

Dit type kwetsbaarheden veroorzaken achterdeurtjes voor hackers waardoor ze kunnen binnendringen in onze systemen. De gevaren komen echter niet alleen van hackers maar ook van eigen gebruikers die per ongeluk op een knop kunnen drukken en zo onherstelbare schade veroorzaken. Hetzelfde kan gebeuren als er een ongebruikelijke transactie wordt aangeboden.

Gelaagdheid van vulnerabilities

In onze case was sprake van eigen servers in een eigen netwerk. Door de komst van Cloudcomputing moeten we de infrastructuur in 3 lagen beschouwen IaaS, PaaS en SaaS. Iedere laag wordt door een andere partij beheerd en valt vaak buiten onze controle. Sterker nog, van je SaaS dienst weet je niet dat de PaaS-provider Rackspace is die weer AWS in de USA als IaaS provider heeft. Dit maakt het vrijwel onmogelijk om je systemen op kwetsbaarheden te checken, laat staan om ze zelf op te lossen.

De enige oplossing hiervoor is om alleen in zee te gaan met leveranciers die ISO 27001 gecertificeerd zijn. We hebben dan wel is waar niet zelf vastgesteld dat er geen vulnerabilities zijn, maar de certificerende instantie heeft dat voor ons gedaan.

Is technische schuld altijd de oorzaak van alle vulnerabilities?

Euh… Ja. Alle genoemde problemen komen voort uit verwijtbaar gedrag. Dankzij een houding als:

• Dat komt later wel.
• Daar is nu geen geld meer voor.
• De deadline gaat voor.
• We zijn onvoldoende opgeleid.
• Er was niet genoeg tijd om alles te testen.
• Ik geloof wel dat het goed zit.
• We checken het niet, want hij levert altijd goed werk.
• We lopen maar een klein risico.
• De leverancier heeft gezegd dat het in orde is.
• De ondersteuning is gestopt maar deze servers draaien nog prima.
• Et cetera.

Een ramp komt bijna nooit door één oorzaak, meestal is het een opeenstapeling van fouten en verkeerde beslissingen. Door deze houding ontstaat Technische Schuld. Er sluipen in de loop der tijd steeds meer vulnerabilities in het systeem en de kans op een ramp wordt steeds groter. En als de ramp daar is kijken we elkaar aan. Was het mijn schuld? Of toch van die ander?

Wat moeten we doen om vulnerabilities te elimineren?

In de eerste plaats moet het voorkomen van technische schuld een vast onderdeel van onze werkprocessen worden. Als deze aanpassing is doorgevoerd wordt het checken op het probleem routine. We krijgen een procesmatige mindset. Let op de volgende controles:

• Maak voldoende ruimte op de begroting om technische schuld te voorkomen.
• Zorg dat de infrastructuur up-to-date is.
• Check of de leveranciers blijvend gecertificeerd zijn.
• Patch alle systemen met de laatste updates.
• Installeer een minimale set aan beveiligingsmaatregelen.
• Test de beveiligingsmaatregelen regelmatig.
• Maak dagelijks een back-up van de systemen.
• Test ook de restore regelmatig.
• Voer regelmatig een Dark Web monitoring uit.
• Gebruik waar mogelijk encryptie voor het verzenden van data.
• Maak en test een Disaster Recovery plan.
• Check na iedere systeemupdate of de applicatie nog goed werkt.
• Reserveer tijd in de planning om technische schuld te voorkomen.
• Review ieder ontwerp op onvolkomenheden.
• Test iedere module voor iedere oplevering, ook de delen die niet zijn aangepast.
• Verwijder code die je niet meer gebruikt.
• Werk de documentatie bij na iedere oplevering.

We moeten bovenal luisteren naar onze gebruikers. Zij merken vaak als eerste op als er iets niet met het systeem klopt. Betrek ze om de technische schuld laag te houden en voorkom ten alle tijden dat je bij de NCSC op het matje wordt geroepen.

Discussieer mee op LinkedIn.