Ministerie VWS raadt zorgverleners aan om browsers niet te updaten

Klanten van het zogenaamde UZI-register hebben een e-mail ontvangen met het verzoek om geen updates uit te voeren op hun webbrowsers. In de e-mail staat dat webbrowsers vanaf oktober 2016 de benodigde Java- en ActiveX-onderdelen niet meer ondersteunen.

Het UZI-register geeft certificaten uit waarmee zorgaanbieders zich kunnen identificeren. Hiervoor wordt de zogenaamde UZI-pas gebruikt, dat is een smartcard waarop digitale sleutels worden bewaard. Het register is onderdeel van het CIBG, dat op zijn beurt weer een uitvoeringsorganisatie is van het ministerie van Volksgezondheid, Welzijn en Sport.

De Java- en ActiveX-plug-ins worden onder andere gebruikt voor het identificeren van zorgverleners aan de hand van de smartcard. Hoeveel mensen gebruikmaken van de plug-ins is onbekend, zegt Vera Wagenaar, communicatieadviseur van het CIBG, tegen Tweakers. Ze verwacht dat het probleem rond november is opgelost. De e-mail is volgens haar rondgestuurd om de klanten te waarschuwen dat ze niet in staat zullen zijn om de applicatie te gebruiken als zij hun browser updaten.

In de e-mail wordt aangeraden om automatische updates uit te zetten. "De UZI-pas(lezer) maakt in veel gevallen gebruik van bepaalde webbrowser-onderdelen voor identificatie, authenticatie en het plaatsen van digitale handtekeningen op medisch gerelateerde documenten. Deze onderdelen, zoals Java en ActiveX, gaan vanaf oktober 2016 verdwijnen." Verderop in de mail staat: "Het is belangrijk dat er geen automatische updates meer plaatsvinden aan uw huidige webbrowser. Installeer ook geen nieuwe browsers."

Vermoedelijk wordt er in de e-mail gerefereerd aan het feit dat Java met versie 9 een einde maakt aan de ondersteuning van de web-plug-in. De Java-plug-in heeft geen feilloze reputatie op het gebied van veiligheid en is vaak slachtoffer van zero-day-kwetsbaarheden geweest. Java 9 was origineel voor september 2016 gepland, maar is later uitgesteld naar maart 2017.

ActiveX is een software-framework dat inmiddels 20 jaar bestaat en door steeds meer instanties wordt uitgefaseerd. Ondersteuning door andere browsers dan Internet Explorer is nauwelijks van de grond gekomen en zelfs in Microsofts eigen nieuwe browser, Edge, is de functionaliteit niet toegevoegd. Het framework is in het verleden al meerdere keren in het nieuws gekomen vanwege veiligheidslekken.

Door Emile Witteman

Nieuwsposter

22-09-2016 • 16:53

141

Submitter: vosje99

Lees meer

Apple blokkeert Java op Mac OS X
Apple blokkeert Java op Mac OS X Nieuws van 12 januari 2013

Reacties (141)

141
135
95
13
1
24
Wijzig sortering
Installeer dan Firefox ESR of gebruik Internet Explorer 11? Die gaan nog een lange tijd beveiligingsupdates krijgen, hoef je geen automatische updates uit te schakelen...

Bij Chrome werkt de browser-plugin al een hele lange tijd niet meer. Alleen Java Web-start is nog ondersteund omdat dit gewoon een browser protocol gebruikt om zo de java applicatie te starten in zijn eigen VM(dus niet in de browser zelf). Dit blijft dan dus ook gewoon nog in Java 9 zitten.

TL;DR: Ik snap de email dus dan gewoon helemaal niet. Waarom zeg je dan niet gewoon "Installeer Java 9 niet" ipv het browsergedoe wat volgens het artikel helemaal niks mee te maken heeft?

[Reactie gewijzigd door MrFax op 23 juli 2024 04:08]

Geloof me, het verwarde mij net zoveel als jou. Ik heb het hele internet afgestruind naar iets waarvan de support in oktober zou ophouden, maar ik vond alleen dingetjes dat oudere versies van Flash en Silverlight niet zouden werken - niet relevant dus. De afloop van de ondersteuning van de Java-plug-in met Java 9 leek mij hetgeen dat het meest leek aan te sluiten op het verhaal, dus dat heb ik maar vermeld.

Het is imo ook niet het belangrijkste punt van het artikel. De overheid gebruikt een hopeloos verouderd systeem en vereist dat je jouw software daarom niet up-to-date (dus onvoldoende beveiligd) houdt.
Niet alleen de overheid. Veel grote bedrijven hebben hier ook grote moeite mee, zowel intern als extern. Een vrij grote telecom boer vereist nog Java 1.5 op z'n retail kassas omdat de kassasoftware niet met hoger overweg kan. En dan ook nog certificate revocation uitzetten omdat niemand ooit die certs bijgehouden heeft.

IT security bij grote bedrijven is een lachertje, omdat het een kostenpost is die pas bij een enorme - en publieke - inbraak serieus genomen wordt. En omdat 90% van alle IT geoutsourced wordt waarbij elke wijziging een jarenlang project wordt...

[Reactie gewijzigd door Aetje op 23 juli 2024 04:08]

Het is niet alleen een kostenpost. Software herschrijven, op basis van andere methodieken, testen en vervolgens uitrollen naar 10 duizenden of 100 duizenden systemen kost niet alleen veel geld, het kost ook bijzonder veel tijd.

Daarbij moet de retailer op de hoek, in jouw kassa verhaal, maar bereid zijn een nieuwe kassa aan te schaffen ook. Over het algemeen kopen ze die niet met de verwachting dat de software het over 5 jaar begeeft vanwege beveiligings issues of gestopte ondersteuning van 1 van de zoveel stukken software die er op draait.

Er zijn erg veel afhankelijkheden die je niet kan negeren buiten alleen de kosten.

En dan zullen we het voor het gemak, in omgevingen als ziekenhuizen en overheden, nog maar even niet hebben over de integratie/communicatie met andere apparaten/software pakketten die mogelijk ook opnieuw moet en kapitalen kost.

[Reactie gewijzigd door freaky op 23 juli 2024 00:35]

