Crimineel eist losgeld na onderscheppen wachtwoorden Belgische patiënten

Een crimineel heeft onversleutelde wachtwoorden, e-mailadressen en telefoonnummers onderschept van het Belgische systeem Digitale Wachtkamer, waarmee patiënten afspraken kunnen maken bij hun huisarts. Hij eiste 42 bitcoin losgeld, zo'n 85.000 euro.

De leverancier van de Digitale Wachtkamer zegt tegen VTM Nieuws dat er 550.000 tot 600.000 mensen gebruikmaken van de software. In de reportage van de nieuwszender is de e-mail te zien die werd gestuurd aan het bedrijf dat de software maakt. Daarin eist de persoon een 'boete' van 42 bitcoin. De crimineel stelt de informatie in handen te hebben, maar niets online te zetten. Inmiddels is een deel van de gegevens online geplaatst als bewijs dat ze in handen zijn van de crimineel.

Ook zou de crimineel huisartsen hebben benaderd en van hen 1 bitcoin hebben geëist. Een huisarts zegt in de reportage dat hij gegevens kreeg van de crimineel om te bewijzen dat er inderdaad toegang tot was geweest. Hoe de gegevens onderschept konden worden is niet bekendgemaakt, maar in ieder geval waren de wachtwoorden niet versleuteld. Via het systeem kunnen patiënten berichten sturen naar hun huisarts en ook die konden worden ingezien.

De maker van de Digitale Wachtkamer is naar de Computer Crime Unit van de politie gestapt. Of het beveiligingslek intussen ook is gedicht en of er wel of geen losgeld is betaald, blijkt niet uit de berichtgeving. Gebruikers van het systeem wordt aangeraden om hun wachtwoorden te veranderen, zeker als zij dezelfde combinatie van het wachtwoord en e-mailadres ook bij andere diensten gebruiken.

Reacties (197)

Deze crimineel heeft eerst ook alle patienten aangeschreven. Mijn broer was er één van. Hier de tekst van zijn boodschap, ontvangen op 10 juli:

Dear xxx,

On yyyy-mm-dd you created an account on digitalewachtkamer.be.
This website is unsafe and leaks your personal information.
Not only your contact information, but all notes you sent to your doctor as well.
I was also able to obtain an unencrypted version of your password.
Change your password immediately!

The website is ran by a company that made over 175000 euro in profits last year.
Money that could better be spent on securing your personal information.
It took the company almost a week so solve the most basic security issue.

You as a tax payer are actually paying for this as with IMPULSEO III doctors get the cost paid back from the government.
Talk to your politicians and ask why they are funding insecure software.

As proof I can tell you that your date of birth is yyyy-mm-dd.
I can send you all the information, that I was able to capture, of you by sending your PGP key and I will send the data encrypted to you.

You should talk to you doctor about this and stop using this website.

If you want to support me in my research you can send bitcoins to 1PdWbY4jFa3iuahhbZHV6j6dgRMBs1tFBi

Hij heeft waarschijnlijk niet genoeg geld kunnen aftroggelen van de gebruikers zelf, en is dus maar een versnelling hoger geschakeld.

De brief klinkt als iemand die mot heeft met het bedrijf. Een ontevreden (ex?) werknemer misschien?

Ik heb als gebruiker geen mail gehad van de hacker. Mag ik vragen wanneer je broer zich heeft geregistreerd? De eigenaar van Digitale wachtkamer beweert namelijk dat enkel de gegevens van nieuwe gebruikers onderschept zijn:

Een onbevoegd persoon heeft gedurende een aantal dagen de gegevens en versleuteld paswoord van nieuwe patiënten, die zich recent hebben geregistreerd als nieuwe gebruiker op de Digitale Wachtkamer, kunnen onderscheppen en heeft deze patiënten hierover een mail gestuurd.

Op 2017-06-26 - zou dus toch kunnen kloppen.

Als je even de broncode van de website bekijkt verbaast het me dat deze nog draait...
Table design, inline css, geen CSRF codes, en wat in hemelsnaam doet dit hier nog:
document.getElementById('ws_EmailAdres').focus();

De jaren 90 hebben gebeld, ze willen hun code terug! Wat een grap deze site, en daarmee worden dan persoonlijke gegevens uitgewisseld tussen dokter en patiënt... Elke dokter die hier gebruik van maakt moest dat bedrijf aanklagen voor nalatigheid.

[Reactie gewijzigd door WebApp op 18 juli 2017 21:01]

Ik heb het verder niet bekeken. Echter, jouw reactie op deze code:

document.getElementById('ws_EmailAdres').focus();

Laat in elk geval zien dat je nog veel te leren hebt. Het is erg gebruiksvriendelijk om een veld focus te geven als de pagina daar om draait. Daarnaast is het 100% veilige pure javascript. Jij bent wellicht downstream frameworkjes (jQuery) of andere hulpmiddelen gewend, maar dit heeft niks te maken met 1990.

Nogmaals, die site zal vast bagger zijn. Geen idee. Probeer echter niet een punt te maken met zaken waar je geen verstand van hebt.

Edit; mocht je het echt niet weten.. als je $("#ws_EmailAdres").focus(); gebruikt dan vertaald jQuery dat intern naar exact deze pure JS code voor jou.

[Reactie gewijzigd door ExIT op 19 juli 2017 01:39]

table layout is echt wel 1990 hoor, en die meta generator tags maken het er niet fraaier op.

Nou ja, dat ze eerder document.QuerySelector("#ws_EmailAdres"); worden tegenwoordig JQuery's hoofdfunctie is vervangen.

Je kan het met jQuery oplossen, wat mij betreft doe je het met vanilla JS, maar waarom niet gewoon een autofocus erop zetten?
http://caniuse.com/#feat=autofocus

Bovendien vind ik je opmerking over "nog veel te leren" niet echt nodig, maar best wel grappig gezien je mijn achtergrond niet kent.

Wat is er mis met?
document.getElementById('ws_EmailAdres').focus();

Het gebruikt niet "framework du jour".

Er is 'tegenwoordig' (vanaf IE10, eerder al in de andere browsers) een autofocus attribuut. Maar in het geval van frameworks is dat niet altijd even makkelijk in te passen

[Reactie gewijzigd door 418O2 op 18 juli 2017 23:19]

Daar is niet zoveel mis mee. Maar de webapplicatie schreeuwt aan alle kanten "al 10 jaar niet onderhouden". Voorbeeldje: als je een pagina als deze ziet https://www.digitalewacht...spx?D_ID=19&Taal=&Talen=, dan heb je toch niet het idee dat dit uberhaupt onderhouden wordt?

Het is gewoon de optelsom van het geheel. Het valt mee dat er een ssl-certificaat op zit, maar voor de rest is het gewoon oude pauperzooi. Met een beetje rondklikken vind je zo al verschillende validation errors.

"if it works, don't fix it". Een veel gehoorde onzinkreet in het lefloze IT landschap in Nederland en België. Men is doodsbenouwd werkende dingen kapot te maken, vnl ook omdat het vaak aan de skillset ontbreekt om een dergelijk defect ook weer op te lossen. En het geld natuurlijk. Altijd het geld.

Dit komt net zo goed buiten Nederland en België voor, het is een typisch voorbeeld van legacy. Maar zolang huisartsen die applicatie nog steeds dagelijks gebruiken om afspraken te maken heb je als SaaS/cloudpartij (wat de aanbieder hiervan is) wel een verantwoordelijkheid om de boel veilig te houden. Als je de rest van de applicatie ziet verbaast het me niet dat dit niet gelukt is.

"If it works, don't fix it" - op zich niet zo veel mis mee, maar hier ging het eerste deel van de kreet al mis (it works njet).

Legacy is het nummer één probleem overal. Men durft er maar geen afscheid van te nemen. Bedenk je daarbij ook dat legacy vaak groter is dan zuiver de code en aanverwante zaken, het gaat ook om mechanismes en concepten. Ik heb het wel meegemaakt dat bedrijven legacy code in taal x, lieten porten naar taal y, en claimden dat het geen legacy meer was.

maar hier ging het eerste deel van de kreet al mis (it works njet).

it works, da!. Het functioneert, maar het bevat een beveiligingsfout/lek. Er zijn verschillende definities van 'it works'

Nha, het gaat meer om het nemen van verantwoordelijkheid. Als je dit wilt fixen, als ict'er, zal je een opdracht van iemand moeten krijgen die waarschuwt voor de gevaren van die verandering. Er zijn niet veel managers die dan toch doorzetten.

Aan de andere kant zijn er ook weinig ict'ers die het vanuit zichzelf gaan oplossen in een development omgeving.

De IT industrie in NL en BE is dood, kapotgemanaged, en zit vol kansloze prutsers. Mensen die een keer een websitetje in elkaar geflanst hebben, zijn al devvers.

Hoe dit soort zaken gaan.. artsen denken dat ze alles kunnen, en er is ergens een arts geweest die ooit een opzetje hiervoor gemaakt heeft. En wachtwoorden in plain text opgeslagen heeft. Desondanks was zijn tool nuttig, en werd gebruikt. Na verloop van tijd zo nuttig, dat men het ontwikkelen ervan is gaan outsourcen. Van daaruit is het doorgegroeit naar een systeem wat door veel mensen gebruikt wordt.

