Rapporto sui risultati

4.7 Gestione delle lacune di sicurezza (cpv. 1 lett. b)

I Cantoni NW e ZH nonché ZAD ribadiscono il parere espresso sul numero 4.6. A differenza del commento fatto al numero 4.6, ZAD propone però una semplificazione invece dello stralcio. Accanto ai Cantoni NW e ZH, anche K3 e VZK sono a favore dello stralcio del numero 4.7. Essi affermano che la disposizione è corretta nel principio, ma che è troppo dettagliata. ISSS vuole dei numeri supplementari con la seguente redazione: «4.7.4 Gemeinschaften müssen zur Unterstützung des Sicherheitsschwachstellenmanagements mindestens vierteljährlich automatisierte Schwachstellen-Scans durchführen» e «4.7.5 Gemeinschaften müssen zur Unterstützung des Sicherheitsschwachstellenmanagements mindestens jährlich einen Penetration-Test durch einen unabhängigen Anbieter durchführen lassen». VAKA caldeggia la proposta di cui al numero 4.7, ma ritiene relativamente oneroso verificare in qualsiasi momento le lacune di tutti i software, anche perché spesso si tratta di software «closed source» le cui lacune di sicurezza di solito sono sconosciute.

4.8 Gestione dei dati e dei sistemi degni di protezione (art. 1 lett. c e d)

K3, VZK, ZAD nonché i Cantoni NW e ZH ritengono troppo dettagliata la disposizione e bassa la sua utilità pratica. Chiedono pertanto una semplificazione del numero 4.8.

4.8.1: 6 Cantoni¹¹⁷ ricordano che ciò fa parte dell’obbligo di diligenza che i professionisti della salute devono osservare già oggi. Bleuer ritiene che non si possa definire a priori la rilevanza del trattamento. VAKA dichiara che la decisione di cui al numero 4.8.1 viene presa dai professionisti della salute e deve essere valutata ad hoc. KSSG chiede come sia possibile soddisfare tale prescrizione, se non esistono direttive sui dati rilevanti per il trattamento. Anche BINT e Integic si domandano come interpretare in questo contesto il termine «behandlungsrelevant» e ricordano che la sua interpretazione è soggetta a forti trasformazioni. Anche SSIM considera la definizione «behandlungsrelevant» troppo poco precisa e ne chiede una concretizzazione, come già espresso nel parere sul disegno di legge del 2011. Anche VGIch sostiene che non sia chiaro quali dati/documenti vengano considerati rilevanti per il trattamento. Mentre complessivamente 9 partecipanti¹¹⁸ chiedono lo stralcio totale del numero 4.8.1, Integic e KSSG si accontenterebbero di una precisazione. VGIch propone che l’UFSP fornisca un template non vincolante in modo da favorire una best practice per la messa a disposizione dei documenti da parte degli ospedali. OFAC chiede come le comunità possano garantire qualcosa che riguarda le strutture sanitarie aderenti. Chi assicurerebbe il controllo sul lungo termine, come e con quale diritto? I compiti delle comunità sono descritti in modo esauriente all’articolo 10 LCIP. Le strutture sanitarie, indipendentemente dalla loro adesione, sono soggette al diritto svizzero sulla protezione dei dati. È inoltre opportuno notare che il diritto al quale sono soggette le strutture sanitarie dipende anche dalla loro forma giuridica.

4.8.2 – 4.8.4: Posta ribadisce il parere espresso al numero 4.5 anche in riferimento al numero 4.8.2. 6 Cantoni¹¹⁹ chiedono un chiarimento, perché nella versione francese il termine «sensible» utilizzato al numero 4.8.2 non ha lo stesso senso che negli articoli 1 e 2 OCIP o nella LCIP. CMC, BüAeV, GAeSO e KAeG SG osservano che qui viene utilizzato di nuovo il termine «schützenswerte Daten», senza aver fornito una definizione. Poiché ciò potrebbe causare delle incertezze giuridiche, chiedono di aggiungere una definizione legale. Integic desidera un chiarimento perché a suo parere il numero 4.8.3.8.1 implica che per ogni attore IHE debba essere utilizzato un certificato client. Riguardo allo stesso numero KSSG scrive che la memorizzazione del certificato TLS-Client non è sicura nell’inventario e che tali certificati dovrebbero invece essere conservati in un luogo protetto. Propone quindi o di stralciare il numero o di riformularlo. L’inventario dovrebbe contenere solo il nome del certificato client, ma non il certificato stesso. 6 Cantoni¹²⁰ ricordano che una comunità non può tenere un inventario con migliaia di sistemi primari, né fornire indicazioni sul certificato TLS installato su questi sistemi, e chiedono dunque di stralciare il numero 4.8.3.8. SQS critica che la frase al numero 4.8.4.3 non è comprensibile. Non si capisce