Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 59 reacties

De Autoriteit Persoonsgegevens heeft in een brief aan het Koninklijk Nederlands Genootschap voor Fysiotherapie laten weten dat als er bijzondere persoonsgegevens via een contactformulier verwerkt worden, dit moet zijn voorzien van een beveiligde https-verbinding.

autoriteit persoonsgegevensDeze verduidelijking volgde op een vraag vanuit het KNGF over de beveiliging van dergelijke formulieren. Zo worden er daarmee vaak BSN's en medische gegevens verstuurd, die aan te merken zijn als bijzondere persoonsgegevens. Dit zijn gevoelige gegevens die een grote impact op de persoonlijke levenssfeer kunnen hebben.

Een woordvoerder van de Autoriteit Persoonsgegevens bevestigde tegenover Tweakers dat de beveiligingseis niet alleen in dit geval toepasselijk is, maar ook een bredere toepassing kan hebben. Zo geldt bijvoorbeeld ook voor bedrijven en overheidsorganisaties dat als zij bijzondere persoonsgegevens via een webapplicatie verwerken, deze via een https-verbinding beveiligd moeten zijn. De verplichting tot degelijke beveiliging vloeit voort uit de Wet bescherming persoonsgegevens. Daardoor zouden bijvoorbeeld ook gemeentes aan deze eis moeten voldoen, echter bleek onlangs nog dat dit niet altijd het geval is.

Begin deze maand bracht de toezichthouder ook het advies uit dat het ondersteunen van het verouderde sslv2 tot overtreding van de wet kan leiden. Daarvoor was bekend geworden dat websites daardoor kwetsbaar kunnen zijn voor de zogenaamde 'Drown'-aanval.

Moderatie-faq Wijzig weergave

Reacties (59)

Het probleem is dat een ceriticaatje kopen en op je server neerplempen tegenwoordig niet genoeg is.
Teveel "IT-ers" die denken: "Kijk ik zie een SSL slotje, ik ben klaar !", laten dat aan de klant zien en ook zij zien een slotje en zijn tevreden.

Je dient daarna de server nog te configureren op basis van je doelgroep.
Teveel protocollen en cipher suites uitschakelen en je ondersteunt alleen de laatste browsers.
Alles "aan" laten staan (afhankelijk van gebruikte server OS) en je ondersteunt weliswaar ook oude browsers, maar je bent dan niet "veilig" meer.
En zelfs de volgorde van gebruikte cipher suites kan je instellen op je server.
Een ander probleem is dat dit geen éénmalige handeling is. Een cipher suite wat nu nog veilig wordt geacht kan over een tijdje als onveilig worden gezien en dan dien je dat ook tzt uit te schakelen.
Dat klopt allemaal, maar er zijn websites op het internet die je hier bij helpen. Zoals Mozilla server side tls en ssllabs test.

Als je een administrator bent, die servers beheert waar BSN data over en weer gaat. Dan ben je in mijn optiek verplicht naar je gebruikers om dit te regelen.

[Reactie gewijzigd door jvdheuve op 25 maart 2016 17:59]

https://www.htbridge.com/ssl , ook een hele goede, die scant ook mailservers.
Daar zou deze wet ook op moeten gelden vind ik. Alleen via TLS met goede ciphers en liefst ook nog Perfect Forward Secrecy.
Zie ook http://cipherli.st

Tweakers doet het overigens slecht:
  • Non-compliant with PCI DSS requirementsNon-compliant with NIST guidelines
  • The server is vulnerable to POODLE over SSL
  • Consider generating a stronger Diffie-Hellman parameter
  • Consider reviewing the set of supported protocols
  • Consider reviewing the set of supported cipher suites

[Reactie gewijzigd door twicejr op 25 maart 2016 18:59]

Dan wil ik graag nog "testssl.sh" aanraden, lokaal te draaien en eventueel met cron te schedulen. Plus: kleurtjes! :9
In principe geld de wet natuurlijk natuurlijk niet alleen voor websites. De wet stelt namelijk enkel heel generiek dat persoonsgegevens veilig verwerkt dienen te worden. Er worden in de wet en richtlijnen wel enkele regels aan gesteld maar deze zijn niet uitsluitend en op zichzelf niet genoeg om aan de wet te voldoen.