De meeste nederlandse EPD's zijn ook op die manier ontstaan. En het is, zonder enige vorm van uitzondering, allemaal rotzooi als je naar de code kijkt. En ja, ik heb van de top 5 van EPD leveranciers, van 4 de code gezien, en het was rotzooi.

Dat komt door twee factoren. De eerste is dat met name de grote partijen niet kijken naar kwaliteit. Die harken met grote sleepnetten op banenbeursen mensen binnen. Die worden nagenoeg ongecontroleerd aan het werk gezet en worden na 2 en 4 jaar automatisch medior resp senior. Het is gepruts alom. Een sterke goede, en dus eigenwijze, developer wil men bij dit soort bedrijven helemaal niet hebben, het moet eenheidsworst zijn, in eenheidsworstteams scrum werken, en vooral niet boven- of onder het maaiveld uitsteken, want dan ben je lastig en geen teamspeler.

Dat is de ene kant van het verhaal. De andere kant zijn de klanten. Ik durf er vergif op in te nemen dat de developers in deze kwestie echt al lang meermaals hebben aangegeven dat wachtwoorden opslaan in plain text een risico is. Alleen tsja, als je je logincode verneukt, kan niemand meer inloggen en ligt het hele systeem plat. Daarbij is het geen nieuwe feature waarmee je je matties op de golfbaan kun imponeren. Dus zal de gemiddelde manager ervoor kiezen het zo te laten.

Logincode "verneuken" is pure onzin, er zijn vele oplossingen om seamless over te gaan naar veilig wachtwoorden. Aangezien het om plain tekst wachtwoorden gaat is dit zelfs nog makkelijker, gewoon even een scriptje maken dat de wachtwoorden gaat hashen en de logincode wat aanpassen. Er bestaat in mijn ogen echt geen enkel excuus om dit niet te doen. Helaas hangt hier wel een kost aan die vaak door management of de klant te hoog is, al is het maar enkele uurtjes, het is altijd te veel.

Veiligheid is vaak de laatste zorg van een klant, hoe vaak je het ook uitlegt, het boeit ze gewoon niet. Ze denken allemaal dat er niets kan gebeuren. En dan op een dag is het te laat.

Ik bekeek even de bron, de eerste 20 regels zeggen al genoeg. Generator hier en daar, versie nummers van de gebruikte talen er in, ze vragen er gewoon om ..

Ook al weer een tijdje geleden dan ik een flash element heb gezien

Is niets pure onzin aan. Als jij een login op je website hebt, en je vernaggelt op welke manier dan ook de programmacode die die login afhandelt, kan niemand meer inloggen.

Als je deze situatie tegenkomt, plain text wachtwoorden in een database, dan MOET dat ook in je risicoanalyse meegenomen worden. Hoewel de loginfunctie op zichzelf triviaal is, als die niet meer functioneert, werkt het hele systeem niet meer, want niemand kan inloggen.

Dus als je als devver bij een manager aankomt met de melding van plaintext wachtwoorden in de database, dan zal die manager vragen wat de risico's zijn van dat fixen. Dan MOET je het risico noemen dat het fixen fout gaat, en het geheel in het geheel niet meer werkt.

En dan zal de gemiddelde manager al snel eieren voor z'n geld kiezen. Zeker als het gaat om iets wat geen nieuwe functionaliteit toevoegt. Kwaliteit is érg moeilijk tijd voor te krijgen in IT land, men heeft liever features dan kwaliteit. Helaas.

Het risico om plein wachtwoorden om te zetten naar encrypted wachtwoorden is wel heel erg klein. Dat kun je eenvoudig testen alvorens je live gaat. Risico is naar mijn inziens zeer laag. Absoluut geen reden om het niet te doen!

Je kunt alles testen voor je live gaat. Een grotere drogredenatie heb ik zelden gehoord. Dan is altijd alles veilig om te doen, want je kunt het testen.

Iedereen met een beetje ervaring, weet dat er, ondanks testen en alle goede bedoelingen, dingen mis gaan. Dat is een risico. Dat moet je overwegen.

Password hashing is geen rocket science....

Het kan zelfs gefaseerd ingevoerd worden....
Eerst een paar nieuwe kolommen in de database waarin pers_salt, sha265(password+site_salt+pers_salt). (Pers_salt is een random string), site_salt een geconfigureerde string per site., password update code past beide aan.

Dan probeer versie login code die gebruik maakt van hashed password. (je hebt 55000-600000 test cases beschikbaar), als de steek proef slaagt, kun je de nieuwe login-code definitief maken en de plain text kolom droppen..., backup maken en oude backups na korte tijd vernietigen.

Ik vraag me af hoeveel mensen hun email-account password ook gebruikten voor dit systeem....
Her gebruik van passwords wordt nog veel te vaak gedaan.

[Reactie gewijzigd door tweaknico op 19 juli 2017 11:38]

Klopt, maar dit is zo ontzettend simpel dat het risico erg klein is. Het risico om het niet te doen is vele malen groter en daarom in deze situatie absoluut geen reden om af te zien van het aanpassen van het inlogscript!

Mwah dit vind ik wel wat kort door de bocht. Je gaat dit uiteraard eerst ontwikkelen in een aparte omgeving inclusief een migratiescript, dan laat je het testen in een testomgeving en pas daarna gaat het naar productie? Zelfs voor een eenmanszaak is dat allemaal niet heel moeilijk!

Er zijn zo veel migratie scenario's te bedenken die die risico's weg managen. En angst is nu eenmaal een slechte raadgever.

Begrijpend lezen is ook moeilijk he, mensen. Ik zeg nergens dat je logincode niet kunt veranderen of upgraden naar iets wat wel encryptie gebruikt.

Wat ik zeg, is dat als je zo'n project hebt, en je als devver bij je manager aankomt met de opmerking 'passwords zijn plain text', dat dit het scenario is wat je gaat krijgen. Hij gaat vragen 'zijn er risico's', en JA die zijn er. Het worst case scenario is dat niemand meer kan inloggen. DAT IS GEWOON ZO. Ook al is de kans daarop klein, als je manager vraagt wat de risico's zijn, moet je dit ook meenemen.

En dan komt de vraag 'is het een nieuwe feature'? --> nee. 'zijn er ooit problemen mee geweest in het verleden?'--> nee. En dan zal je manager al snel zeggen 'laat het maar zo'.

"Ja maar dan lopen we risico gehacked te worden". Nou dat is al 5 jaar niet gebeurd, dus zal nu ook wel niet gebeuren, daar gaan we geen risico voor lopen.

Ik zeg niet dat dat is HOE IK ER OVER DENK, maar dat dat is hoe dit soort zaken IN DE PRAKTIJK gaan.

Wanneer ik zou aangeven wat de risico's zullen zijn, dan zou ik aangeven: Bij een hack, wat aannemelijk is zou bedrijf min of meer ten gronde gaan wanneer niet gefixed en tijdens het fixen lopen we het risico dat bij slecht testen gebruikers een uurtje niet kunnen inloggen.

Klinkt redelijk. Alleen gaat het management nooit van een hack uit. Die horen dus alleen 'gebruikers kunnen een uurtje niet inloggen' en zullen het idee direct afschieten.

Temeer daar er nieuwe features zijn nog ontwikkeld moeten worden, waar gebruikers om zitten te springen, en wat er voorgesteld wordt volslagen onzichtbaar is.

Het komt altijd neer op de bottom line: Geld. In IT land krijg je echt waar je voor betaald. Dit heeft niet zozeer te maken met de kwaliteit van de uitvoerende technische mensen maar wel met de (onmogelijke) specs waar op geprogrammeerd moet worden of het tijdsbestek waarin een project af moet.

Wat mij altijd verbaasd in de medische wereld is hoe gigantisch veel geld hierin omgaat, patenten er zijn, riante salarissen er worden betaald aan (onder andere) bestuurders en monopolies er zijn, maar dat er geen greintje gegeven wordt om bepaalde aspecten van de patient zoals privacy en bescherming van gegevens.

Geloof mij, ik ben bij 4 EPD partijen geweest om te helpen met het opzetten van hun developments- en kwaliteitscyclus, het is een samenhang. Gebrekkige kwaliteit van devvers en featuregericht management.

Van een aantal EPD's weet ik dat er nog grote lekken in zitten. Als jij patient bent bij een groter ziekenhuis, zijn jouw gegevens NIET veilig. Er wordt wel aan gewerkt om het op te lossen, de ontwikkelingen en ook het feit dat men vaker en vaker 'betrapt' wordt, noopt ze hier toe, maar de situatie is nog vrij precair.

Ook raken er op grote schaal gegevens kwijt. Ziekenhuizen hebben een bewaarplicht van 15 jaar, en 15 jaar na een eventueel overlijden. Als je toevallig iemand in de 1e lijn familie hebt zitten die 14 jaar geleden overleden is, ga ze maar eens bellen over gegevens. Het merendeel zal kwijt zijn.

