How fast can you patch

Uit een onderzoek van Google Mandiant zie je de tijdspanne tussen vinden van een zwakheid en het misbruiken steeds korter wordt.

Je kan je dan afvragen ..”moet ik nog sneller patchen .. hoe kan ik alles nog steeds goed testen”.  Echter hoe langer je wacht en ‘security updates’ stapelt, hoe groter de kans op verstoring en een misbruik van een kwetsbaarheid.

Dit betekent dat je eigenlijk een ander strategie moet bezien, het traditionele monoliet (op één server alles installeren) is niet werkbaar en vergt veel onderhoud. Aantal oplossingsrichtingen:

  1. Breek servers op in lagen (client, front-end, applicatie en database). Hierdoor creëer je naast flexibiliteit en wordt de kans op conflicterende updates kleiner
  2. Zorg dat je client, front-end en applicaties stateless zijn. Stateless is dat er geen data op de servers staan, vuistregel “als je de front-end server weggooit, verlies je dan bedrijfsdata (niet verwarren met config bestanden)?”
  3. Automatiseer zodanig dat de servers snel opnieuw geïnstalleerd kunnen worden. Zodat je bij een nieuwe security update snel een server kan uitrollen
  4. Infra as a code, het is een methodiek wat vaker voorkoment. Je gaat van traditionele server (virtuele hardware, besturingssysteem, applicatie) naar stukje code wat draait op een server. De servers van punt 2 worden in ‘het stukje code’ gevangen. Een nieuwe uitrol is dan niet meer dan code ipv nieuwe virtuele server etc.
  5. Zorg voor goede lifecycle, het doorvoeren van veranderingen en stem goed af dat dit het nieuwe ‘way of work is’

Vele zullen zeggen…“dat hebben wel al” en is “allang bekend”, dan zeg ik “prima, dat is dan mooi”. Voor degene die er midden zitten en afvragen “hoe zorg dat de gehele organisatie zich hieraan committeert”, dan zeg ik “je weet me te vinden”

How fast can you patch