Ik denk overigens dat een goede SSL implementatie van e-mail voor de wet niet nodig is. Het is namelijk überhaupt niet toegestaan om gevoelige persoonsgegevens uit te wisselen via de e-mail. E-mail is namelijk een van nature onveilig protocol; de verbinding vanaf je eigen mailserver naar de volgende hop mag dan misschien wel veilig zijn maar indien je geen volledige controle hebt over de infrastructuur van zowel de ontvanger als verzender kun je nooit garanderen dat de communicatie veilig verloopt. Het is niet voor niets dat steeds meer partijen overstappen op een 'berichtenbox'. Je krijgt per e-mail melding dat er een nieuw bericht is (zonder linkje, let wel! Dat is namelijk gevoelig voor phishing) en je kunt het bericht zelf lezen op de website van de verzendende partij.
O.a. de Rijksoverheid, ziektenkostenverzekeraars en opleidingsinstituten gebruiken deze methode al.

[Reactie gewijzigd door Joolee op 25 maart 2016 20:32]

De overheid kan ook met netwerken anders dan internet met elkaar communiceren. Deze netwerken zijn met elkaar verbonden o.a. door diginetwerk (zie site logius).
Suwinet-Mail is een dienst die de mail over deze besloten netwerken laat gaan ipv internet. Op deze manier kunnen persoonsgegevens in principe veilig over en weer gestuurd worden zonder zelfs maar gebruik te maken van tls/ssl.
Sterker nog; voor Tweakers wordt HTTPS wordt alleen gebruikt op https://secure.tweakers.net en niet voor de frontpage of whatsoever. Dus geen idee welk domein je getest hebt, maar ik vermoed niet de juiste. :)

[Reactie gewijzigd door CH40S op 26 maart 2016 22:02]

Ik heb de mailserver getest mail.tweakers.net:465 .
Wel de poort waarop TLS draait.
Zo worden er daarmee vaak BSN's en medische gegevens verstuurd, die aan te merken zijn als bijzondere persoonsgegevens. Dit zijn gevoelige gegevens die een grote impact op de persoonlijke levenssfeer kunnen hebben.
Grote ? Impact ? "Zou kunnen hebben" ?

Ik vind dit zeer onduidelijk gedefinieerd. Valt bijvoorbeeld een reservering voor een massage hier ook onder? En dan één misschien niet. Maar als iemand nou regelmatig de salon bezoekt? Wat is dan de grens? En hoe zit dat dan met de verhuur van een auto? Of het bestellen van etenswaren en kleding etc? Ook kleding "zou" een impact kunnen hebben op iemand zijn persoonlijke levenssfeer.

De persoonlijke levenssfeer omvat eigenlijk alles wat iemand doet in het leven.
Als je de precieze definitie wilt, kan je de Wet Bescherming Persoonsgegevens erop naslaan. Dit is puur een sterk vereenvoudigde samenvatting, die zich vooral richt op waarom ze bijzondere bescherming moeten krijgen.
De verwerking van persoonsgegevens betreffende iemands godsdienst of levensovertuiging, ras, politieke gezindheid, gezondheid, seksuele leven, alsmede persoonsgegevens betreffende het lidmaatschap van een vakvereniging is verboden behoudens het bepaalde in deze paragraaf. Hetzelfde geldt voor strafrechtelijke persoonsgegevens en persoonsgegevens over onrechtmatig of hinderlijk gedrag in verband met een opgelegd verbod naar aanleiding van dat gedrag.
Wat overigens nog wel eens vergeten wordt is dat een foto (mits te koppelen aan de persoon) ook een bijzonder persoonsgegeven is omdat je daar over het algemeen het ras en soms ook godsdienst/levensovertuiging uit kunt afleiden.

[Reactie gewijzigd door ACM op 26 maart 2016 09:49]

Ik had laatst via een webformulier van een ziekenhuis dat ik wat moest versturen, dit was ook onversleuteld. Had bij de opmerkingen bijgezet dat ik het een slechte zaak vond.

Werd wel teruggebeld nav het formulier maar snapte niet van m'n opmerking. Na een klein gesprekje werd al snel duidelijk dat het beeld van het personeel daar is dat de IT slecht geregeld was. Dit is dan waarschijnlijk wel een algemeen beeld over de kantoorautomatisering, maar ik denk dat rest van IT systemen bij hetzelfde clubje in beheer zijn.
Websites zijn juist regelmatig buiten het normale netwerk geplaatst, vaak in beheer bij een partij die in webhosting gespecialiseerd is. Je wilt niet dat de site via een lek toegang geeft tot het patiëntendossier of vergelijkbare systemen.
Maar is het dan juist niet extra vreemd dat het formulier niet beveiligd was? Daarbij wil een extern bedrijf niet echt garanderen dat gegevens veilig blijven. Zo zijn er laatst nog persoonsgegevens van het dorp waar ik woon (Oegstgeest) verspreid omdat iemand een USB stick van zijn werk thuis in zijn router (meende ik?) had gestoken waar stapels persoonsgegeven op stonden. De afhandeling van persoonlijke gegevens is een eerste klas puinhoop, bij zowel zakelijk Nederland als de overheid.
Tuulijk, ook externe bedrijven kunnen er met de pet aan gooien, maar zoals gezegd: als het al 2 aparte systemen zijn, dan is dat al winst. Maar sowieso moet elke site ondertussen wel in HTTPS gaan werken, zeker als je informatie over het lijntje gaat gooien wat niet zo openbaar mag worden.

