Wachtwoord-op-monitor in ziekenhuis

Door Rukapul op maandag 5 september 2011 07:30 - Reacties (30)
Categorie: -, Views: 7.445

Een recent bezoek aan een ziekenhuis bevestigde nog maar eens een stereotype over informatiebeveiliging in de gezondheidszorg: de welbekende gebruikersnaam/wachtwoord geplakt op de monitor:
http://kosteronline.net/pics/blog/inlogcodes.jpg


Helaas was dit niet de enige teleurstelling. Een paar snelle observaties leerde:
  • gebruikersnaam/wachtwoord op scherm geplakt
  • de schermen met persoons- en behandelgegevens zijn richting de open ruimte gericht
  • op de twee aanwezige schermen tonen gegevens van twee verschillende patienten (een gerelateerd aan de huidige patient, een ander gerelateerd aan de vorige patient of de patient in de aanpalende behandelruimte)
  • patienten en begeleiders worden alleen gelaten in de ruimte met vrij toegang tot de beschikbare computers
  • de schermen worden niet gelocked
Hoewel gebruikersgemak en workflow belangrijk zijn in medische omgevingen worden zelfs enkele hele eenvoudige maatregelen achterwege gelaten varierend van technische maatregelen tot de opstelling van de apparatuur.

Dat technische maatregelen niet automatisch betekenen dat het perfect werkt toont het resultaat van een recent Noors onderzoek aan, maar het is beter dan niets:
http://kosteronline.net/pics/blog/acexperiences.png

Uit Healthcare Professionals' Experiences With EHR-System Access Control Mechanisms. Hier zal men in bovenstaand ziekenhuis nog niet snel tegenaan lopen ;)

Zakelijke persoonlijke vragen

Door Rukapul op woensdag 10 november 2010 23:36 - Reacties (7)
Categorie: -, Views: 4.342

Onlangs kwam ik in aanraking met A-OK van Arcot wat o.a. gebruikt kan worden om in te loggen op een bedrijfsnetwerk als alternatief van bijvoorbeeld een Secure-ID tokens. A-OK werkt op basis van persoonlijke vragen zoals wat is je naam van je eerste liefde? En je teddybeer?

Aangezien deze authenticatie typisch puur zakelijk is rijst de vraag waarom je als werknemer de antwoorden op dit soort persoonlijke vragen met je werkgever of IT dienstverlener zou willen delen? Niet echt gepast in elk geval.

Zou voor zakelijke toepassingen de authenticatie niet zou moeten werken op basis van kennis van zakelijke informatie? In elk geval is er dan geen conflict op het vlak van ethiek of persoonsgegevens. De creatieve geesten van Arcot & co. kunnen vast een paar mooie vragen verzinnen ;)

Voor de concrete uitvoering hoop ik overigens dat de antwoorden niet als zodanig opgeslagen worden. Het gegeven dat interpunctie etc. precies moet overeenkomen geeft hoop, maar die hoop wordt weer teniet gedaan door de privacy policy die de antwoorden op de vragen in het geheel niet noemt in het kader van persoonsgegevens.

Ik heb in elk geval wat nonsens antwoorden ingevuld en samen met de vragen in m'n password manager opgeslagen. Tijd voor een vleugje meer ethiek bij security?

http://kosteronline.net/pics/zakelijkepersoonlijkevragen.png

Duurzaam internetbankieren en de mens in informatiebeveiliging

Door Rukapul op zondag 26 september 2010 12:28 - Reacties (13)
Categorie: -, Views: 6.315

Er is al veel geschreven over de veiligheid en beveiliging van online bankdiensten, maar de ""Voorwaarden ASN Online Bankieren" van de ASN Bank zijn toch wel een stukje waard. Wie zou immers niet verwachten dat een duurzame bank ook een duurzame relatie met haar klanten nastreeft?

Zou een verplichting tot wekelijkse controle van saldi, transacties, digipas en digicode hieronder vallen?
http://kosteronline.net/pics/asnbank.png

