Updates zonder cloud: hoe software veilig bijblijft in een gesloten netwerk

Ja, software kan veilig bijblijven zonder ook maar één keer met een cloud te praten. Een gesloten netwerk haalt updates niet automatisch bij een leverancier op, maar krijgt ze in een bewuste, gecontroleerde stap binnengebracht. Het pakket wordt buiten voorbereid, voorzien van een digitale handtekening die bewijst dat het echt van de maker komt en onderweg niet is geknoeid [2], en pas na controle en een test op de machine geïnstalleerd. De machine heeft daarvoor geen live internetverbinding nodig — alleen het update-bestand en de sleutel om de handtekening te verifiëren. Je levert het gemak van automatisch bijwerken in, en krijgt er controle en bewijsbaarheid voor terug: je bepaalt zelf wat er binnenkomt, wanneer, en of het is getest. De keerzijde is dat het invoerkanaal — meestal een USB-stick of een afgeschermde tussenzone — zelf een aanvalsroute wordt en dus streng beheerd moet worden [7]. Updaten in een gesloten netwerk is dus geen kwestie van "kan niet", maar van een strak proces in plaats van een automatische druk op de knop.

Het misverstand: "offline betekent nooit updaten"

Er leeft een hardnekkig idee dat een systeem zonder clouddienst per definitie vastroest op oude, lekke software. Dat klopt niet. Updates dichten beveiligingslekken en beschermen je tegen grote schade door bijvoorbeeld gijzelsoftware — dat blijft precies zo belangrijk voor een lokale opstelling als voor een clouddienst [1]. Het enige verschil is hoe de update binnenkomt.

Bij een clouddienst gebeurt dat onzichtbaar: de leverancier duwt op afstand een nieuwe versie naar je toe, vaak zonder dat je het merkt. Bij een gesloten netwerk draai je die pijl om. Jíj haalt de update op, controleert hem, en brengt hem naar binnen. Dat vraagt een handeling, maar het levert iets op wat automatisch bijwerken niet kan: je weet exact wat er op je machine terechtkomt en op welk moment. Voor omgevingen met gevoelige gegevens is dat geen ongemak maar een ontwerpkeuze.

De handtekening: hoe je weet dat een update echt is

De spil onder een veilige offline update is code signing, oftewel het digitaal ondertekenen van software. De maker berekent bij het uitbrengen een handtekening over het pakket met een geheime sleutel; jouw machine controleert die handtekening met de bijbehorende publieke sleutel. Volgens het Amerikaanse normeninstituut NIST geeft code signing de zekerheid dat software authentiek is en tijdens verspreiding en onderhoud niet is gemanipuleerd, en kan de controleur die eigenschappen bij installatie valideren [2].

Het mooie is dat die controle volledig lokaal kan. Je hebt geen verbinding met de leverancier nodig om te verifiëren dat een pakket echt van die leverancier komt — de wiskunde zit in het pakket en in de sleutel die je al hebt. Klopt de handtekening niet, bijvoorbeeld omdat iemand het bestand onderweg heeft aangepast of een nep-update heeft gemaakt, dan weigert het systeem de installatie. Zo blijft "vertrouw alleen wat aantoonbaar echt is" overeind, óók zonder internet.

De keten: van buiten voorbereiden tot binnen installeren

Een veilige offline update verloopt via een vaste keten. De kern is dat je een tussenzone maakt tussen het open internet en het gesloten netwerk, waar je updates downloadt, controleert en scant vóór je ze overzet — en dat je een eigen voorraad bijhoudt van de pakketten die je gebruikt [6]. Concreet ziet dat er zo uit:

1. Ophalen. Op een aparte, wél verbonden machine download je de update rechtstreeks bij de bron.
2. Controleren. Je verifieert de digitale handtekening en scant het pakket op malware [6][2].
3. Overzetten. Via een beheerd medium — een gecontroleerde USB-stick of een afgeschermde overdrachtsplek — breng je het pakket naar binnen [7].
4. Testen. Je installeert eerst in een testomgeving, met de mogelijkheid om terug te rollen als er iets misgaat [5].
5. Uitrollen en vastleggen. Pas na een geslaagde test installeer je in productie en leg je vast wat er is gedaan [5].