Ik vraag me echter af of degene die de mailtjes ontvangt, ook degene is met de benodigde ervaring en niet zozeer ingaat op inhoud dan op de techniek ;)

[Reactie gewijzigd door Martinspire op 25 maart 2016 18:00]

Ik draai een hobby-website die niet al te groot is maar toch een redelijk aantal gebruikers heeft(20000 per maand of iets in die orde van grootte) en hoewel ik geen specifieke kennis heb wat dit betreft heb ik er toch maar voor gekozen om standaard https te draaien met uitsluitend de "veilige" varianten van TLS.
Was het maar zo... Ik ken genoeg omgevingen waarbij je direct vanaf de webserver zo hoppa het bedrijfsnetwerk in duikt. Als je vervolgens navraagt naar het hoe en waarom, dan komen argumenten als "Dat hebben we al jaren zo" en "Dan hoeven we niet zo lang te wachten totdat de wijzigingen bijgewerkt zijn" tegen. Echt complete bullshit.

Wij hebben zelf alle omgevingen strikt gescheiden van elkaar, zoals het natuurlijk ook hoort. We hebben wel een formulier waar zeer vertrouwelijke data in verwerkt wordt, maar vanzelfsprekend na inloggen en via een beveiligde verbinding. De data wordt na het posten van het formulier direct verwerkt en verwijderd van de server.

Het enige risico wat we lopen is dat de frontend gehackt wordt. Vroeg of laat gaat dat gewoon een keer gebeuren ben ik bang. Maar omdat daar niets meer of minder in staat dan een e-mailadres én een tijdelijk wachtwoord dat per SMS verstuurd wordt, zal dat niet zoveel interessants bevatten.

Tips zijn echter altijd van harte welkom :-)
Zijn weinig mensen buiten de IT die vinden dat de IT goed geregeld is binnen een bedrijf denk ik gezien ze thuis wel alles mogen en op het werk meestal niet. Maar dat even ter zijde.

Ze hadden de melding beter kunnen forwarden naar de hosting partij. Raar dat dat niet gebeurd is.
Zijn weinig mensen buiten de IT die vinden dat de IT goed geregeld is binnen een bedrijf
Ik kan ze geen ongelijk geven. Ik ken geen enkel bedrijf (of wat voor organisatie dan ook) waar het goed gaat. IT is gewoon verschrikkelijk moeilijk. Onze software zit vol fouten, er zijn eindeloos veel zaken om rekening mee te houden, alles is voortdurend in beweging en het kost verschrikkelijk veel geld. Voortdurend moeten we vervelende compromissen sluiten zoals tussen gemak en veiligheid.
Op sommige plekken en sommige gebieden gaat het beter dan elders maar ik heb nog nooit gezien dat het op alle gebieden goed is.

Nu kun je dat tot op zekere hoogte over onze hele maatschappij zeggen maar in de IT is het wel heel erg.
Mensen moeten zo af en toe gewoon hun verwachting bijstellen / verwachtingen moeten beter gemanaged worden... en daar heeft ICT ook wel een rol in denk ik.

Het gros van de klachten komt gewoon voort vanuit vergelijkingen met een thuissituatie. Er zijn natuurlijk 101 redenen waarom die vergelijking niet gemaakt kan worden en ik denk dat je dat voor een belangrijk deel wel kan afvangen gewoon kort en bondig uit te leggen waarom niet als zoiets ter discussie komt.
ICT en hoger management zijn in veel bedrijven echter van die onbenaderbare afdelingen en dan krijg je van die "verhalen" en "wijsheden".
Het probleem is dat IT een kostenpost is. Dit brengt niet op... en als het al gaat over automatisering... dan is het op hoeveel tijd is het terug verdient of hoeveel mensen kan ik afdanken....

