Het ministerie van Defensie bevestigt dat de oorzaak van de storing in de toegangsverlening tot het Nafin-netwerk (Netherlands Armed Forces Integrated Network) lag. Nadat gisteren ministeries en overheidsdiensten grote hinder ondervonden en zelfs heel Airport Eindhoven platging, opperden enkele experts al dat de complicatie zich daar verscholen hield.
Door een softwarefout is een probleem ontstaan in de tijdsynchronisatie op het netwerk, schrijft minister Ruben Brekelmans (Defensie) aan de Tweede Kamer. In verband met de beveiliging kent Nafin een systeem voor identity and access management (iam) die op tijd gebaseerde toegangscontrole ondersteunt. Dit stelt de organisaties die op Nafin vertrouwen in staat om de toegang te beperken op basis van bepaalde tijdscriteria, zoals werkuren of specifieke dagen. Als een ambtenaar bijvoorbeeld nooit ‘s nachts of op zondag werkt, zal het systeem hem of haar in die tijdvakken geen toegang geven. Het inloggen werkt dan niet. Ook komt het voor dat gekoppelde systemen alleen in bepaalde perioden aan elkaar data doorsturen. Maar als de klokken op betrokken systemen niet synchroon lopen, ontstaan problemen. Daardoor konden ambtenaren en medewerkers van organisaties als Eindhoven Airport gisteren geen verbinding maken met dit zwaar beveiligde netwerk.
Volgens Defensie is er vooralsnog geen indicatie dat een (staats)hacker of andere kwaadwillende partij de storing heeft veroorzaakt. Dat Defensie het woord ‘vooralsnog’ gebruikt, duidt erop dat dit toch niet helemaal wordt uitgesloten. Defensie zal de storing met betrokken partijen evalueren.
Commando
Bij Nafin zijn meerdere bedrijven betrokken. KPN is juridisch eigenaar van het netwerk. Het beheer zit bij het Joint Informatievoorziening Commando (JIVC), het it-bedrijf van Defensie. De PTT leverde het netwerk oorspronkelijk op. KPN en Nortel hebben langlopende contracten voor het onderhoud. Anders dan gisteren gesteld, staan Atos en IBM buiten deze publiek-private samenwerking.
Bij het 25-jarig jubileum van Nafin stelde Ger Vrolijk, account manager van KPN, vijf jaar geleden dat het netwerk is uitgegroeid tot de ‘ruggengraat van de rijksoverheid’. Frank Lokhorst, productverantwoordelijke bij de Defensie Materieel Organisatie (DMO), inmiddels Commando Materieel en IT geheten, sprak bij die gelegenheid van een ‘robuust systeem’ waarbij alles dubbel is uitgevoerd. ‘Verbinding met het netwerk is net zo vanzelfsprekend als gas, water en licht,’ zei hij. Maar gisteren werkte de ‘lichtknop’ even niet.
Eerder waren er al zorgen over de kwetsbaarheid van Nafin. De Algemene Rekenkamer onderzoekt sinds eind 2023 welke maatregelen het ministerie van Defensie treft om Nafin weerbaar te maken tegen cyberaanvallen. Dat onderzoek moet volgens de planning in november van dit jaar gepresenteerd worden.
Als de oorzaak van verstoring in de tijdssynchronisatie zit dan lijkt me ergens een basale fout gemaakt te zijn omdat dit cruciaal is voor de beveiliging.
Dan ben ik benieuwd op welke laag dat dan geïmplementeerd is. Ze zullen toch hopelijk indertijd niet zelf iets op de transport- of netwerklaag gebakken hebben?
als afgesproken uptime en rpo/rto en niet bekend zijn weet je natuurlijk nooit of het systeem heeft voldaan.
Tot nu las ik alleen dat ze zo hun best deden om het te fixen.. Best effort heet dat in SLA termen.
Veel access bijv op basis van kerberos, heeft idd een sterke afhankelijkheid met tijd.
Dubbel uitvoeren en robuust is ook betrekkelijk. Robuust als er 1tje onderuit gaat, maar een 2e vloert het hele systeem.
“‘Verbinding met het netwerk is net zo vanzelfsprekend als gas, water en licht,’ zei hij. Maar gisteren werkte de ‘lichtknop’ even niet.” Fijn, daar kunnen we verder mee.
Was die update wel in een juiste testomgeving getest?
Niet alleen Kerberos is tijdsafhankelijk Dino want ook veel logging loopt er op stuk. Twee klokken maar niet dezelfde tijd lijkt me een replay van een ander probleem want het kan ook gewoon een verlopen certificaat zijn. Vooralsnog zullen we gewoon moeten wachten wat er boven komt drijven maar RPO/RTO hebben er niet veel mee te maken als ik kijk naar één kill switch in het netwerk.
Het zal waarschijnlijk Radius geweest zijn. In dat geval is interessant hoeveel NTP-peers ze hebben en waar. En wat er met NTP fout is gegaan.
Misschien hadden ze NTP-hosts zelf ook per ongeluk verbonden staan onder een regime van Radius-instellingen. Dat zou een hoop verklaren. ?