AT Blog

In oktober 2001 was ik voor een conferentie in Florida. Voor de terugreis moest ik reizen via Detroit, samen met een kennis die toevallig op hetzelfde moment van Miami via Detroit naar Canada zou reizen.

In Detroit aangekomen moesten we (weer) langs een veiligheidscontrole heen. Zwaar bewapende militairen hielden met hun M16 geweren toezicht op de juiste gang van zaken. Amerika was zo vlak na de aanslagen van 11 september in rep en roer, heel voorstelbaar.

We konden niet geloven wat we zagen: langs de controle gekomen liepen we langs een perron voor treintjes van een ander deel van het vliegveld. Net toen wij door de controle kwamen, arriveerde er zo'n treintje. Zodra de deuren opengingen, en de mensen uit het treintje waren gekomen, zagen we dat ook de deuren aan de andere kant van de trein open waren. We konden zó de winkels zien waar we eerder ook langsgelopen waren. We hadden helemaal niet door de controlepost hoeven gaan, we hadden alleen even bij de winkels moeten wachten op een aankomende trein, om vervolgens dóór de trein naar het beveiligde gebied te lopen.

Dit soort situaties zie je vaker: Je denkt een uitstekende beveiliging opgeworpen te hebben, met een stevige voordeur en een onbreekbaar slot. Maar als je dan de achterdeur open laat staan als je 'even op zolder iets gaat halen'', heeft dat slot plotseling veel minder zin.

Ik zou wel eens willen weten hoeveel robuuste firewalls bij bedrijven geïnstalleerd zijn, waar via een achterdeur alsnog ongewenst verkeer mogelijk is. Bijvoorbeeld men heeft voor de webserver ingesteld dat alleen met browser type XYZ toegang mogelijk is. Men realiseert zich niet dat in veel browsers aan te geven is met welk 'type'' browser bij de server wordt aangeklopt. Of er zijn mensen die op een laptop met extra netwerk-interface alsnog naar buiten weten te komen (wireless, modem, UMTS, ...). Kan er nu ook verkeer ten onrechte naar binnen?

Bij veel beveiligingen kun je je afvragen of ze er zijn om daadwerkelijk te beveiligen, of dat ze er zijn om de indruk te wekken dat men met beveiliging bezig is. En als het om het eerste gaat, laat dan alsjeblieft iemand met verstand van zaken de beveiliging installeren, want voor je het weet heb je een situatie zoals ik op het vliegveld van Detroit in 2001 aantrof...

Als de telefoon gaat omdat een klant een dringend probleem met een kritieke server heeft die gisteren al in de lucht had moeten zijn, is het voor de consultant die in de auto stapt altijd een verrassing wat hij tegen gaat komen. Hij (we gaan even uit van een hij omdat er bij ons weinig vrouwen in technische functies werken) moet beschikken over een brede bagage aan technische kennis, maar ook weten wanneer hij een collega moet bellen met meer expertise op een specifiek gebied. Hij moet bovendien onder druk kunnen werken, en nooit zomaar aannemen dat het probleem zoals de klant dat beschrijft ook het échte probleem is...

Klinkt allemaal als een open deur, maar laten we eens twee voorbeelden nemen die de beide uiteinden van het spectrum illustreren. Een klant die belt dat alle internet functionaliteit eruit ligt bijvoorbeeld. Ter plekke aangekomen bleek het probleem eenvoudig op te lossen door de stekker van het internet modem vijf seconden uit het contact te trekken en weer in te pluggen. Jammer van de reistijd, maar in ieder geval een tevreden klant.

Lastiger zijn problemen die soms optreden, of die alleen verminderde functionaliteit opleveren. Een goed voorbeeld hiervan is de klant die meldde dat de performance van zijn SSL beveiligde website zo nu en dan "schokken" vertoonde. Een snelle test leerde dat de website gedurende zo'n 'performance dip' inderdaad vrijwel onbereikbaar was, maar daarna was het gissen naar de oorzaak. De logfiles van de webserver lieten een verminderd aantal verzoeken per tijdseenheid zien, maar met de capaciteit van de internetverbinding was niets mis. Alleen het langdurig opvangen van alle verzoeken naar de webserver gaf uiteindelijk het benodigde overzicht waardoor het echte probleem duidelijk werd. Voorafgaand aan iedere "performance dip" was een duidelijke daling te zien in het aantal geslaagde SSL onderhandelingen. Toen we dit spoor nader gingen onderzoeken bleek dat de webserver een hardware encryptie kaartje gebruikte dat het afhandelen van duizenden SSL transacties tegelijkertijd mogelijk zou moeten maken. Dat kán ook, zolang het kaartje zelf geen problemen vertoont. En precies dat bleek het geval.

Totale doorlooptijd van het onderzoek: twee maanden. Wel even iets anders dan dat uurtje op en neer rijden voor het resetten van een modem. Maar de klant was tevreden en de consultant ook. Want die kan weer een stukje ervaring met het oplossen van een complex probleem in z'n spreekwoordelijke broekriem steken. En dat is wat iedere techneut stiekem heerlijk vindt.