Imho het is pas recent dat SSL certificaten gratis te krijgen zijn... als je weet dat sommige KMO's al klagen bij hosting kosten van 200euro per jaar kun je moeilijk 100euro aan een SSL certificaat verkopen (want ja.. daar zit ook werk en support in).

edit:
Je hebt blijkbaar nog nooit in een bedrijf gewerkt waarbij IT een 'middel' is.. dat is hetzelfde als een telefoon of een nietjesmachine.

Een IT-er die een SSL certificaat moet onderhouden bij een hosting kost meer als 15min. Openen van SSL portaal. Het openen van remote environment. Het valideren en de klant een mail sturen, opvolgen van betalen van factuur, ....
Een IT-er zijn uurtarief ligt rond de 75euro excl btw...

[Reactie gewijzigd door Icekiller2k6 op 25 maart 2016 17:59]

Het probleem is dat IT een kostenpost is. Dit brengt niet op... en als het al gaat over automatisering... dan is het op hoeveel tijd is het terug verdient of hoeveel mensen kan ik afdanken....
Volgens mij heeft een modern bedrijf zonder ICT geen bedrijfsvoering...
Dus hoewel een kostenbaten analyse niet zo makkelijk is als bij bijvoorbeeld een sales medewerker is dat wel iets te kort door de bocht geredeneerd.
Als je aan het hoofd staat van een bedrijf en zo denkt zou ik me zorgen maken.
Imho het is pas recent dat SSL certificaten gratis te krijgen zijn... als je weet dat sommige KMO's al klagen bij hosting kosten van 200euro per jaar kun je moeilijk 100euro aan een SSL certificaat verkopen (want ja.. daar zit ook werk en support in).
Een SSL certificaat heeft geen significant onderhoud buiten een jaarlijkse verversing die niet meer dan 15 minuten mag duren en dat kan elke ICT'er doen die je toch al in dienst hebt.
Er is absoluut zoiets als een gezonde kritische blik op je bedrijfskosten, begrijp me niet verkeerd, maar je hebt ook zoiets als moeilijk doen om het moeilijk doen... als je een ziekenhuis runt kan het niet zo zijn dat die marginale kosten van een certificaat een daadwerkelijk issue is.

[Reactie gewijzigd door Alpha Bootis op 25 maart 2016 17:38]

"Een SSL certificaat heeft geen significant onderhoud buiten een jaarlijkse verversing die niet meer dan 15 minuten mag duren en dat kan elke ICT'er doen die je toch al in dienst hebt."

Dat is juist de instelling waarmee het fout gaat. GoT, hierboven, geeft prima aan waarom dat nou juist niet goed is. Het configureren van een SSL certificaat voor een website eindigt niet met 'er is een slotje in de browser!'. Er is kennis van zaken voor nodig om een webserver zo veilig mogelijk te configureren. Hierbij moeten concessies worden gedaan waarvoor je kennis moet hebben van de techniek, de doelgroep en het gewenste beveiligingsniveau van de website. Dat kan niet "elke ICT'er doen die je toch al in dienst hebt."

Verder is het ook nodig om de configuraties up-to-date te houden. Technieken die een jaar geleden als veilig werden gezien, zijn nu hopeloos achterhaald.
Het in gebruik nemen van een certificaat is een kwestie van de config file in kwestie vertellen waar deze staat. Daar heb je geen verstrekkende kwalificaties op webserver gebied en/of applicatieontwikkeling voor nodig. Ook het in en uitschakelen van cipher suites (en achterhalen welke nog veilig zijn, vermoedelijk waar je het in je laatste alinea over hebt) is geen raketkunde en hoort tevens gewoon bij regulier serveronderhoud.
Sterker nog je hebt tegenwoordig gewoon sites die je exact vertellen wat je uit zou moeten zetten zoals SSL labs.
Dat is voor een beetje doorgewinterde allround IT'er echt geen probleem.

Je moet uiteraard wel een beetje snappen waar het over gaat maar dat gaat voor alles op. Je moet het niet groter maken dan het is want als mensen het idee krijgen dat het zware materie is blijven ze er alleen maar bij uit de buurt.
Mensen moeten zich juist bezig gaan houden met dergelijke zaken. Hoe meer hoe beter. Dat daar niet vanaf moment 1 de meest optimale configuraties uit komen zal ongetwijfeld zo zijn maar een brakke SSL implementatie is beter dan geen SSL implementatie.
Wijsheid komt met de tijd vanzelf.

[Reactie gewijzigd door Alpha Bootis op 26 maart 2016 19:10]

