Minister: storing bij Nederlandse Defensie werd veroorzaakt door softwarefout

De computerstoring bij de Nederlandse Defensie, die woensdag meerdere overheidsdiensten trof, werd veroorzaakt door een softwarefout op een van de IT-netwerken van Defensie. Dat schrijft minister Ruben Brekelmans van Defensie in een brief aan de Tweede Kamer.

"De oorzaak van het probleem lag in de toegangsverlening tot het zogeheten Netherlands Armed Forces Integrated Network", schrijft Brekelmans in zijn brief. Nafin is een eigen glasvezelnetwerk van Defensie. Het gesloten netwerk is zo'n 3300 kilometer lang en verbindt onder meer defensielocaties, politielocaties en ministeries en hun datacenters met elkaar. Een fout in de softwarecode zorgde voor een probleem in de tijdsynchronisatie op het netwerk, waardoor het niet mogelijk was om verbinding te maken met het netwerk, aldus de minister. "Er is vooralsnog geen indicatie dat de storing is veroorzaakt door een kwaadwillende partij." Tweakers schreef eerder een artikel over hoe de Nederlandse overheidsdiensten samenwerken over het Defensie-netwerk.

De storing had volgens de minister effecten op de vaste verbinding, mail en telefonie. Naast Defensie zelf hadden ook overheidsdiensten als DigiD, de Kustwacht en de Marechaussee last van problemen. Daarnaast hadden hulpdiensten zoals de politie last van de storing. Alarmnummer 112 werd niet getroffen en bleef gewoon bereikbaar. "Ondanks al dit ongemak konden veel processen binnen en buiten Defensie wel gewoon doorgang vinden en is de veiligheid niet in het gedrang geweest", aldus Brekelmans.

Eindhoven Airport had ook last van de storing bij Defensie. Dit civiele vliegveld bevindt zich op de militaire vliegbasis Eindhoven, die onder het beheer van Defensie valt. Als gevolg van de storing ondervond de luchtverkeersleiding op het vliegveld hinder, waardoor de afhandeling van vluchten vertraagd raakte.

De problemen begonnen dinsdag al rond 22.00 uur. Brekelmans schrijft in zijn brief, die hij woensdagavond naar de Tweede Kamer verstuurde, dat de externe dienstverlening inmiddels weer grotendeels op orde is. "De komende uren worden de laatste stappen gezet om systemen volledig te laten functioneren. Defensie monitort dit uiteraard nauwgezet." Als alles weer werkt, gaat Defensie met andere betrokkenen de storing en de weerbaarheid van de IT-systemen evalueren.

Reacties (145)

[xxs]

Geen SSL verbindingen op kunnen zetten doordat de klokken te ver uit sync waren?????

[the_stickie]

Kerberos is ook tijdafhankelijk, net zoals heel wat andere authenticatie/autorisatie protocollen

[kr4t0s]

One Time Password oplossingen ook. Daar is vaak time drift maximaal 30 seconden. Bij Kerberos is het 5 minuten. Als jou client tijd teveel afwijkt ten opzichte van de server kun je nooit autoriseren ook al probeer je in te loggen met correcte gebruikersnaam, wachtwoord en OTP code.
En het duurt inderdaad ongeveer een dag om weer in sync te komen.
Quick fix voor Microsoft kan zijn om die default van 5 min tijdelijk langer te zetten op bijvoorbeeld 30 min in de GPO.

Als tijd voorloopt kun je niet alle klokken weer gelijk zetten. Dan gaat heel veel stuk, databases vooral vinden dat niet leuk dat er opeens data in de toekomst al staat. Dus NTP brengt de klokken dan heel langzaam in sync wat ongeveer en dag duurt.

Lijkt op een een menselijk fout, dat ze NTP niet goed geconfigureerd hebben. Of te weinig NTP servers, of NTP servers waren down of niet bereikbaar. NTP wordt vaak 1x geconfigureerd en dan kijkt men er 10 jaar niet meer naar om. Even agenda reminder aanmaken voor beheer om dat eens in de 3 maanden te controleren.