IT security bij grote bedrijven is een lachertje,...
IT security is bij grote bedrijven op eieren lopen. De klant (en daarmee bedoel ik de business) denkt dat het installeren en bijwerken van software net zoiets is als thuis. Dus je doet er een DVD-tje in en na een paar minuten staat het erop. (of erger nog: je downloadt het bij een of andere site en klaar). Als ik dan roep, dat het zes weken duurt vanaf het moment van aanvraag tot het daadwerkelijk in productie uitrollen van de software, dan kijkt men raar.
De andere kant is dat de klant er absoluut geen moeite mee schijnt te hebben dat er stokoude software in de omgeving rondhuppelt. Ik kan voorbeeld geven van een stokoud stukje maatsoftware voor een bedrijfskritisch proces, wat nog vrolijk draait met J-Initiator code. Wij hebben deze code al een tijdje proberen te updaten, maar we krijgen de klant niet mee. Hij wil hier zelf geen tijd voor vrijmaken en als we aangeven dat dit niet meer beheerbaar is, wordt vrolijk via een escalatie op het hoogste niveau richting ons geslagen dat we het wel moeten blijven beheren.
(Dit zelfde gebeurt overigens ook als ik roep dat key users, FAB-ers of TAB-ers de bedrijfskritische applicaties moeten testen als de systemen gepatched zijn.)

Het is heel gemakkelijk om IT de schuld te geven van alle problemen. Ja, ik ben me ervan bewust dat we veel te vaak nog vanuit een ivoren toren het IT landschap proberen te beheren, maar op elk onderdeel van de keten liggen de problemen.
Bij grote bedrijven heb je vaak afdelingen of klanten die gebruik willen blijven maken van een applicatie die in 1865 ooit door een collega geschreven is en waarop een heel werkproces is gebouwd.
Ik heb applicaties gezien die voor het afgeven van belangrijke papieren voor de luchtvaart zijn bedoeld waarin een type printer hard stond opgegeven, bij vervanging van de printer voor een ander type werkte de applicatie gewoon niet.

En het is verbazend hoeveel macht afdelingen of klanten hebben om zaken op hun manier te willen (case in point minister Kamp die met zijn Gmail bleef werken omdat hij dat nu eenmaal makkelijker vond dan de encrypted omgeving die het ministerie hem bood).
De overheid heeft jaren met IE8 geploeterd omdat anders teveel web applicaties van de klanten het niet meer zouden doen.

Het gaat dus niet zozeer om het geld maar de relatie met de klant.
Een vrij grote telecom boer
Gooit ie er ff nonchalant uit.
Maakt niet uit - ik hoor uit de comments dat het bij andere grote bedrijven en service providers niet anders is. En ik had niet anders verwacht - als je een tijdje meegedraaid hebt in IT support/beheer dan zie je vanzelf hoe er in de praktijk omgegaan wordt met deze onzin.
Verbaast me dat VMs niet populair zijn tegenwoordig - het is nog wel te doen om antieke apps via een emulator in een stabiele omgeving te houden, terwijl de serveromgeving continu gepatcht kan worden.
Dat begrijp ik, ik weet dat ik waarschijnlijk de enige ben die dit vind, maar als ik ergens op een IT gerelateerd forum of iets dergelijks iemand hoor praten over een:" ..... boer" dan rol ik altijd van mijn stoel af. Deze kreet heeft een bepaalde nonchalante "expertise" over zich, die in mijn oren op zijn zachts gezegd twijfelachtig klinkt. Op de verdere inhoud van de comment had ik niks aan te merken of toe te voegen trouwens.
Ze zouden gewoon allemaal failliet moeten gaan.
Maar ja, bij kleine bedrijven is het vaak niet beter.
Alleen als men alleen 'standaard' software gebruikt kan men bij blijven en anders kost het gewoon te veel. Dat vindt men bij de grote bedrijven, dat is zo bij het MKB / de KMO's. Gespecialiseerde machines en software kost dusdanig veel dat deze jarenlang mee moet gaan.

Voor Overheid zou kosten minder zwaar mogen wezen, als het maar goed is, maar geen een software bedrijf kan bijbenen wat de ambtenarenmassa allemaal aan nieuwe wetten, regels, richtlijnen e.d. uitschrijft en dat laatste is deels om de maatschappelijke en ontwikkelingen bij te blijven, maar ook gewoon om bezig te blijven. Een ambtenaar die geen nieuwe wetten/beleidsplannen/ e.d. maakt is immers 'overbodig' en die indruk moet ten alle tijden vermeden worden. Zelfs overheidsonderdelen kunnen de toenemende complexiteit niet aan, voorbeelden: belastingdienst, svb, uwv enzovoorts.

Is er een nieuwe regelgeving, dan geldt die meestal alleen voor nieuwe gevallen. Voor bestaande gevallen blijft de regeling van kracht die gold toen zij in het systeem rolden (WW, WAO enz) en de overheden die dit moeten verwerken hebben zodoende met een veelvoud aan verschillende regelgevingen te maken zodat ze zelf weken moeten puzzelen welke er op jou van toepassing is voordat ze kunnen bepalen waar je wel en geen recht op hebt. Laat staan dat de gewone consument/werknemer er nog wijs uit kan. Dat laatste is ook helemaal niet de bedoeling want als hij het niet snapt moet hij een specialist inschakelen (bv advocaat) en dan kan die er ook weer aan verdienen. Daar verdient de overheid dan aan mee via vennootschapsbelasting, inkomstenbelasting enzovoorts.

Kortom wij als maatschappij maken onze wereld zo ingewikkeld dat we er zelf in omkomen, vastlopen, verzuipen.
Gespecialiseerde machines en software kost dusdanig veel dat deze jarenlang mee moet gaan.
Wat op zich nog niet zo'n probleem zou zijn als je die antieke software afzondert van het kantoornetwerk en vooral het internet. Zodat die apparaten alleen lokaal of deels remote op dezelfde locatie benaderbaar zijn, en dus niet vanaf externe locaties op in te breken is.
Maarja, remote support is goedkoper dus alles toegankelijk maken van buitenaf - nooit updaten omdat dat duur is... En dan krijg je dit.
Ik vind het nou hopeloos dat volgens velen in Europa "Het land van de ICT" is met zulke verouderde systemen werken. Het geeft een heel apart beeld.

