Hét proces voor het op orde houden van de updates op al je machines. In elke norm voor informatiebeveiliging (ISO27001, BIR, BIG, NEN7510) komt patching terug en ook bij de DigiD-audit wordt de patching gecontroleerd. Hoe kan je in jouw organisatie ook dit proces voldoende op orde krijgen? Hier kies ik bewust voor de term proces omdat het een herhaalbare hoeveelheid aan gestructureerde stappen betreft die een start en een eind vormen en welke eindeloos herhaalt kunnen worden. Dit is tevens een van de processen waar een IT-auditor vaak naar op zoek is. Dit geeft een bepaalde zekerheid voor de beheersing en veiligheid binnen de IT-organisatie als dit aantoonbaar op orde is.

Patching: Techniek

Ik ben geen technisch specialist, maar conceptueel kan ik het prima uitleggen. Het gaat over het bijwerken van de programmatuur/code op elk apparaat wat de organisatie:

• in bezit heeft
• gebruikt voor de verwerking van informatie
• anderszins een verantwoordelijkheid voor draagt

Deze moeten continu voorzien worden van de juiste software/firmware. Dit gaat dus verder dan alleen de Windows-servers! Dit omvat ook de drivers van de (fysieke) servers, de firmware in de routers en de software op de werkplekken van de eindgebruiker. Vergeet ook niet de beheersystemen voor de beveiliging, bewaking en/of klimaatbeheersing. Hier zie je dus direct een zeer duidelijke relatie met het configuratiemanagementproces, je CMDB.

Daarnaast betekent dit dus ook dat je elke (software) leverancier van specifieke apparatuur, of uitbestede IT-dienstverlening, hierop kan aanspreken. Tevens zal in een contract hierover een sectie opgenomen moeten worden waarin afspraken over en weer belegd worden rondom dit proces. Denk bijvoorbeeld aan de acute beveiligingsproblemen wanneer een technische zwakheid wordt gevonden, of periodiek technisch onderhoud.

Patching: Controleproces

Zoals bij de inleiding al benoemd is het patchen een proces. Het (technische) uitvoerende werk zelf is uitvoerig beschreven in een procesframework als bijvoorbeeld ITIL. Of zie het NCSC whitepaper (Whitepaper Patchmanagement) als bijlage. Hier ga ik verder niet op in. Zelf wil het hebben over het meta-proces wat hierboven ligt. De controle en beheersing van dit proces. Het patchingproces is een proces wat prima vanuit een plan-do-check-act benadering aangepakt kan worden. Specifiek in deze blog wil ik hier de focus leggen op de do- en de check-stap.

Voor do-stap geldt dat het klakkeloos installeren op de productie-omgeving van alle patches waarschijnlijk niet de juiste manier is. Dit zal beoordeeld en (beperkt?) getest moeten worden voordat een dergelijke pleister geplakt wordt. Hierbij zal je dus gebruik gaan maken van het voortbrengingsproces en change management. Vanuit het patchen van de ontwikkel- en test-omgeving kan doorgegaan worden naar de acceptatieomgeving. Indien hier alles doorgetest is kan uiteindelijk de patch op productie geïnstalleerd worden.

Daarom is een van mijn stelregels altijd:

• Als je geen standaard hebt moet je alles behandelen als een uitzondering.
• Heb je een standaard, dan kan je uitzonderingen gaan managen

Voor de check stap is het van belang dat er interne controles, inclusief bijhorende (management)rapportage, ingericht worden waaruit blijkt dat de hier bovenstaande stelregel gehanteerd is. Dit zal veelal resulteren in een dashboard waar per categorie objecten een inzicht gegeven wordt in welke mate de patching op orde is. Hierbij horen de toetsvragen voor de kwaliteit. Het gaat daarbij om de woorden juiste en alle:

• Welke patches moeten op de machine aanwezig zijn wil deze veilig genoeg zijn.
• Elke machine moet voorzien van patches. In een keten is een maatregel zo sterk als de zwakste schakel.

Uitdaging: Governance

Waarom hebben organisaties hier problemen mee? Vaak begint dit vanuit een probleem in de governance. Vanuit de demand/supply-gedachte is de IT-afdeling randvoorwaardelijk in een organisatie en kan de business aangeven wat zij van deze afdeling verlangt, wenst en eist. Hier zal een dialoog gevoerd moeten worden. De discussie die op gang zal moeten komen zal gaan over het vernieuwen/innoveren versus beheren/onderhouden. Bij deze laatste component dient onder andere het aspect beveiliging aan bod te komen, inclusief het hierboven genoemde proces patching. Het is geen gekke gedachte om een service level agreement (SLA) tussen business en IT af te spreken met daarin KPI’s over de na te leven kwaliteit van de verschillende processen en onderdelen.

Tot slot: Specifiek voor de uitbraak van de Wanacry-malware had je dus alleen die patch van 2 maanden geleden even moeten installeren. Meer niet. Soms kan informatiebeveiliging zo simpel zijn.