In de AD server logs zie je dan ook errors met "Clock skew too great"
Bron:
https://learn.microsoft.c...ter-clock-synchronization

[Reactie gewijzigd door kr4t0s op 29 augustus 2024 12:51]

[ANdrode]

Wij hebben een NTP appliance die recent een failure had. Onze NTP appliance heeft een GNSS (GPS) antenne en heeft een voorkeur voor deze klok boven de atoomklok en backup klok die er in zit.

Bij een netwerk operator presentatie heb ik een presentatie gezien van hoe de tijd weg kan lopen tov de referentie als je geen GNSS gebruikt.

Dit kan erg rare failures veroorzaken als je niet genoeg redundantie in je NTP (of eigenlijk, NTPS) setup hebt.

(PTP ken ik niet goed genoeg)

[Jerie]

GPS is eenvoudig te jammen (iets moeilijker te spoofen maar het kan). Dus dat lijkt me voor deze toepassing niet wenselijk.

[ANdrode]

Precies.

Wij werden gered door onze GNSS antenne. Als je dat niet gebruikt (wat ook niet zou moeten in deze use case) ben je vatbaarder voor defecten aan je NTP appliance.

[toxict]

Daar hebben ze monitoring voor uitgevonden.
Zaken die je installeert, zet je in de monitoring, zodat je daar niet meer naar om hoeft te kijken.
En als er iets fout gaat, dan krijg je meldingen; het liefst, voordat zaken echt stuk zijn, zodat je nog in kan grijpen.
Helaas kom ik maar al te vaak tegen bij bedrijven dat men monitoring maar "lastig" vind.
Systeembeheerders die vinden dat een simpele ping genoeg is. KOEKOEK!

[GeroldM]

Voor zover ik het begrepen heb is het NTP protocol een toekomstig groot probleem. En niet in de verre toekomst, maar eentje die nog maar enkele jaren is verwijderd.

Het technische brein achter de standaard/protocol begint al heel oud te worden en er zijn geen opvolgers. Niet omdat deze persoon dat afhoudt, maar omdat er niemand in is geïnteresseerd om de stok over te nemen. Terwijl het dus wel een heel belangrijk protocol is. En heel wat gecompliceerder dan dat het op het eerste gezicht lijkt.

[kr4t0s]

Valt wel mee volgens mij is ontwikkeling is in handen van Internet Engineering Task Force (IETF)

v5 draft is er nu.
https://datatracker.ietf....f-ntp-ntpv5-requirements/

Zijn ook andere tijdsprotocollen als PTP en TSN maar die zijn niet breed geïmplementeerd.

[mmarlon]

Wij zijn actief bezig met de (open source) doorontwikkeling van NTP met o.a. NTS en NTP v. 5
https://tweedegolf.nl/en/pendulum

[emansom]

TLS hoop ik

[xxs]

In mijn spreektaal is het nog steeds ssl maar je hebt gelijk. Inmiddels zijn er al betere en uitgebreidere reacties maar het lijkt erop dat het niet in sync zijn van klokken ‘de authenticatie’ in de weg zat.

[DiedX]

Als je de certificaten niet kan controleren op geldigheid, dan krijg je dat

[the_stickie]

Een 'softwarefout' in ntp? Sterk.
Een configuratiefout die ntp beïnvloedt, lijkt me waarschijnlijker. Een foute firewall rule, een gewijzigd dns record, een service die stopte... Allemaal plausibel, maar natuurlijk minder strakke PR

[Reactie gewijzigd door the_stickie op 29 augustus 2024 08:50]

[dasiro]

politici babbelen maar na wat hen ingefluisterd is en hun uitleg wijkt soms wat af, waardoor je van die rare uitspraken krijgt, wat wel weer vreemd is nu het om een brief (worden die dingen echt nog op papier gestuurd??) gaat.