Het probleem is dat IT een kostenpost is. Dit brengt niet op... en als het al gaat over automatisering... dan is het op hoeveel tijd is het terug verdient of hoeveel mensen kan ik afdanken....

Imho het is pas recent dat SSL certificaten gratis te krijgen zijn... als je weet dat sommige KMO's al klagen bij hosting kosten van 200euro per jaar kun je moeilijk 100euro aan een SSL certificaat verkopen (want ja.. daar zit ook werk en support in).
Daarom pleit ik er voor dat IT-beveiliging een plicht wordt met controle. Net zoals ieder kantoor door de brandweer wordt gecontroleerd en iedere auto regelmatig gekeurd wordt. Dat hoeft geen ingewikkelde controle te zijn maar een basale checklist met zaken als "is er een wachtwoord ingesteld" of "gebruikt de site https" zou al veel verschil maken.

Het maakt het ook een stuk makkelijker om het aan de baas uit te leggen. Als brandmelders niet verplicht waren denk ik dat NL er heel anders uit zag. Hoeveel concierges lukt het om hun baas te overtuigen om rookmelders en sprinklers te installeren? Als de brandweer gebouw sluit dan is de baas snel om.
Ik snap niet waarom zo'n persoon die niets van je opmerking snapt niet gewoon je melding forward naar de ICT afdeling en eventuele compliance officer waarvan ik absoluut zeker weet dat er één van rondloopt in zo'n ziekenhuis... het kan met al die regelgeving rondom data niet anders dan dat daar gewoon iemand full-time mee bezig is.

Dat geëmmer over dat ICT al dan niet slecht is geregeld is zo'n perceptie dingetje waar je onder de streep geen drol aan hebt. Dat de computers langzaam zijn wil bijvoorbeeld niet zeggen dat het ook feitelijk slecht ingeregeld is. Dat kan ook gewoon een budgetgebrek zijn of eisen elders.
Zeker als iets implicaties voor beveiliging met zich meetrekt moet er gewoon iemand naar gaan kijken. Of een forumuliertje wel of niet middels HTTPS aangeboden/geforceerd wordt is een kwestie van 1 configuratievariabele. (en een certificaatje) Dat is zo opgelost.
Althans... als je de kwalificaties bezit om de ICT in een ziekenhuis te mogen doen danwel jezelf verkoopt als webhoster mag ik hopen je dat je min of meer weet hoe dat werkt. :P

[Reactie gewijzigd door Alpha Bootis op 25 maart 2016 17:05]

Ik snap niet waarom zo'n persoon die niets van je opmerking snapt niet gewoon je melding forward naar de ICT afdeling en eventuele compliance officer waarvan ik absoluut zeker weet dat er één van rondloopt in zo'n ziekenhuis... het kan met al die regelgeving rondom data niet anders dan dat daar gewoon iemand full-time mee bezig is.
Ze zijn v.z.i.w. ook wettelijk verplicht om jou up-to-date contactgegevens te verstrekken van de data controller. Gebeurt eigenlijk ook nooit.

Als het CBP echt serieus met boetes zou gaan schieten, zou zowat half gegevens-verwerkend Nederland platzak gaan.

[Reactie gewijzigd door R4gnax op 25 maart 2016 21:06]

Ach, zelfs mensen die hun brood verdienen met online business snappen er geen zak van. Waarom moet ik een SSL Certificaat? Mijn payment provider heeft er toch één? Maar inderdaad, als het ambtenaren zijn is het nog droeviger gesteld.
Het is treurig dat enkel SSLv2 als verouderd bestempeld wordt. Het is namelijk sterk af te raden om SSLv3 toe te laten: Poodle attack disablessl3.

[Reactie gewijzigd door jvdheuve op 25 maart 2016 16:46]

Waar wordt 'alleen' SSLv2 als verouderd bestempeld? Of roep je maar wat?
Laatste alinea van het artikel: "Begin deze maand bracht de toezichthouder ook het advies uit dat het ondersteunen van het verouderde sslv2 tot overtreding van de wet kan leiden." - zie nieuws: Autoriteit Persoonsgegevens: gebruik sslv2 kan in strijd zijn met de wet voor meer info.
Ja...maar er staat toch nergens enkel en/of alleen?

Beetje systeem beheerder weet dat SSLv3 ook niet (meer) 100% veilig is, maar nog wel (veel) gebruikt

[Reactie gewijzigd door RJWvdH op 25 maart 2016 17:53]

