Hvem har ansvaret når hospitalets sæbedispenser kører på open source

Annonce – sponsoreret indhold.

Moderne hospitaler og plejehjem investerer massivt i digitale hygiejneløsninger. Smarte sæbedispensere med IoT-sensorer, automatiske håndhygiejnemonitorer og netværksforbundne dosering­systemer er blevet standardudstyr i kampen mod infektioner. Men hvem bærer ansvaret, når hospitalets sæbedispenser kører på open source-software — og den software viser sig at have en sikkerhedsbrist? Det spørgsmål er ikke længere hypotetisk. Med Cyber Resilience Act (CRA), der trådte i kraft i 2024 og nu håndhæves fuldt ud, står producenter af digitale sundhedsprodukter over for et juridisk ansvar, som mange først nu begynder at forstå omfanget af.

Producentansvar for digitale hygiejneprodukter under CRA

Cyber Resilience Act ændrer fundamentalt spillereglerne for alle, der udvikler, producerer eller sælger produkter med digitale elementer på det europæiske marked. For sundhedssektoren rammer det direkte: fra avancerede medicintekniske apparater til tilsyneladende simple produkter som automatiske sæbedispensere, desinfektionsstationer med forbrugsmåling og digitale håndhygiejnesystemer.

Det afgørende princip i CRA er, at producenten har fuldt ansvar for cybersikkerheden i hele produktet. Det inkluderer al software — også den del, producenten ikke selv har skrevet. Når en sæbedispenser indeholder en mikrocontroller med firmware, et netværksmodul til dataindsamling og måske en cloud-forbindelse til hygiejnestatistik, så gælder ansvaret for hver eneste softwarekomponent.

Reglerne for CRA og open source er langt mere komplekse, end de fleste producenter forventer, særligt når tredjepartskomponenter indgår i et CE-mærket produkt. Mange producenter af sundhedsudstyr har historisk set betragtet open source som en gratis ressource, man frit kunne inkorporere. Den tid er forbi. Under CRA skal producenten kunne dokumentere sikkerhedsegenskaberne ved hver komponent — og bære konsekvenserne, hvis noget går galt.

For hospitaler og plejehjem betyder det, at indkøbsafdelingen ikke længere bare kan fokusere på funktionalitet og pris. Spørgsmålet om leverandørens CRA-compliance bliver en kritisk faktor i enhver anskaffelse af digitalt sundhedsudstyr.

Hvad CRA konkret kræver af sundhedsproducenter

CRA opstiller en række bindende krav, som producenter skal opfylde, før de kan CE-mærke og sælge deres produkter. For producenter af digitale hygiejneprodukter og sundhedsudstyr er følgende områder særligt relevante:

Security by design og security by default

Produkter skal designes med sikkerhed som udgangspunkt. Det betyder, at en smart sæbedispenser skal leveres med sikre standardindstillinger: krypteret kommunikation, unikke adgangskoder, minimale nødvendige netværksrettigheder. Producenten kan ikke forvente, at hospitalet selv sikrer produktet efter installation.

Sårbarhedshåndtering gennem hele produktets levetid

Producenten skal have processer til at opdage, vurdere og afhjælpe sikkerhedssårbarheder i hele den periode, produktet forventes at være i brug. For et hygiejnesystem på et hospital kan det betyde 10-15 års forpligtelse til sikkerhedsopdateringer.

Software Bill of Materials (SBOM)

Producenten skal vedligeholde en komplet oversigt over alle softwarekomponenter i produktet — en såkaldt SBOM. Det inkluderer:

• Egen udviklet kode
• Kommercielle tredjepartsbiblioteker
• Open source-komponenter
• Firmware og drivere
• Operativsystem og middleware

Denne SBOM er ikke bare intern dokumentation. Den skal kunne fremvises ved tilsyn og danner grundlag for løbende sårbarhedsmonitorering.

Rapportering af aktivt udnyttede sårbarheder

Opdager producenten en aktivt udnyttet sårbarhed i et af sine produkter, skal den rapporteres til ENISA (EU’s cybersikkerhedsagentur) inden for 24 timer. Det gælder også, hvis sårbarheden ligger i en open source-komponent.

Teknisk dokumentation og overensstemmelsesvurdering

Producenten skal udarbejde teknisk dokumentation, der demonstrerer, hvordan produktet opfylder CRA’s sikkerhedskrav. For standardprodukter kan producenten selv foretage overensstemmelsesvurderingen, men for kritiske produkter kræves involvering af et notificeret organ.

Open source-komponenters særlige problematik

Open source-software udgør rygraden i moderne produktudvikling. Et typisk IoT-produkt som en netværksforbundet sæbedispenser indeholder ofte hundredvis af open source-komponenter: fra operativsystemet og netværksstakken til krypteringsbiblioteker og dataformateringsværktøjer.

For producenten opstår flere konkrete udfordringer:

Licensforhold og oprindelse