[field33P]

De minister schrijft zelf doorgaans de brief niet, die leest in grote lijnen door en ondertekent.

En de Kamer wil per brief geïnformeerd worden, dus gaat het per brief. Nu schat ik in dat het tegenwoordig grotendeels per mail gestuurd wordt uit gemak.

[Frank Kroon]

Papier is betrouwbaarder dan de email, deze werkte deels ook niet tijdens de storing.

[leefa]

Communicatie van een departement naar het parlement gaat feitelijk door toezending per email van het document. Dat moet namelijk omgezet worden naar een Kamerstuk dus wil je een elektronische versie hebben. Daarnaast wordt er voor de vorm nog een papieren versie met natte handtekening verzonden maar daar kijkt eigenlijk alleen de archivaris naar.

[RobVI]

Het certificaat van een NTS server (Secure NTP) zou verlopen kunnen zijn...

[ANdrode]

Dan moeten de andere klokken nog voldoende desynchroniseren om problemen te veroorzaken. Dat duurt even.

Ben het wel met je eens dat certificaten voor NTPS één van de weinige redenen zijn om je NTP referentie te verliezen. Want normaal meet je tov minimaal drie klokken zodat je één clock met veel drift kan uitsluiten.

[Gazuhl]

Zou ook noeteen gekke uitleg zijn. Omdat dat even duurt ga je verschil zien in wanneer systemen uit beginnen te vallen. De eerste uitval wordt dan nog niet zo snel bemerkt of niet kritiek ingeschat. Naarmate tijd verstrijkt (heerlijk) vallen er steeds meer systemen uit omdat ze uit de pas lopen, maar dan is het nog wel random genoeg dat je niet direkt een oorzaak aan kan wijzen. Past wel in het verloop dat we hebben gezien

[novastorm76]

Op zich is desynchronisatie wel goed te tackelen. Ik heb destijds een checker gemaakt voor in een monitoring systeem die alle NTP tijden met elkaar vergelijkte en wanneer er meer verschil dan X tijd was, dan ging er een alarm af. Dus het is makkelijk te tackelen voor niet al te veel moeite

[Guru Evi]

Zou me niet verwonderen dat dit een SPOF is. Iedereen kijkt naar dezelfde klok en voor veiligheidsredenen enkel 1 geconfigureerd. Maar dan toch, het kristalletje in je computer is relatief precies, ik krijg een alert als een klok een 30 seconden verschilt van de referentie maar dat kan soms 3 of 4 jaar duren van systemen die al die tijd verkeerd geconfigureerd waren alvorens dit alert tevoorschijn komt.

[Reactie gewijzigd door Guru Evi op 29 augustus 2024 19:50]

[ANdrode]

Het is goed te monitoren maar je moet het wel doen. Wat het verhaal voor mij gek maakt. Skill issues zijn geen goede verklaring bij zo'n kritisch netwerk.

Het zou kunnen dat de timing veel preciezer komt. Denk aan time division multiplexing. Dat doe je alleen vooral bij radio (of many to one, zoals bij docsis). Niet bij een fiber backbone.

[the_stickie]

Ook niet de beste PR

[thehighnotes]

Tech geeft het door aan management, die geeft het door aan PR en dan krijg je dit. Ik sluit ook niet uit dat ze intern de mogelijkheid van een kwaadwillende zeer grondig onderzoeken.

[CAPSLOCK2000]

Een 'softwarefout' in ntp? Sterk.

Ik denk dat hij vooral bedoelt dat het geen militaire aanval is, de regering/het leger niet is gehacked en er ook geen bommen zijn ontploft of zo iets.. Het is een geruststelling dat het land veilig is, geen inhoudelijke uitleg van het probleem.

[Speleding]

"Een fout in de software code". Lijkt me contaminatie van "broncode" en "software", dus duidelijk door iemand geschreven die niet erg met de materie bekend is. Kan dus nog steeds van alles zijn, lijkt me.

