SBOM e modellazione delle minacce per i dispositivi medici
Sytance · Aggiornato
Una SBOM e un modello delle minacce rispondono a domande diverse. La SBOM identifica i componenti software e i rapporti di dipendenza. Il modello delle minacce spiega come si possa attaccare un dispositivo, un sistema software, un utente, un ambiente o un percorso di aggiornamento e come l’attacco possa incidere sulla sicurezza, sulle prestazioni o sulla protezione.
Documenti distinti
La vulnerabilità di un componente diventa una questione specifica del dispositivo quando se ne comprende il ruolo. Un parser di rete può ricevere direttamente input non attendibili; la stessa libreria, compilata senza la funzione interessata, può comportare un’esposizione diversa. La SBOM identifica il componente, mentre il modello delle minacce fornisce l’architettura necessaria per analizzare tale differenza.
NTIA definisce una SBOM come un inventario leggibile da una macchina dei componenti software e delle loro relazioni. Nella valutazione di un dispositivo, ciò aiuta a stabilire quale software sia presente e dove reperire informazioni sui fornitori o sulle vulnerabilità.
SBOM
Registra nomi dei componenti, fornitori, versioni, identificativi, hash, dipendenze e informazioni sulla paternità, affinché fabbricante e cliente possano monitorare l’esposizione dei componenti e lo stato del supporto.
Modello delle minacce
Registra asset, attori, confini di fiducia, flussi di dati, interfacce, percorsi di attacco, minacce, misure di mitigazione, ipotesi e decisioni sul rischio residuo.
Architettura di sicurezza
Mostra come controlli quali autenticazione, autorizzazione, cifratura, registrazione, protezione degli aggiornamenti e ripristino siano distribuiti nel sistema e nei servizi correlati.
Gestione dei rischi
Stabilisce se il rischio residuo sia accettabile e in che modo i rilievi di cibersicurezza incidano su sicurezza, prestazioni, etichettatura, sorveglianza post-market e correzione.
Collegamento con la fase pre-market
L’attuale guida FDA pre-market prevede che SBOM, modellazione delle minacce, valutazione dei rischi di cibersicurezza, architettura e prove funzionino insieme. Per un dispositivo cyber ai sensi della sezione 524B, la SBOM è un elemento della presentazione previsto per legge e deve includere componenti software commerciali, open source e off-the-shelf.
- Il modello delle minacce dovrebbe coprire il sistema del dispositivo, le entità esterne, l’installazione, l’interoperabilità, la manutenzione, gli aggiornamenti, le ipotesi sulla catena di fornitura e la dismissione.
- La SBOM dovrebbe includere componenti sviluppati dal fabbricante e di terze parti, dipendenze upstream, stato del supporto e informazioni necessarie per valutare le vulnerabilità note.
- Le viste architetturali dovrebbero spiegare interfacce, protocolli, confini di fiducia, utenti, controlli, sistemi correlati e percorsi di aggiornamento.
- Le prove dovrebbero dimostrare che i controlli di sicurezza e le misure di mitigazione delle minacce selezionati funzionano, incluse le prove di vulnerabilità e i test di penetrazione quando pertinenti.
Una voce della SBOM dovrebbe poter essere ricondotta alla posizione del componente nell’architettura e alla pertinente analisi delle vulnerabilità. Questi collegamenti mettono in relazione l’inventario con la modellazione delle minacce, le prove, l’etichettatura e la gestione post-market.
Collegamento con la fase post-market
Dopo il rilascio, la SBOM e il modello delle minacce diventano documenti operativi. La SBOM aiuta a individuare l’esposizione quando cambiano un fornitore, un pacchetto open source, un componente commerciale o una dipendenza del sistema operativo. Il modello delle minacce aiuta a stabilire se tale esposizione possa causare danni ai pazienti nell’architettura e nell’ambiente d’uso effettivi del dispositivo.
Verificare se la versione e il codice interessati siano presenti nel dispositivo, quindi determinare come un attaccante potrebbe raggiungerli. Valutare i controlli esistenti e i possibili danni ai pazienti. Il risultato si applica alle configurazioni analizzate; potrebbe essere necessaria una valutazione separata per altre versioni ancora in uso.
Il modello delle minacce dovrebbe essere aggiornato quando una nuova vulnerabilità, una nuova tecnica di attacco, una modifica delle ipotesi di installazione, una nuova interfaccia, un nuovo servizio cloud o un cambiamento del percorso di aggiornamento modificano il quadro dei rischi.
Vulnerability Exploitability eXchange (VEX) comunica una valutazione dell’impatto per una vulnerabilità identificata e un prodotto specifico. Indicare la versione e la configurazione interessate e illustrare le condizioni che il destinatario deve mantenere. Se occorre una correzione, specificare l’aggiornamento o l’altra azione disponibile per l’utente.
Mantenere documenti utilizzabili
La SBOM e il modello delle minacce dovrebbero indicare la versione del prodotto descritta e rimanere aggiornati dopo il rilascio. La SBOM deve inoltre usare un formato leggibile da una macchina. Entrambi i documenti dovrebbero essere collegati al fascicolo di gestione dei rischi.
La baseline NTIA del 2021 identifica elementi di dati quali nome del fornitore, nome del componente, stringa della versione, identificativo del componente, relazione di dipendenza, nome dell’autore e timestamp. La FDA aggiunge aspettative specifiche per i dispositivi, quali stato del supporto software, vulnerabilità note e relazione con i controlli dei rischi del dispositivo.
Il modello dovrebbe spiegare come un attaccante potrebbe raggiungere una funzione del dispositivo e quali protezioni impediscono o limitano tale azione. Descrivere il dispositivo e i sistemi connessi, quindi collegare ogni scenario di attacco alle relative condizioni, ai controlli selezionati e al rischio residuo.
- Anche un dispositivo offline può ricevere input malevoli tramite un’interfaccia di aggiornamento o manutenzione. Includere questi percorsi nel modello delle minacce.
- Una SBOM senza CVE critiche note dice poco sui difetti di progettazione o sui controlli di accesso mancanti. Valutare tali minacce rispetto all’architettura.
- Un rapporto di penetration test vale per l’ambito e la configurazione dichiarati. Usarne i risultati insieme all’analisi del progetto e ai controlli di manutenzione previsti.
- Se la protezione dipende dalla rete del cliente, indicare i controlli richiesti e verificare che affrontino la minaccia. Comunicare le condizioni che il cliente deve mantenere.