Open source-komponenter kommer med forskellige licenser, og producenten skal sikre, at brugen er licensmæssigt korrekt. Men vigtigere under CRA: producenten skal kunne dokumentere komponenternes oprindelse og vedligeholdelsestilstand.

Vedligeholdelse og opdateringer

Mange open source-projekter drives af frivillige fællesskaber. Nogle projekter er velfinansierede og aktivt vedligeholdte, andre er reelt forladte. Når producenten inkorporerer en open source-komponent, overtager producenten ansvaret for at sikre, at komponenten forbliver sikker — uanset om det oprindelige projekt stadig eksisterer.

Det skaber et konkret dilemma: Hvad gør producenten, hvis et kritisk sikkerhedshul opdages i et open source-bibliotek, som ingen længere vedligeholder? Under CRA er svaret klart: producenten skal selv fikse det, finde et alternativ eller trække produktet tilbage.

Transitiv afhængighed

Open source-komponenter bruger selv andre open source-komponenter. En produkt-SBOM kan hurtigt vokse til tusindvis af transitive afhængigheder. Producenten er ansvarlig for dem alle — også dem, der ligger fire-fem lag nede i afhængighedstræet.

Risikoscenarier for hospitaler og plejehjem

For at forstå konsekvenserne kan vi gennemgå nogle realistiske scenarier:

Scenario 1: Sårbarhed i kommunikationsmodul

Et hospital har installeret 200 smarte sæbedispensere, der rapporterer forbrugsdata til et centralt hygiejneoverblik-system. Dispenserne bruger et open source MQTT-bibliotek til kommunikation. En kritisk sårbarhed opdages i biblioteket, som gør det muligt for angribere at aflytte netværkstrafikken eller injicere falske data.

Under CRA er producenten forpligtet til hurtigt at udsende en sikkerhedsopdatering. Hvis producenten ikke har styr på sin SBOM, opdager de måske slet ikke, at de er berørt. Hvis de ikke har en etableret proces for firmware-opdateringer, kan det tage måneder at rulle en rettelse ud. I mellemtiden ligger hospitalets hygiejnedata potentielt åbne.

Scenario 2: Uautoriseret netværksadgang

En angriber udnytter en sårbarhed i en desinfektionsstations webinterface til at få adgang til hospitalets interne netværk. Standardadgangskoden var aldrig blevet ændret, fordi producenten leverede produktet med “admin/admin” som default.

Under CRA ville dette være et klart brud på “security by default”-princippet. Producenten ville kunne holdes ansvarlig, uanset at hospitalet teoretisk set kunne have ændret koden.

Scenario 3: Datatab fra hygiejnesystem

Et digitalt håndhygiejne-monitoringssystem logger, hvilke medarbejdere der vasker hænder hvornår. Systemet kompromitteres, og persondata lækkes. Ud over GDPR-implikationer rejser dette spørgsmål om produktets grundlæggende sikkerhedsarkitektur — noget producenten under CRA er ansvarlig for.

I sundhedssektoren er sikker håndtering af data afgørende. Problemstillingen med digital sikkerhed rækker langt ud over produkter og ind i daglige arbejdsgange — for eksempel i forhold til, hvordan man i det hele taget bør stoppe med at sende patientdata på usikret e-mail.

Compliance-trin for producenter af digitale sundhedsprodukter

For producenter, der endnu ikke er fuldt CRA-compliant, er følgende trin afgørende:

1. Kortlægning af produktporteføljen

Start med at identificere alle produkter med digitale elementer. Husk, at “digitale elementer” defineres bredt og inkluderer software, firmware og hardware med programmérbare komponenter. En simpel sæbedispenser med en mikrocontroller falder inden for definitionen.

2. Etablering af komplet SBOM

For hvert produkt skal der oprettes en fuldstændig Software Bill of Materials. Brug automatiserede værktøjer til at scanne kodebaser og identificere alle afhængigheder, inklusive transitive. SBOM’en skal holdes opdateret ved hver produktændring.

3. Sårbarhedsmonitorering

Implementer processer til løbende at overvåge kendte sårbarheder (CVE’er) i alle komponenter på SBOM’en. Der findes kommercielle og open source-værktøjer, der kan automatisere denne overvågning.

4. Sikker udviklingsproces (Secure SDLC)

Udvikling skal følge secure-by-design-principper fra start. Det inkluderer:

• Trusselsmodellering i designfasen
• Sikker kodningspraksis
• Automatiseret sikkerhedstest (SAST, DAST)
• Kodegennemgang med sikkerhedsfokus
• Penetrationstest før release

5. Opdateringsmekanismer

Produkter skal designes, så sikkerhedsopdateringer kan rulles ud effektivt. For IoT-produkter i sundhedssektoren betyder det ofte over-the-air (OTA) opdateringskapabilitet med sikker autentificering.

6. Dokumentation og sporbarhed

Al dokumentation skal være på plads til at demonstrere compliance ved tilsyn. Det inkluderer designdokumentation, testrapporter, SBOM, sårbarhedshåndteringslog og sikkerhedsopdateringshistorik.