[Triblade_8472]

Wat ik héél graag zou willen weten, is hoe een software fout\tijdsync issue de rest vna het netwerk onderuit kan halen. Als ik een fout lopende server heb, dan is de rest gewoon nog werkend.

Wat duidelijker stellen:
Wat ik héél graag zou willen weten, is hoe een software fout\tijdsync issue bij Defensie de netwerken van andere diensten onderuit kan halen.

Wat ik mij wel kan voorstellen is dat ze een configuratiefout in netwerkapparatuur bedoelen, waar hun apparatuur belangrijk is voor de Haagse Ring. Maar dan zouden ze dat toch schrijven...?

Wel vindt ik dat de impact niet goed genoeg benoemd wordt. Zaken als het RiVG en DigiD zijn best wel heel belangrijk en naar mijn mening noemenswaardiger dan Eindhoven Airport (al schreeuwde de mensen daar het hardst).

[Reactie gewijzigd door Triblade_8472 op 29 augustus 2024 08:50]

[bzzzt]

Wat ik héél graag zou willen weten, is hoe een software fout\tijdsync issue de rest vna het netwerk onderuit kan halen. Als ik een fout lopende server heb, dan is de rest gewoon nog werkend.

Authenticatieoplossingen als SAML, OAuth, Kerberos etc maken gebruik van tokens met een beperkte looptijd. Een server valt niet om van een verkeerd ingestelde klok, maar keurt domweg alle verzoeken af wat ongeveer hetzelfde resultaat oplevert.

[Triblade_8472]

Maar het gaat om NAFIN. Hoe kan een server bij Defensie andere diensten beïnvloeden? Dat moet toch niet mogen.

Ik snap hoe een timesync zaken kapot kan trekken, ik zal het net wat specifieker maken. "Wat ik héél graag zou willen weten, is hoe een software fout\tijdsync issue bij Defensie de netwerken van andere diensten onderuit kan halen."

[HMBakker]

Ik kan me voorstellen dat de geheime dienst IDs uitzet waar bv Schiphol en vv Eindhoven, maar ook gemeentes 'langs' moeten voordat ze iemand service mogen verlenen. Als dat niet gebeurt dan kan er een gezochte het land uit verdwijnen... Waarom Schiphol dan wel door gedraaid heeft?? Impact van de <100 vluchten vanuit Eindhoven is natuurlijk veel kleiner.

[Triblade_8472]

Mogelijk doordat Defensie de Eindhoven airport beheert en dat niet meer kon.

[Rolfie]

Schiphol is een commerciële luchthaven en Eindhoven is ook een militaire luchthaven.
Dat zou dit perfect kunnen verklaren.

[toxict]

Ik ken de omgeving verder niet hoor... maar....
Ik las ergens dat KPN een stuk beheer doet?
Als dat de gemeenschappelijke factor is, dan lijkt het mij dat daar de oorzaak ligt.

[tweazer]

Was dat niet vodafone die een publieke aanbesteding won die kpn juist weer aanvechtte en verloor ?

[TheBrut3]

Maar het gaat om NAFIN. Hoe kan een server bij Defensie andere diensten beïnvloeden?

Dat staat er toch in;

Nafin is een eigen glasvezelnetwerk van Defensie. Het gesloten netwerk is zo'n 3300 kilometer lang en verbindt onder meer defensielocaties, politielocaties en ministeries en hun datacenters met elkaar.

[Triblade_8472]

Ah ja, dat is inderdaad iets wat ik niet goed doorkreeg.
NAFIN beheert het netwerk. En als dan in het verkeerde deel een storing veroorzaakt wordt, kan de hele ring eruit liggen.

Ok, die kan ik begrijpen. Hopelijk wordt dat nog bevestigd.

[Blokker_1999]

Omdat het netwerk niet enkel door defensie wordt gebruikt, maar om veel meer vertrouwelijke informatie van de overheid over te sturen. Defensie treed daar op als de partij die die informatie helpt beveiligen. Als het Nafin netwerk dan problemen krijgt, krijgen die andere diensten ook problemen.

