Minister: gebruik onveilige Java-versie door huisartsen was onwenselijk

Minister Schippers van VWS noemt het gedwongen gebruik van een onveilige Java-versie door huisartsen onwenselijk. Ze deed dit in antwoord op Kamervragen. Het CBP moet bekijken of aan de wettelijke eisen is voldaan.

D66-Kamerlid Pia Dijkstra diende begin deze maand Kamervragen in naar aanleiding van een artikel op Tweakers over een veiligheidskwestie bij het beheren van patiëntendossiers door huisartsen. Hun werd door Promedico, het bedrijf achter een inlogsysteem, met klem geadviseerd om update 21 van Java 7 niet te installeren. Werd dit wel gedaan, dan konden artsen niet inloggen met behulp van een Uzi-pas, een door de overheid uitgerold authenticatiemechanisme. Doordat artsen Java niet konden bijwerken, werden zij kwetsbaar door tal van veiligheidsgaten in verouderde Java-versies.

D66 stelde dat Promedico de wettelijke bepalingen voor gegevensbescherming heeft overtreden door een verouderde en onveilige Java-versie te vereisen. De minister wil in de beantwoording van de Kamervragen zo ver niet gaan, maar spreekt wel over een 'onwenselijke situatie'. Schippers meent echter dat het College Bescherming Persoonsgegevens moet bepalen of Promedico aan de vereiste wettelijke regels voor gegevensbescherming heeft voldaan.

Minister Schippers schrijft verder dat zowel zorgaanbieders als de leveranciers de wettelijke plicht hebben software voor medici adequaat te beveiligen. Verder heeft Promedico aangegeven dat bij hen niet bekend is of computers met de desbetreffende verouderde Java-versie daadwerkelijk zijn overgenomen, maar het bedrijf erkent dat er beveiligingsproblemen waren. In totaal zouden er 134 huisartenpraktijken zijn geweest die een Uzi-pas gebruiken in combinatie met een kwetsbare Java-versie.

Inmiddels is de software zo aangepast dat deze weer samenwerkt met recente Java-versies. Ook belooft het bedrijf, nadat het in allerhaast zijn software van een update had voorzien, er alles aan te zullen doen om herhaling te voorkomen.

<

Reacties (59)

[thetrueman2]

Tja, een moeilijke kwestie natuurlijk. Aan de ene kant wil men niet dat er beveiligingsgaten kunnen worden misbruikt, maar het te snel (onzorgvuldig) uitrollen van een update brengt ook risicos met zich mee.

Ik heb zelf weinig ervaring met het uitrollen van dergelijke updates, maar als men kan zien waar de API is veranderd dan zou je toch zeggen dat een update niet zo heel erg lang op zich laat wachten? of zie ik dit verkeerd?

[Niemand_Anders]

Een update HOORT de api niet te wijzigen! Dan betreft het namelijk geen update, maar een upgrade. Als jij een applicatie maakt op basis van Java 7, update 17, dan moet deze nog ook nog steeds werken met update 73..

Promedico mag er vanuit gaan dat bij een update van versie 17 naar 21 de API niet wijzigt. Daarbij heeft Promedico geen zeggenschap over de PC van de gebruiker en moet deze zelf zorgen dat deze veilig is. Oracle is hier degene welke hier een breaking-change doorvoert in een beveiligings update. Vervolgens krijgt Promedico allerlei telefoontjes dat huisartsen niet meer kunnen inloggen en zij vragen of de klant recentelijk software heeft geinstalleerd of geupdated. Dan komt naar voren dat een groep welke update 21 heeft geinstalleerd 'ineens' niet meer kan inloggen.

Dat is natuurlijk niet de schuld van Promedico, alleen zitten zij uiteindelijk wel met het probleem.
Dan zijn er twee oplossingen:
1. Huisarts het systeem niet meer laten gebruiken of een andere inlog methode te gebruiken anders dan de uzi-pas.
2. Huisartsen adviseren de update niet te installeren totdat probleem achterhaald en hersteld is.