Dat de Autoriteit Persoonsgegevens alleen SSLv2 en niet SSLv3 als onveilig noemt is precies het punt dat jvdheuve maakt. Als zo'n toezichthouder roept dat je dan in strijd met de wet handelt is het wel zo handig om volledig te zijn.
Dan zijn dat zeker selfsigned V3 certificates, want denk niet dat je ze meer kan kopen. En de oude zal onderhand ook al wel verlopen..
Alles wat je nu koopt is TLS1.2 en SHA256 hash

[Reactie gewijzigd door citegrene op 27 maart 2016 01:48]

Daarom moet je ook TLS v1.2 gebruiken en alle SSL versies links laten liggen.

SSLv2 is namelijk erg onveilig en is al na een jaar opgevolgd door v3 (en ook al deprecated & prohibited gemaakt in 2011), de enige juiste versie is TLS v1.2

[Reactie gewijzigd door GrooV op 25 maart 2016 16:58]

Mooi. :)
Het lijkt me dat je, zeker in de (para)medische sector, toch wel ¤5 kan missen voor een SSL certificaatje of het zelfs via LetsEncrypt kan binnenhalen. Zoveel moeite is het niet... Maar bij dit soort beroepen wel heel erg belangrijk.
Ik vermoed dat het in de praktijk eerder zo gaat;

-Ziekenhuis heeft website nodig
-Vind een extern bedrijf wat dit gaat bouwen
-Requirements worden opgesteld door een niet-technisch onderlegd persoon

Een eis als 'site moet https gebruiken' valt dan al snel buiten de boot. Wat ik echter kwalijk vind is dat de bouwer niet met de hakken in t zand is gegaan en ervoor pleit dat dit een MUST is.
Daarentegen als je pech hebt als bouwer wordt zoiets genegeerd "omdat het geld kost en niks zichtbaars opleverd".

En notitie: veel eigen ervaring hiermee gezien ik ook tot een club 'bouwers' behoor :)
Heb zelf bij meerdere bedrijven gewerkt voor het maken van software, het zal je verbazen hoe veel bedrijven er werken op het principe; "U vraagt, wij leveren.". Ook is er nog het probleem dat er partijen zijn die niets willen weten van die dingen, ook al kost het bijna niets, ze kennen het niet en willen het niet.

Voor een bedrijf is het belangrijk dat de persoon die naar een externe partij gaat voor het opstellen van de requirements ook een redelijke basiskennis heeft. Dit zou enorm veel problemen kunnen voorkomen.
Het levert een groen padlock icoontje op, het is alleen jammer dat mensen daar niet op letten.
Wat ik echter kwalijk vind is dat de bouwer niet met de hakken in t zand is gegaan en ervoor pleit dat dit een MUST is.
De meeste ontwikkelaars zijn liever lui dan moe. Ik kom er op jaarbasis enkele tientallen tegen en het is allemaal bedroevend slecht gesteld. Het project wordt opgeleverd, er wordt niet gekeken naar welke checklist dan ook, maar men is klaar. Hoezo, SSL? Zelfs de meest eenvoudige functionaliteiten worden niet geactiveerd.

Als je de ontwikkelaar er daar dan vervolgens op aanspreekt dan hebben ze zelf niets fout gedaan. "Ja, wist je wel hoe goedkoop dit project was?" Ja, en? Als ik een Dacia koop tanken ze 'm ook gewoon af en is 'ie toch ook startklaar? Zum kotsen die clubs, maar goed.
Ja, dat is ook zo.
Er zijn teveel beunhazen die maar wat doen, en veel mensen in de (para)medische sector willen zo goedkoop mogelijk een website. Je kan voor ¤75 geen goede site krijgen. Het bestaat gewoon niet... Komt enkel ellende van. Toch doen ze het. En vaak zie je dan later spijt krijgen, en dan komen ze om hulp vragen. Dan schrikken ze even van de prijsopgave, en moet je nog gaan toelichten dat het redelijk is ook (okee, ben wat aan de dure kant.); en dan kunnen er twee dingen gebeuren:
1.) Ze gaan akkoord
2.) Ze kiezen voor... Beunhaas 2 die voor ¤25 "alle problemen" oplost. :')
... En het gezeik begint weer van voor af aan.

Een bouwer moet dit gewoon aangeven, jij bent immers de expert; die fysio niet. Die weet enkel dat ze moeten voldoen aan WBP. *Hoe* ze dat moeten doen... Tja. Dat is aan de technische man/vrouw. ;)

