Security (b)log: testen

vrijdag 7 april 2023

Opstap

Afbeelding via Pixabay

Iedere ICT’er weet dat je, als je iets hebt gemaakt of gewijzigd, eerst moet testen of alles (alles!) nog werkt. In een professionele omgeving hebben we daar een meertraps mechanisme voor, dat we koesteren onder de afkorting OTAP: Ontwikkel, Test, Acceptatie, Productie. Deze week hoorde ik een variant op deze afkorting die mij eerst met de oren deed klapperen en die daarna een brede grijns op mijn gezicht veroorzaakte.

Die variant is OPSTAP en dat staat voor: Ontwikkel, Productie, Shit het werkt niet, Toch maar testen, Acceptatie, Productie. Ik hoorde dit tijdens een risicoanalyse. In zo’n sessie bespreken we wat er allemaal fout kan gaan en hoe erg dat is, en een van de vaste onderwerpen daarbij is: iemand maakt een fout, welke maatregelen zijn er genomen om ervoor te zorgen dat dit tijdig wordt ontdekt en dus geen schade kan veroorzaken? Bij alle risicoanalyses die ik tot nu toe heb begeleid – en dat zijn er heel wat – riepen de aanwezigen op dit punt triomfantelijk in koor: OTAP!

En daarmee was eigenlijk alles gezegd. We ontwikkelen iets, we doen een degelijke test, de klant doet een acceptatietest en pas als iedereen tevreden is, gaat het nieuwe systeem of de nieuwe versie in productie. Als er nog fouten aan het licht komen, dan gaat het product terug naar de ontwikkelfase. Een degelijke werkwijze die in het DNA van alle ICT’ers zit en die zo vanzelfsprekend is dat we ons zelden afvragen of een team écht áltijd op deze wijze werkt. Of dat er, soms of misschien zelfs structureel, afkortingen worden genomen.

Vanzelfsprekend, tot deze week dus. Na al die jaren durfde eindelijk iemand uit te spreken dat het kennelijk wel eens voorkomt – en niet eens noodzakelijkerwijze bij hemzelf, denk ik – dat er geitenpaadjes worden genomen. Het kon eigenlijk ook niet anders hè. Ik weet ook wel dat de druk om iets op tijd op te leveren soms zo groot kan zijn, dat je een keuze moet maken tussen op tijd klaar zijn of netjes de officiële route volgen. Kies je voor het eerste, dan zit je als consciëntieuze medewerker vervolgens een paar dagen of weken met dichtgeknepen billen te wachten of het allemaal wel goed blijft gaan.

Naarmate je vaker zo’n afkorting neemt, word je daar misschien wat gemakkelijker in. En dan zou het wel eens link kunnen worden. Je begeeft je dan op een glijdend pad naar onachtzaamheid, misschien zelfs onverschilligheid. In een organisatie, die zo groot is als de onze, kan ik overigens niet uitsluiten dat er ook enkele collega’s rondlopen die nooit bovenaan dan glijdende pad hebben gestaan, die van nature altijd de gemakkelijkste weg kiezen. Ik ken veel collega’s, en ik heb er nog geen één ontmoet waarvan ik dacht: daar heb je er zo eentje. Maar statistisch kan ik niet uitsluiten dat ze er zijn. Misschien verblijven ze in de luwte van hun team en worden ze bijvoorbeeld niet gevraagd om mee te doen aan risicoanalyses en andere activiteiten waarbij ik betrokken ben. Tegen deze mensen – en hun managers – wil ik zeggen: recht je rug, sta voor je vakmanschap en zorg daarmee dat je niet zelf een risico voor onze bedrijfsvoering wordt. Misschien heb je wel een (opfris)cursus nodig. Of – wees eerlijk tegen jezelf – ander werk.

Ik heb hier ook van geleerd. Ik word strenger. Nog meer dan nu ga ik doorvragen, ook als ik collega’s spreek waarvan ik met zekerheid weet dat ze heel erg begaan zijn met security. Doe je het echt altijd op deze manier, of ga je heel soms OPSTAP? Als je dat durft toe te geven, dan verdien je daar bonuspunten mee. Want je zegt ermee dat er misschien ergens een risico zou kunnen zitten, en daar kunnen we alleen iets aan doen als we het weten. Het markeert ook het verschil tussen risico’s lopen (dat gebeurt onbewust) en risico’s nemen (bewust en op basis van afwegingen).

Ten slotte vanaf deze plek nog even een speciale groet aan een van mijn trouwste lezers: mijn moeder. Ze is vandaag negentig geworden. Van harte gefeliciteerd!

En in de grote boze buitenwereld …

vrijdag 25 maart 2022

WC-rol

Afbeelding via Pixabay