Als patient zit je ook niet te wachten op een huisarts welke niet kan inloggen in het systeem..

[latka]

Leuk verhaal maar ik gebruik genoeg platformen (waaronder Java) om je te melden dat dit in de praktijk anders loopt. Ik ken niet dit specifieke issue, maar een ander issue wat ik wel van nabij ken is de SSL/TLS fixes nav. Beast attacks: niet fixen of compatible fixen blijf je vulnerable. Moet je toch een upgrade uitbrengen of het niet fixen (niet acceptabel) In het geval van de SSL fixes is er gekozen voor een fix met gelijke API en moet je wat parameters zetten om het oude (nog steeds lekke) gedrag te krijgen. Default is veilig geworden en voor meer dan 90% van de applicaties is er geen impact. Is het dan een upgrade? Gedrag is iig. gewijzigd.

[Verwijderd]

Dus: Zeer urgent de applicatie aanpassen en updaten. Ik zie geen andere oplossing bij dit probleem.

[R4gnax]

Dat is natuurlijk niet de schuld van Promedico, alleen zitten zij uiteindelijk wel met het probleem.

Tenzij Promedico's originele code dingen deed die volgens platform documentatie niet mochten of waar niet op gerekend mocht worden, maar toevalligerwijs wel werkten in de versie van Java waar tegen het product gebouwd werd.

Daarnaast werd er misschien ook wel gebruik gemaakt van reflection om aan interne componenten uit andere code (bijv. in de base libraries van Java) te komen. Daar bestaat ook geen garantie bij dat het allemaal blijft werken bij minor version updates. (Het maakt immers geen deel uit van publieke APIs en is dus 'veranderlijk'.)

[Reactie gewijzigd door R4gnax op 25 juli 2024 09:58]

[djwice]

Een update HOORT de api niet te wijzigen! Dan betreft het namelijk geen update, maar een upgrade. Als jij een applicatie maakt op basis van Java 7, update 17, dan moet deze nog ook nog steeds werken met update 73..

Promedico mag er vanuit gaan dat bij een update van versie 17 naar 21 de API niet wijzigt. Oracle is hier degene welke hier een breaking-change doorvoert in een beveiligings update. Dan komt naar voren dat een groep welke update 21 heeft geinstalleerd 'ineens' niet meer kan inloggen.

Dat is natuurlijk niet de schuld van Promedico, alleen zitten zij uiteindelijk wel met het probleem.

Dat Promedico op een foutieve manier (onveilige manier) een bepaald onderdeel van de API aansprak, welke door de update onmogelijk is gemaakt is niet te verwijten aan Oracle.
Het mogelijk zijn van deze onwenselijke manier van aanspreken was een bug welke tot een vulnerability leidde.
Je kunt dan drie dingen verwijten;

• Promedico dat ze hun software onveilig ontwikkelen
• Promedico dat ze in hun hele OTA-straat maanden lang een aanbevolen Java update niet uitvoeren (anders hadden ze zelf het probleem ontdekt)
• Oracle dat ze niet eerder de fix, dit deze manier van coderen onmogelijk maakte, hebben uitgebracht.

Mijn mening is dat als je software ontwikkeld die privacy gevoelige gegevens verwerkt, dat je moet zorgen dat de authenticatie module gemaakt is conform best practices. In Java zou dat niet al te ingewikkeld moeten zijn.

Fijn trouwens dat de minister mijn mening deelt m.b.t. het CBP in deze situatie.

[scuro]

Wat een paniek om niets. Oude browserversies, Flash, Java, Windows. Allemaal software waar beveiligingsgaten inzitten die de PC van de gebruiker(!) kwetsbaar maken. In de berichtgeving wordt gedaan alsof de dossiers hiermee op straat kwamen te liggen, terwijl dit niets met elkaar te maken heeft. De PC van de gebruikers is kwetsbaarder geweest door dit advies. Het systeem van Promedico zelf niet.

[CUnknown]