Ik ben oprecht van mening dat het goed zou zijn als er een keurmerk komt voor personen/bedrijven die websites willen bouwen voor de (para)medische sector. Als je een beetje serieus bent als bouwer, dan laat je je accrediteren. En als je een beetje bezorgd bent dat je spullen goed in elkaar zitten, dan ga je als (para)medicus opzoek naar een site bouwer die geaccrediteerd is. Ze moeten zich goed realiseren dat de boetes hoger zijn dan zo'n site goed laten bouwen kost... Maarja, zoiets zal er zo 1,2,3 niet komen ben ik bang. :P
"omdat het geld kost en niks zichtbaars opleverd".
http://ist2-2.filesor.com...1/M/V/j/1MVj1/1%20(2).gif

[Reactie gewijzigd door WhatsappHack op 26 maart 2016 04:08]

Voor de gemiddelde paramedicus zal die paar tientjes meer voor een degelijk certificaat enkel als 'verkopen' van de bouwer gezien worden. Ik zie het in mijn omgeving ook wel met mensen die bijvoorbeeld een webshop starten. Ze vertellen dan op een verjaardag dat de 'websitebouwer' ze allemaal extra dingen als een 'veilige verbinding' wilde verkopen en zulks. Het blijft gewoon een beetje jezelf verdiepen in materie denk ik. Helemaal als zelfstandig ondernemer zul je in de beginfase van je bedrijf toch heel veelzijdig moeten zijn qua kennis.
Ieder z'n vak natuurlijk. Fysiotherapeuten hebben over het algemeen niet zoveel op met IT. De websites zijn altijd netjes, maar wel heel erg eenvoudig. Bij de meesten kom je nog wel een contactformulier tegen, maar een afsprakenformulier is al snel teveel van het goede. En als het werkt, dan raken ze die ook het liefst nooit meer aan, want dan moet je weer die dure webbouwer inhuren om het te fixen.
Ja dat zijn eigenlijk twee mentaliteiten die niet kloppen.

Ten eerste heb je gelijk natuurlijk; ieder z'n vak. Maar dan moet de gene die de website bouwt SSL voorstellen, anders moet je gewoon geen sites voor de (para)medische sector maken. Hoewel de eindverantwoordelijkheid ligt bij de fysiotherapeut (of wie dan ook), ben ik wel van mening dat bedrijven die zo iets in elkaar willen zetten ook een mate van verantwoordelijkheid opgelegd moeten krijgen. En als SSL geweigerd wordt door de klant, dan een vrijwaringsformuliertje laten tekenen dat ze de implicaties snappen en jou vrijwaren van enige schuld. Maar als je als site bouwer die informatie niet verstrekt (SSL is noodzakelijk voor beveiliging): dan kan je dat niet per definitie die fysiotherapeut aanrekenen omdat het inderdaad hun vak niet is.
Teveel beunhazen die rondlopen, dat is denk ik het probleem.

Ten tweede moet de fysiotherapeut als het aankomt op beveiliging van patiëntgegevens natuurlijk gewoon het geld investeren. (Zeker als het van die lullige bedragen zijn) Als ze dat niet doen, is het gewoon nalatigheid...
Ik vind het treurig dat ze het überhaupt moeten vragen. Voor mij is het vanzelfsprekend dat bijzondere persoonsgegevens altijd via een beveiligde verbinding moeten worden verstuurd. Iedere consultant had ze dat kunnen vertellen. Het doet me afvragen hoe ze verder met hun vertrouwelijke gegevens om gaan als dit niet vanzelfsprekend is.

Dit geval onderstreept waarom ik er voor pleit om altijd HTTPS te gebruiken. Het is blijkbaar moeilijk om te beoordelen wanneer het nodig is. Als we altijd HTTPS gebruiken dan kan het ook niet meer fout gaan.
Tot de volgende heartbleed lek.
Vet iemand heeft ook een klok horen luiden...

Naast dat ze eigelijk het antwoord al wel op de vraag wisten is het natuurlijk beetje raar dat je een vraag gaat stellen aan Autoriteit Persoonsgegevens om een Certificaat van misschien maximaal ¤ 100,-.
HTTPS certificaten zijn tegenwoordig gratis te krijgen. De enige kosten zijn het implementeren van het gebruik ervan, maar dat is een vereiste.
Zijn dat ook organization validated certificaten of enkel domain validated? Voor partijen als ziekenhuizen heb ik liever eerstgenoemde namelijk, zodat ik weet dat mijn gegevens écht naar het ziekenhuis stuur ipv sciptkiddies.