Usable security is een beweging in informatiebeveiligingsland waarbij geprobeerd wordt de mens als integraal deel van het systeem te beschouwen en daarbij rekening te houden met de menselijke mogelijkheden en beperkingen in plaats van als perfecte instructie-opvolgende entiteit zoals regelmatig onder techneuten en juristen voorkomt. Interessant leesvoer hier.


Achtien pagina's voorwaarden
Het eerste dat opvalt is dat ASN naast de 6 pagina's algemene bankvoorwaarden nog 12 pagina's nodig heeft voor online bankieren waarvan een flink deel betrekking heeft op aansprakelijkheid en veiligheid. Hiermee spant het de kroon onder de banken.

De algemene bankvoorwaarden zijn gelijk aan dat van andere banken en in overeenstemming met de consumentenbond opgesteld:
Artikel 21: Bewaar- en geheimhoudingsplicht
1. De cliŽnt moet aan hem ter beschikking gestelde middelen zoals formulieren, informatiedragers, communicatie- en beveiligingsmiddelen, passen, pin- en toegangscodes en wachtwoorden zorgvuldig bewaren en behandelen. De cliŽnt moet met persoonlijke pin- en toegangscodes en dergelijke zorgvuldig omgaan en deze geheim houden voor andere personen. De cliŽnt houdt zich aan de door de bank gegeven beveiligingsvoorschriften.
2. Als de cliŽnt weet of redelijkerwijze kan vermoeden dat door of namens de bank aan hem ter beschikking gestelde middelen in handen van een onbevoegde zijn geraakt of daarmee misbruik is of kan worden gemaakt of dat een onbevoegde zijn pin- en/of toegangscode(s) kent, moet hij daarvan terstond mededeling doen aan de bank.
Redelijk toch? Dit is echter pas het begin...

Voorwaarden online bankieren
Bij ASN online bankieren heeft de klant veel verplichtingen om op bepaalde wijze te handelen. Om dat te kunnen plaatsen vanuit gebruikers- en bruikbaarheidsperspectief heb ik enkele verplichtingen geselecteerd en opgedeeld in passieve, reactieve en actieve verplichtingen.

Passief
ASN begint met enkele gedragingen die de kant moet laten. Niet zo vreemd en de meeste mensen kunnen hiermee omgaan al vormt het probleem van phishing natuurlijk wel een contra-indicator over de limitaties hiervan:
De Klant mag Digicode en Digipas onder geen voorwaarde aan een ander overdragen of ter beschikking stellen.
Reactief
Naast passief wordt er bepaald actief gedrag verwacht in bepaalde situaties. Hierbij wordt het soms al moeilijk om aan te voldoen:
de e-mail of brief waarmee hij de toegangsnaam ontvangt, onmiddellijk na opening en lezing vernietigt
Het merendeel van de bankklanten zal een E-mail niet duurzaam kunnen vernietigen. Het past niet in hoe veel mensen omgaan met E-mail (inbox als archief) en dat wissen veelal als enig gevolg heeft dat het naar de prullenbak wordt verplaatst.
Het Beveiligingsmiddel geeft de Klant toegang tot ASN Online Bankieren. De Klant is verplicht steeds te controleren of hij zich daadwerkelijk in deze (beveiligde) omgeving bevindt.
In het kader van usable security is redelijk wat onderzoek naar SSL, etc. gedaan met als uitkomst dat mensen bovenstaande eigenlijk niet goed kunnen. Natuurlijk kan men een slotje als indicator van een beveiligde verbinding herkennen, maar daarbij kan men makkelijk gefopt worden.
De Klant moet de Digipas altijd veilig bewaren en gebruiken. De Klant bewaart en gebruikt de Digipas alleen veilig als de Klant: [...] de Digipas buiten het zicht van anderen opbergt wanneer hij deze niet gebruikt; en de Digipas zodanig opbergt dat anderen er niet ongemerkt bij kunnen [...]
Eenieder met enig inzicht in het gemiddelde huishouden weet dat bovenstaande niet realistisch is. Digipassen en telefoons liggen overal en nergens en er is geen kluisje per gezinslid bij wijze van spreken.