Ik weet niet waarom dit omhoog gemod wordt, maar dit is natuurlijk onzin. Een systeem is zo sterk als de zwakste schakel. Als een geïnfecteerd systeem toegang krijgt tot het Promedico systeem, is het systeem hiermee direct kwetsbaar. Wanneer een aanvaller tegen een goed beveiligde muur aanloopt bij het direct aanvallen van de Promedico backend, gaat de aanvaller natuurlijk op zoek naar systemen waar Promedico wel graag mee wilt praten: de pc van de gebruikers die een valide inlogcertificaat hebben. De communicatie van de aanvaller via deze pc wordt door het Promedico systeem geaccepteerd als integer en valide, waardoor de aanvaller nog steeds schade kan doen aan het, op zichzelf goed beveiligde, Promedico systeem. Dossiers kunnen ook via deze kwetsbare pc van de gebruiker op straat terechtkomen.

[Reactie gewijzigd door CUnknown op 25 juli 2024 09:58]

[scuro]

Het is inderdaad waar dat dossiers kunnen lekker via een besmette PC. Maar mijn punt is dat deze client PC's nog talloze andere kwetbaarheden kennen! Het is dus een beetje symboolpolitiek om nu heel hard boe te gaan roepen om deze kwestie. Het probleem is namelijk veel groter dan een Java versie die niet up-to-date is.

[CUnknown]

Kwetsbaarheden in een systeem houd je altijd, maar bekende kwetsbaarheden bewust niet repareren is het probleem waar ophef over gemaakt wordt. Een update is er niet voor niets, deze dicht tal van bekende lekken. Bekende lekken zijn door alle aanvallers altijd nog makkelijker te exploiteren dan wanneer ze zelf met een nieuw lek op de proppen moeten komen. Vaak is een succesvolle aanval ook een combinatie van exploits. Heb ik een grotere set van bekende lekken in een systeem (doordat er al een langere tijd niet is geupdate), dan wordt het puzzeltje van combineren van exploits om tot mijn uiteindelijke doel te komen makkelijker. Als je met dergelijk gevoelige informatie werkt moet je zorgen dat je deze speelruimte voor een aanvaller ten alle tijden tot een minimum beperkt.

[BoringDay]

Leuk en aardig dat je alles gaat updaten. Maar als er om wat voor reden die pas niet meer werkt zal er eerst de oorzaak en reden van bekend moeten worden. Dan moet je nog weten hoe je het moet oplossen, uitwerken, testen en documenteren.

Dat kost eenmaal tijd en een probleem kan misschien simpel zijn je het binnen een uurtje hebt opgelost, het kan ook zijn je weken er voor nodig hebt of erger nog van derden afhankelijk bent. Ik denk de ontwikkelaars ook niet veel meer aan kunnen doen dan hun best doen.

[To_Tall]

LoL.. een dag na het artikel was het lek gedicht.. Dus de oorzaak, oplossing ed waren er al.. Ze gaven alleen aan dat er uitgebreid getest moest worden..

Maar helaas wilde ze waarschijnlijk niet overwerken om het systeem te testen in OTAP.. Dat is zeer kwalijk.. Zo'n test plan moet standaard aanwezig zijn.. en de Testers zullen moeten weten cq opgeleid zijn om het component te testen..

Dat zou vrij snel moeten kunnen gezien er niets kwa functionaliteit niets veranderd..

[BoringDay]

Misschien hebben ze al keihard gewerkt? soms kan je beter een avondje goed rusten, goed slapen en met een frisse geest gaan testen. Mensen zijn geen machines.

Testen een opleiding? kwestie van goede checklist doorlopen, debuggen ...

[CUnknown]

Testen is een vak ja. Testen kun je op basis van verschillende manieren, op basis van een checklist specifieke punten testen is daar een van. Maar dan heb je zeker nog niet alles getest. Wanneer je goede testcases ontwerpt waarbij zoveel mogelijk uitzonderlijke situaties gecombineerd worden, is dit zeker veel werk en ook een expertise.

[anboni]

Maar laten die kwetsbare systemen van nou net deze gebruikers hoogstwaarschijnlijk vol staan met gevoelige gegevens...