Ziekenhuizen hebben de grootste moeite met het omzetten van de oude papieren dossiers in digitale. Hiervoor worden vaak de goedkoopst mogelijke uitzendkrachten ingezet, verkeerde procedures toegepast, etc, waardoor er van alles kwijt raakt.

De zorg is, net zoals alle 'grote gebieden' in Nederland, op IT gebied, een totale ramp. Misschien nog wel erger dan bij banken, het OV en de overheid zelf.

Ook raken er op grote schaal gegevens kwijt. Ziekenhuizen hebben een bewaarplicht van 15 jaar, en 15 jaar na een eventueel overlijden. Als je toevallig iemand in de 1e lijn familie hebt zitten die 14 jaar geleden overleden is, ga ze maar eens bellen over gegevens. Het merendeel zal kwijt zijn.

Er is niet één periode van bewaarplicht. Voor niet medische data is het meestal 5 jaar. Voor medische data is het verschillend voor de periode waar in de data is gemaakt papier/digitaal. Verder hebben we ook te maken met de leeftijd van de patient. De termijn gaat pas in als de patient 18 jaar of ouder is. Inmiddels is er al sprake van een verplichte bewaar termijn van 50 jaar.

Als je gegevens wilt hebben uit de papieren dossiers dan heb je veel geduld nodig. Een gemiddeld ziekenhuis heeft tonnen aan papieren dossiers opgeslagen.

Voor medische data geldt een wettelijke bewaarplicht van 15 jaar, inclusief 15 jaar na overlijden.

En voor zaken als keuringsdata geldt een termijn van 5 jaar. En de 15 jaar gaat pas in vanaf de 18 jaar.

Er wordt inmiddels al gesproken om de termijn van 15 jaar op te rekken naar 50. Met het oog daar op hebben we hier inmiddels de opdracht gekregen om de medische data onbeperkt veilig te stellen.

De overheid en banken hebben, door de bank genomen, hun interne ict wel op orde. Het gaat pas mis als er grote(re) projecten gaan draaien waar externe expertise voor ingehuurd moet gaan worden. Dan komen namelijk de grote bedragen op tafel en wordt er gekozen, bij aanbestedingen, voor de laagst mogelijke prijs.

Ik weet niet of ziekenhuizen ook moeten aanbesteden?

PS. het EPD is iets waar ik op tegen ben, juist om de redenen die je noemt. Ook ik loop al wat langer mee in ict land

Eh de overheid en banken hebben het wel voor elkaar? Waar haal je dat vandaan? Als er twee partijen zijn die hun shit NIET op orde hebben, zijn het wel de overheid en banken. Je wil niet weten hoeveel bij banken nog op fortran of cobol draait of een taal uit hetzelfde tijdvak. Niet omdat dat zo goed is, maar omdat men bang is er aan te komen en het kapot te maken. Recent nog zagen met wannacry ook foto's van pinautomaten die besmet waren.

De overheid? Dit meen je toch niet serieus? ik noem als voorbeeld eens de automatisering van het UWV. Of de belastingdienst. Of het feit dat ze nog een deal hebben met MS om godbetert windows XP maar te blijven ondersteunen, een 16 jaar oud besturingssysteem, waarvan ze niet één, twee of enkele PC's hebben staan die het draaien, maar 'ergens tussen de 40.000 en 60.000'.

Miljarden gaan er in rook op. En niemand weet het exact, want er is geen overkoepelende IT organisatie die het bijhouden. Toen Elias door de kamer gevraagd werd het te onderzoeken was het antwoord feitelijk 'ik kan het niet onderzoeken, want we weten helemaal niet wat er allemaal is aan ICT'.

Kijk nog eens de vermakelijke aflevering van Arjen Lubach na over dit onderwerp:
https://www.youtube.com/watch?v=O33veh73H5w

We geven 'tussen de 1 en 5 miljard' uit aan ICT via onze overheid. Alleen die spreiding al, zegt al genoeg. Men heeft geen benul.

[Reactie gewijzigd door Anoniem: 943161 op 19 juli 2017 00:28]

Eh de overheid en banken hebben het wel voor elkaar? Waar haal je dat vandaan? Als er twee partijen zijn die hun shit NIET op orde hebben, zijn het wel de overheid en banken. Je wil niet weten hoeveel bij banken nog op fortran of cobol draait of een taal uit hetzelfde tijdvak. Niet omdat dat zo goed is, maar omdat men bang is er aan te komen en het kapot te maken.

Waarom is fortran of cobol slecht dan? Ja, ok de kennis neemt af en het is niet onderhoudsvriendelijk. Maar het ombouwen van die systemen hebben weinig prioriteit, want 'het werkt toch'.

De overheid? Dit meen je toch niet serieus? ik noem als voorbeeld eens de automatisering van het UWV. Of de belastingdienst. Miljarden gaan er in rook op. En niemand weet het exact, want er is geen overkoepelende IT organisatie die het bijhouden. Toen Elias door de kamer gevraagd werd het te onderzoeken was het antwoord feitelijk 'ik kan het niet onderzoeken, want we weten helemaal niet wat er allemaal is aan ICT'.

De belastingdienst had toen ook al aangegeven het aantal veranderingen wat de politiek, per maand, wilt niet kon doorvoeren. Dit is dus allemaal uitbesteed werk overigens.

Wellicht verwoorde ik mij niet goed in het vorige commentaar. Met interne ict bedoelde ik eigenlijk de interne, eigen, medewerkers. Die hebben, over het algemeen, een goede opleiding en algemeen goede kijk op ict en zijn betrokken bij wat ze doen.

Dat laatste geloof ik zonder meer. Wat men van mijn kritieken vaak niet begrijp, is dat ik niet zozeer de mensen bekritiseer maar het systeem. Ik ga er vanuit dat iedereen naar z'n werk gaat om zijn of haar best te doen, en dat er óók bij de overheid en de grote ICT partijen, zeer capabele mensen werken.

Die zitten echter vast in een cultuur en systeem wat niet klopt. De cultuur bovenin is samen te vatten als 'CT bouwen, aan jezelf bouwen' en onderin van 'zorgen dat je niet opvalt en je baan en inkomen houdt'. Verantwoording is in dit soort bedrijven te vergelijken met een ballon die door een menigte hooggehouden wordt. Hij bestaat, maar als je op enig moment vraagt wie ergens de verantwoording voor heeft cq de ballon vastheeft, is dat op dat moment onbekend. Net zoals waar het exact daarvóór zat, of waar het naartoe zal gaan.

wat is er mis met cobol? Meeste devs van tegenwoordig kennen het alleen uit de analen (dat laatste heeft een wisselwerking natuurlijk, zelfde geld voor hackers, kudos voor de hacker/cracker die daar goed mee om kan, maar die kan sowieso veel geld in de industrie verdienen), laat staan dat ze er lekken in vinden. Er is imho sowieso niets mis met een oude op taal als dat werkt. Als een oude taal bewezen vol met fouten zit is dat iets anders natuurlijk. De laatste opmerking wel los van efficiëntie

Moet hierbij wel opmerken dat ik een paar COBOL-devs heb ontmoet die, welja bedroevend omgingen met security issues. Maar wederom, die kom ik sowieso ook wel tegen....

tuurlijk, cobol heeft zijn flaws wel, maar niet meer of minder als een nieuwe taal. Het hangt voornamelijk van de devs af... (geld kosten doen deze sowieso )
Sowieso zie ik het nog niet gebeuren dat de ingewikkelde BE-systemen van financiële instellingen op 1.2.3 herschreven kunnen worden. Dat kost niet alleen geld, maar ook veel te veel risico dat het systeem op de schop gaat.

En daarbij, denk dat dat financiele instellingen veel meer andere gaten hebben in meer hedendaagse systemen in hun FE-systemen.

https://www.kiuwan.com/bl...nted-languages-cobol-rpg/

Uit de analen

Ach het Java van nu is de legacy van morgen, over een jaar of 5-10 is er een nieuwe mode in programmeer talen en dan "moeten" al die "legacy" (Java, C, etc.) omgezet worden naar de nieuwe taal...

We geven 'tussen de 1 en 5 miljard' uit aan ICT via onze overheid. Alleen die spreiding al, zegt al genoeg. Men heeft geen benul.

Meen je dat? Je maakt anderen voor incompetent en erger uit en je hebt zelf niet het taalniveau om een conclusie goed te lezen? 1-5 miljard is niet wat er in totaal uitgegeven wordt aan ICT door de overheid, het is het bedrag waarvan dat incompetente ons-kent-ons mannetje beweert dat het verspilt is. Een conclusie die zo breed gedragen werd dat 'ie nu zelfs als kamerlid niet meer welkom is.

Het gaat pas mis als er grote(re) projecten gaan draaien waar externe expertise voor ingehuurd moet gaan worden. Dan komen namelijk de grote bedragen op tafel en wordt er gekozen, bij aanbestedingen, voor de laagst mogelijke prijs.

Ja en nee, volgens de Europese aanbesteding mogen bedrijven allemaal een bod doen, waarvan vervolgens de goedkoopste (die de vereisten haalt) MOET worden gekozen, dan is er nog wel een korte periode waarin ze moeten laten zien dat ze het ook kunnen. In feite is er dus eigenlijk ook maar weinig te kiezen ook al zouden ze wel een duurdere optie willen kiezen.