[Reactie gewijzigd door MrFax op 23 juli 2024 04:08]

Je weet niet half hoe verouderd sommige dingen in high-tech landen als Japan en Korea zijn. In Japan draait er nog veel op PC98 en Zuid Korea heeft tijden nog IE6 vereist vanwege een ActiveX plugin voor het lezen van de identiteitspas :')

Al met al doen we het niet zo heel erg slecht denk ik dan maar :)
ach.

er is helemaal geen java of activex nodiom met een smartcard te werken hoor ..
bv; met de belgische eID kan je met firefox werken zonder dat je java hebt geinstalleerd;je moet gewoon de middleware hebben en een plugin voor firefox (die je gewoon in de public library kan zoeken; belgium eid"
In sommige gevallen is het beter om een ouder systeem te gebruiken dat goed getest en stabieler is, dan een nieuw systeem dat nog een hoop kinderziektes bevat. Of die vlieger op gaat bij dat vliegveld in je link weet ik echter niet :P
Hier in Xiamen(China) zie je overal nog windows XP om je heen. Ik denk dat in Nederland het ICT budget vaak verkeerd word besteed, en dat er geen geld over is voor bijhouden van dit soort systemen. Zolang 't nog werkt raken ze 't liever niet aan. Miljoenen naar 1 project, dat onder matig toezicht in India word ontwikkeld door stagairs/vers afgestudeerde werknemers die al helemaal geen idee hebben hoe de systemen in Nederland al werkte.

Maar sowieso zijn we niet super modern in het land van de ICT, hier in China word alles met QR codes gedaan. Betalen met een chat applicatie bijvoorbeeld, het werkt heerlijk en je hebt een stuk meer controle dan met bijvoorbeeld NFC betaling.

Je kan vanuit diverse apps, bijvoorbeeld: AliPay, WeChat of MiWallet, je gas/licht/water/telefoonrekening/internet betalen.

Diverse features van chatdiensten hier zijn overgenomen door diensten als Whatsapp, Telegram en FB Messenger.

[Reactie gewijzigd door royb3 op 23 juli 2024 04:08]

Zijn die minuteman rakketten die op Apple ]['s werken al volledig geshred ? Of is die software aansturing van de schroeven van dat amerikaans battleship gemigreerd van windows NT ? Die 8" floppydrives al naar microsd emulators omgezet ? Je staat soms te kijken wat uit betrouwbaarheid, kosten of beheerbaarheid nog loopt te zoemen...
Kan Tweakers niet de e-mail publiceren, geanonimiseerd?
Ik zou het graag willen lezen.

Misschien ben ik wel te nieuwsgierig.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 04:08]

Maar dan kan er dus niks aan gedaan worden, omdat het hier over de cloud van Microsoft gaat?

[Reactie gewijzigd door MrFax op 23 juli 2024 04:08]

Hmmm ja het niet updaten van een browser lijkt me vragen om moeilijkheden. Ik lees altijd de release notes.

Updated the HSTS preload list to a much more updated source list, and performing our own checks on validity from now on to have the list be as accurate as possible.
Disabled Triple-DES cipher suites by default (mitigating SWEET32).
Als ze mij zo een e-mail zouden sturen krijgen ze mijn C4 in bijlage terug. Als een overheidsinstantie zo omspringt met beveiliging kunnen ze mij onmogelijk genoeg betalen om er te blijven werken.
Ik heb geen idee wat een C4 is, behalve een compacte middeklasseauto en een explosieve stof, maar ik denk dat je punt is dat dit iets is dat niemand zou moeten accepteren. En dat ben ik met je eens. Ik heb een helpdesk meegemaakt die altijd om wachtwoorden vroeg. Die krijgen ze van mij gewoon niet. Als ik door beveiligingsupdates te installeren niet meer kan inloggen op een website die noodzakelijk is om mijn werk uit te kunnen voeren dan kan ik mijn werk niet uitvoeren. Geen beveiligingsupdates installeren is geen optie.
Kleine nuance is natuurlijk wel dat als het hier om het afraden van upgrades dus echt nieuwe versies, in plaats van beveiligingupdates, dan kan dat best even getolereerd worden.

[Reactie gewijzigd door 84hannes op 23 juli 2024 04:08]

In de zorg hoef je ze niet te vertellen hoor om niet te updaten, daar zijn ze zowieso al niet toe geneigd. Ik werk vaak voor grote zorginstellingen en het is mij wel duidelijk waarom er geen geld is om oma meer dan een keer in de week onder de douche te zetten. De hele toplaag functioneert gewoon totaal niet en kost veels te veel geld.
Inderdaad! Firefox ESR zal tot begin 2018 plugins ondersteunen. Dit is ook wat Mozilla zelf aanraad als je nog afhankelijk bent van plugins. Erg slecht dat het ministerie niet zoiets aanraadt.
Grote kans dat het gros van de applicaties niet goed werkt onder non-IE browser. Die beerput wil je echt niet opentrekken. :)

In sommige gevallen (DIS portal) is het zelfs met het aangeraden IE huilen met de pet op, doordat de server-kant niet altijd meewerkt.
Het probleem is dat veel EPD systemen alleen met Internet Explorer samen werken. Wij hebben als tweede browser google Chrome draaien op onze omgeving. Echter gebruikt het EPD dit niet. Dus als je Internet Explorer toch upgraded etc ben je de klos. Hiermee kunnen bijvoorbeeld geen verificatie zaken plaats vinden waardoor bepaalde handelingen niet uitgevoerd kunnen worden etc. Ook draaien wij op onze omgeving met Java 7.x en deze wordt gewoon niet geupdate omdat er anders meer applicaties om vallen. Ja sommige zaken lopen achter maar als je afhankelijk bent van leveranciers kun je zelf ook niet veel hoe graag je ook wilt.
Gelukkig zijn er ook EPD's die wel of juist in moderne browsers werken. Maar dan bestaat het probleem nog steeds, want het applicatielandschap van de gemiddelde zorginstelling bestaat uit weet ik veel hoeveel applicaties die nog steeds afhankelijk zijn van een (vaak ook nog eens antieke) IE-versie. De leveranciers die de zaakjes wel op orde hebben, zijn dan nog steeds afhankelijk van de vele leveranciers die dat niet hebben. En dan zie je dat het soms andersom gaat werken: van de leverancier die wel met moderne browsers werkt wordt verwacht dat deze antieke versies blijft ondersteunen "want die en die applicaties werken alleen in die versie". Zo komen we nooit vooruit met zijn allen. Hoewel er de laatste jaren al wel vooruitgang in zit en we niet meer zo veel te maken hebben met bedrijven die nog op IE 8 of 9 willen blijven.

