Kuipers: datalek Albert Schweitzer mede door overschrijven van back-up
Het datalek bij het Albert Schweitzer ziekenhuis, waar ruim een half miljoen patiëntdocumenten permanent werden gewist, kon zich mede door het overschrijven van de periodieke back-up voordoen, zo laat minister Kuipers van Volksgezondheid weten. Bij het datalek werden scans van niet meer gebruikte papieren uit dossiers van voor september 2017 gewist, zoals verwijsbrieven, onderzoeksresultaten of aantekeningen van de behandelaar.
Het ziekenhuis had de documenten twintig jaar moeten bewaren voordat ze mochten worden verwijderd. Doordat dit niet is gedaan, is er sprake van een datalek. In 2017 stapte het ziekenhuis over van een papieren patiëntendossier op een elektronisch patiëntendossier (EPD). Daarbij werden per patiënt en per behandeling alle actuele, relevante gegevens overgezet naar de digitale omgeving.
Oude documenten uit het papieren dossier die de artsen op dat moment niet meer nuttig vonden voor de behandeling, gingen niet mee naar het EPD. Maar ze moesten volgens de wet nog wel worden bewaard. Afgelopen oktober bleek dat in dit archief, als gevolg van foute instellingen, al bijna een jaar lang nieuwere documenten werden opgeslagen met bestandsnummers die ook in gebruik waren voor inactieve documenten.
Het CDA had minister Kuipers om opheldering gevraagd. Volgens de bewindsman is het datalek door drie factoren veroorzaakt: een verkeerd gekozen nummerreeks, het niet beveiligd zijn van data tegen overschrijven én de gekozen manier van back-ups maken, waarbij elke nieuwe volledige back-up in de plaats komt van de vorige volledige back-up.
"Omdat het om statische data ging, is voor dit specifieke archiefontwerp een afwijkend regime gekozen waarbij elke geslaagde periodieke back-up de vorige overschreef. Hierdoor kon de fout in elke back-up ongemerkt iets verder doorwerken", laat de minister verder weten. Het Albert Schweitzer ziekenhuis heeft inmiddels een andere back-upmethode gekozen. "Een herhaling van dit specifieke incident is daarmee uitgesloten", aldus Kuipers.
Of zijn die aan Peute meegegeven om duurzaam te worden gerecycled?
Er is geen minister van Digitalisering maar wel een staatssecretaris. Digitalisering is desondanks niet exclusief van één staatssecretaris of één ministerie. Alle departementen gaan óók over digitalisering, omdat het overal plaatsvindt. De staatssecretaris van Digitalisering zet strategische hoofdlijnen uit. Omdat een incident geen hoofdlijn is vind ik het niet zo gek dat de vraag aan een ander gesteld wordt.
Wat is trouwens de relatie tussen het ziekenhuis en de minister van Economische zaken, anders dan dat een ziekenhuis als (zorg-)bedrijf ook een economisch aspect heeft? De verplichting om patiëntendossiers 20 jaar te bewaren heeft meer met het zorgaspect dan met het economische aspect te maken van een ziekenhuis.
De fout is jaren geleden al gemaakt toen de frequentieveilingen een goudmijn bleken te zijn. Toen is besloten de oude Hoofddirectie Telecommunicatie en Post (HDTP) om te vormen naar een agentschap en onder Economische Zaken te hangen. Daarmee kwam de focus op geld verdienen te liggen en niet meer op kwaliteit, veiligheid en betrouwbaarheid van de (digitale) infrastructuur.
Ik blijf het roepen, breng het Agentschap Telecom weer onder het ministerie van Infrastructuur en Waterstaat; daar hoort het thuis.
https://nl.wikipedia.org/wiki/Ministerie_van_Infrastructuur_en_Waterstaat
Dat laat zien dat waar iets thuishoort geen vast gegeven is maar dat het alle kanten op stuitert, afhankelijk van wat men door de tijd heen een goede indeling vindt. Er zullen steeds argumenten voor geweest zijn die in die tijd steekhoudend waren.
Het is dus geen vast gegeven, en misschien vindt je groeperingen van onderwerpen wel vanzelf spreken omdat dat is hoe je er ooit kennis mee hebt gemaakt.
De fout is dat in het archief zelf abusievelijk bestandsnummers (ik neem aan dat ze bedoelen dat de bestandsnamen numeriek zijn) hergebruikt werden bij nieuwe toevoegingen aan het archief. De backupstrategie voor het archief was gebaseerd op de aanname dat dat soort dingen niet zouden gebeuren.
Gedachte: dit had ondervangen kunnen worden door het archief onder git (of een soortgelijk scm) te brengen en na toevoegingen aan het archief een commit te doen (een periodieke automatische commit zou ook werken). Overschreven bestanden waren dan terug te halen geweest. Dit niet ter vervanging van andere beveiligingen (nummers niet hergebruiken, bestanden read-only maken, backups maken), maar als extra waarborg om fouten die daarmee gemaakt worden herstelbaar te maken.
Merk op dat de (niet goed geïmplementeerde) waarborgen die ze hadden niet onafhankelijk van elkaar waren: de backups werken alleen maar goed als de nummertoekenning en overschijfbeveiliging goed werken. Daarmee zijn deze backups, zoals gebleken is, geen afdoende beveiligingsmaatregel. Dat had met git ondervangen kunnen worden, omdat dat een onafhankelijk mechanisme voor het niet overschrijven van eerder vastgelegde inhoud toevoegt.
De fout is dat in het archief zelf abusievelijk bestandsnummers (ik neem aan dat ze bedoelen dat de bestandsnamen numeriek zijn) hergebruikt werden bij nieuwe toevoegingen aan het archief. De backupstrategie voor het archief was gebaseerd op de aanname dat dat soort dingen niet zouden gebeuren.
Gedachte: dit had ondervangen kunnen worden door het archief onder git (of een soortgelijk scm) te brengen en na toevoegingen aan het archief een commit te doen (een periodieke automatische commit zou ook werken). Overschreven bestanden waren dan terug te halen geweest. Dit niet ter vervanging van andere beveiligingen (nummers niet hergebruiken, bestanden read-only maken, backups maken), maar als extra waarborg om fouten die daarmee gemaakt worden herstelbaar te maken.
Merk op dat de (niet goed geïmplementeerde) waarborgen die ze hadden niet onafhankelijk van elkaar waren: de backups werken alleen maar goed als de nummertoekenning en overschijfbeveiliging goed werken. Daarmee zijn deze backups, zoals gebleken is, geen afdoende beveiligingsmaatregel. Dat had met git ondervangen kunnen worden, omdat dat een onafhankelijk mechanisme voor het niet overschrijven van eerder vastgelegde inhoud toevoegt.
Git is een mogelijke techniek - als je de keuze maakt dat *alle* data sinds "het begin" bewaard moet worden .
Het is natuurlijk een keuze met consequenties - dat de benodige opslagcapaciteit soms erg veel groter wordt.
Er zijn beslist ook andere manieren dan git om de keuze "we bewaren alles - en inclusief een update van een reeds bestaande file/dossier met dezelfde naam, dan bewaren we alle voorgaande versues" in te vullen .
(Ik denk dat git niet de beste keuze is voor non-text data )
Je hebt special purpose archiveringssystemen , en snapshotting filesystemen (en SANs) bijvoorbeeld.
Maar welke techniek dan ook - de keuze "we kunnen het archief van elk moment in het verleden reconstrueren " - heeft consequenties voor de benodige opslagcapaciteit .
Het meer algemene probleem is dat Bad Things Happen wanneer je een model/system/opslag/database hebt dat aanneemt dat een bepaalde key of index altijd uniek is, en er entries komen waarbij de unieke key niet meer uniek is.
De tupel (initialen,voornaam, geboorde datum) is best _redelijk_ uniek, maar zelfs in een vrij kleine populatie kun je daar al duplicaten krijgen.
Sommige IT systemen indexeren alleen op *host*naam, en sommige matig ervaren beheerders ontdekken dan pas dat hostA.subdomein1.tlld en hostA.subdomein2.tld geen handige naamconventie is.
MAC adressen zijn wereldwijd uniek - is de gedachte. Heel vervelend in een netwerk als dat niet klopt.
En bij dit ziekenhuis werd de aanname dat de filenaam van een dossier altijd uniek is overtreden.
(totaal natte vinger gok : ze zijn een keer gefuseerd met een ander ziekenhuis, en hebben de gezamelijke archiefdata geintegreerd , en waren allebei met een zelfde logische nummerreeks (20180101.volgnummer , ofzo ?) begonnnen.
https://www.ad.nl/dordrecht/albert-schweitzer-ziekenhuis-krijgt-honderden-boze-en-verdrietige-reacties-van-patienten-na-datalek~a9ef2c58/
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
