Tegenwoordig lijken berichten over systemen of netwerken die gehacked zijn dagelijkse kost in de krant. Alle systemen of applicaties die aangesloten worden op het internet zijn kwetsbaar voor een incident op het gebied van informatiebeveiliging. Als vanzelfsprekend is het van belang dat de beveiliging van je medische applicatie ook op orde moet zijn. Uiteraard wil je niet de volgende zijn die met een hack van jouw software in de krant staat.
De beveiligingsstandaarden en best practices voor app-makers zijn gelukkig goed gedefinieerd. Vaak wordt er ook gebruik gemaakt van OWASP richtlijnen. De website van OWASP geeft een goed overzicht van de richtlijnen, maar geeft ook voor back end webapplicaties en voor specifiek mobile een top-10 aan van ontwikkelfouten en kwetsbaarheden die voorkomen in de praktijk. De OWASP-richtlijnen zijn geen wettelijke verplichtingen, maar helpen wel met de eerste stap naar een veilige applicatie.
Hacken is eenvoudig
De tools om een applicatie, website of compleet ICT-systeem te hacken zijn tegenwoordig heel eenvoudig, en vaak gratis, verkrijgbaar via het internet. Via Google kun je op verschillende websites komen die je eenvoudig de apparatuur voor een 'hack' laten aanschaffen, net zo eenvoudig als dat je een nieuw onderdeel voor je stofzuiger bestelt. Zo staan complete tools online zoals Metasploit of BackTrack Kali en kun je als je een beetje goed zoekt ook op een soort 'werkspot' voor hackers terechtkomen. Op dit portaal vul je de applicatie (of ander item) in die je wilt (laten) hacken en binnen een dag heb je een offerte in je mailbox tegen welke prijs je dit kunt laten doen. Het zijn ontwikkelingen die doorgaan en die ons in deze digitale wereld erg kwetsbaar maken.
De formule voor de hacker is ook niet eerlijk: een hacker heeft alle tijd en heeft maar één kwetsbaarheid nodig in een applicatie, terwijl een app-bouwer nooit al zijn tijd aan beveiliging kan besteden en daarnaast veel geld kwijt is aan het beveiligen van alle kwetsbaarheden.
Een hacker heeft alle tijd en heeft maar één kwetsbaarheid nodig in een applicatie
Stapje terug….. buiten dit inzicht in de wereld van hacking ben je per slot van rekening vooral geïnteresseerd wat verder jouw verantwoordelijkheden zijn voor het ontwikkelen van een medische applicatie. Zo zijn er voor informatiebeveiliging in de zorg verschillende standaarden beschikbaar, zoals bijvoorbeeld het convenant veilige toepassing van medische technologie, NEN 7510, NEN 7512, NEN 7513 en ISO27001/1 + ISO27001/2. Naast deze richtlijnen wil ik ook wijzen op de richtlijn gerelateerd aan de beveiliging van netwerken waarop medische apparatuur is verbonden, namelijk IEC 80001. Ook relevant voor de medische applicaties kan zijn de richtlijn inzake telemedicine NEN 8028 en de hierbij horende Europese variant die recent is uitgebracht ISO TS13131:2014.
En nu?
Is het nu de bedoeling dat je als ontwikkelaar volledig voldoet aan deze richtlijnen en waar mogelijk zelfs hiertegen gecertificeerd bent? Naar mijn mening hoeft dat niet. Wat veel belangrijker is, is dat je bij de ontwikkeling van de medische applicatie rekening houdt met deze richtlijnen. Daarmee lever je hopelijk een applicatie af die past binnen een omgeving die wel overeenkomstig deze richtlijn is gecertificeerd of handelt. Hiermee voorkom je bijvoorbeeld dat een ziekenhuis jouw applicatie gebruikt en vervolgens niet meer voldoet aan de eigen normen die het heeft ingericht.
Concreet zorgt dit ervoor dat je als ontwikkelaar ook de aspecten uit de richtlijnen, voor zover van toepassing, op orde zult moeten hebben. Een mooi voorbeeld van wat wij hiermee bedoelen is gerelateerd aan hoofdstuk 9 van de NEN 7510 norm. Hoofdstuk 9.2.4 van NEN 7510 geeft aan dat apparatuur op een correcte wijze hoort te worden onderhouden, om te waarborgen dat de apparatuur in goede staat verkeerd en de geleverde informatiediensten beschikbaar blijven.
Verantwoordelijkheid
De zorgaanbieder is uiteraard verantwoordelijk voor de verzorging van dit proces en de bijbehorende documentatie. De app-ontwikkelaar is geen actieve provider en geeft de applicatie uit als middel voor gebruik binnen de zorginstelling. De app-ontwikkelaar heeft naar mijn mening ten aanzien van de applicatie wel de verantwoordelijkheid om te verzorgen dat de applicatie correct wordt onderhouden en de geleverde diensten beschikbaar blijven.
Dit houdt in dat je als ontwikkelaar onder andere de laatste securitypatches en overige beveiligingsrisico’s moet blijven volgen en tijdig moet verwerken in updates van de applicatie. Wij adviseren app-ontwikkelaars om van deze stappen een gestandaardiseerd proces te maken. Door dit proces te standaardiseren loop je niet het risico dat je applicatie onderhevig is aan allerlei onnodige beveiligingsrisico’s en kun je aantonen aan afnemers dat je op een gestandaardiseerde methode wijze omgaat met het waarborgen dat de applicatie in goede staat verkeert en daarmee de geleverde informatiediensten beschikbaar blijven.
Maak van het volgen van de laatste beveiligingsrisico’s een gestandaardiseerd proces
De zorginstantie die van jouw bedrijf een applicatie afneemt mag aannemen dat je net zo verantwoord omgaat met informatie als dat zij zelf doen. Dit is volgens ons een voorbeeld voortkomend vanuit de NEN 7510, waaraan je als app-ontwikkelaar tenminste moet voldoen op het moment dat je een zorgapplicatie ontwikkelt en aflevert aan zorginstanties voor gebruik.
Er zijn veel aspecten van informatiebeveiliging voor een medische applicatie, en dit blog is natuurlijk geen volledig overzicht, maar geeft wel een eerste beeld van de reikwijdte voor wat betreft informatiebeveiliging. In mijn volgende en laatste blog ga ik in op de thema’s privacy en usability binnen medische apps.
Rob Peters is registeraccountant bij Deloitte Innovation B.V en initiatiefnemer van Assuring Medical Apps. In een serie blogs gaat hij in op een aantal belangrijke zaken waar gebruikers en app-ontwikkelaars op moeten letten, zoals wet- en regelgeving en informatiebeveiliging.
Software indien beschouwd wordt als "medical device" (SaMD), moet via risico management voldoen aan deze en andere standaarden, tenzij je het notified body (bij klasse II / III of "klasse I + meting") of de bevoegde overheid (klasse I zonder meting / zelfcertificatie) kan overtuigen dat je iets anders toepast dat even goed is om te voldoen aan de essentiële eisen van de EU richtlijn!