[Reactie gewijzigd door voz op 23 juli 2024 04:08]

Het is niet zozeer het EPD maar allerlei ingebouwde plug-ins die via IE werken of aangeroepen worden. Een basis EPD werkt prima. Denk aan even röntgen beelden opvragen uit het dosier of andere zaken die bij de patiënt horen. Dat gaat meestal via weblinks naar bijvoorbeeld een PACS systeem. Ook hier komen weer plug-ins naar voren.

@Oef! hieronder een datalek is als er patient gegevens vrij inzichtelijk zijn of andere gegevens. Als je systeem niet meer werkt krijg je ook geen datalek. Hier wordt wel degelijk heel veel aandacht aan besteed! En afdwingen bij een leverancier wens ik je veel succes mee, is makkelijker over te praten dan het voor elkaar krijgen.
Wacht even, niet alleen Internet Explorer, maar ook ActiveX is sowieso iets van Microsoft Windows. Dit systeem dwingt zorgverleners dus gebruik te maken van IE op MS Windows.
Inderdaad. Een aantal jaren geleden kreeg mijn vrouw ook zo'n pas, en ik heb geprobeerd hem aan de praat te krijgen op haar Linux PC. IE lukte wel, in Wine, hoewel dat licentietechnisch natuurlijk niet helemaal lekker zit, en die paslezer deed het ook. Werd zonder meer herkend. Maar om de activeX module in IE zo gek te krijgen de Linux driver van de paslezer te gebruiken is me niet gelukt.
Jammer dat dit nog niet aangepakt is want bij allerlei andere zaken van de overheid, zoals digid en allerlei diensten van rvo.nl waar burgers en bedrijven niet omheen kunnen, zijn de laatste jaren steeds vaker eindelijk 'web based' gemaakt – op een manier waarbij je niet meer vast zat aan een Microsoft product.
Raar dit aangezien de UZI pas ook op (Ubuntu) Linux (met Firefox en Thunderbird) hoort te werken, volgens alle documenten / documentatie die ik vorig jaar heb gelezen. (die ik nu niet meer terug kan vinden) dus ik weet niet of er in de tussentijd dingen zijn veranderd waardoor het niet meer werkt maar daar ga ik niet vanuit.
Het is een tikkende tijdbom, als hier een datalek uitrolt worden jullie en je leverancier diep, diep ongelukkig. Ik heb bij verschillende softwarehuizen gewerkt en dit gaat normaal professioneler - je club mag en moet afdwingen dat het geregeld wordt.
Anoniem: 145867 @oef!22 september 2016 20:39
NSA smult van al die openstaande Europese informatie. Heerlijk !!! Bedrijfsinformatie, persoonlijke gegevens van iedereen... noem het maar op. :) Ze lachen zich rot. Als je ziet hoe ver ze gaan met Stuxnet zijn dit soort zaken een eitje.
Daar heb je een enorm punt. Jammer dat veel mensen dat niet begrijpen.
Wat ik er zo snel kan van vinden is een UZI-pas 'gewoon' een smartcard die ook gebruikt kan worden om op Windows mee in te loggen. Kunnen de PKCS11-mogelijkheden van browsers niet gebruikt worden ipv plug-ins?

[Reactie gewijzigd door Rafe op 23 juli 2024 04:08]

Dat kan als je de UZI pas puur wilt gebruiken als identificatie. Echter om te communiceren met het landelijk schakelpunt (LSP) is het nodig om XML berichten te signen met de pas, dat gaat niet met PCKS11 mogelijkheden van de browser.

Ik weet dat er al wel 2 leveranciers zijn die alternatieve oplossingen hebben gevonden die werken zonder Java plugin of ActiveX.
Ah, interessant! Is die XML toevallig SAML?
Nee een WS-security header. Hier kun je precies de opbouw zien: https://www.vzvz.nl/uploa...ichtauthenticatie_UZI.pdf
Dat is nou het probleem. Het hele medisch systeem van het land draait op Java. Die UZI-pas is dus alleen te gebruiken via Java in een browser omdat het systeem hier in het land zo geschreven is.
De taal op de backend maakt toch niet uit als er een browser nodig is om het (medische) systeem te benaderen?

Ben nog even verder wezen zoeken, in Chrome 54 (we zitten nu op 53) krijgt support voor de WebUSB API en voor ChromeOS is er al een Smart Card Connector plugin. Work in progress zo te zien.
Ja maar dan moet je nog tot 2020 wachten totdat Nederland hier iets mee gaat doen
Zonde. Het Belgische eID is ook zo'n pas en daar lijkt het wel te kunnen.
of gewoon maxthon 5 (beta)

deze ondersteund java en acticex nog zolang de communitie er animo voor heeft.
zolang mensen ernaar blijven vragen om het te behouden blijft het een feature.

anders zijn er genoeg addons die op browser level werken (dus niet in een shell in de browser)
die activeX activeren
Ja ondanks dat we dit wel aan hebben zien komen zijn het nu de IT leveranciers die allerhande wijzigingen moeten doorvoeren om tijdelijk de updates uit te zetten.

Los van het ASP platform wat wij hosten zit je met een versplintering van diverse HIS (Huisarts Informatie Systeem)

