Audit di sicurezza informatica richiesto per i nostri dispositivi medici: cosa controllano esattamente?

Uno dei primissimi punti della lista sarà la SBOM leggibile via software in formato CycloneDX o SPDX. Se il vostro gateway gira su kernel Linux, dovete presentare versione di ogni pacchetto open source e report di scansione CVE. Se non avete lasciato telnet aperta o HTTP in chiaro sul gateway, siete già a metà dell'opera.

Due anni fa, per un appalto simile, abbiamo speso 11.500 EUR per un penetration test indipendente e una certificazione di conformità allo standard ospedaliero B3S. Allegato il report all'offerta, l'IT dell'ospedale ha validato la lista dei 45 punti praticamente all'istante senza fare altre domande.

Chiedete al team IT se fanno riferimento al BSI IT-Grundschutz o al profilo B3S Medizinische Versorgung. La maggior parte degli ospedali non si scrive i requisiti da zero, ricopia le checklist degli standard federali. Se conoscete lo standard di riferimento rispondere diventa una passeggiata.

I team IT degli ospedali di solito non capiscono la logica interna del software medicale, quindi lo trattano come un normale server. Potrebbero dirvi 'installate un antivirus sul dispositivo'. Dovete spiegare con pazienza perché un antivirus tradizionale non può funzionare sui dispositivi embedded e che al suo posto utilizzate il controllo dell'integrità hardware (Secure Boot).

Nel 2021 siamo stati bloccati da un audit simile per la gara d'appalto di una clinica universitaria. I nostri dispositivi erano perfetti, ma il meccanismo di aggiornamento software da remoto non aveva la verifica della firma crittografica. L'auditor ci ha bocciato su quel singolo punto e hanno sospeso il contratto per 5 mesi finché non abbiamo implementato l'infrastruttura di firma.

se non avete lasciato password predefinite tipo 'admin/admin' sui dispositivi e avete reso obbligatorio il cambio password al primo accesso all'interfaccia, avete già superato il primo scoglio su cui l'auditor si concentra di più.

Ai sensi dell'Allegato I Sezione 17.2 dell'MDR, la sicurezza delle informazioni è già un requisito legale fondamentale. Presentare all'auditor la documentazione come parte integrante del fascicolo tecnico del dispositivo medico (Post-Market Surveillance e Risk Management) dimostrerà la vostra serietà aziendale.

edit: ho scritto una cosa sbagliata sopra, scusate.

I 4 documenti da consegnare in prima battuta sono questi: 1) Report di analisi delle minacce conforme a MDCG, 2) Documento di architettura di rete con l'elenco di porte e servizi aperti, 3) Documento sulla policy di notifica delle vulnerabilità e rilascio delle patch, 4) Prova del Secure Boot a livello hardware del dispositivo.

Parlo dal lato opposto, io sono dalla parte dei fornitori. Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

Naturalmente cambia se la vostra situazione è diversa.

Vorrei fare una domanda. Un backup non testato non è un backup.

Buon lavoro.

Non lo sapevo.

Sono d'accordo. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Lascio una nota, potrebbe servire.

Nel nostro caso è andata così. Se permessi e ambito non sono scritti, quel test non deve iniziare.

Confermato dall'esperienza.

Su questo punto non sono d'accordo. La risposta varia molto in base al settore, non esiste una regola generale.

Un backup non testato non è un backup.

Sono nella stessa situazione, per questo chiedo. boh il vero problema non è il numero ma su cosa si basa quel numero.

Sono d'accordo anzi vorrei sottolinearlo. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Se scrivete qui il risultato, sarà utile anche ad altri.

Sono passato da qui vi racconto. Non abbiate paura di chiedere, chi non chiede paga sempre di più.

Scrivo questo per evitare che facciate lo stesso errore. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Questa è la mia opinione, non la scrivo come verità assoluta.