Staying ahead: over veilig vliegen en het belang van ‘vooruit denken en werken’ deel 2

In mijn vorige blog maakte ik de vergelijking tussen de werkdruk van een piloot en een IT-er. Verschillende disciplines kunnen immers altijd van elkaar leren. In de opleiding van een piloot en in de cockpit is alles gericht op de beheersbaarheid van werkdruk. Zodat je tijd en aandacht hebt op de momenten waarop het echt even spannend wordt.

Die houding hebben we in IT nog niet genoeg ontwikkeld. Ook daar gaan ontwikkelingen razendsnel en zijn er – zeker op security gebied en in mission critical omgevingen – echt momenten waarop je te weinig tijd hebt om efficiënt en effectief te acteren. Ondanks of misschien wel juist door alle hulpmiddelen (‘tools’) en dashboards die (te) veel informatie geven.

Patch management is hiervan een mooi voorbeeld. Meestal kennen we prima de patch-status van onze infrastructuur en apparatuur. Maar toch lopen we te vaak, te ver achter. Dat is niet alleen bijzonder, maar dat is ook raar. Houding: we weten dus dat we extra kwetsbaar zijn en dat we extra werk gaan krijgen op momenten dat we al druk zijn; bijvoorbeeld als kwetsbaarheden echt worden misbruikt (exploits), maar we acteren toch niet of onvoldoende.

Ik heb me lang afgevraagd waarom dat zo is. Je weet immers dat je toch een keer moet patchen? Waarom dan niet gelijk?

Voorbeelden van - te vaak - gehoorde argumenten zijn…

1. ‘We patchen conform het contract met onze opdrachtgever, dus we zijn compliant.’
Toch maar weer die vergelijking met vliegen; we gaan gewoon vertrekken al zijn we kwetsbaar, want op papier is alles oké. Gelukkig ben je in de luchtvaart al wat sneller ‘niet compliant’. Want ook op papier zit men er daar, na veel lessons learned, gelukkig zero-tolerant in. Als je niet snel patches installeert, omdat je opdrachtgever dat eist doe het dan voor je eigen nachtrust!

2. ‘We hebben toch meer bescherming? Security-in-depth?
Security-in-depth is het op verschillende manieren en in verschillende systeemlagen bescherming in te bouwen. Zinvol en nuttig, maar geen excuus om het verhelpen van kwetsbaarheden in één of meerdere systeemlagen uit te stellen. Zo verzwak je voor je het weet je infrastructuur en vergroot je onnodig risico’s. Geloof me, in de luchtvaart is alles redundant uitgevoerd. Maar als er iets extra’s niet werkt dan is dat al snel een reden om niet te vertrekken. Omdat je gewoon te kwetsbaar bent en de risico’s veel te groot zijn!

3. ‘We moeten eerst uitgebreid testen om te kijken of de patch andere systemen en applicaties niet verstoort.’
Oké, tot een paar jaar geleden vond ik dit een valide argument. Maar leveranciers hebben op dit gebied enorme stappen gemaakt. Security is riskmanagement. Wat mij betreft zijn de risico’s van niet snel patchen vele malen groter dan het risico dat een systeem door de patch omvalt. Dat zijn echt incidenten geworden; misschien moeten we toch wat meer vertrouwen hebben? De grootste kans dat het mis gaat is in omgevingen waar asset & system life cycle management niet goed voor elkaar is. Als je in de keten verouderde en soms zelfs end-of-support hard- of software gebruikt. Dan heb ik als security professional nog steeds liever dat iets omvalt tijdens een geplande change met ‘roll back’ scenario dan onverwachts als gevolg van uitstel van de update. En ja, vervangen van systemen en software kost geld; maar een kaartenhuis zorgt ook niet echt voor ‘Nachtrust as a Service’.

Ik wil de inspanning en complexiteit van patch management echt niet onderschatten. Maar als je dingen uiteindelijk toch moet doen; doe ze dan zo snel mogelijk! Dat is staying ahead of the airplane en maakt je IT-infrastructuur een stuk minder kwetsbaar. Steeds vaker is IT ‘mission critical’ en hangen ook echt levens af van de betrouwbaarheid en beschikbaarheid.

Dat is geen kwestie van techniek meer; die is er echt wel. Het is vooral een kwestie van houding van mensen; opdrachtgevers en opdrachtnemers die verantwoordelijk zijn voor, een zo veilig mogelijke, IT-omgeving.

Overtuigd als ‘beheerder’? Mooi, in mijn volgende blog schrijf ik over de rol van ontwikkelaars en eindgebruikers op dit vlak.