IT Services JaapZero Trust in een netwerk: er zijn geen verbindingen mogelijk, anders dan expliciet toegelaten verbindingen. Default is: geen verbinding. Zero Trust.
Zero Trust wordt gezien als de ultieme beveiliging tegen hacken. Is het dat ook? Of is het de zoveelste hype in security land?
Een paar jaar terug schreef ik over een ontwikkeling die ik op vakantie tegenkwam (zie link). Ik schreef toen hoe ontwikkelingen bij ICT de maatschappij beïnvloeden. Ik deed een voorspelling voor 2025.
Vandaag kom ik daarop terug. De ontwikkelingen gaan sneller dan ik toen verwachtte.
Niet dus. Begin april faalde een cruciaal NS-systeem. Alle treinverkeer werd stopgezet.
NS: “Niet alleen de borden en app van NS waren uitgevallen, het complete planningsysteem voor materieel en personeel lag plat. Normaal gesproken kan men dan op een back-up terugvallen, maar dat lukte niet.”
Dit soort blogs beginnen met je te vertellen dat hackers het op je bedrijf voorzien hebben en, als ze slagen, de schade enorm is. Mocht je dat niet al weten, Internet is je vriend.
Deze blog gaat over offensief beveiligen, over de vijand terugdrijven. Aanvulling op goed patchen, eindpuntbeveiliging, off-line backups, multi-factor autorisatie, compartimentering, versleuteling. Want defensie blijft immer nodig. Het is alleen niet genoeg.
Bij Dataveiligheid gaat het erom houding en gedrag van management positief te beïnvloeden. Dat kan met een Dynamische Krachtenveld Analyse (DKA).
Algemeen bekend: software bevat altijd defects. Minder bekend is, dat we 86% voor en tijdens de bouw kunnen elimineren, tegen een tiende van de kosten als dat pas later gebeurt.
Uit onderzoeken blijkt dat een uitstekend ingeregeld realisatieproces de doorlooptijd halveert en resulteert in meer wendbaarheid, een betere functionaliteit en aanzienlijk minder fouten bij productie.
In deze blog gaan we in op zeven verbeteringen die in de praktijk bewezen zijn te werken.
Er was eens ….
Zo beginnen sprookjes. Deze blog is geen sprookje. Deze blog gaat over harde werkelijkheid en over zware management besluiten.
Er was eens een software systeem. Dat software systeem deed het goed. Zo goed, niemand peinsde erover het te vervangen. Het was in Cobol geschreven. Geen dialect, gewoon puur en standaard Cobol. Onderhoud was schaars en zelden nodig. Eigenlijk was het een lief systeem dat nooit om aandacht vroeg.
Het systeem werd ouder en ouder. En de laatst overgebleven Cobol programmeur werd ouder en ouder. Die wilde met pensioen. En toen werd dat software systeem plots een management probleem.
Toen mijn vader opging voor het aannemers-examen was er om 11 uur koffiepauze. Er moest een garage begroot worden. Iedereen had een prijs in gedachten. ƒ3800. ƒ3960. Nee, zei weer een ander, ƒ3400. Mijn vader had alleen nog maar materialen uitgetrokken. Het laatste uur schreef hij dat netjes uit, vrij wanhopig, want de prijs berekenen, daar was hij nog lang niet aan toe.
Een grote verzekeraar heeft een chatbot:
Ik: “Waar vind ik mijn uitkeringsspecificatie?”
Bot: “Ik begrijp u niet, kunt u uw vraag korter stellen?”
Ik: “Nee”
Bot: “Wilt u chatten met een medewerker?”
Ik: “Ja”
Bot: “Er is geen medewerker beschikbaar.”
Bot: “Kan ik verder iets voor u doen?”
Ik: “Barst!”
Bot: “Een schademelding kunt u doen op de website … ”
Ik begrijp niet dat een bedrijf het aandurft het eerste klantcontact aan zo’n bot toe te vertrouwen. Dat komt nooit meer goed.
U kent het wel. Er loopt een project en dat project heeft een deadline. Wordt die deadline gehaald?
Een goede vraag. Uitloop is bij ICT-projecten standaard. Dat hoeft echter niet zo te zijn. Met een goede analyse van de gevonden en opgeloste issues kunnen je statistisch een uitstekende voorspelling doen.