[akalucas]

Veel systemen hangen af van dezelfde tijdsinstellingen, zoals bij SAML of OAuth. Als Defensie een probleem heeft met hun tijdsynchronisatie, en andere diensten dezelfde tijdserver of infrastructuur gebruiken, kan dat een kettingreactie veroorzaken.

Natuurlijk zou er een backupplan moeten zijn, en in theorie had dit niet mogen gebeuren. Maar in complexe IT-systemen kan er zoveel misgaan dat je nooit een 100% uptime kunt garanderen. Ik zeg overigens niet dat ze het probleem niet sneller hadden kunnen identificeren of dat er geen failover dienst had moeten zijn.

[Yordi-]

Als ik de link tussen netwerk - tijd synchronisatie leg lijkt het mij eerder een PTP-timestamp afhankelijkheid. Waarom dat gebruikt wordt is gissen, maar PTP heeft verschillende toepassingen.

[Charlie_Root]

Mogelijk dat een NTP issue er voor gezorgd heeft dat het optische netwerk (wat gebruik maakt van encryptie) de certificaten ongeldig verklaard heeft. Dan stopt het hele optische netwerk er mee. Aangezien ze deze dienst aan andere partijen (waaronder politie) leveren zou dit het kunnen verklaren.

[ANdrode]

Imo moet men hier een goede, publieke, post mortem doen om overtuigend uit te kunnen leggen dat het geen kwaadaardige actor was die het probleem heeft veroorzaakt.

Key exchange voor het optische netwerk zou één van de plekken zijn waar ik het met je eens ben dat synchronisatie belangrijk is.

[Jerie]

Absoluut niet. De minister heeft voldoende uitleg gegeven. Bij een publieke postmortem geef je interne processen prijs die burgers niet hoeven te weten. Dan weten de Russen het immers ook.

Een interne postmortem voor mensen die hier toegang toe moeten hebben volstaat.

[ANdrode]

Dit is infrastructuur die impact heeft op diensten buiten het militaire domein. En infrastructuur waar überhaupt al dubieus veel OSINT over te vinden is (voorbeeldje: een kaart). Voor de businesscase voor het onderhouden van een high-end netwerk is het delen van deze fysieke infrastructuur overigens logisch.

Je zou er realistisch gezien vanuit moeten gaan dat alle informatie die een buitenlandse dienst met beperkte middelen voor het doel (dit is een kritiek telecomnetwerk, dus zeg 400K cash/een berg BTC/een agent een jaar paar embedden) kan achterhalen, deze informatie al heeft.

Informatie waarvan je redelijkerwijs kan verwachten dat een capabele aanvaller deze al heeft kan je in het beste openbaar maken. In het ontwerp en in het scenario dat hier misging zouden (vrijwel) geen geheimen moeten zitten.

[Reactie gewijzigd door ANdrode op 29 augustus 2024 16:57]

[Jerie]

Zou kunnen, dan moet je wel goed weten wat je wel en niet kunt / mag delen. Daar gaat dan wel tijd en moeite in zitten, en de vraag is wat het oplevert. Ik denk dat de directe partners wel voldoende op de hoogte zijn. Zo niet, dan zou je dat (onder strikte geheimhouding) wel kunnen delen met hen.

Maar je zag al in deze thread en diverse vorige iemand die voor defensie zeggen dat hij niet mag verbeteren terwijl hij meer weet, ook diverse foutieve informatie die hij zou kunnen verbeteren. Diegene zag ook diverse mensen informatie delen die intern is. Dat is gevaarlijk, en zouden we niet moeten doen. Ook niet als iemand al eerder in de fout ging. We moeten dat over laten aan experts. Of het dus verstandig is of niet, dat laat ik eigenlijk ook liever aan de experts. Maar vanuit mezelf zou ik daar terughoudend over zijn. En dus vooral: niet zeuren wanneer men het niet deelt. Ja, ik ben ook van nature bijzonder nieuwsgierig, maar dat is geen goede reden.

