Valt me nog mee dat de Russen of de Chinezen hier niet de schuld van krijgen. De VS is samen met de VK op oorlogspad met de Russen en de Chinezen en die Nederlandse sukkels hier lopen daar als schoothondjes achter aan maar snappen niet dat niet de VS of de VK maar dat zij de kernraketten over zich heen krijgen.

Reeds bij installatie is bekend wanneer hij verloopt. De vervangingsdatum kun je simpel in een digitale agenda zetten. (Beter een paar week ervoor)

Het is geen overmacht dus ben ik benieuwd hoe ze met geclaimde schade omgaan.

Als er een raket van Baikonur wordt gelanceerd, zeg je dan ook: de Russen hebben hier niets mee te maken?

WTF komen die Chinese Russen ineens vandaan?
Ik dacht toch echt dat het artikel over een Britse mobiele provider ging.

Lekker makkelijk om de software buiten werking te stellen (wat vreemd is want waarom heb je het anders draaien).
Eigenlijk heb je een sleutelbeheer proces niet op orde, dat is toch echt iets anders... Kortom ze hebben zitten slapen en ze geven software de schuld wat eigenlijk niet kan. zeer zwak.

Welkom bij Security....

Op een laagdrempelig ongecensureerd medium als http://security.nl mag iedereen zijn of haar (*) zegje doen! lk weet dat bepaalde elementen hier graag censuur ingevoerd zouden willen zien maar daar doen we in een vrije samenleving niet aan! Toch?

(*) https://taaleidoscoop.nl/blog/genderneutraal/

Klopt, maar aluminium hoedjes zijn hier ook in de mode, je ziet ze hier namelijk vaak. Sommige zitten alleen te krap heb ik een vermoeden, waardoor logisch nadenken erg belemmert wordt.

In het ITSM proces met ITIL is dit soort zaken niet geregeld. Het klinkt voor een normaal mens logisch dat je klokken / licenties / certificaten met een tijdsmoment op tijd moet vervangen. De gedachte en dogma is dat elke verandering tot problemen kan leiden en als je niets zelf veranderd dat het dan wel blijft werken. Een dogma dat wat nuancering behoeft.
- Er moet een planning met uren en budget ingeschoten worden.
- De planning kent afhankelijkheden bijvoorbeeld de betaling en verkrijgen van nieuw certificaat.
- In het verdeel en heers is niemand echt verantwoordelijk voor de continuïteit
Resultaat is dat degene op de vloer (geoutsourced want onbelangrijk) het niet kan uitvoeren en wel de schuld krijgt.
Dat noemen ze dan inderdaad overmacht want de best practices zijn ingevuld.

Nee ik vind dat net goed, eerder triest. Het is een beschrijving uit de praktijk.

De triestheid, en het veel-schijven probleem zijn bekend.

In het ITIL proces zou dit eerder onderdeel van monitoring/bewaking zijn - met een alarm geruime tijd voor verloopdatum.
Dat test zowel het werken van de interface/API als certificaat geldigheidsduur . Net zo goed als diskfailures en aanstaande diskfailures bewaakt moeten worden.

Maar goed, het _is_ lastig om dit in grote organisaties bij allerlei interne API koppelingen goed te doen.
In mijn (werk)omgeving hebben we bewust kozen voor certificaten die 1 jaar geldig zijn puur om de routine van bewaken/aanvragen/vervangen erin te houden. Als je kiest voor langer dan zijn mensen die wisten hoe/wat/waar , zowel aan de technische kant als aan de proceskant mbt tot het regelen van een purchase vaak al naar een andere rol of functie.

Een 'normale' webserver is wat dat betreft vrij makkelijk - dat is voor een beheerder bekend terrein , overal manuals etc .
Allerlei interne API koppelingen met SSL erop tussen systemen die erg kritisch zijn zijn veel lastiger - de reguliere beheerders hebben die zelden 'from scratch' gebouwd, want dat deed de leverancier, en dan na drie of vijf jaar opeens zo'n diepliggende component als een SSL certificaat aanpakken is een klamme handjes moment .
Met wat ironie was er misschien ook zo'n strak security beleid dat het onsluiten van die API voor een bewakings/monitoring systeem niet mogelijk was. En heeft de leverancier die caveat 'certificaat verloopt over drie jaar' al of niet in de oplever documentatie gezet, maar is die natuurlijk nooit in dat detail tussen de oren van de beheerorganisatie gekomen.

Het _is_ uiteindelijk een faal van de organisatie maar het kan inderdaad erg lastig zijn in dat type organisaties.