7. Incident response-processer

Etabler klare processer for håndtering af sikkerhedshændelser, herunder den lovpligtige 24-timers rapportering til ENISA ved aktivt udnyttede sårbarheder.

Indkøberes rolle og ansvar

For indkøbere, kvalitetsansvarlige og it-afdelinger i sundhedssektoren ændrer CRA også spillereglerne. Selvom producentansvaret ligger hos leverandøren, har indkøberen en kritisk rolle i at sikre, at de produkter, der bringes ind i organisationen, er compliant.

Konkrete tiltag inkluderer:

1. Krav i udbud og kontrakter: Stil eksplicitte krav om CRA-compliance og dokumentation heraf i alle indkøbsaftaler for digitale produkter
2. SBOM som leverance: Kræv at få leveret produktets SBOM som del af leverancen
3. Opdateringsaftaler: Sikr kontraktuelle forpligtelser om sikkerhedsopdateringer i hele produktets forventede levetid
4. Leverandørvurdering: Inkluder cybersikkerhedsmodenhed som parameter i leverandørevaluering
5. Løbende opfølgning: Etabler processer til at følge op på, om leverandører lever op til deres compliance-forpligtelser over tid

Konsekvenser ved manglende compliance

CRA er ikke en tandløs forordning. Håndhævelsen er reel, og konsekvenserne for non-compliance kan være alvorlige:

• Bøder: Op til 15 millioner euro eller 2,5% af global årsomsætning for overtrædelse af de væsentligste krav
• Markedsadgang: Produkter kan forbydes på EU-markedet eller tvinges tilbagekaldt
• Omdømme: Offentlig omtale af sikkerhedsbrist i sundhedsudstyr kan være ødelæggende for en producents brand
• Erstatningsansvar: Ud over CRA-sanktioner kan producenten møde civilretlige erstatningskrav fra skadelidte

Fra compliance til konkurrencefordel

Selvom CRA primært opleves som en regulatorisk byrde, rummer den også muligheder. Producenter, der tager cybersikkerhed seriøst og kan dokumentere det, kan differentiere sig i markedet. For sundhedssektoren, hvor tillid er afgørende, kan demonstreret sikkerhedsmodenhed blive et reelt konkurrenceparameter.

Hospitaler og plejehjem bliver i stigende grad bevidste om cybersikkerhedsrisici. Leverandører, der proaktivt kan fremvise CRA-compliance, SBOM’er og dokumenterede sikkerhedsprocesser, vil stå stærkere i fremtidige udbud end konkurrenter, der behandler compliance som et nødvendigt onde.

Ofte stillede spørgsmål

Gælder CRA for alle sæbedispensere med sensorer?

CRA gælder for produkter med digitale elementer, der forbindes til et netværk eller en anden enhed. En simpel batteridrevet sæbedispenser med mekanisk sensor falder uden for. Men når produktet indeholder software og kan kommunikere — f.eks. via WiFi, Bluetooth eller kabelnetværk — er det omfattet. Det afgørende er tilstedeværelsen af digitale elementer, ikke produktets kompleksitet.

Hvem har ansvaret, hvis en sårbarhed stammer fra open source?

Producenten, der bringer produktet til markedet, har det fulde ansvar. Det gælder uanset, om sårbarheden ligger i egen kode, kommercielt licenseret software eller gratis open source-komponenter. Open source-udviklere og -fællesskaber er ikke ansvarlige under CRA, medmindre de selv kommercialiserer softwaren som et produkt. Producenten overtager ansvaret ved at inkorporere komponenten i sit produkt.

Hvor længe skal producenten levere sikkerhedsopdateringer?

CRA kræver, at producenten leverer sikkerhedsopdateringer i hele produktets forventede levetid, dog minimum fem år fra markedsføring. For hospitalsudstyr, der typisk bruges i mange år, kan det betyde en opdateringsforpligtelse på 10-15 år eller mere. Producenten skal kommunikere den forventede supportperiode tydeligt ved salg.

Kan hospitaler holdes ansvarlige, hvis de bruger non-compliant udstyr?

CRA’s producentansvar ligger hos producenten, ikke brugeren. Hospitaler kan dog have andre forpligtelser under NIS2-direktivet om netværks- og informationssikkerhed, der stiller krav til deres egen cybersikkerhedspraksis. Desuden kan hospitaler have et medansvar, hvis de bevidst ignorerer kendte sikkerhedsproblemer eller undlader at installere tilgængelige sikkerhedsopdateringer. God praksis er at stille CRA-compliance som krav ved indkøb.

Hvordan kommer vi i gang med CRA-compliance?

Start med en foranalyse, der kortlægger jeres produkter, deres digitale komponenter og jeres nuværende modenhed i forhold til CRA-kravene. En GAP-analyse identificerer, hvor der er huller mellem nuværende tilstand og krav, og danner grundlag for en prioriteret handlingsplan. For mange producenter vil det kræve involvering af ekstern rådgivning med specialviden om både cybersikkerhed og compliance.