Actief
Tenslotte moet de ASN klant actief en uit zichzelf regelmatig wat handelingen uitvoeren:
De Klant is verplicht om de juiste werking en beveiliging van zijn apparatuur, programmatuur en aansluitingen regelmatig te controleren en geheel up-todate te houden.
De Klant dient alle instructies van de Bank over ASN Online Bankieren strikt op te volgen. [...] De Klant is ook verplicht regelmatig de informatie te raadplegen die de Bank via deze communicatiemiddelen ter beschikking stelt over het gebruik, de Beveiligingsmiddelen en de beveiliging van ASN Online Bankieren.
Hierna wordt het pas echt een uitdaging voor de duurzame mens:
De Bank stelt informatie over het verloop van de Rekening beschikbaar via ASN Online Bankieren. [...] Hij is verplicht om de saldi en saldomutaties periodiek, maar minstens ťťn keer per week, te controleren.
De Klant moet de veiligheid van de Digicode en het gebruik ervan regelmatig controleren door: [...] minimaal ťťnmaal per week te controleren of zijn eigen Digicode nog werkt
De Klant moet de veiligheid van de Digipas en het gebruik ervan regelmatig controleren door [...] minimaal ťťnmaal per week te controleren of hij zijn eigen Digipas nog heeft
Behalve dat er genoeg situaties zijn waarbij men dit niet wekelijks kan uitvoeren is ook nog eens uit de literatuur bekend dat mensen er niet op zijn ingesteld om handelingen te verrichten die niet onderdeel uitmaken van het primaire proces in dit geval het online betalen. Aangezien veiligheid vanuit het perspectief van de klant altijd secundair is is het goed gebruik om het in het primaire (betalings)proces te integreren. Wekelijkse controles verplicht stellen is het paard achter de wagen spannen en niet meer dan het makkelijk afschuiven van aansprakelijkheid.

Een andere aanpak uit het hoge noorden
Het kan ook anders. Friesland bank heeft bijvoorbeeld naast de algemene bankvoorwaarden, maar anderhalve pagina extra voorwaarden nodig voor het internetbankieren waarbij men bovendien volstaat met:
De rekeninghouder zal alle door de bank verstrekte gebruiksvoorschriften, zoals onder andere uiteengezet in de informatiebrochure en op de website, naleven en zorgvuldig omgaan met alle door de bank verstrekte hulpmiddelen.
Rekeninghouder dient er tevens zelf voor te zorgen dat deze apparatuur, software en verbinding veilig zijn
De rekeninghouder dient zorgvuldig om te gaan met en is verantwoordelijk voor de hulpmiddelen. De rekeninghouder zal de hulpmiddelen uitsluitend gebruiken volgens de door de bank aan de rekeninghouder bekend gemaakte gebruiksvoorschriften en aanwijzingen.
De rekeninghouder zal met de meeste zorgvuldigheid voor de hulpmiddelen zorgdragen en regelmatig met behulp van de meest recente versies van anti-virusprogramma’s en andere programma’s de personal computers, die gebruikt worden voor internetbankieren, scannen op computervirussen en andere schadelijke programma’s en passende maatregelen treffen.
Een verschil dat direct in het oog springt is dat deze voorwaarden niet of nauwelijks expliciete eisen stellen waar je op voorhand als homo sapiens eigenlijk al niet aan kunt voldoen. Uiteraard is dit slechts papier en kan de uitvoering afwijken.

Een toekomst met duurzame systemen en relaties
Ik hoop dat techneuten en juristen op een dag de mens als uitganspunt zullen nemen en niet een of ander irrealistisch ideaalbeeld ervan. Pas dan kunnen systemen per saldo veiliger worden, verantwoordelijkheden eerlijk verdeeld worden en de relatie tussen klant en aanbieder echt duurzaam zijn :)

