Storing Defensienetwerk veroorzaakt door fout in standaard netwerkonderdeel
Een softwarefout in een standaard netwerkonderdeel van het Defensienetwerk NAFIN zorgde voor de grote storing waar allerlei overheidsinstanties en Eindhoven Airport eind augustus mee te maken kregen. De leverancier heeft inmiddels een update uitgebracht om het probleem te verhelpen en Defensie heeft tijdelijk de configuratie van netwerkonderdelen aangepast die betrokken zijn bij tijdsynchronisatie. Dat laat staatssecretaris Tuinman van Defensie op Kamervragen van Nieuw Sociaal Contract (NSC) weten.
"De oorzaak van het probleem lag in de toegangsverlening tot het zogeheten Netherlands Armed Forces Integrated Network (NAFIN). Door een fout in de softwarecode is een probleem ontstaan in de tijdsynchronisatie op het netwerk. Hierdoor was het niet mogelijk om verbinding te maken met dit netwerk. Er is vooralsnog geen indicatie dat de storing is veroorzaakt door een kwaadwillende partij", verklaarde minister Brekelmans van Defensie eerder over de oorzaak van de storing.
Tuinman is nu met iets meer informatie gekomen. "De foute softwarecode zat in een redundant uitgevoerde netwerkcomponent die Defensie als standaardproduct van een leverancier inzet. Defensie heeft geen zicht op hoe deze softwarefout in dit standaardproduct bij de leverancier is ontstaan. De leverancier heeft een nieuwe versie van de software geleverd waarin dit probleem is opgelost."
De staatssecretaris zegt dat Defensie nog onderzoekt hoe de fout tot de grote storing heeft kunnen leiden. "Er is geen indicator gevonden die duidt op betrokkenheid van een kwaadwillende partij. Dit betreft een voorlopige conclusie", voegt Tuinman toe. De staatssecretaris stelt ook dat verstoringen, zoals door fouten in software, nooit volledig uitgesloten kunnen worden.
Naar aanleiding van de storing heeft Defensie tijdelijk aanpassingen doorgevoerd in de configuratie van netwerkonderdelen die betrokken zijn bij tijdsynchronisatie. Het NAFIN-netwerk is voorzien van beveiligingsmaatregelen tegen 'time spoofing'. Door de doorgevoerde aanpassingen is de kans op een soortgelijke grote storing verkleind, aldus Tuinman. "Deze wijziging heeft echter weer andere nadelen waar ik vanwege veiligheidsredenen geen details over kan verstrekken. Onderdeel van de evaluatie is het heroverwegen wat het optimale ontwerp is van de configuratie van de netwerkcomponenten", legt de staatssecretaris verder uit (pdf).
...dan is het Tuinman wel?
Er is te weinig informatie voor een gedetailleerd beeld, maar wat er staat is toch prima te snappen ?
"Een (redundant uitgevoerd) standaard netwerkapparaat" - (router, switch, firewall) blokkeerde door een software fout "tijdsynchronisatie" .
(ntp , misschien ptp) .
Ze zoeken nog waarom dit een 'grote storing' werd. (technisch ? Of waarom dit operationeel niet eerder/sneller ontdekt werd?)
Ze hadden waarschijnlijk van alles super strak ingesteld, dat de kleinste afwijking meteen de boel op slot gooide.
Nu wat meer open , en zijn aan het afwegen of "maximaal veilig, fail closed" niet een beetje doorgeslagen is en teveel availability kosten heeft.
Ik denk dat het waar is, en dat ze alleen de technische details zo min mogelijk willen benoemen.
Ga's in tijdje de IT werken in de techniek.
Het zijn alleen buitenstaanders, junioren en managers die geloven dat "redundant uitgevoerd" betekent "kan op geen enkele manier toch falen" .
Welke van die groepen ben jij ?
Degenen die _wel_ praktijkervaring hebben, hebben in de loop der tijd allerlei redundante apparatuur van behoorlijke merken toch op onverwachte manieren zien falen waarbij er service impact was.
Meestal werkt het wel , en het beschermt ook echt wel tegen 'normale' storingen ( simpele harde uitval van één van de redundant uitgevoerde onderdelen) . Maar het is echt niet _zo_ zeldzaam om een samenloop, een bug (soms juist in het synchronisatie deel van beide redundante systemen), een storing in de éne gedeelde component (passieve backplane, of zo) en dan heb je toch service impact.
Er is echt niks ongeloofwaardigs aan.
Voor je complot verdenking moet je met meer aankomen dan 'redundant en toch falen dat geloof ik niet'.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
... de koekoeksklok uit het commandocentrum van de opperbevelhebber der Nederlandse Strijdkrachten en mocht die blijven hangen, als back-up - héél verstandig - een eierwekker uit de kantine van het Min. van Defensie.
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten.
Voor nauw-gekoppelde redundantie met state synchronisatie (routers, switches, firewalls) is het nu juist keihard noodzakelijk dat die dezelfde OS/patch/ en evt blade revisie draaien.
Het is meestal onmogelijk - of sterk af te raden - om daar verschil in te hebben, meestal omdat de state synchronisatie daar niet mee om kan gaan.
Soms kun je een design kiezen waarin de redundantie op een andere protocol laag zit, en de apparatuur niet zo strak gekoppeld is.
Dat is waar jij aan denkt - omdat je aanneemt dat het in "de" "redundante" NTP server misging, en dat je daar twee (natuurlijk op verschillende plaatsen) van wilt neerzitten.
Als je alleen maat dat als oorzaak uit je duim zuigt moet je niet al te arrogant formuleren "wat leren we hieruit", want we weten helemaal niet wat de oorzaak was.
Meestal "betaal" je voor redundantie op een hogere laag zonder nauwe koppeling met langere failover tijden.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Je kunt ook verzinnen dat er een redundante firewall was waarbij iets misliep in de sessie synchronisatie waardoor alle *:123 verkeer gedropt werd.
Of een (redundante) router die de prefix naar "het NTP server subnet" niet meer leerde.
Past allemaal in de uitleg, en kan allemaal voorkomen.
Of de technische oorzaak iets is van "tsja kun je verwachten met die keuzes" is niet te zeggen.
Ik denk dat de verbeterpunten meer zitten in "waarom duurde het zo lang voordat het probleem gezien/gesnapt/opgelost werd".
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.