[scuro]

Het betreft een webapplicatie, dus de dossiers staan niet lokaal.

En daarnaast bevestig je gewoon mijn punt. Want waar ligt de grens? Overtreed je de wettelijke bepalingen ook als je gebruikers met IE7 laat inloggen? Of windows XP zonder virusscanner?

[To_Tall]

Ja voor dit soort instellingen is het verboden om met onvelige systemen te werken..

Zo zijn bepaalde instanties verplicht om aan te tonen dat zij met systemen werken die volledig geupdate zijn.. Voldoe je niet aan die eis, en wordt hierdoor de kans groter dat gevoelige informatie zoals persoons gegevens opstraat komen te liggen. Zal daar een grote boeten aan worden gehangen...

Dus Ja huisartsen zijn verplicht om hun systemen up-to date te houden zodat de kans kleiner. Windows XP mag door gebrek aan support door MS dadelijk dus ook niet meer gebruikt worden.. En zullen die bedrijven versneld nieuwe systemen moeten neerzetten..

En ja jouw gegevens staan ook lokaal op die computers.. Artsen kunnen de gegevens in Promedico delen. Dat houd niet in dat een arts ook deze gegevens lokaal heeft staan. of zelfs in dossier vorm in de kast..

[Steef435]

Het systeem dat toegang heeft tot het systeem van Promedico is kwetsbaarder geweest.
Ik snap eerlijk gezegd sowieso niet dat hier Java voor gebruikt wordt. Zal wel zijn gesubsidieerd door de NSA

[proatjeboksem]

diversiteit in gebruikte apparatuur (zowel bij klanten als bij UZI) & software vs. ontwikkelkosten ==> Java

[Huismus]

Orly. We hebben een kamerlid nodig om te zeggen dat dit onwenselijk was?
Oh dank u wel meneer ik dacht dat het wenselijk was maar nu weet ik beter ...[/cynisme]

Ik vind eerlijk gezegd dat het een beetje overdreven is. Ja, tuurlijk is het onwenselijk, maar het is opgelost. Misschien moet Pormedico er over nadenken hun Java-applets te vervangen, maar ik denk dat ze zelf ook wel op dat idee gekomen waren.

[RSpliet]

Ja, helaas hebben we een kamerlid nodig om dit te herhalen. Wij techneuten op Tweakers weten natuurlijk allang dat een onveilige Java versie onwenselijk is, maar kamerleden zijn een van de weinige mensen met de macht om dit probleem in de toekomst daadwerkelijk te voorkomen. Het zou mij niets verbazen als zelfs de techneuten bij de overheid maar al te vaak aan de kant worden geschoven zijnde niet relevant wanneer ze een probleem aankaarten, totdat er publieke "vernedering" als deze plaatsvindt. Sneu dat het zo werkt, maar ik ben blij dat dit besef is doorgedrongen tot ministers dus.

[tweaker2010]

Dit kamerlid heeft Bestuurslid ICT Instituut in de Zorg op haar CV staan, dus dan mag je wel wat preventie verwachten. Iedereen snapt dat een onveilig systeem in de zorg onwenselijk is.

[BoringDay]

Preventie moet je aan de vakmensen overlaten ... die moeten serieus genomen worden.
Hebben ze meer tijd nodig om betere code te ontwikkelen dan moeten ze die ruimte gewoon bieden.

[To_Tall]

LoL.. geloof een dag nadat tweakers over het lek had geinformeerd was het de software bijgewerkt.. Lek was al ruim 1,5 maand oud en ze wilde pas over een paar maanden de software bijwerken ivm testen..

Daarnaast, is het gewoon niet alleen onwenselijk als je data op straat komt te liggen maar ook gevaarlijk gezien het vertrouwen wegvalt bij de arts..
Omdat Promedico hoe groot ook in het nieuws zal komen en faliet zou gaan hierdoor. Toch de Arts wordt aangekeken..

[psyBSD]

Tja... dat je je software wil testen lijkt me ook wel goed...