http://usablesecurity.com/2005/12/25/bizarro.jpg

MasterCard SecureCode: veilig voor wie?

Door Rukapul op zondag 10 januari 2010 06:33 - Reacties (7)
Categorie: -, Views: 8.097

Afgelopen herstvakantie ben ik gecapituleerd voor MasterCard SecureCode na het jaren te hebben kunnen afhouden. MasterCard SecureCode (en Visa's Verified by Visa) is een aanvulling voor online creditcardbetalingen waarbij een extra wachtwoord moet worden gegeven om transacties te authoriseren. Dit maakt creditcardbetalingen iets veiliger, maar het verschuift ook risico's van de uitgevende bank en/of retailer naar de consument / kaarthouder. Dit rechtvaardigt de vraag: veilig voor wie?
Algemene voorwaarden gebruik MasterCardģ SecureCode™

5. Bij de aanmelding voor de dienst dient de kaarthouder een wachtwoord te kiezen, die door hem/haar als persoonlijke beveiligingscode bij het gebruik van de dienst moet worden gebruikt. Het wachtwoord dient door de kaarthouder zodanig te worden gekozen dat het wachtwoord niet makkelijk te raden is voor derden. Het wachtwoord is niet overdraagbaar. De kaarthouder is verplicht zijn/haar wachtwoord en de door hem/haar bij de aanmelding voor de dienst op te geven welkomstboodschap strikt geheim te houden ten opzichte van een ieder, daaronder mede begrepen familieleden, huisgenoten, mederekeninghouders en gemachtigden.

6. Indien de kaarthouder enige aantekening maakt van zijn/haar wachtwoord dient hij/zij dat in een zodanige vorm te doen, dat het wachtwoord op generlei wijze voor derden herkenbaar is. De kaarthouder zal de ING onverwijld op de hoogte stellen door contact op te nemen met de klantenservice indien sprake is van enig ongeautoriseerd gebruik van het wachtwoord of enige andere schending van de beveiliging. De klantenservice is bereikbaar op telefoonnummer 0900 0933 (10 cent per minuut). De kaarthouder is volledig aansprakelijk voor schade die het gevolg is van het door hem/haar niet naleven van de in dit artikel vermelde verplichtingen.

7. De kaarthouder is verplicht om bij transacties in verband met aankopen bij aangesloten winkels zijn wachtwoord te gebruiken. De kaarthouder is volledig aansprakelijk voor de schade die het gevolg is van het niet nakomen van deze verplichting.

12. De ING is niet aansprakelijk voor enig verlies of enige schade die voortvloeit uit transacties die onder gebruikmaking van deze dienst met aangesloten winkels plaatsvinden ten laste van de kaart van de kaarthouder, tenzij het verlies of de schade is te wijten aan opzet of schuld van de ING.
Uit bovenstaande voorwaarden spreekt dat de kaarthouder aansprakelijk is voor wat er met zijn wachtwoord gebeurt. In de huidige wereld van trojans en wachtwoordloggers is dit geen aantrekkelijk vooruitzicht. De kans dat de creditcardinformatie en securecode een keer gestolen worden zijn niet onwaarschijnlijk. In de oude situatie zonder SecureCode is de kaarthouder niet aansprakelijk omdat hij de fysieke kaart nog in bezit heeft, terwijl hij dat op basis van bovenstaande voorwaarden wellicht wel is.

Er kan natuurlijk gedacht worden dat het allemaal zo'n vaart niet zal lopen en dat uitgevende banken en creditcaardmaatschappijen zich coulant zullen opstellen. Aanhangers van die gedachte moeten echter wel realiseren dat de slachtoffers van skimming in het begin door de banken ook volledig aansprakelijk werden gehouden voor transacties met de afgekeken PIN-code en dat dit pas veranderde na flinke tijd en druk.

Extra zuur aan SecureCode is dat de oplossing zelf bijzonder weinig veiligheid biedt. Het werkt alleen met een eenvoudig wachtwoord in plaats van (optioneel) two-factor authenticatie danwel authorisatie. Bevestiging per SMS of challenge-response met bankkaart zou de consument in elk geval een fatsoenlijk niveau van beveiliging bieden. Voor veel uitgevende banken zou dit niet meer zijn dan een lichte integratie met het reguliere online bankieren.

Naast de single-factor authenticatie springt ook de "geheime vraag" in het oog. Tijdens de registratie wordt hierom gevraagd, maar er wordt niet aangegeven voor welk doeleinde deze gebruikt zal worden. Empirisch wetenschappelijk onderzoek heeft aangetoond dat de meeste antwoorden van "geheime vragen" met enig zoek- en gokwerk zijn te beantwoorden. Gezien deze zwakke veiligheid in combinatie met bovenstaande voorwaarden is het de vraag of het verstandig is het echte antwoord te geven.

Security is vaak niet het laten verdwijnen van risico's maar ze verschuiven ;)

http://kosteronline.net/pics/securecode.png
Het registratiescherm van MasterCard SecureCode bij ING.

e-veiligheid bij de e-overheid

Door Rukapul op zaterdag 22 maart 2008 12:10 - Reacties (2)
Categorie: -, Views: 3.195

Tegenwoordig kan alles online en dat maakt het leven van de burger makkelijk. Tijd om eens te kijken naar wat de digitale overheid ons anno 2008 te bieden heeft en hoe veilig dat is: casus Eindhoven.

Afgaande op de resultaten - een ratjetoe aan (veiligheids)processen - rijst de vraag of er bij de digitale overheid wel iemand is met het precieze overzicht over het beoogde en daadwerkelijke veiligheidsniveau :X Voor de burger is het echter zeker niet transparant.

Ter onderbouwing worden hieronder vier methoden uit de doeken gedaan waarmee de burger zijn gegevens kan opvragen of wijzigingen bij de gemeende Eindhoven. We letten daarbij met name op hoe gegarandeerd wordt dat alleen een burger zelf wijzigingen kan doorgeven die betrekking hebben op hem. Dat valt in een aantal gevallen nogal tegen, omdat er van echte authenticatie geen sprake is...

Geheimloos #1 :|
Bij de digitale belastingbalie kan de burger zijn gemeentelijke belastingaanslag opvragen zoals rioolrecht, verontreinigingsheffing en WOZ-aanslag. Deze worden dan netjes gepresenteerd tezamen met enkele persoonlijke gegevens.

De gebruikte authenticatiemethode voor deze toepassing komt regelrecht uit de 20e eeuw: BSN, geboortedatum en aanslagbiljetnummer zijn voldoende inloggegevens om toegang te krijgen tot de informatie. Nou zal niet iedereen strooien met zijn BSN en aanslagnummer, maar dit zijn geen geheimen en zijn niet strikt persoonlijk. Geboortedatum en BSN staan bijvoorbeeld gewoon op het rijbewijs. De enige horde is het om van dezelfde persoon het aanslagnummer en de rest van de informatie te vergaren.

Geheimloos #2 :|
Dezelfde gemeentelijke site biedt de burger ook de mogelijkheid om wijziging van adres of rekeningnummer door te geven.

De privacy van de burger hangt hier af van naam, geboortedatum en legitimatiebewijsnummer en het oude adres. Er wel eens bij stil gestaan dat de medewerker van het autoverhuurbedrijf je kan laten verhuizen voor de overheid? In theorie kan in het proces nog een andere handmatige vorm van verificatie zitten of volgt een papieren vervolgtraject, maar die last wordt wel bij de burger gelegd.

Onpraktische veiligheid: DigiD :)
Uiteraard kan het beter door een aanvrager te authenticeren en vooraf te verifiŽren of deze voor een bepaalde handeling geautoriseerd is. De gemeente Eindhoven biedt daartoe het 21e eeuwse DigiD aan, bijvoorbeeld om diezelfde wijzigingen van adres of rekeningnummer door te geven.