MicroHIS (lokale installaties en in house ASP)
OmniHIS Scipio (lokale installaties en in house ASP)
Promedico VDF (lokale server en werkplekken)
Pomedico ASP (eigen hosting Promedico)
Zorgdossier (in house ASP)
Callmanager (huisartenposten draaien hier veelal op, hosten wij ook voor 2 regio's)
Mira (niet zelf mee bekend)
Medicom (niet zelf mee bekend)

De impact KAN, als dit inderdaad verkeerd gaat gigantisch zijn. Het is tegenwoordig bij wet vastgesteld dat wanneer een arts of assistente iets wil kunnen doen met jouw medisch dossier, VERPLICHT ingelogd moet zijn met een UZI-pas. Goed geregeld dat diezelfde verplichting mogelijk het hele werken van huisarten en huisartsenposten onklaar maakt.

Dat betekent dus dat wij op ons ASP de updates uit moeten stellen, en nu is dat een paar klikken.
Maar alle lokale klanten, zowel server als werkstations remote de updates uitschakelen.
Goede "test" voor ons patch management, of eerder do-not-patch management.

[Reactie gewijzigd door Dograver op 23 juli 2024 04:08]

De impact KAN, als dit inderdaad verkeerd gaat gigantisch zijn. Het is tegenwoordig bij wet vastgesteld dat wanneer een arts of assistente iets wil kunnen doen met jouw medisch dossier, VERPLICHT ingelogd moet zijn met een UZI-pas. Goed geregeld dat diezelfde verplichting mogelijk het hele werken van huisarten en huisartsenposten onklaar maakt.

Dat betekent dus dat wij op ons ASP de updates uit moeten stellen, en nu is dat een paar klikken.
Maar alle lokale klanten, zowel server als werkstations remote de updates uitschakelen.
Goede "test" voor ons patch management, of eerder do-not-patch management.
Dat creeërt een enorme verantwoordelijkheid voor jullie dan.
Alle systemen die persoonsgegevens verwerken (en zeker privaat zwaar wegende gegevens zoals medische gegevens) zijn wettelijk verplicht om van toereikende beveiligingsmaatregelen te zijn voorzien.

Als er een data lek komt en daarbij uit het onderzoek rolt dat er bewust oude lekke software ingezet is, dan zijn bij jullie de rapen gaar.

(Eigenlijk is het bespottelijk dat het advies wat het ministerie van VWS uitgegeven heeft, lijnrecht tegen wetgeving ingaat.)
Klopt inderdaad, daarom waren wij ook reuze enthousiast om de browser plugin van java te moeten activeren om de uzipas software te kunnen draaien. :+
Ja ondanks dat we dit wel aan hebben zien komen zijn het nu de IT leveranciers die allerhande wijzigingen moeten doorvoeren om tijdelijk de updates uit te zetten.

Los van het ASP platform wat wij hosten zit je met een versplintering van diverse HIS (Huisarts Informatie Systeem)

MicroHIS (lokale installaties en in house ASP)
OmniHIS Scipio (lokale installaties en in house ASP)
Promedico VDF (lokale server en werkplekken)
Pomedico ASP (eigen hosting Promedico)
Zorgdossier (in house ASP)
Callmanager (huisartenposten draaien hier veelal op, hosten wij ook voor 2 regio's)
Mira (niet zelf mee bekend)
Medicom (niet zelf mee bekend)

De impact KAN, als dit inderdaad verkeerd gaat gigantisch zijn. Het is tegenwoordig bij wet vastgesteld dat wanneer een arts of assistente iets wil kunnen doen met jouw medisch dossier, VERPLICHT ingelogd moet zijn met een UZI-pas. Goed geregeld dat diezelfde verplichting mogelijk het hele werken van huisarten en huisartsenposten onklaar maakt.

Dat betekent dus dat wij op ons ASP de updates uit moeten stellen, en nu is dat een paar klikken.
Maar alle lokale klanten, zowel server als werkstations remote de updates uitschakelen.
Goede "test" voor ons patch management, of eerder do-not-patch management.
En in dat soort systemen staat/communiceert mijn elektronische patiënten dossier (of hoe het nieuwe equivalent daarvan dan ook maar mag heten)?
Een HIS is een applicatielaag om de patiëntinformatie heen, de data zelf staat op servers (niet lokaal). Ditzelfde geldt voor een AIS (Apotheek Informatie Systeem) zoals bijv. Pharmacom,
Er kunnen, mits je daar zelf toestemming voor hebt gegeven, gedeeltes van jouw dossier in een soort cloud staan ja. Wel een kleine verlichting van de druk dat de communicatie daarnaartoe wel voornamelijk over speciaal ingerichte zorgverbindingen gaat, dan al niet verplicht over een zorgverbinding zoals E-Zorg of St. Gerrit.

Neemt niet weg dat er altijd een risicofactor aanwezig blijft.

[Reactie gewijzigd door Dograver op 23 juli 2024 04:08]

Er kunnen, mits je daar zelf toestemming voor hebt gegeven, gedeeltes van jouw dossier in een soort cloud staan ja. Wel een kleine verlichting van de druk dat de communicatie daarnaartoe wel voornamelijk over speciaal ingerichte zorgverbindingen gaat, dan al niet verplicht over een zorgverbinding zoals E-Zorg of St. Gerrit.

Neemt niet weg dat er altijd een risicofactor aanwezig blijft.
Een risicofactor?! Als er zoveel verschillende systemen mijn data verwerken. Systemen die door verschillende mensen/bedrijven gebouwd zijn in het heden en verleden. Data die zo veel verschillende mensen in kunnen zien, kunnen kopiëren en eventueel cracken (1 stukje spyware op 1 computer van 1 van de ~10.000'en mensen die potentieel toegang hebben tot mijn dossier is genoeg).

Dan is dat IMO niet "een risicofactor" dat is eerder een regelrechte garantie dat het een keer helemaal mis gaat.

Ik ga mijn toestemming voor het LSP volgende week nog intrekken. Al is het alleen al, omdat ik hier niet (bewust) toestemming voor heb gegeven en omdat toestemming intrekken alleen via de huisarts kan (niet via DigiD = wtf).

[Reactie gewijzigd door GeoBeo op 23 juli 2024 04:08]

Java heeft geen feilloze reputatie op het gebied van veiligheid en is vaak slachtoffer van zero-day-kwetsbaarheden geweest.
Correctie: De Java browser plug-in heeft geen feilloze reputatie op het gebied van veiligheid. Met Java op de server is weinig mis op het gebied van veiligheid. (Voordat er weer honderd mensen gaan roepen dat Java crap is omdat ze denken dat Java alleen maar bestaat uit de browser plug-in).
Correctie: De Java browser plug-in heeft geen feilloze reputatie op het gebied van veiligheid. Met Java op de server is weinig mis op het gebied van veiligheid. (Voordat er weer honderd mensen gaan roepen dat Java crap is omdat ze denken dat Java alleen maar bestaat uit de browser plug-in).
Daar ga je toch wel even ergens de mist in, als jij lokaal, op welke manier dan ook, een software versie draait die te exploiteren valt, en er een aanval via een andere weg dan die plugin binnenkomt, ben je alsnog de sjaak.
Ik zei dus Java op de server, niet Java lokaal op je desktop of laptop. Het grote succes van Java is op het gebied van serversoftware, niet op client computers.
Dit. Het is een solide programmeertaal en wordt in het bedrijfsleven (en inderdaad op servers) nog enorm veel gebruikt.
Tegenwoordig worden er met Java ook talloze normale websites gemaakt.
Geen plugin maar gewoon HTML code.

Veel fijner om met Java websites te maken dan met PHP bijvoorbeeld.
Niet alleen tegenwoordig. Je kunt al jaren web front end schrijven met frameworks zoals Wicket, Struts, Spring MVC, GWT etc, of simpel jsp.

Server side staat Java nog altijd aan de top in termen van onderhoudbaarheid, support en ecosysteem. Bovendien zijn er redelijk wat programmeurs te vinden die het redelijk beheersen, dat is met bijv Scala of Erlang een stuk lastiger.
Heb je daar een voorbeeld van..?

Edit:
Bedankt allemaal voor de -1, ik ben oprecht benieuwd omdat ik er nog nooit van heb gehoord ;)

[Reactie gewijzigd door SilentLucidity op 23 juli 2024 04:08]

Met Spring, SpringBoot worden genoeg Java websites gemaakt. Die HTML uitpoepen.

https://spring.io/guides/gs/serving-web-content/
Ziet er wel tof uit. Ik kende het principe backend (API) in Java schrijven, maar dan moest je alsnog zelf de frontend bouwen (dan wel in een framework) en het dan werkend krijgen mbv API calls.
Als die backend JSON uit kan spugen is HTML ook zo moeilijk ;)
Tweakers heeft er zelfs samen met Capgemini een advertorial (advertentie + tutorial) over gemaakt afgelopen jaar:
https://tweakers.net/advertorials/onlinejavaacademy2/
Ben je niet in de war met javascript ? Dat is iets heel anders namelijk, dat alleen om marketingredenen een naam heeft gekregen die op java lijkt.
Belastingdienst is een voorbeeld. Bijna al hun websites draaien op Java EE op de backend. Het hele aangifte doen ook bijvoorbeeld. Meestal wel in combinatie met bijvoorbeeld Angular aan de voorkant. Dit is inderdaad wel een Javascript framework.

Bron: Ik heb een tijdje stage gelopen op de software engineer afdeling.

[Reactie gewijzigd door Nardon op 23 juli 2024 04:08]

Dat is waarom ik in een andere reactie om een voorbeeld vroeg, want de backend heeft dan in feite niets te maken met wat de browser ziet (het framework) dus is de site eigenlijk niet in Java gemaakt.
Je kunt gewoon een website in Java maken net zoals je een website met bijvoorbeeld C#/ASP.NET, of PHP kan maken.

https://netbeans.org/kb/d...-webapps.html#creatingJSP

[Reactie gewijzigd door keesdewit op 23 juli 2024 04:08]

Neuj. Java applicatie met built in HTTP server, templating engine erin, en hoppakee.
Wij gebruik Java voornamelijk voor Solr. Om een intranet door fysieke documenten te laten zoeken (office en pdf bestanden).
Java heeft geen feilloze reputatie omdat je bij installatie van de JRE of JDK automatisch de browser plug-in op je systeem krijgt, of je wilde of niet.
De conclusie dat Java onveilig is, is dan niet zo een vreemde. Het onderscheid wat je maakt klopt, maar is voor de reguliere gebruiker niet relevant.

edit: hoe het tegenwoordig zit weet ik niet precies, JRE applicaties voor de desktop komen er bij mij al heel lang niet meer in, maar de reputatie van Java is natuurlijk gebaseerd op het verleden, dwz. de afgelopen 15 jaar. En destijds werd de plug-in gewoon in je browser geïnstalleerd. Dat dat tegenwoordig niet meer lukt is te danken aan de browsers die wijs geworden zijn, niet omdat de Java installer het niet probeert.
En als je dan de plug-in verwijderd had, vanwege niet nodig en niet veilig, dan werd bij de volgende update het ding gewoon weer teruggezet. Weer zonder vragen natuurlijk.
En daar komt die crapware reputatie dus vandaan. En terecht.

[Reactie gewijzigd door locke960 op 23 juli 2024 04:08]

Uh nee? De browserplugin staat standaard gewoon uit.
Ze worden wel standaard mee geïnstalleerd, alleen moet je bijvoorbeeld bij IE11 zelf kiezen of je bij de eerste browser start de plugin wilt activeren of niet.
Hoe het precies zit bij Firefox weet ik niet, ik meende dat het daar standaard aanstond, Firefox ondersteund het momenteel nog wel.
Sinds Chrome 45 is er geen Java plugin meer mogelijk, geen NPAPI ondersteuning meer.
Het is een combinatie van. Java opzich is niet slecht, de manier waarop het vaak word gebruikt echter wel. Java haalt af en toe dingen die wel gebruikt worden weg, waardoor het voor bepaalde software noodzakelijk is dat je een oudere versie blijft gebruiken. Zeker als het gaat om software die je niet zo maar even vervangt, kan het lastig zijn om deze te vervangen voor andere software of zelfs om te updaten als de mogelijkheid niet bestaat of als het bedrijfskritisch is waardoor het langer kan duren. Precies om die reden heb ik op dit moment 5 verschillende Java versies op mijn computer staan, alleen om noodzakelijke software te kunnen blijven gebruiken. Als je daarnaast andere functionaliteit gaat schrappen die gebruikers nodig hebben om websites te gebruiken, dan zal het algehele beeld niet echt gaan verbeteren. Ik heb persoonlijk ook geen hekel aan de browser plugin, maar wel aan de normale Java versie die lokaal op een systeem gedraaid word. Dat is voor mij een bron van irritatie. Er zijn echt wel goede manieren om Java te implementeren en als dat goed gedaan is, zal je vaak niet eens door hebben dat er Java word gebruikt. De problemen zijn echter de graadmeter voor de ervaring van mensen.
Onzin, Java is enorm backwards compatible, vooral met anderen vergeleken. Wat voor incompatible changes zijn dit wel niet.
Cilph heeft gelijk, Oracle (en vroeger Sun) passen heel goed op dat nieuwe Java versies backward compatible zijn met oude versies en ze halen niets weg (wat ook wel weer een nadeel is, want oude, slecht ontworpen classes blijven bestaan).

Als je programma niet werkt op een nieuwe Java-versie dan komt dat waarschijnlijk doordat jij zelf iets slordig hebt geprogrammeerd (bijvoorbeeld door interne API's te gebruiken die niet officieel worden ondersteund).
ik programmeer niet. sterker nog, ik kan dat niet. De software komt van leveranciers. Als je zegt dat het slecht is geprogrammeerd en dat dat het probleem is, zou ik het melden bij CISCO onder andere.
Ja, Java is al een tijd lang open source. Zie het OpenJDK project.
Het is natuurlijk een heel slecht advies om je gebruikers te vertellen dat ze hun updates moeten stopzetten. Zeker in een branche waar met uiterst betrouwbare gegevens gewerkt wordt. Het is inmiddels al zo lang bekend dat Java langzamerhand niet meer in de browser ondersteunt wordt. Ze hadden daar veel eerder op moeten anticiperen. Nu heeft mijn arts straks een onveilige browser en liggen derhalve mijn gegevens op straat als hij gehackt wordt. Als je in staat bent om dit soort adviezen uit te geven dan ga ik op zijn minst twijfelen aan de veiligheid van het onderliggende systeem. Zijn daar ook dergelijke concessies gedaan?
Het zou wel fijn zijn als er voor alle browsers een open-standaard komt dat OS onafhankelijk is en waarmee je authenticatie en autorisatie kan regelen die ook externe hardware aan kan sturen. Zoveel browser engines zijn er niet meer dus zo moeilijk hoeft het niet te zijn om hierover onderlingen afspraken te maken.
Het zou wel fijn zijn als er voor alle browsers een open-standaard komt dat OS onafhankelijk is en waarmee je authenticatie en autorisatie kan regelen die ook externe hardware aan kan sturen.
Dat bestaat al in bepaalde mate. Desktop browsers kunnen van smartcard readers gebruik maken voor client-side authenticatie. IE (en mogelijk Edge) en Chrome onder Windows maken gebruik van Microsoft's CryptoAPI. Een smartcard ontwikkelaar moet daarvoor een Cryptographic Service Provider of Key Service Provider/Cryptography Next Generation Provider ontwikkelen als het niet de provider van Microsoft kan gebruiken. Firefox heeft ondersteuning voor PKCS#11, een soortgelijke (en open) interface.

Dus PKCS#11 is de open standaard waar je om vraagt. Echter ondersteunen niet alle browsers en smartcard readers die standaard. Een beperking is dat de smartcard (reader) middleware specifiek gecompileerd moet worden voor een specifieke architectuur en besturingssysteem.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 04:08]

En wat Sv3n hierboven zegt: niet alle benodigde functionaliteit is vanuit deze frameworks toegankelijk. Naast het signen ook bijvoorbeeld de detectie dat de pas eruit wordt getrokken.
Binnen de W3C is zo'n standaardisatietraject bezig.
Nou duren die standaardisatieprocess vaak wel enorm lang, maar er zit in ieder geval goede voorgang in, en ook verschillende browserbouwers zijn vertegenwoordigd in de Working Group.

https://www.w3.org/2015/12/web-authentication-charter.html
Dus veiligheidsupdates van de browser moeten ook genegeerd worden?
juist die veiligheidsupdates zijn in kwestie de reden dat het niet meer werkt. Java en activeX zijn erg onveilig
ActiveX is zelf is niet onveilig overigens. Het heeft die reputatie gekregen uit de begindagen toen er nog geen sandbox was. ActiveX is in feite gewoone en API rondom COM waarmee je plugins kunt maken. Maar als die plugins allerlei functies en API's aanroepen waar 'hoge' rechten voor nodig zijn heb je een probleem.

De laatste generatie van ActiveX pluigins draait gewoon in enhanced proteced mode, hetgeen hetzelfde afscherming is is als een universal 'app' op Windows 8/8.1/10 en dezelfde bescherming als Edge standaard heeft. Volledig afgeschermd van je systeem, gebruikersdata, interne netwerk, etc.

Probleem is dat veel bedrijfs-plugins stopt met werken als ze in die sandbox moeten werken omdat ze juist allerlei netwerk en systeem toegang vereist.
En daarmee is dit advies dus des te kwalijker. De gebruikte techniek is al verouderd, blijkbaar is er te laat geinvesteerd in de ontwikkeling van een opvolger, en nu adviseert men om vooral geen updates te installeren. Dit riekt naar het paard voor de wagen spannen.
Bedoel je niet het paard achter de wagen spannen?
Een paard voor de wagen is juist vooruit gaan ;)
Gelukkig zag je dit 5 jaar geleden nog niet aankomen, dat scheelt.
Vindt het een ernstige zaak. Mede daar deze UZI-pas onderdeel is van het EPD waarmee een zorgverlener toegang krijgt tot die gegevens.

Onbegrijpelijk dat men dit niet al vroegtijdig heeft afgevangen.
Hét EPD bestaat toch niet meer? Iedere zorginstelling heeft zijn eigen dingetje volgens mij.
Nee, EPD bestaat nog wel (aldus mijn arts) maar sommige instellingen hebben een eigen systeem voor als jij je gegevens niet met het EPD wilt delen.

Zo heb ik expliciet aangegeven dat ik niet wil dat ziekenhuizen en de artsen tussen elkaar gegevens delen, als ik dus bij de meeste bezochte ziekenhuis mijn gegevens inzie zie ik alleen de dingen die daar gebeurt zijn, geldt ook voor hun.

Reden dat ik het niet toe stond? Ik vind het een gebrekkig en onveilig systeem.
Het EPD is er nooit gekomen. Er wordt nu gebruik gemaakt van het LSP, Landelijk SchakelPunt.
Om hier toegang voor te krijgen moet elke zorgverlener in het systeem van de betreffende instelling inloggen met de UZIpas.
Verschil met het EPD is dat er geen medische informatie centraal wordt opgeslagen. Er wordt alleen een "vlag" geplaatst of een patiënt toestemming heeft gegeven voor de uitwisseling.
Zo ja dan kunnen gegevens als medicatiehistorie, belangrijke ziektes, recente contacten, allergieen etc opgehaald worden.

Heel fijn dat we nu niet meer mogen updaten!

En ik was al een enorme fan van het hele LSP (/end sarcasmemodus ) |:(

[Reactie gewijzigd door martinx76 op 23 juli 2024 04:08]

Inderdaad. Maarbuiteindelijk is het LSP gewoon een decentraal EPD. Onderhouden door onder andere..... De verzekeraars.
Ja duh...
1. als je alle computers die ergens via een internetkabel zijn aangesloten gaat bekijken kun j e wel van elk project zeggen dat het decentraal opgeslagen is.
Het werkt enorm verwarrend om van een EPD te blijven spreken.
Die term houdt in dat elke toch een centrale toegang is. Dat is dus pertinent niet waar. Daarnaast kun je heel gemakkelijk de toegang tot het LSP aan of uitzetten.
2. Dat onderhouden door de zorgverzekeraars geldt dan ook voor elke huisartsenpraktijk, apotheek, fysiotherapiepraktijk ziekenhuis.... Etc etc. Voor al deze voorzieningen worden kosten (deels ) betaald door de zorgverzekeraars.
Maar dat betekent niet dat ze de boel runnen...
Het LSP is ook zo'n voorziening.
Referentie: https://www.vzvz.nl/page/...ol-van-de-zorgverzekeraar

Een aantal punten in de zorg kan met het LSP zeker verbeteren.
Bijvoorbeeld doordat je medicatiebewaking geautomatiseerd kan laten verlopen.
Daar zit bijv ook winst voor de zorgverzekeraars. Er belanden per jaar veel mensen in het ziekenhuis Door "fouten" met medicijnen, deels is dit te voorkomen Door de computers hun bewaking te laten doen.
gevolg is dat als je nee zegt tegen het LSP jezelf altijd een up-to-date Actueel Medicatie Overzicht bij je moet hebben. Die kun je krijgen bij je apotheek.

Let wel ik ben geen onverdeeld voorstander van het LSP ik denk dat iedereen zijn eigen keus naar en moet maken.
Maar dan wel met correcte informatie.
Bedankt voor je uitleg.
Haha, jij dacht dat de overheid naar de leverancier luisterde die aangaf dat er wat moest veranderen? Het werkt nu toch?
Dit is natuurlijk geen goede oplossing, kunnen ze niet zelf een '' browser '' of programma maken die alleen hun eigen service ondersteunt?
Hadden ze misschien al veel eerder moeten doen, waren ze niet meer afhankelijk van andere partijen.
Nee, alsjeblieft niet! Dan moet je op elke computer waar je wilt Internetbankieren een desktopprogramma gaan installeren. Van dat programma moeten dan versies gemaakt worden voor op z'n minst Windows en macOS. Mensen die een apparaat hebben met bijvoorbeeld Linux of ChromeOS kunnen het vergeten. En in die programma's zitten dan waarschijnlijk weer allemaal veiligheidslekken die moeten worden gedicht.

[Reactie gewijzigd door jj71 op 23 juli 2024 04:08]

Het gebruikers gemak gaat er inderdaad ten koste van, maar om niet je browser up te daten... lijkt me geen goed idee.

Ik zie zelf ook liever dat alle plug-ins gewoon beschikbaar blijven en dat de gebruiker dan kan kiezen als de website een mogelijk onveilige plug-in wil laden dat er dan een pop-up venster o.i.d. tevoorschijn komt waar je dan kunt kiezen van als je dat wilt uitvoeren of niet.

Waarschuwen is prima, eventueel dubbel waarschuwen ook, maar om het helemaal niet toe te staan is wat mij betreft geen optie, hoe gevaarlijk die plug-in ook is.

Google Chrome blokkeerd zelfs al gedownloade bestanden, wat min of meer niet te omzeilen is dus ben ik dan gedwongen om op dat moment een andere browser te gebruiken.
Nee, alsjeblieft niet! Dan moet je op elke computer waar je wilt Internetbankieren een desktopprogramma gaan installeren.
Deden we vroeger niet anders met Girotel ;)
Blij dat we van Viditel afwaren :)