[ANdrode]

> Diegene zag ook diverse mensen informatie delen die intern is. Dat is gevaarlijk, en zouden we niet moeten doen.

Dit is wat ik ook observeerde. Ik denk dat je veel kan afleiden (en ok je houdt een spectrum aan oorzaken over) op basis van wat er nu al gelekt is.

Dan zou ik liever actief openbaar maken. In operator circles ging men gisteren van een cyberaanval uit. Dat wil je eigenlijk ontkrachten (als dat kan zonder extra methoden en technieken te lekken)

[Jerie]

Ik geloof gewoon wat de overheid daarover stelt. Als ze daarover liegen dan komt dat of toch wel uiteindelijk uit, of er is een gegronde reden voor. Dat zien we dan wel weer. Ook zag je geen follow-up. Dus ik dacht niet aan een cyberaanval. Hoogstens een (mislukte?) oefening.

Mensen geloven helaas toch wel wat ze willen, ook met degelijk bewijs.

[BadRespawn]

Wat ik héél graag zou willen weten, is hoe een software fout\tijdsync issue bij Defensie de netwerken van andere diensten onderuit kan halen.

Die andere (lokale) netwerken functioneerden mogelijk nog wel, maar daar had men niets aan omdat de verbinding met andere diensten loopt via het netwerk van defensie wat niet meer functioneerde.

[field33P]

Wel vindt ik dat de impact niet goed genoeg benoemd wordt. Zaken als het RiVG en DigiD zijn best wel heel belangrijk en naar mijn mening noemenswaardiger dan Eindhoven Airport (al schreeuwde de mensen daar het hardst).

Eindhoven Airport is ook een militaire installatie, waar de burgerluchtvaart te gast is. En bij DigiD was alleen de sms-authenticatie getroffen, een functie die door steeds minder mensen gebruikt wordt.

[Reactie gewijzigd door field33P op 29 augustus 2024 16:08]

[Triblade_8472]

Dan nog zijn, naar mijn mening, de RiVG diensten en DigiD/SMS belangrijker dan een vliegveldje. Hoe vervelend dan ook voor de mensen aldaar.

We hebben genoeg luchtmacht basissen en als het leger nodig is, dan gaan ze echt wel vliegen hoor, met of zonder werkende ICT.

[ibmpc]

Gelukkig heeft Nederland de DARES om te communiceren bij storingen van dit kaliber en groter. Hier zijn vast wel een aantal vrijwilligers aanwezig die iets kunnen vertellen over wat zij hebben gedaan in de afgelopen 24 uur.

[vinkjb]

Ik neem aan ook al ben je vrijwilliger aan geheimhouding bent gebonden he.

[mtak]

DARES is een compleet open (als in niet-geheime) organisatie. Ook de activiteiten van DARES worden gedaan over niet-versleutelde kanalen, want zendamateurs mogen geen radiocommunicatie versleutelen.

Zie Regeling gebruik van frequentieruimte met meldingsplicht 2015 artikel 10.1f.

[trick2011]

ik lees wat je linkt maar het is totaal niet zo dat mensen zich daar aan houden (of überhaupt wat de markt aanbied)

Neem bijvoorbeeld DMR, dat is digitaal en ondersteund gewoon encryptie en wordt zodoende ook gebruikt.

In het geval van LoRaWAN gebeurt dat ook in de 'vrije'/amateur banden. (433MHz)

[MrDaViper]

Zij hebben niets gedaan in dit geval.
DARES is net zoals het Belgische B-EARS compleet van de kaart geveegd bij Defensie.
Er zal al een ENORM grote ramp moeten voorvallen voordat DARES (of in Belgie B-EARS) opgeroepen zal worden om hulp te bieden.

[DarkForce]