De java update van dinsdag heeft ook issues (zowel java 6, als java 7) omdat diverse applicaties stoppen met werken.

Blijkbaar heeft oracle de class-loading van de awt module om zeep geholpen.

Dan duurt het toch een paar weken voordat het is opgelost en je daadwerkelijk kunt beginnen met patchen.

[Reactie gewijzigd door psyBSD op 25 juli 2024 09:58]

[j-phone]

Bestuurslid ICT heeft meer met bestuur te maken dan met ICT (op detailniveau). Er is geen ict'er op aarde die alle ict beheerst, ervan uitgaan dat een bestuurslid dat wel kan is een beetje naief.

[tweaker2010]

Dat kan wel zijn, maar dat maakt haar niet minder verantwoordelijk. Zij zit juist in dat bestuur om toezicht te houden. Jammer dat er pas achteraf actie ondernomen wordt.

[Verwijderd]

Macht ligt vaak altijd ver weg van de mensen die echt kennis hebben... Dat merk ik vooral bij onze overheid heel erg..

Zoals Ivo Opstelten.. minister van veiligheid. Wat een gedrocht van een minister is dat. Ik kan het weten. Hij was hier ooit burgemeester.

[Verwijderd]

Dat is niet alleen bij de overheid zo, dat is in veel gevallen zo. En In veel gevallen wordt er door technici gewaarschuwd tegen dit soort problemen, echter vallen die meestal in een zwart gat omdat er op middenkader niveau geen gehoor gegeven wordt. En pas als de directeur him or herself op het matje wordt geroepen door de klant, dan pas wordt er gerend en krijgt technici de schuld. En middenkader een foei want zij hadden deze risico in scope moeten hebben maar ook weer een bedankje want het risicomanagement was zo goed uitgevoerd.

Dat is de complete dogma waar je als techneut keer op keer tegenaan dreunt, overheid of niet.

[Sv3n]

Door wat moeten die Java applets vervangen worden dan? Activex? Ze gebruiken die Java applet om dmv. de UZI pas communicatie met het LSP op te zetten, daarvoor moet je het private key certificaat dat op de UZI pas staat uit lezen, dat kan niet met Javascript.

[Steef435]

Het hoeft toch niet per se een browser applet te zijn?

[Soldaatje]

Waarschijnlijk wel omdat er gebruik wordt gemaakt van een of andere smartcard.
Zonder plugin is de hardware niet toegankelijk voor de browser.
Ik heb dan ook zo mijn twijfels of dit smartcard-systeem de ideale oplossing is, een sms-systeem of externe losse calculator zoals de banken gebruiken zouden alternatieven kunnen zijn.

[flabber]

Waarschijnlijk wel omdat er gebruik wordt gemaakt van een of andere smartcard.
Zonder plugin is de hardware niet toegankelijk voor de browser.

Maar dat is een verkeerd uitgangspunt!
Waarom moet er per sé een browser gebruikt worden?
Omdat programmeurs van web/browser-applicaties goedkoper zijn?
Omdat ze een specifieke IDE gebruiken?
Je kan toch ook een dedicated applicatie ontwikkelen? En die kan dan best http of soap kletsen, wat je maar wil.

De enige reden om dit te kiezen is geld.
En snelheid en kosten worden meestal beter gewaarborgd dan veligheid.

[Pep7777]

Een reden om web-apps te gebruiken is dat het updaten heel erg makkelijk gaat. Nieuwe web paginas op de server en klaar. Geen gedoe met downloaden/installeren enzo (minder kosten aan IT hulp, huisartsen zijn niet altijd even handig met computers).

Maar ik weet niet of dat hier nu eigenlijk wel het belangrijkste is in dit geval.

[909trauma]