Na twee jaar gaan we weer mondjesmaat naar kantoor. En daar had zich een verandering voltrokken die je niet had zien aankomen. Er waren nieuwe toiletrolhouders geïnstalleerd.

Even voor kantoorloze lezers: zo’n houder is niet het eenvoudige dingetje dat bij jou en bij mij thuis hangt, maar een gesloten doos met een gleuf onderaan de voorkant. In de doos zitten twee rollen boven elkaar en het papier komt door de gleuf naar buiten. Althans, dat is de bedoeling. Maar daar gaat het bij deze nieuwe dingen nou precies mis. De rollen ondervinden teveel wrijving. Als je aan het papier trekt, dan scheurt het af – binnen in de houder. Waardoor je iedere keer opnieuw op zoek moet naar het begin door je vinger in de houder te steken en de rol moeizaam rond te draaien – vaak meerdere keren – tot je het uiteinde van het papier te pakken hebt. En dan voorzichtig trekken, want voor je het weet scheurt het wéér af. Soms heb je opeens de uiteinden van beide rollen te pakken en ervaar je de luxe van dubbellaags wc-papier.

Er is een fabrikant die deze dingen maakt. Niet zomaar uit het niets, maar volgens een ontwerp. Ze maken er eerst eens eentje, of een handjevol: de prototypes. Die worden getest, er komen een paar kinderziektes aan het licht, het ontwerp wordt aangepast, er komt een nieuw prototype en uiteindelijk (na misschien nog een paar iteraties) is de houder rijp voor productie.

Waar ging het bij dit product zo vreselijk mis? Hebben ze alleen onder laboratoriumomstandigheden getest? Is niemand op het idee gekomen om een prototype aan de muur te schroeven, er twee rollen wc-papier in te doen, op de pot te gaan zitten en volgens de een of andere Europese norm dan wel naar behoefte papier te gebruiken? Kortom, is er geen veldtest gedaan?

Maar ook aan onze kant ging het mis. Het zal wel een rijksbrede aanbesteding zijn geweest. Daarbij wordt gekeken welke offerte, die aan de vooraf opgestelde eisen voldoet, de goedkoopste oplossing biedt. Misschien zijn de inkopers vergeten om als eis op te nemen dat het papier er soepel uit moet komen. En ik vraag me af hoe de acceptatietest is uitgevoerd.

Jaren geleden hebben we een softwarepakket aangeschaft om ons information security management system (ISMS) te beheren. Het leek een geweldig product en we gingen met een paar man op cursus bij de fabrikant. We zagen een product met een heldere structuur en we konden alle oefenopdrachten soepeltjes uitvoeren. En toen moesten we het product in onze organisatie implementeren. Het lukte maar niet om onze inrichting te verenigen met die van het product. Ik heb toen zelfs nog het datamodel van het product ge-reverse-engineered*, met andere woorden: ik heb uitgetekend hoe het product in elkaar zat. Vervolgens hebben we geprobeerd om onze organisatie en onze werkwijze hierop te plotten. We hebben een paar keer de fabrikant erbij gehaald en na zo’n consult dachten we telkens dat we het hadden gevonden. Uiteindelijk hebben we het opgegeven en tot op de dag van vandaag werken we met de oude, vertrouwde spreadsheets.

Daar is overigens niets mis mee. Op een conferentie vroeg een spreker eens wie er allemaal Excel gebruikte voor dit soort dingen. Talrijke handen gingen omhoog en daar werd besmuikt bij gelachen. Tegelijkertijd golfde een gevoel van opluchting door de zaal omdat in één klap duidelijk werd dat het helemaal niet ongebruikelijk was om zo te werken. Soms heb je nu eenmaal functionele behoeftes die je niet goed kunt uitdrukken in eisen en wensen en waar je om die reden geen inkooptraject voor kunt starten. Je gaat dan zelf wat knutselen of je leent iets wat ze elders hebben gemaakt. Qua beheer is dit overigens een nachtmerrie: als zo’n zelfgemaakte tool ingeburgerd raakt en de maker ervan is niet meer beschikbaar, dan heb je een probleem.

Ik heb zelf ook zoiets in elkaar geknutseld. En om mijn collega’s niet met de handen in het haar te laten zitten als ik onder de tram mocht komen, heb ik daar een technische handleiding bij gemaakt, die precies beschrijft hoe het er onder motorkap van mijn spreadsheet aan toe gaat. Of ze daar ook mee uit de voeten kunnen, moet op het uur U blijken. Want we zijn natuurlijk veel te druk om zoiets te testen. Bovendien weet niemand waar de handleiding staat. Ruimte voor verbetering dus. Hoe zit dat eigenlijk bij jou? Is de continuïteit van de belangrijke hulpmiddelen van jouw team gewaarborgd?

*) Reverse engineering houdt in dat je kijkt hoe iets werkt en daaruit afleidt hoe het is ontworpen.