Helemaal niets want er kon nog worden gecommuniceerd.
Waren ze wel opgeroepen zou je het wel in de P2000 monitor, op de website van Dares of de regiosites voorbij hebben zien komen.

[Homer J.Simpson]

Kunt er lang en kort over praten, maar je komt niet heen om het feit dat in redundante systemen het falen van 1 component per definitie nooit tot gevolg mag hebben dat beide systemen er uit liggen. Dit is simpelweg slechte architectuur. Punt.

[PolarBear]

En wat nu als de architectuur wel goed is maar er onbedoeld en/of onvoorzien toch een afhankelijk is gecreeerd?

Beetje beste stuurlui aan de wal gevoel hierbij.

[Homer J.Simpson]

Dan is de architectuur dus niet goed…

[Rolfie]

Ooit wel eens een een cluster gezien had, dat beide dacht de master te zijn?
Of dat het cluster er mee stopt omdat ze elkaar niet meer zagen?
Een configuratie mismatch was bij de cluster configuratie?

Je opmerking zou zo vanuit de politiek kunnen komen, zonder kennis van zaken.

[Homer J.Simpson]

Meerdere malen meegemaakt en een perfect voorbeeld dat een cluster dus GEEN volledige redundantie biedt wegens gezamenlijke afhankelijkheden.
Een cluster is imo slechts een manier om tolerantie te bieden tegen hardwarefapen, en misschien, als het goed gepland wordt tegen patchproblemen. Werkelijke redundantie gaat echt wel veel verder, denk aan geografische scheiding, real time backups, aanbieden van diensten op onafhankelijke, en liefst ook technologisch verschillende platformen etc.
Werkelijke redundante gaat echt veel en veel verder dan klakkeloos de oplossingen van diverse fabrikanten oplepelen.

[Reactie gewijzigd door Homer J.Simpson op 29 augustus 2024 14:02]

[Ruthhl3ss]

Alles zal redundant zijn uitgevoerd maar er is altijd software die het vervolgens aanstuurt. Als je daar een configuratie fout in maakt dan ligt de boel eruit. Je kunt het maar redundant maken tot een bepaald niveau.

Zie vergelijkbare incident bij Microsoft, AWS en verschillende content delivery netwerken.

[jongetje]

Precies dit. Ik ken dubbel uitgevoerde netwerken waarbij iemand een verkeerde configuratie in de routers had ingeladen en beide routers dachten dat ze master waren en actief werden...

Daar helpen nog 1000 extralijnen niet mee. Dan moet je alle componenten helemaal compleet dubbel en gescheiden uitvoeren met een eigen release management wat echt enorm kostbaar is.

[pe0mot]

Inderdaad redundant is redundant,
dus niet dezelfde leverancier, OS en software!

[tweazer]

Ook redundantie op "standaarden" heeft zo z'n nukken (uit eigen ervaring microsoft dhcp option 69, checkpoint HA met cisco en fortinet). Voor military grade zou ik voor de core eerder alles tweevoudig (met verschillende hardware) uitgevoerd willen zien.... Ik vermoed alleen dat 8 en 9 in het iso 7 lagen model de doorslag hebben gegeven (politics & economics).

[ANdrode]

Bij dual vendor kan je in ieder geval het incident in beperkte tijd mitigeren door één van de vendors hun hardware uit te zetten.

Ik vind het issue niet verbazingwekkend. Wel de time to fix (20h) en de "dit kan gebeuren" reactie van de minister.

[Ruthhl3ss]

Waarschijnlijk stond het wachtwoord van een bepaalde dienst/appliance ook ergens op het netwerk.

[pe0mot]

Ik denk dat de oplossing niet via het netwerk mogelijk was door het authenticatie probleem.
Dus met een laptop onder de arm en een steker rechtstreeks in de achterdeur.
Daarna een nieuwe setting, of nog erger een nieuw OS. Dat laatste kan even duren als de developers al aan de vrijmibo zijn.

[Ruthhl3ss]

En hierbij zeg ik dan weer: "Precies dit".