Voor het makkelijk updaten van software hoeft het niet persee een browser app te zijn. Ik maak zelf al jaren gebruik van het Microsoft Click-once mechanisme (http://en.wikipedia.org/wiki/ClickOnce) om een smart-client uit te rollen bij mijn klanten.

Platform onafhankelijkheid is denk ik een belangrijker argument om een browser-applicatie te ontwikkelen.

[telenut]

platform onafhankelijk, en werken met Microsoft...

[909trauma]

ja? Wat probeer je hier mee te zeggen? Heb je mijn post wel goed gelezen? Beweer ik ergens dat click-once platform onafhankelijk is?

[flabber]

Het 'leuke' is dat er meerdere keren wordt gezegd dat webapplicaties handig(er) zijn omdat het updaten makkelijker is, dat er minder afhankelijkheden zijn en nog zo wat van die dingen.

Maar in dit geval is de applicatie afhankelijk van Java.
Java zelf is geen webapplicatie, maar blijkbaar is het voor huisartsen geen enkel probleem om Java updates te installeren en is het bij Java wel mogelijk om platformonafhankelijke software te schrijven, te distribueren en te updaten.

Begrijp me goed, ik ben geen tegenstander van webapplicaties, maar de reden ervoor moet wel goed onderbouwd zijn.
Als je verwacht dat gebruikers in staat zijn om updates van software te kunnen controleren (wel of niet updaten of updates zelfs terugdraaien), dan is de redenering dat webapplicaties makkelijker zijn met betrekking tot updates enkel een verkapt financieel argument.

En financiele argumenten mogen doorslaggevend zijn bij 'normale'
applicatiies zoals een tekstverwerker of een sp[elletje, maar niet bij software die persoonsgegevens moet bewaken!

[Anonyymm]

Waarom moet er per sé een browser gebruikt worden?
Omdat programmeurs van web/browser-applicaties goedkoper zijn?

Ik kan me aansluiten bij de vorige twee. Het is niet dat je maar tien huisartsen in Nederland hebt. Via een webapplicatie kan je centraal updaten. Denk je overigens dat het niet updaten van een dedicated applicatie niet onveilig is? Want dat ga je natuurlijk ook krijgen. Niet iedereen update gelijk applicaties of laat deze door een IT bedrijf updaten.

En wat freaq zegt. Je kan je afvragen of je überhaupt Java moet willen gebruiken bij dit soort toepassingen. Voor de Rabobank RFLP Reader mag je niet hoger dan Java 6 update 18 gebruiken. En dan hebben we het over zakelijk autorisatie/betalingsverkeer.

[Reactie gewijzigd door Anonyymm op 25 juli 2024 09:58]

[CAPSLOCK2000]

En wat freaq zegt. Je kan je afvragen of je überhaupt Java moet willen gebruiken bij dit soort toepassingen. Voor de Rabobank RFLP Reader mag je niet hoger dan Java 6 update 18 gebruiken. En dan hebben we het over zakelijk autorisatie/betalingsverkeer.

Het probleem is dat er niet echt een alternatief is. Als je geen Java gebruikt, wat dan wel? ActiveX en Flash hebben net zo veel problemen.
Ook als je native applicaties maakt is dat geen garantie dat ze veilig zijn. Zelfs als je eigen code veilig is dan zitten er wel fouten in de systeemlibraries die je gebruikt.
Het grootste verschil is dat zo'n applicatie misschien iets minder makkelijk te bereiken is dan een website, maar uiteindelijk moet de applicatie communiceren met de buitenwereld, er blijft dus een risico.

Het grootste probleem is niet dat er fouten worden gevonden maar hoe daar mee om wordt gegaan. Als softwareleverancier moet je eigenlijk een stel programmeurs klaar hebben staan om onmiddelijk op dit soort problemen te duiken maar in praktijk is dat voor de meesten onbetaalbaar.

[freaq]

en als er meer wordt uitgegeven dan nodig wordt er moord en brand geschreeuwd naar de overheid, doen ze eens zuinig is het weer niet goed.

kijk ik snap best dat dit niet optimaal is, maar om nu tedoen alsof dit een ramp is is gewoon zwaar overdreven, Oracle patcht zowieso pas elke X maanden, oftewel als er een probleem is dan is dat enkele manden zo, die 3 weken maken het niet beter maarja zoveel verschil maakt het ook niet.

en ja natuurlijk moet het blijven werken met een update.. maarja punt is, JAVA heeft altijd gaten en zou daarom uberhaupt niet gebruikt moeten worden.. iig voor dit soort systemen,

maar om vele tonnen uit te geven vor een ander systeem om het dan 5x over te doen en de huisartsen te laten zitten met baggerprogramma's uit het jaar nul (it voor de overheid gaat altijd goed namelijk) dan is dit mogelijk nog wel de minst erge optie...

complete kerncentrales werken op software uit 1998 en hangen aan het net, DAT is eng. dat is erg, maar daar hoor je veel minder mensen over (zelfs met stuxnet notabene) dit is zwaar uit verband getrokken en opgelbalen tot idiote proporties imho.

[Reactie gewijzigd door freaq op 25 juli 2024 09:58]

[sfranken]

Omdat een webapplicatie in princiepe platformonafhankelijk is.

[freaq]

het punt is natuurlijk dat er even tijdelijk geen andere optie was,
als ze updaten en niets werkt had dat ook mensen in gevaar kunnen brengen gezien de artsen niet bij de informatie kunnen komen (wat soms levensbedreigend kan zijn)

het was beter geweest als men had kunnen updaten zodra de update er was en er getest was met deze update etc, maar het kwam erop neer dat de keuze was updaten en nergends bij kunnen, of niet updaten voor 2-3 weekjes...

laten we eerlijk zijn, dan is niet updaten toch een betere keuze...
(om op dat moment te maken, dat dit noodzakelijk was praat ik niet perse goed)

[CAPSLOCK2000]

het was beter geweest als men had kunnen updaten zodra de update er was en er getest was met deze update etc, maar het kwam erop neer dat de keuze was updaten en nergends bij kunnen, of niet updaten voor 2-3 weekjes...

Voor korte tijd is dat begrijpelijk, maar hier heeft het meer dan een maand geduurd en dat is te lang.

Het vervelende is dat het duur is om programmeurs stand-by te hebben die je onmiddelijk kan inzetten. De markt kiest echter voor het goedkoopste product. Dan krijg je dit soort problemen.

[SuperDre]

En dan weer extra rekening moeten houden met alle verschillende OSsen?

[CUnknown]

Als ik het screenshot zo zie twijfel ik zelfs over de algehele zorgvuldigheid waarmee het systeem wordt bijgehouden. Niet alleen zijn de nieuwsberichten een onoverzichtelijke bende gecombineerd met een onnodige scrollbalk, het zit ook vol met spelfouten.

Er staat bijvoorbeeld:
"Onze Servicedesk zal voor UW het UZI-servercertificaat in orde maken."
Gebruik van "UZI-servercertificaat", maar dan wel weer "uziregister", daarna "UZI pas" en zelfs "UZI-register".

[Reactie gewijzigd door CUnknown op 25 juli 2024 09:58]

[clogie886]

Inderdaad, als ik dit zo lees lijkt het wel 'out-sourcing' naar een land waar Nederlands niet de moedertaal is. Hoe is het anders mogelijk dat er zoveel spellingsfouten staan in een scherm!

[Eloy]

Java:
"Write once, exploit everyweek"

Kunnen ze voor een patientendossier niet gewoon een programmeertaal kiezen waar geen runtime voor nodig is, dan ben je hier voor altijd vanaf?

[Verwijderd]

Kunnen ze voor een patientendossier niet gewoon een programmeertaal kiezen waar geen runtime voor nodig is, dan ben je hier voor altijd vanaf?

Is dit een grap ofzo? De exploits van Java, Flash, .Net gaan er allemaal over dat je UIT de sanbox (ie. runtime) weet te breken. Als je gewoon machinecode draait (wat uiteindelijk het resultaat van je gecompilde C, C++, C11, etc. applicatie is) dan is er geen sandbox dus hoef je ook nergens uit te breken. Dat is in feite in vergelijking dan exploited by default...

Je moet gewoon geen "hostile" code draaien, niet in je sandbox en niet erbuiten.

[Steef435]

Dan ben je zelf in charge van de sandbox, en kun je dus zorgen dat het goed werkt. Het is ook belachelijk dat software op een sandbox leunt om de boel recht te trekken. Het grote probleem is dat een interpreter gemaakt is om verscheidene dingen te kunnen doen, terwijl compiled software maar voor één doel geschreven is.

Machinecode injecten is lastiger dan een scriptje door een interpreter heen rammen.

Verder wordt de Java runtime niet alleen gebruikt voor de applets van het werk.

En dan hebben we nog een sandbox; het besturingssysteem.

Eigenlijk komt het op hetzelfde neer als alle regeringscomputers op Windows ME te laten draaien zonder enige firewall of andere bescherming, alle poorten open te zetten en als beheerderswachtwoord "admin" te hanteren met gemakkelijke toegang via ssh. Maar geen nood, we hebben een sandbox die controleert of er geen command wordt uitgevoerd waarmee het systeem wordt uitgeschakeld.

[elmuerte]

Ook C en C++ applicaties gebruiken een runtime, bijvoorbeeld libc op Linux, of msvcr/msvcp in Windows.

[Umbrah]

Er is ALTIJD een runtime nodig, tenzij je rechtstreeks *ASM gaat schrijven... en zelfs DAN heb je een gigantisch risico. We zijn als land te groot om alles op papier te doen, maar blijkbaar té paranoide om alles digitaal te doen...

[Verwijderd]

Als je ASM gaat schrijven ben je afhankelijk van machine instructies.... Die zijn op elke processor anders. hehe.

[memphis]

Gewoon terug naar een text terminal inbellen op een direct modemlijntje. Dan heb je geen internet en ken je met de meest onveilige machine (mits niet aan het internet hangend) veilig inbellen.

[Verwijderd]

Werkt deze al? meuk: Oracle Java 7 update 25
Dat is van daarna...

[Cheetah_777]

google: minister onwenselijk

Bezuinigingsplannen minister Donner zeer onwenselijk ,
Minister: dubbele pet notaris bij woningcorporatie onwenselijk ,
D66 - actueel - Inzet tasers door politie onwenselijk
Minister Kamp: gedwongen forse premiestijging voor 2011onwenselijk
Kamerbrief met reactie op rapport 'Niet onwettig, wel onwenselijk
Minister Leers: generaal pardon asielzoekers is onwenselijk
Minister: Afhankelijkheid van Fox-IT onwenselijk
PVDA: BSA in derde jaar is onwenselijk'
Bestuur Amarantis handelde 'niet onwettig, wel onwenselijk'

Tijd voor eens een nieuw woordje? Gepruts bijvoorbeeld?

[LlamaLoco]

Het gebruik van Java is in de praktijk altijd onwenselijk blijkt.
Nu lopen ze te zeuren omdat het toevallig de zorg betreft maar hoeveel andere systemen weken op een eeuwenoude java?
Vandaag nog een (meest recente versie) PZ-systeem gezien (hallo privacy!) die Java 5u02 (hoi 2004!) nodig heeft om rapportage te draaien!!!!!11! (daa-hag RAET)

Lijkt me een goed idee als virusscanner vanaf nu JRE aanmerken als malicious en in quarantaine plaatsen.

[Verwijderd]

Bedrijven en updaten. Hallo slechte ICT werknemers die geen actie durfen te ondernemen.

[DeTeraarist]

Verder heeft Promedico aangegeven dat bij hen niet bekend is dat computers met de betreffende verouderde Java-versie daadwerkelijk zijn overgenomen, maar het bedrijf erkent dat er beveiligingsproblemen waren.

Wat is dat nou voor rotsmoes? Hou je code gewoon lekker up to date of sluit geen contracten af die je niet kunt nakomen. Dat het niet is gebeurd zegt namelijk niet dat het niet mogelijk was. Het was genoeg bewezen dat v7.17 kwetsbaar was. Voorkomen is beter dan genezen, daar zijn ze in de zorg toch ook van op de hoogte? Van mij part tijd voor een nieuwe leverancier.