Edit:
Lijkt erop van niet, zie ook hier: https://community.letsenc...anization-validation/6753 Let's Encrypt is leuk voor particulieren en mkb, verder dus niet.

[Reactie gewijzigd door CH40S op 27 maart 2016 11:49]

En weet ook nog een de klepel hangt ;)

De hele reden om in dit soort gevallen SSL te gebruiken, werdt met een lek zoals heartbleed te niet gedaan.
Ja je verbinding was beveiligd, maar je gegevens waren met een beetje geluk, uit het geheugen van de server te vissen.

Daarom kan je en mag je niet zeggen, dat door het gebruik van HTTPS het nooit fout kan gaan, zoals Capslock2000 het zegt.

Dan nog, de CA's bestaan op basis van vertrouwen. Je hoeft maar 1 rotte vis er tussen te hebben ( en die zijn er) en je hele beveiliging ligt op zijn gat.
Maar dat hebben we niet geleerd van o.a. diginotar :)
Daarom kan je en mag je niet zeggen, dat door het gebruik van HTTPS het nooit fout kan gaan, zoals Capslock2000 het zegt.

Dan nog, de CA's bestaan op basis van vertrouwen. Je hoeft maar 1 rotte vis er tussen te hebben ( en die zijn er) en je hele beveiliging ligt op zijn gat.
Maar dat hebben we niet geleerd van o.a. diginotar :)
Er kan vanalles fout gaan, maar je kan niet meer vergeten om HTTPS aan te zetten, dat was mijn punt.

Perfecte oplossingen bestaan niet, zeker niet als het om veiligheid gaat. Dat is geen reden om niet te doen wat wel mogelijk is. Een goede beveiliging bestaat uit lagen. Al die lagen zijn imperfect maar als je er genoeg (en de juiste) hebt dan bieden ze samen ze redelijk wat veiligheid.

Het is heel makkelijk om overal gaten te zien, dat is zelfs een belangrijk aspect van ons werk in de IT, maar je kan niet altijd "nee" zeggen, de wereld gaat verder. De kunst is om je beveiliging "goed genoeg" te maken om te overleven, gegarandeerd veilig bestaat niet.
Dat is natuurlijk te makkelijk... Ik heb ook klanten die updates uitstellen 'omdat er toch wel weer eentje achteraan zal komen'. En ondertussen is de zooi zo lek als een mandje.
Zo worden er daarmee vaak BSN's en medische gegevens verstuurd, die aan te merken zijn als bijzondere persoonsgegevens. Dit zijn gevoelige gegevens die een grote impact op de persoonlijke levenssfeer kunnen hebben.
Ik heb nog geen (overheids)instantie hierop betrapt, maar als er daadwerkelijk formuliertjes zijn waar al die meuk gewoon eau naturelle over internet gaat moet die instantie onder stevig verscherpt toezicht geplaatst worden...
Het lijkt mij intuïtief volstrekt vanzelfsprekend dat dergelijke data via HTTPS dient te verlopen.
Wauw, ik sta versteld dat het niet vanzelfsprekend was. Ik vertik het zelfs om m'n e-mail of telefoonnummer zonder TLS te versturen - laat staan BSN e.d.
Wauw, ik sta versteld dat het niet vanzelfsprekend was. Ik vertik het zelfs om m'n e-mail of telefoonnummer zonder TLS te versturen - laat staan BSN e.d.
Ik heb zelfs van een aantal bedrijven (stomgenoeg altijd kaliber grootbedrijf...) al bij het CBP gemeld dat er persoonsgegevens over onbeveiligdde verbindingen opgevraagd en/of verstuurd worden.

Misschien helpt het niets, misschien helpt het iets. Wie zal het zeggen. Het kost maar 5 minuten, dus je kunt het net zo goed gewoon doen.
Heb hier laatst aan de klantzijde (overheid) mee te maken gehad. Die hadden wel de voorkant (formulier) met TLS 1.0 versleuteld maar niet richting de backend. Dat was niet mogelijk (lees te duur).
Pas met Let's Encrypt bezig geweest. Gratis certificaat en bevalt me erg goed. Link: https://letsencrypt.org/
Let's Encrypt is leuk, maar doet enkel domain validation. Organization validation doen ze niet. En juist zo'n certificaat wil je bij omgevingen als webshops, banken, ziekenhuizen en overheden. Zodat je ook 100% zeker weet dat je de gegevens écht naar die organisatie stuurt.

Zie ook: https://community.letsenc...anization-validation/6753

[Reactie gewijzigd door CH40S op 27 maart 2016 11:56]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True