[BadRespawn]

Je kunt het maar redundant maken tot een bepaald niveau.

In principe kan een backup netwerk 100% gescheiden zijn (dat staat dan nog los vd rest vd voorzieningen die evt ook wel of niet redundant kunnen zijn).
Een 100% gescheiden backup netwerk maakt het kostbaarder dan niet-echte redundantie. Je moet je dus afvragen: wil je redundantie of wil je kans op dit soort problemen.

[Ruthhl3ss]

Dat ben ik met je eens. Ik ben wel nog van mening dat een 100% gescheiden backup netwerk een utopie is.

Elke change zal namelijk altijd consequent toegepast moeten worden op het backup netwerk. We kennen allemaal de change procedures en dat niet iedereen zo consequent is als zou moeten om te 100% gelijkheid zoals in begin na te streven.

Het is vergelijkbaar als men een OTA omgeving neerzet voor een applicatiestraat. Er wordt (bijna) nooit consequent van Ontwikkel (O) naar Test (T) naar Acceptatie (A) gedeployed om alle omgevingen na het einde van een change weer volledig gelijk te hebben. Naar verloop van tijd ontstaan er altijd verschillen in deze OTA straten.

[pe0mot]

Tja, deze hadden we eerder gezien in ons eigen netwerk.
Zonder tijd gaat veel authenticatie niet meer werken (single point of failure).
In het oerwoud van aannames afgelopen 24 uur heb ik deze maar 1 keer gelezen. Kudo voor deze tweaker.

[Vaevictis_]

Zonder exacte tijd syncronisatie werkt authenticatie zoals TOTP en VPN niet en kun je dus effectief geen toegang krijgen tot het netwerk, als gebruiker maar ook de systemen. Defensie heeft ook veel hosting voor andere overheden dus is niet zo gek dat er een grote storing optreedt. Zo zie je maar weer de mensen is de zwakste schakel en de impact van menselijke fouten gaat in de toekomst steeds groter worden.

[remyz]

Als het een gesloten netwerk is, zoals in het artikel staat, dan ben ik benieuwd hoe de storing bijvoorbeeld ook DigiD heeft kunnen treffen. Of wat de definitie van “een gesloten netwerk” in dit geval is.

[Saint2Saint]

Lees daarvoor even het achtergrond artikel dat gisteren verschenen is, daar wordt dit in uitgelegd.

[remyz]

Dankje, ik had dat artikel nog niet gelezen.

In het achtergrondartikel wordt gesproken over een ‘besloten Internet’ en dat is in mijn ogen heel wat anders dan een ‘gesloten netwerk’.

[IHVD]

Hoe ik het lees is het in dit geval een beetje tomato-tamato, "besloten" wat gebruikt wordt als "gesloten"

[remyz]

In dit geval is het andersom, 'gesloten' wordt gebruikt als 'besloten' ;-).
Anyway. Ik ben het met je eens hoor.

[BadRespawn]

Het netwerk van defensie is gesloten in de zin dat het los staat van internet en niet iedereen zomaar toegang heeft. Maar dat netwerk koppelt al die andere instanties/diensten dus als het eruit ligt treft dat ook al die andere instanties/diensten.

[beschuitfluiter]

ntp servers niet opgenomen in de nieuwe firewall op de nieuwe basis in Amsterdam?

[paulhekje]

Tijdsynchronisatie kan op een heleboel plekken fout gaan. als klokken teveel verschillen werkt authenticatie niet meer. Dat uit zich door langzaam steeds meer uitvallende systemen.
De grote gemene deler lijkt 1 specifiek netwerk te zijn wat als koppelnetwerk dient voor allerlei overheidsystemen. Het lijkt dan ook waarschijnlijk dat er een foutieve netwerk/firewall-configuratie was, of dat een virtualisatieplatform waar veel van die systemen op draaien niet goed meer functioneerde.
Een combinatie is ook nog mogelijk natuurlijk...