Kiest men voor DigiD authenticatie dan wordt men doorgeleid naar de DigiD website alwaar men eerst gevraagd wordt de gebruikersnaam in te voeren. Vervolgens kan met de gewenste authenticatiemethode selecteren ‘DigiD Wachtwoord’ of ‘mobiele telefoon’ :
De toepassing of webdienst die u wilt benaderen, ondersteunt een aantal authenticatie methoden. Kies eerst de methode die u wilt gebruiken om te authenticeren.
Ondanks dat het iets anders doet suggereren vereist ook het authenticeren met de mobiele telefoon (SMS) dat het DigiD wachtwoord wordt ingevoerd. Helaas, belast en verwart dit de burger alleen maar onnodig. Immers, de gemeente neemt genoegen met de ‘zwakke’ authenticatie, en ook de burger heeft er niets aan om alsnog voor authenticatie via de mobiele telefoon te kiezen.

Al met al is DigiD authenticatie een stuk veiliger dan de methoden hierboven door dat er van een persoonlijk geheim wachtwoord gebruik gemaakt wordt, maar het is wel jammer dat de burger gevraagd wordt een keuze te maken die er niet toe doet en waarvan men bovendien zich af kan vragen of hij deze keuze wel kan maken.

Analoog beter dan digitaal? :?
Op basis van bovenstaande zou je wellicht denken dat de burger in de digitale wereld slechter af is dan in de analoge wereld. Laten we daarom bijvoorbeeld eens kijken wat er voor nodig is om met een oud vertrouwd formulier het bankrekeningnummer te wijzigen: naam, adres, geboortedatum, oude en nieuwe rekeningnummer en een handtekening. Veel minder gegevens dus dan bij een digitale aanvraag maar wel met een handtekening.