*zucht*, ik word oud...
Aan de andere kant, het offline bankieren had vroeger ook voordelen. Zo had je bijvoorbeeld een "oneindige" historie aan transactie gegevens. Nu zijn online deze gegevens na een jaar ofzo niet mee beschikbaar. Waardeloos!! Zoveel data is dat ook weer niet. Alleen op aanvraag, en tegen betaling kan je oude gegevens weer opvragen.
Goed idee, laten we het een “app” noemen!
ING zakelijk is sinds kort ook gestopt met USB paslezers in verband met het verdwijnen van de Java plugin. De dames en heer van de administratie klagen nu steen en been dat ze zelf weer codes moeten intoetsen. :p
Data versturen via USB kan ook zonder Java. Het apparaat dat de data verstuurt kan zich immers voordoen als tweede toetsenbord en de data "intypen".

Uiteraard niet geschikt voor grote hoeveelheden data, maar prima voor een bankcode die je anders toch zelf intypt. (Zo werken veel barcode scanners ook. )

Enfin, de oplossing van de ING is natuurlijk goedkoper, voor hen.
ABN Amro doet dat via een eigen softwarepakket, ING had daar de laatste Java versie voor nodig (zodra er een update was, meldde ING het al dat er niet de laatste versie werd uitgevoerd),.
En staat er in de email ook wanneer er een echte oplossing komt? Of wordt dat UZI-register überhaupt uitgefaseerd? We hebben de laatste jaren zoveel extra geld in de zorg gepompt dat er echt geen hand meer aan het bed de vergadertafel bij kan, dan zouden dit soort dingen toch eigenlijk niet meer mogen voorkomen.
Mail? Ik heb gewoon een ouderwetse brief gekregen hoor. Meer dan "aan een oplossing wordt gewerkt" staat er niet in.

Op dit item kan niet meer gereageerd worden.