Misschien is het handig bij het doen van een aanbesteding in het bestek minimale eisen ten opzichte van proces, code kwaliteit en beveiligingsmaatregelen op te nemen...

Die zijn er ook wel, maar die liggen logischer wijs dus lager dan eigenlijk zou moeten

Nja, voor 'n kleine €80k/maand kan je toch wel even een deftig systeempje laten zetten. Gebrek aan geld was in dit geval het probleem niet. Gebrek aan kennis langs de kant van de klant en geldbejag langs de kant van de leverancier.

Developers? Dot-it (bedrijf achter de site en dienst) is een bvba die amper groter is dan een eenmanszaak (zie website Nationale Bank van België - werknemers en financiële resultaten 2015). Volgens wat ik zie op de Facebookpagina lijken de personen die deeltijds in dienst zijn vooral jobstudenten en veel andere werknemers zijn er dus niet (een vertegenwoordiger daar gelaten).

Je kan hier toch echt niet veel van verwachten als alles afhangt van zo'n select groepje/een man, blijkbaar. Gelukkig kan ie met de winst van 2015 die 42 bitcoin makkelijk betalen ;-) (correct me if I'm wrong, ik ben geen boekhoudkundige)

Gelukkig kan ie met de winst van 2015 die 42 bitcoin makkelijk betalen ;-) (correct me if I'm wrong, ik ben geen boekhoudkundige)

Ja, geen probleem. Blijkbaar betalen artsen minimum 61,50€ / maand voor de diensten:

U kan reeds gebruik maken van alle bovenvermelde diensten voor slechts 61,50 Euro / maand (Excl. aankoop kiosk)

Volgens de VTM reportage zijn er 1000 artsen die er gebruik van maken. Die man harkt dus zomaar even 61500€ / maand binnen. Dat is gewoon bijna op automatische piloot want de website is al jaren niet veranderd.

Op de jaarrekening zie je ook dat ze 2 voltijdse en 5 deeltijdse personeelsleden hebben.

Het id van de wachtkamers loopt op tot 1354. Het zijn er dus wellicht meer dan 1000. Op id 1 heeft ie nog een test online staan, lol.
https://www.digitalewachtkamer.be/default.aspx?id=1354

Mja als het van testing naar productie is 'gepromoveerd' - normaal in deze niches - zullen de eerste 100 wachtkamers bestaan als test.

En met zo een omzet naar binnen graaien en dan nog plain text login gegevens. Niet te geloven.

Overigens al zo jammer dat email password en username in 1 tabel staan. Netter was om authenticatie tabel te gebruiken met alle velden versleuteld en een 1:1 key naar andere tabel met gegevens.

Waarschijnlijk, en nu baseer ik mij op ervaring niet op feiten, is die BVBA opgericht door iemand in dienst van een grotere partij, die op die manier nog afroomt voor zichzelf.

De man achter Dot-it is nochtans degene die in de berichtgeving/reportage het woord neemt. Hij heeft de mobiele apps uitgegeven, de website in beheer en er een tester op geplaatst. Ik twijfel of er hier een grotere partij is, maar feit blijft dat deze man en zijn bvba (bijna hetzelfde in casu) de hele boel heeft opgezet. Ook vertegenwoorders om het product in andere provincies te promoten, moeten hem persoonlijk aanschrijven...tjah

Tsja.. dan is het voor de verandering een keer een kleine partij. Alhoewel het meer klinkt als een manager die alles outsourced.. en drie keer raden waar ie dat dan zal doen..

Artsen denken niet dat ze alles kunnen. Managers van ziekenhuizen verplichten artsen te werken met uitgekozen software. De arts heeft hier inderdaad nul verstand van en krijgt ook bijna geen begeleiding. Ook wordt er vaak van software gewisseld omdat het volgens de managers weer iets goedkoper kan. Beetje kortzichtig om meteen de artsen de schuld te geven.

Die site is wel lekker snel

Maar wat erg zeg, stylez.css/js, de lage kwaliteit van de afbeeldingen.
En in de head, meta generator visual studio 7.1, volgens wikipedia nu 14 jaar oud!

Je zat er met de jaren 90 niet ver naast

[Reactie gewijzigd door john_vw op 18 juli 2017 21:14]

In Nederland zijn er verschillende tweedelijns psychologische hulpverlening waarbij het aanmelden gaat via een open formpje via http, niet eens https.

Zo werd er ergens een 'lifestyle app' en 'merk' aangeraden - dat bleek een volledige GGZ-instelling voor verslavingshulp te zijn.
Aanmelden gaat via een formulier dat zelfs niet over https loopt:
http://www.readyforchange...atient-is-verslaafd/index

Verbaasd ben ik verder gaan kijken, en zo uniek blijkt dat dus niet te zijn:
http://www.compassverslavingshulp.nl/contact/

Deze instelling levert ook nog een handig aanvinklijstje van klachten / indicaties mee:
http://www.psymens.nl/?pageid=2

En hier wordt zelfs gevraagd de gehele verwijsbrief te uploaden (met BSN, verzekering, diagnose, etc.)
http://mtsr.nl/verwijzer/

En allemaal dus zelfs zonder https - de AIVD hoeft hiervoor de nieuwe tapwet niet eens te gebruiken om versleutelingscodes op te vragen: dit kan nu al routinematig worden opgevangen en ingezien.

Ja dat is toch normaal? Een hoop van hun klanten (huisartsen) zit waarschijnlijk nog op XP met IE8...

Een hoop ziekenhuizen ook maar die hebben wel alles zo veel mogelijk dicht gezet. Het probleem is dat software voor bijvoorbeeld een MRI scanner 10 jaar terug is gemaakt voor windows XP. De leverancier weigert vervolgens om de software om te bouwen naar een recent OS maar het ziekenhuis moet vervolgens volgens de regels nog een x aantal jaar doen met de MRI scanner voordat ze deze af mogen schrijven. Het gevolg is dat de werkstations die zulke apparatuur aan moeten sturen vervolgens dus op XP (al dan niet een embedded versie) door moeten blijven draaien.

Het is niet alsof overheidsinstanties zoals de belastingdienst of de politie het beter voor elkaar hebben.

Nee. Het is lax. En weer komen die MRI scanners als voorbeeld. In een ziekenhuis staan hooguit een paar van die apparaten. Het is echt volstrekte bullshit te beweren dat daarom een heel ziekenhuis op een archaisch OS moet blijven draaien.

Dat zijn excuses van laffe beheerders die het niet aandurven. Zoals iemand hierboven terecht zegt, het gaat om het nemen van de verantwoordelijkheid. Niemand durft dat dus schuiven ze allemaal de hete aardappel voor zich uit, met als excuus die paar MRI apparaten.

Die overigens doorgaans prima samenwerken met apparaten die niet op XP draaien, maar ja, dan moet je er verstand van hebben, weten wat je doet, en het lef hebben het te proberen.

Volgens mij was niet eens zo heel lang geleden nog in het nieuws dat huisartsen voorlopig IE8 moesten blijven gebruiken om een ActiveX control te kunnen gebruiken, die hun toegangspas valideert. En die gaf toegang tot het EPD, dus het was geen optie om dit te omzeilen

@Anoniem: 943161 lezen is een moeilijk iets of niet? Ik zet er duidelijk neer:

Het gevolg is dat de werkstations die zulke apparatuur aan moeten sturen vervolgens dus op XP (al dan niet een embedded versie) door moeten blijven draaien.

Helaas kan via 1 zo'n systeem de infra van jouw organisatie wel de nodige risico's lopen. En nee het gaat niet alleen om een MRI scanner maar om zo nog tig voorbeelden van zaken waar ze verplicht mee moeten werken en die niet matchen met de gewenste situatie. Je beveiliging is zo sterk als de zwakste schakel in de keten.

Ik ken meerdere overheidsinstanties waar bijna alle werkstations netjes bij zijn op een paar machines na juist omdat die met zaken moeten communiceren die aanbesteed zijn en welke niet vervangen mogen worden. Dat heeft 0 te maken met laksheid van de beheerders. Die zouden het liefst per direct die systemen vervangen. Bij een van de revalidatiecentrum onderdelen van defensie was destijds de software voor het aansturen van de apparatuur die de röntgenfoto's maakte van een gebit zo'n voorbeeld. Als oplossing stond er 1 werkplek waar alleen de software voor de aansturing van dat apparaat op kon draaien. Vervolgens moest de arts deze dan vanaf deze werkplek doorzenden naar zijn andere werkplek om deze aan het dossier enz te kunnen hangen. Die werkplek was gewoon netjes bij met alle software.

Ja er zullen vast bedrijven en instanties tussen zitten die 1 zo'n device als excuus misbruiken om vooral niet te hoeven veranderen maar er zijn er meer dan genoeg die er wel serieus mee bezig zijn en het echt geen laksheid van beheerders is.

Een MRI is niet echt een goed voorbeeld. Het ding is erg duur dus je gaat er niet snel een nieuwe van kopen en onderhoud is lastig omdat een MRI in principe nooit uit gaat.

Maar wat dacht je van alle andere medische apparaten. De trend is om tegenwoordig alles aan te sluiten omdat we alle data bij moeten houden. In een middelgroot ziekenhuis gaat het om duizenden apparaten, van medicijn pomp, hart monitor tot de wasmachines. Veel meer dan de paar PC's en servers die ze ook in huis hebben.

Table is nog steeds geen beveiligingsprobleem, wat ia daar het probleem? Is niet mooi, is niet correct, maar daarmee zijn geen wachtwoorden ontfrutselt.

Het geeft wel een bepaalde 'bad code smell'. Als iemand zoiets al niet voor elkaar heeft, zou die dan wel de OWASP top 10 kennen en daartegen beveiligd hebben? (sql injection, session hijacking etc)

Als je even de broncode van de website bekijkt verbaast het me dat deze nog draait...
Table design, inline css, geen CSRF codes, en wat in hemelsnaam doet dit hier nog:
document.getElementById('ws_EmailAdres').focus();

De jaren 90 hebben gebeld, ze willen hun code terug! Wat een grap deze site, en daarmee worden dan persoonlijke gegevens uitgewisseld tussen dokter en patiënt... Elke dokter die hier gebruik van maakt moest dat bedrijf aanklagen voor nalatigheid.

Wat een onzin, als een dergelijk systeem draait en functioneert ga je het niet updaten puur om het updaten. Dit wachtwoord verhaal staat daar verder los van, je gaat geen code/opmaak etc wijzigen als dat niet nodig is, dat geeft alleen maar meer kans op nieuwe problemen.

Webdevelopment was in de jaren 90 al een lachertje, toen was het al gepruts van mensen die niet wisten wat ze deden en zo is het blijkbaar nog steeds. Als je zoiets in de industrie flikt als C++ ontwikkelaar krijg je een stevig gesprek met de baas en als het nog eens voorkomt vlieg je eruit.

If it ain't broke don't fix it..

Ik wordt een beetje moe van al die ontwikkelaars die andermans code afkraken alleen maar omdat het niet aan hun standaard voldoet. Dat jij tegenwoordig voor iedere regel javascript een heel framework laat aanrukken is fijn maar anderen kunnen nog wel gewoon zelf javascript schrijven. Dat is bovendien sneller dan het laden van een framework die je voor 90% niet gebruikt.

Daarnaast is het gebruik van een Table helemaal niet zo gek als je bijvoorbeeld ook oudere browsers moet ondersteunen. Als je geen gebruik kunt maken van alle CSS functies dan is het gebruik van DIV's behoorlijk irritant. Een Table is dan zeker net zo makkelijk. En de gebruiker merkt daar niets van, dus wat is het probleem?

..maar in ieder geval waren de wachtwoorden niet versleuteld.

Ongelooflijk, en dat voor een medische applicatie waar privacy een van de fundamentele beginsels is. Die gene(n) die dat geprogrammeerd hebben moeten zich diep schamen.

[Reactie gewijzigd door DukeBox op 18 juli 2017 20:51]

In hoeverre dit een medische applicatie is, is discutabel. Dit gaat over een online agenda om afspraken te maken.
Natuurlijk is het lekken van persoonlijke gegevens van ieder wie op de site heeft aangelogd niet acceptabel.

Als daar een (medische) reden ingevuld kan / moet worden om die afspraak te maken zijn het wel degelijk medische gegevens.

Ik denk dat je als programmeur werkzaam bij zo'n bedrijf op je cv bij toekomstige sollicitaties spontaan vergeet te vermelden dat je daar gewerkt hebt.

Nu hoeft dit natuurlijk niet de schuld te zijn van de programmeurs. Het management kan dit net zo goed als opdracht hebben gegeven.

Persoonlijk zou ik dit zelf wel gemeld hebben bij de juiste instanties. Ik heb bij mijn huidige werkgever met een eerdere directeur ook al eens een heftige discussie gehad op het gebied van privacy. Tot zeer gevoelige systemen ben ik de enige die toegang heeft. Zo ben ik de enige die zaken al tijden van inloggen, internet history enz in kan zien en krijgt niemand hier zomaar toegang tot. Ik heb al een keer de opdracht gekregen om alle gegevens van een medewerker inzichtelijk te maken voor de directeur zonder dat daar verder toezicht op zou zijn en zonder duidelijke redenen. In het IT reglement staat duidelijk dat alleen bij zeer zwaarwegende redenen dit kan maar dan alleen in het bijzijn van iemand van HR, iemand van de directie en iemand van informatiemanagement. Een goede reden kon hij niet geven en het proefde meer als dat ze op zoek waren naar redenen om die persoon er uit te werken. Waarop ik heb aangegeven dit te weigeren. Er werd toen met ontslag gedreigd door de directeur waarop ik heb aangegeven dat als hij het zo zou spelen dat hij dan heel vervelend in de media zou komen en de diverse instanties ingeschakeld zouden worden. Een later moment probeerde hij het nogmaals met vrije toegang tot de beelden van de camera beveiliging. Waarop ik opnieuw geweigerd heb. Gelukkig is de huidige directie totaal anders en zijn ze blij dat wij er op die manier in staan.

Ik verlies liever mijn baan dan dat in de media te lezen is dat er gevoelige gegevens uitgelekt zijn en dat ik voor dat deel van de IT verantwoordelijk was. Voor iedereen zijn eigen afweging natuurlijk. Maar als medewerker bij zo'n bedrijf met zulke slechte beveiliging had ik persoonlijk echt wel aan de bel getrokken.

Ik heb al een keer de opdracht gekregen om alle gegevens van een medewerker inzichtelijk te maken voor de directeur zonder dat daar verder toezicht op zou zijn en zonder duidelijke redenen.

Ik heb ooit de opdracht van mijn baas gekregen om het "probleem van het verloren paswoord" op te lossen. Mijn baas verwachte dan geen nieuw gegenereerd paswoord, maar het paswoord dat hij zelf had gemaakt en vergeten was. Ik zei hem dat dit niet veilig was, maar hij wou me niet geloven. Uiteindelijk liep hij boos weg en zei dat ik deze werkweigering nog wel zal voelen bij de volgende evaluatiebespreking.

In mijn geval trok de directeur zelf toch uiteindelijk aan het kortste eind. Ik had alles namelijk ook direct door HR vast laten leggen dat ik dit had geweigerd en op basis van welke redenen.

Een wachtwoord terughalen is bij ons geen optie. Alles staat dusdanig geencrypt dat dit niet in te zien is. Ik kan hooguit een nieuw wachtwoord voor hem laten genereren of ik zou de hele database van datum x terug moeten zetten om alle wachtwoorden naar dat punt in de tijd te zetten, maar dan is dat wel voor iedereen en ik kan dan nog steeds niet zien welk wachtwoord hij op dat moment had

Ook als ze dit al in 2003 hebben gemaakt? Visual studio 7.1 stamt namelijk uit 2003....

Ja, het hashen van wachtwoorden met bijv. blowfish en later bcrypt stamt nog uit de vorige eeuw.

maar in ieder geval waren de wachtwoorden niet versleuteld.

Dat men anno 2017 nog wachtwoorden in plain text durft op te slaan is toch niet te omvatten.
Een bedrijf dat met zulke data werkt zou toch beter moeten weten.

Als dit binnen enkele jaren was had het bedrijf nog een serieuze boete kunnen krijgen in het kader van GDPR.

Ik weet niet hoe het in België is maar in Nederland zorgt zulke nalatigheid al een tijdje voor zeer grote problemen. Per halverwege volgend jaar verbeterd het alleen nog maar meer. Lekken studentgegevens uit dan is het nu al een boete van 10% van je jaaromzet met een maximum van iets van €850.000. Wij zijn als MBO school per volgend jaar verplicht om alle dragers waar ook maar het vermoeden van bestaat dat daar persoonlijke gegevens van studenten op opgeslagen zouden kunnen worden om die te voorzien van encryptie. De MBO raad zit hier dan ook bovenop en is nu al alle MBO scholen langs aan het gaan om ze te helpen te kijken waar ze staan met de informatiebeveiliging. De security officer, de directie en de raad van toezicht zijn aansprakelijk om het moment dat grove nalatigheid te verwijten valt.

De wet die volgend jaar in mei in werking treedt is echter te zot voor woorden, onuitvoerbaar. Jij bent zelfs verantwoordelijk als bij bv de belastingdienst een lek zou zijn, want jij bent verantwoordelijk om er op toe te zien dat waar jij gegevens aan levert ook fatsoenlijk met deze gegevens om gaat. Ofwel degene die die wet hebben opgesteld zijn compleet doorgeslagen zonder enig besef van praktische uitvoering.

[Reactie gewijzigd door SuperDre op 19 juli 2017 09:29]

Dan lees jij de nieuwe wetgeving iets anders als dat wij het doen. Zoals wij hem lezen (en ook door de MBO raad uitgelegd krijgen) is het zo dat jij er alles binnen jouw kunnen aan moet hebben gedaan om te voorkomen dat gegevens uit kunnen lekken. Voorbeelden daarvan zijn dus bewerkingsovereenkomsten met leveranciers omtrent wat er wel en niet mag met jouw gegevens en het contractueel vastleggen van de afspraken waar de leverancier aan moet voldoen. Ik heb immers geen rechten op de systemen bij het bedrijf waar wij verplicht (vanuit de MBO raad) onze studentgegevens moeten stallen. Wel staat heel duidelijk op schrift een bewerkingsovereenkomst dat de studentgegevens zonder contact met ons nergens anders voor gebruikt mogen worden. Dus ook niet voor een testomgeving of een analyse. De gegevens mogen alleen op de systemen staat die we vooraf hebben besproken. In het contract met de betreffende partij staat aan welke eisen de opslag van de gegevens moet voldoen voor wat betreft encryptie, toegankelijkheid enz. Op het moment dat er een datalek is bij het betreffende bedrijf met gegevens van onze studenten dan moeten zowel het bedrijf als wij daar melding van maken. Het enige verschil is dat wij dan aan kunnen tonen dat we alles binnen onze macht aan hebben gedaan om de veiligheid van de gegevens te borgen waardoor wij dus niet de boete opgelegd zullen krijgen.

Wij hebben een paar jaar terug al de nodige stappen genomen om de informatiebeveiliging flink te verbeteren. In het verleden waren wij bijvoorbeeld verplicht om een kopie paspoort/ID te maken en op te slaan binnen onze systemen puur om naar DUO te bevestigen dat de student is wie hij zegt dat hij is. Na overleg met de diverse instanties voldoet het tegenwoordig om bij inschrijving het paspoort/ID van de student (en indien minderjarig ook die van de ouders) te controleren op de echtheid. De controle wordt in het bijzijn van de persoon/personen gedaan en wij hoeven niet langer verplicht een kopie van de legitimatie hier voor op te slaan.

We worden periodiek dan ook door de MBO raad hier op gecontroleerd en 2 security officers binnen ons bedrijf dienen periodiek verantwoording af te leggen over waar wij staan met informatiebeveiliging en de privacy.

Ja de wetgeving gaat erg ver maar in mijn ogen is het een goede zaak.

Het is doenlijk misschien voor een groot bedrijf, maar ondoenlijk voor een hoop kleine bedrijven. Zelf vind ik het ook te gek voor woorden dat mn loonslip dan bv niet meer per mail verstuurd mag worden, terwijl ik dat wel wil, zelfde probleem met bv mijnoverheid.nl, ik wil gewoon due mails rechtstreeks in mijn eigen mailbox hebben ipv dat ik telkens daar moet inloggen om te kijken, aanslagen heb ik daardoor al enkele keren gemist welke ik voorheen gewoon netjes op mn deurmat kreeg.

Wij zijn geen groot bedrijf hoor. Wij hebben 3500 studenten en ergens tussen de 100-150 medewerkers/flexkrachten verspreid over 6 grote locaties en 20-25 kleinere locaties. Dit alles moeten we draaiende zien te houden met 3 personen op de afdeling informatiemanagement. Mijn ene collega doet vooral de telefonie en de werkplekken, mijn andere collega applicatiebeheer en wetgeving en informatiebeveiliging en ik doe zelf technisch beheer, netwerkbeheer, security en informatiebeveiliging. Dus ja ik heb zeker genoeg andere zaken te regelen maar de hele wetgeving is er juist om er voor te zorgen dat jij als bedrijf je verantwoording pakt voor de informatie waar je mee werkt.

Nee, bij de Belastingdienst ben je dat niet. Jij bent wettelijk verplicht die gegevens aan de Bd over te dragen, en zij worden er dan verantwoordelijk voor.

Jij moet er zorg voor dragen dat jouw hulppersonen zich aan de wet houden. En daar is men inderdaad heel streng in, maar dat vind ik ook goed want je staat wel met andermans persoonlijke gegevens te spelen. En hoezo mag jij dat dan gewoon aan eender wie geven waarna ik het risico draag dat die pipo mijn data lekt? Ga maar eens je leveranciers screenen en afspraken maken, zo moeilijk is dat niet.

Grappig dat je het zo stelt, want het is zo naar boven gekomen tijdens een overleg van softwareleveranciers en de bd, en dan hebben we het dus over leveranciers die heel dicht op de wetgeving zit.

Wat je feitelijk aangeeft is dat de BD faalt in de aanbesteding om leveranciers zich aan de wettelijke verplichtingen te houden. Heel herkenbaar ze hebben een eigen andere agenda.
Een softwareleverancier die met de ICT onderhandelt over te bereiken bedrijfsdoelen door de business zonder de business te betrekken is een ander herkenbaar iets.

Nee ik ga geen inside voorbeelden geven. Helaas ik heb die echt in realiteit als een C-soap.
Je zult het er mee moeten doen.

Achja, wij merken dat het gelukkig langzaam aan het veranderen is, dat ook de mensen boven in de top (en dus ministers etc) nu wel beginnen in te zien dat ze, voor ze dingen willen doorvoeren, eerst eens even met een groep softwareontwikkelaars in conclave gaan om te kijken of het wel haalbaar is (op het termijn dat 'het ministerie' het zou willen). Dus er wordt langzaamaan wel beter geluisterd. En gelukkig zitten er bij de BD ook nog wel mensen die wel willen luisteren en waar heel goed mee te werken is, maar soms hebben die weer mensen boven zich die dan net weer de boel tegenhouden.

Andere ervaring de top heeft geen idee wat er echt aan de hand is en begint in paniek rare acties te doen.
Ik zag zelfs leugens in de 2e kamer verkondigd worden. Er zouden geen operationele systemen geraakt worden door die paniekreacties. Integendeel.

Externe leveranciers die aangeven wat haalbaar is. Bedoel je de uwv situatie waar men zelf niets meer kan. Of het brp debacle. Ik heb nog een lijstje van dat soort

Tja, die externe leveranciers worden om input gevraagd, wordt ook niet altijd naar geluisterd, maar je moet niet vergeten dat die externe leveranciers wel verantwoordelijk zijn voor de meeste verloningen, en hun pakketten moeten wel aangepast worden, en soms wordt er iets bedacht wat dan gewoonweg niet mogelijk is in de tijd die er is. Leuk als ze iets bedenken, maar als het niet uit te voeren is kunnen ze er nog niets mee.

De voorbeelden die ik gaf zijn typisch nederlandse overheidssituaties. De functionaliteit bestaat nog niet en als hij al bestaat is het uniek want nergens anders verder toe te passen. Er ligt niks op de plank het gaat via een contract als dienstverlening gebouwd worden. Dat loopt via aanbesteding (tenderned) met een beperkt bestek en koppelt daar wat hardware zaken aan.

Samenhang zoek kwaliteit en stabiliteit onvoorspelbaar. Intussen gaat de stoelendans om de beste baantjes met de meeste macht en meeste geld als belangrijkste item door.
Dus nee, postief over die situatie kun je niet zijn. Zeker niet omdat veilig inrichten conform de interen eigen richtlijnen nauwelijks aan de orde komt. Niet bij de aanbesteding niet bij de uitvoering. Dat speelt overal.

Neem nu eenvoudig dit dot-it commerciële verhaal. Bijhouden moderniseren veilig houden/maken in PDCA met releases is niet echt iets wat veel aandacht heeft gehad. Het is een gangbare cultuur.

Dat betekent dat er een contract moet komen als er gevoelige informatie over de muur moet.
Zonder contract data posten.... tja dat is gewoon publiceren.
Het is dus NU de tijd om afspraken te gaan maken met afnemers en leveranciers van gevoelige data. (en de definitie van gevoelige data is breed).

Het klinkt eerder als een MITM aanval. In het artikel wordt steeds gesproken over onderscheppen, in plaats van inbreken.

Desondanks is het slecht dat er geen enkele vorm van encryptie wordt toegepast.

Paswoorden in plain text is nog steeds normaal. Zelf een software bedrijf als Autodesk (maker van o.a. AutoCad) schrijft na het inloggen de loginnaam en paswoord in plain text in een config file op de zelfde server als waar ingelogd moet worden! Ik zag een forum bericht op hun site hierover uit 2012 terwijl Autodesk het pas in de 2017 software had opgelost. Oudere versies zijn nog steeds kwetsbaar.

niemand die het vreemd vindt dat er losgeld gevraagd wordt?

Wat zou daar vreemd aan zijn? Zulke gegevens zijn grof geld waard op de zwarte markt en er valt flink mee te frauderen. Zo zullen ongetwijfeld ook BSN nummers enz. er in terug te vinden zijn. Ook wanneer er bijvoorbeeld een bekend iemand er tussen zit en deze heeft een gênant medisch geheim dan zou die daar flink mee te chanteren zijn. Ik snap ze wel.

Niet te dramatisch doen he. Is maar het systeem voor afspraken te maken, niet je volledig medisch dossier staat erop.

Dus meer dan een naam, tijdstip en eventueel een opmerking van" ik heb broekhoest "zal er ook niet instaan.

Klopt. Ik ben zelf gebruiker van het systeem en er staan geen Rijksregisternummers, passport ID's of iets dergelijks in. Enkel je geboekte consulaties bij een huisarts incl. een eigen beschrijving waarom je de afspraak maakt.

Het plaatje doet het lijken alsof er in eerdere instantie niet om losgeld gevraagd werd en er enkel geëist is dat de code verbeterd zou worden.. Ik zou eens gaan zoeken in de spambox als ik hen was.. dik kans dat dit inderdaad een white hat is die het toch echt niet langer met lede ogen durfde aan te zien

Zoja: Die white hat gone handhaver/rogue in dienst nemen om de boel te herschrijven, doch niet nadat bij de nalatige partijen gezamenlijk de 42 bitcoin gebeurd is opdat deze veiligheidsplicht ook betaald kan worden

Van een bedrijf wat software maakt waarin zeer gevoelige gegevens worden opgeslagen/verwerkt mag je toch verwachten dat ze snappen dat je alles zo goed mogelijk beveiligd. Wachtwoorden enz. in plain tekst is echt van vorige eeuw. Het is dat ik het de werknemers bij zo'n bedrijf niet gun dat ze zonder baan komen te zitten maar het management en de directie mag best op straat gezet worden of persoonlijk aansprakelijk gesteld worden voor een zeer slechte bedrijfsvoering.

Dit kan nooit gemaakt zijn door een professioneel bedrijf...Dit is lachwekkend als het niet zo'n serieus probleem was....

visual studio 7.1 stamt uit 2003....misselijk hoe oud deze site dus al is. De opdrachtgever/eigenaar heeft hier dus ook een verantwoordelijkheid, meegaan in nieuwe technieken!

In theorie zou de opdrachtgever daar zicht op moeten houden ja maar bijvoorbeeld een huisarts heeft daar 0 verstand van. Zulke bedrijven moeten gewoon periodiek grondig door de overheid worden gecontroleerd. Kom je niet goed uit de controle dan mag je niet langer die gegevens verwerken. Om in het voorbeeld van de huisarts te blijven die denkt gewoon een saas af te nemen bij een gerenommeerde instantie en wil het juist bij zo'n bedrijf beleggen om zeker te gaan dat de gegevens veilig zijn ipv dat hij zelf dingen moet gaan laten bouwen.

Aan de andere kant is het ook weer zo dat lang niet alle nieuwe 'technieken' ook echt beter zijn, vaak zijn het gewoon nieuwe frameworks die eigenlijk amper tot geen zak toevoegen aan de reeds bestaande frameworks. En waarom overstappen op nieuwere 'technieken' als het oude nog overal perfect op draait? Afgezien dan van het in plaintext opslaan van wachtwoorden ( wat ik overigens nog redelijk vaak zie bij mensen die wel met de nieuwste technieken werken).

Het is inderdaad "lachwekkend". In Nederland wordt er al veel serieuzer omgegaan met alleen al de basis gegevens van personen laat staan ook je complete medische geschiedenis en de communicatie er omheen.

Als MBO werken we met de nodige gevoelige gegevens van de studenten. Vanuit de MBO raad zijn er zeer duidelijke regels waar je je als school aan dient te houden ook als je deze gegevens bij bedrijven buiten de deur hebt staan (wat door diezelfde MBO raad soms wordt verplicht). Alle bedrijven die ook maar in aanraking kunnen komen met een deel van de gegevens van studenten zijn verplicht om een verklaring te ondertekenen dat de gegevens van de studenten niet buiten de afgesproken systemen mogen komen (dus ook niet ter analyse of ter test). Verder moeten ze bij ons aan kunnen tonen dat de beveiliging aan hun kant in orde is. Uiteraard moeten ook al onze medewerkers een verklaring ondertekenen en kunnen ze alleen bij de gegevens die voor hun van toepassing zijn. De raad van toezicht is samen met de direct eindverantwoordelijk en ook aansprakelijk als zulke zaken niet geregeld zijn.

Je vraagt je toch af hoe het kan dat een bedrijf dat zulke kwetsbare gegevens opgeslagen heeft staan nooit door de mand is gevallen is bij controles of hebben ze geen instanties in België die zulke bedrijven dienen te controleren op een veilige en juiste verwerking van zulke gegevens?

Heel simpel, prioriteit continu op andere dingen leggen en audits zijn gewoon interviews en invullijsten.

Wassen neus dus in veel gevallen. Wordt er om een papieren beschrijving van de situatie gevraagd en nooit een code review of een log inspectie. Als je maar hebt beschreven in Word hoe proces en systeem in elkaar zou moeten zitten.

En voilá sign off. Daar gaan vaak meer euro's heen dan het werkelijk veilig maken, veilig houden updaten en beheren.

[Reactie gewijzigd door djwice op 18 juli 2017 22:50]

Ik kan je verzekeren dat het bij ons niet het geval is. Bij een audit door de accountant is er inderdaad eerst een interview en mag ik de nodige gegevens oplepelen. Vervolgens komt er iemand naast mij zitten en die wil live mee kijken hoe je dingen geregeld hebt. En zij kiezen aan de hand van de informatie die je eerder hebt verstrekt en op basis van wat zij graag willen weten wat er getoond moet worden. Een accountants controle kost mij rustig een volle dag werk verspreid over 2 dagen. Indien nodig dan komt er een externe expert om het te beoordelen. En ja wij hebben in Word, Visio enz ook alle processen, datastromen en systemen beschreven.

Per volgend jaar komt er een extra jaarlijkse controle waarbij een security check wordt uitgevoerd. Random medewerkers die met studentgegevens werken worden dan ook getoetst op of alles wel in orde is, want je systeem is nu eenmaal zo veilig als de zwakste schakel er in. En helaas blijkt dit vaak toch de gebruiker te zijn.

Hoe kijkt hij dan mee? Hoe ziet hij dat data encrypted is en welke data dat is? Hoe ziet hij welk systeem je laat zien? Hoe ziet hij hoe veilig verbindingen zijn? Hoe ziet hij wie er wel en niet bij een systeem kunnen en wat er in de logs staat? Hoe sterk wachtwoorden zijn?

En hoe ziet hij dat de code veilig is en de salt niet al eeuwen het zelfde is voor alle wachtwoorden en dat het geen md5 is etc. etc.

Heeft een accountent uberhaupt kennis van al die gebieden?

En hoe goed zijn die security checks? Staat er in het rapport welke tools gebruikt zijn en hoe je de findings moet reproduceren? Of is het steeds dezelfde partij en is de security audit op non-prod systemen?

[Reactie gewijzigd door djwice op 18 juli 2017 23:13]

Hoe kijkt hij dan mee?

Gewoon simpel we zitten samen achter mijn systeem om alles door te lopen. De accountant (of de externe expert) geven aan wat ze willen zien van welk systeem en ik klik er voor ze doorheen.

Hoe ziet hij dat data encrypted is en welke data dat is?

Dit gaat op basis van het aantonen dat encrypty ingeschakeld staat. Vanaf volgend jaar komt er ook een controle van een extern bedrijf of het klopt wat wij laten zien. Encrypty op werkstations is pas per volgend jaar een verplichting. Voor de externe applicaties worden bewerkingsovereenkomsten gecontroleerd en worden je contract afspraken met de externe partijen doorgelicht. Uiteraard kan ik ze niet laten zien of ze bij een DUO, CITO enz daadwerkelijk de encryptie aan hebben staan aangezien ik dat zelf ook niet in kan zien.

Hoe ziet hij welk systeem je laat zien?

Wanneer er geen externe expert bij zit gaat dat op basis van wat zij aangeven welk systeem zij samen willen bekijken. Vervolgens mogen zij aangeven wat zij willen zien en klik ik er op mijn werkstation er doorheen. Ook hierbij is van toepassing dat gegevens niet zomaar geëxporteerd worden.

Hoe ziet hij hoe veilig verbindingen zijn?

Dit is een keer door een externe partij samen met ons doorgelicht. Ook een goede controle voor jezelf waar nog verbeterpunten te behalen zijn.

Hoe ziet hij wie er wel en niet bij een systeem kunnen en wat er in de logs staat?

Als het goed is hebben je systemen toch echt gewoon een access list voor wat betreft de rechten. Logs worden steekproefsgewijs samen bekeken.

Hoe sterk wachtwoorden zijn?

Dat is gewoon simpel laten zien wat je in je instellingen hebt staan aan eisen. Uiteraard krijgen ze geen inzicht in de wachtwoorden zelf. Wij hebben een identity management systeem over alle systemen heen liggen waar gebruikers op in moeten loggen en daar zitten niet de meest lichte eisen in aan wachtwoorden, maar wel op zo'n niveau dat het niet de gebruiker dusdanig moeilijk gemaakt wordt dat deze vervolgens zijn wachtwoord op gaat schrijven.

Heeft een accountent uberhaupt kennis van al die gebieden?

Nee niet van al die gebieden daarom schakelen ze steekproefsgewijs externe partijen voor in. De persoon die namens het accountantsbedrijf ons controleert is ook een andere persoon dan die bijvoorbeeld onze examinering moet controleren. Tijdens zo'n controle lopen er rustig 5-6 verschillende personen rond en er vind veel ruggespraak met personen binnen hun organisatie plaats. Vaak heb ik ze op onze afdeling dan ook op 2 verschillende dagen over de vloer en wordt er de 2e dag vaak verdieping gevraagd op dingen die ze de eerste dag bekeken hebben en die ze nog niet helemaal duidelijk is of waar ze vraagtekens bij hebben hoe het geregeld is.

Dat jij slechte ervaringen hebt met audits wil niet zeggen dat het overal slecht geregeld is met controles door accountants en overheidsorganisaties. Per volgend jaar komt er dus aanvullend ook vanuit de MBO raad een controle op hoe de privacy en de veiligheid allemaal geregeld is.

[Reactie gewijzigd door daredevil__2000 op 19 juli 2017 00:04]

Enerzijds bedrijf aanklagen en met een grote boog de deur uit goooien, anderzijds deze hufter opsporen en vervolgen wegens computervredebreuk, diefstal en afpersing. Daarnaast kijken of er door zijn toedoen misschien iemand iets van fysieke schade heeft opgelopen (hoop van niet), dan kunnen ze hem misschien ook nog vervolgen voor toebrengen van lichamelijk letsel... Lijkt mij dat er toch wel iets van gevangenisstraf uit te halen moet zijn...

Eerder die gast in dienst nemen voor 42 bitcoins, en zorgen dat t wel veilig wordt.

Een hacker een baan aanbieden om je omgving veiliger te maken snap ik.
Maar iemand een baan aanbieden die geld af probeert te persen op basis van gestolen patiëntengegevens? Nee, dat gaat mij net ff te ver.

Heb je de mail gelezen onder t bericht? Die kerel heeft t maanden eerder aangegeven dat t echt niet kon, en verzocht dit met spoed te veranderen: geen reactie. 3 maanden later stuurt ie een mail: jullie krijgen nog 1 week dit te veranderen, ik zou de gegevens kunnen publiceren, maar ze zijn t gevoelig, ik doe t niet: geen reactie..

Krijg dan toch ff lekker de schijdt met je beroerde beveiliging, wellicht zal 42 fakking Bitcoin je wakker schudden.. REACTIE: AANGIFTE!?

Nou zak er dan maar in hoor.. wie niet luisteren wil moet maar pleurishard voelen..

Er zijn natuurlijk andere methodes.
1 telefoontje naar een krant en je weet dat je de volgende dag op de voorpagina staat. Geen afpersing, geen gegevens die openbaar gemaakt hoeven worden en je naam als ethisch hacker is gevestigd. Nu is zijn naam ook gevestigd: als bekend wordt wie hier achter zit zal de naam als afperser hebben, en een strafblad...

Ja ik heb de e-mail er onder gelezen, dat neemt nog steeds niet weg dat op het moment dat de hacker begon met het afpersen de boel strafbaar is geworden. Tot dat moment kon het inbreken op het systeem van het bedrijf en het kopiëren van de data nog gezien worden als white hat hacking. Vervolgens krijgt hij niet zijn zin en gaat hij niet alleen over op het afpersen van het bedrijf maar ook op het afpersen van de diverse artsen met daarbij de persoonlijke/gevoelige gegevens van patiënten als inzet. Wanneer hij nu wordt gepakt krijgt hij een strafblad in plaats van de erkenning die hij zocht. Dat gaat zijn toekomstige carrière niet echt heel veel goed doen. Laat staan dat je nog makkelijk internationaal kan reizen. Een ethische hacker zitten bedrijven nog wel op te wachten maar een hacker die als een klein kind de boel begint af te persen op het moment dat hij zijn zin niet krijgt die wil niemand hebben.

maar een hacker die als een klein kind de boel begint af te persen op het moment dat hij zijn zin niet krijgt die wil niemand hebben.

Hangt er vanaf waar je wil werken. De Russische cybermaffia ziet vast geen bezwaar in een strafblad, het zal eerder tot aanbeveling strekken.

Dan nog doe je dit niet, je bent zelf sowieso strafbaar door al uberhaupt in te breken, en dan ook nog eens gaan dreigen, en zelfs afpersen? Nee deze man hoort gewoon in de gevangenis thuis.

Die ontwikkelaar eigenlijk ook

De vraag is natuurlijk of wanneer zo'n bedrijf al zoiets basic als het versleutelen van wachtwoorden achterwegen laat in zijn eigen applicatie hoe goed zij de logging dat geregeld hebben. Met een beetje pech is er weinig tot geen informatie terug te vinden over de inbraak.

Het bedrijf zou gewoon per direct onder curatele van een privacy organisatie of de overheid moeten komen te staan zodat het lek zo snel mogelijk wordt gedicht. Je bent als afnemer immers niet in 1 dag over naar een nieuw systeem. Daarna is er alle tijd om de directie van dit bedrijf te vervolgen voor nalatigheid en onbehoorlijk bestuur.

Het is natuurlijk geen goede zaak dat dit gehakt is geweest. De enige waarde aan de paswoorddatabase is dat veel mensen dezelfde login gegevens gebruiken voor site A als site B.

Voor de gegevens van de site zelf zal er niets schokkend te vinden zijn. Er bestaat immers een alternatief systeem dat zelfs geen paswoordlogin gebruikt voor patiënten. In dat systeem kies je de dokter, krijg je de kalender te zien en moet je enkel een geldig e-mail of telefoonnummer doorgeven. Die "berichtjes" aan de dokter zijn op zich vrij nutteloos.

voorschrift nodig voor aidsremmer bijvoorbeeld....

Dan zet je dit niet in het afsprakensysteem.

als je een afspraakblok hebt, dan kan je dit vragen tijdens de afspraak zelf (je hebt immers een gereserveerd blok, waarbij je ook een doktersbezoek moet betalen).
sommige dokters leveren soms ook voorschriften zonder officieel ingeboekt bezoek, maar dit valt buiten het reservatiesysteem.

Jij zet dit misschien niet in je bericht aan de dokter, maar ik durf ervoor te wedden dat het merendeel van de patiënten dit soort details er wel wel inzet. Wat zet je anders in het berichtenblok? Volgens mij staat er letterlijk boven dat veld dat je de "omschrijving van je klacht" moet formuleren. Een voorschrift vragen is slechts een voorbeeld natuurlijk. "Resultaten darmkankeronderzoek" is ook een omschrijving die niet de hele wereld moet weten.

Dat alternatief systeem zonder paswoordlogin werkt op dezelfde manier. Maar aangezien je geen login heb kan je achteraf je afspraak niet meer aanpassen of de afspraak in een ander tijdsslot plaatsen. Ook bij dit systeem is het niet de bedoeling dat je afspraakgegevens van andere patiënten kan bekijken.

[Reactie gewijzigd door biglia op 19 juli 2017 11:22]

omschrijving van klacht: ziek.

Dat de dokter zelf maar uitzoekt wat er mis is. symptomen zal ik op het moment zelf wel beschrijven. vooraf hoef ie ook niet meer dan dat te weten. Ik hoef ook niet zelf de diagnose te stellen.
Het is ook niet dat het afsprakensysteem zich dan aanpast voor andere ziektes.

In het andere afspraaksysteem is dit in ieder geval geen verplicht veld.

Je hebt wel gelijk dat veel mensen hierin veel te veel informatie willen zetten.

[Reactie gewijzigd door awenmaek op 19 juli 2017 12:32]

Bedrijven mogen hier toch echt niet meer mee blijven wegkomen. Het is toch basiskennis dat paswoorden toch minstens versleuteld opgeslagen moeten worden.

Hopelijk volgt er een klacht tegen de leverancier

Tegen de eigenaar/opdrachtgever bedoel je? Hoe wil je de leverancier van een website gemaakt in bijv. 2003 verantwoordelijk houden? Dit is gewoon nalatigheid van eigenaar/opdrachtgever als je het mij vraagt!

Dat hangt er helemaal vanaf hoe het geheel in elkaar zit. Als je een bepaalde versie koopt dan wel ja. Maar voor zover ik het op de site terug kan vinden betaal je gewoon maandelijks voor het afnemen van de dienst. Daarmee blijft de leverancier verantwoordelijk voor een veilige werking van de website en de gegevens die daar binnen opgeslagen staan. Hoe de infra van de dienst op de achtergrond is geregeld is de verantwoording voor de aanbieder van de dienst, niet voor de afnemer.

Verder is op de website onder voordelen ook te lezen:

Het systeem evolueert mee met latere ontwikkelingen.

Heb zelf een account bij digitale wachtkamer en vind het wel handig ... geen uren meer aanschuiven bij de dokter.
Gelukkig was mijn frank snel gevallen dat er iets niet in de haak zat toen ik na registratie mijn eigen wachtwoord in plain-text toegemaild heb gekregen. Dat ik toen mijn wachtwoord snel heb vervangen door een gegenereerd, random wachtwoord doet mij nu veel plezier

Ja, klopt. Ik had me in 2011 ook ingeschreven en kreeg deze e-mail:
--

Wij heten u van harte welkom op de Digitale Wachtkamer
Uw aanmeldgegevens voor uw volgende aanmelding zijn:

Login: ....
Paswoord: ....

Met vriendelijke groeten,
De Digitale Wachtkamer

--

Dan weet je dat je paswoord wordt opgeslagen.

Dat eerste mailtje zegt nog niet zoveel.
Tenslotte is je wachtwoord bekend bij de registratie.
Echter als het systeem erna je wachtwoord terug kan geven, dat is foute boel.