Ter vergelijk, bij het doorgeven van een verhuizing per post worden juist meer gegevens gevraagd: kopie legitimatiebewijs, kopie huurcontract of kopie koopcontract en waarschijnlijk een ingevuld en ondertekend formulier (niet direct beschikbaar op de site).

Blijkbaar verschilt het in de analoge situatie ook van geval tot geval.

Conclusie: gebrek aan transparantie :(
In de voorbeelden hierboven blijkt dat er veel verschillende methoden zijn om hetzelfde doel te bereiken, elk met ogenschijnlijk andere wijze om de privacy en de digitale veiligheid van de burger te beschermen. Het is uiteraard mogelijk dat de processen voor de verwerking van de aanvragen zorgen zodanig zijn afgestemd dat het eindresultaat ook op het gebied van de veiligheid gelijk is, maar aangezien die processen niet zichtbaar of gedocumenteerd zijn voor het publiek - de site Eindhoven.nl kent niet eens een privacy policy - is dit niet meegenomen. Hetzelfde geldt voor een eventueel aanwezig papieren natraject.

De balangrijkste conclusie ligt in de observatie dat de situatie van e-security in e-overheid – in Eindhoven tenminste - als een ratjetoe bestempeld kan worden met weinig transparantie. Vanuit het oogpunt van digitale veiligheid is dat geen compliment.

PS :)
Is e-overheid vooruitgang? Uiteraard:
Aanvraag status
Aanvraagnummer *****
Product Automatische incasso, rekeningnummer wijzigen
Datum van de aanvraag 18/03/2008 21:19
Actuele status Afgehandeld
Sinds 19/03/2008 15:39
Uiteraard wel het aanvraagnummer geheim houden, want bovenstaande is op te vragen met slechts het BSN en aanvraagnummer waarbij de laatste verdacht veel weg heeft van een oplopend nummer ;) :X