Deze aanpak is niet vrijblijvend gefröbel: NEN 7510 vraagt in de zorg juist om zo'n formeel patchbeleid met duidelijke procedures voor het beoordelen, testen en implementeren van patches, inclusief rollback-mogelijkheden en volledige documentatie [5]. Een gesloten netwerk dwingt je die discipline af te dwingen — en dat is precies het punt.

Hoe snel moet je updaten in een gesloten netwerk?

Omdat een geïsoleerd systeem niet direct aan het internet hangt, is de tijdsdruk lager dan bij een publiek bereikbare server — maar niet nul. De Britse cyberautoriteit NCSC hanteert als richtlijn dat internet-blootgestelde diensten binnen vijf dagen bijgewerkt moeten zijn, en dat voor interne of air-gapped systemen een venster van twee weken volstaat [3]. Belangrijke nuance: al die termijnen moeten fors korter zodra misbruik van een lek "welig tiert" [3]. Een gesloten netwerk koopt je dus wat lucht, geen vrijstelling.

In de zorg zie je vergelijkbare kaders terug: kritieke beveiligingspatches horen binnen vastgestelde termijnen te worden geïmplementeerd, vaak binnen 30 dagen voor hoge risico's, na een risicobeoordeling per patch [5]. De rode draad: bepaal vooraf je termijnen op basis van risico, en houd je eraan.

De valkuil: het update-kanaal als aanvalsroute

Het grootste risico bij offline updaten is het kanaal waarlangs de update binnenkomt. Zodra je een USB-stick of ander verwisselbaar medium gebruikt, wordt dat medium het geliefde doelwit. Het klassieke voorbeeld is Stuxnet: in 2010 passeerde één geïnfecteerde USB-stick de air-gap die de centrifuges van een Iraanse nucleaire installatie moest beschermen [7]. Verwisselbare media zijn daarmee niet de oplossing voor isolatie, maar juist de meest voorkomende manier om die isolatie te doorbreken [7].

De les is niet "gebruik nooit een stick", maar "beheer het invoerkanaal net zo streng als de rest". Dat betekent: vaste, geregistreerde media in plaats van willekeurige sticks, malwarescans op de tussenzone, en een handtekeningcontrole die een geknoeid of nep-pakket sowieso weigert [6][2]. De handtekening uit sectie 2 en het beheerde kanaal uit sectie 3 vangen elkaars zwakke plekken op: het medium kan besmet raken, maar een ongeldig ondertekend pakket komt er niet doorheen.

In de zorg: NEN 7510, legacy en isolatie

In zorgorganisaties komt bij dit alles de norm NEN 7510 kijken, die een formeel, risicogebaseerd patchproces verlangt [5]. Een bijkomende complicatie is verouderde apparatuur: oudere medische systemen die geen updates meer krijgen, kun je volgens het zorg-expertisecentrum Z-CERT afdekken met netwerkisolatie en compenserende maatregelen [4]. Het gesloten netwerk is daar dus niet alleen een privacykeuze, maar ook een manier om niet-patchbare systemen af te schermen — mits je de compenserende maatregelen serieus neemt.

Zo werkt het ook bij Verbinn, dat volledig lokaal draait op één Mac in je eigen pand (de Kern). Updates worden ondertekend aangeleverd en gecontroleerd geïnstalleerd, zodat de belofte "geen woord van het gesprek verlaat de organisatie" ook tijdens het bijwerken overeind blijft: de machine blijft draaien als je hem van het netwerk loskoppelt. Wil je weten waarom die ene Mac genoeg rekenkracht heeft voor een hele organisatie, lees dan Waarom een Mac Mini genoeg is voor een hele zorgorganisatie. En voor de vraag hoe nauwkeurig de spraakherkenning op zo'n machine is, zie Hoe goed is spraakherkenning op een Mac Mini?.