venerdì 24 aprile 2015

I 10 rischi più importanti per le tecnologie sanitarie

Marco Fabbrini, esperto di dispositivi medicali, mi ha segnalato la
pubblicazione "Top 10 Health Technology Hazards for 2015" dell'ECRI
Institute:
- https://www.ecri.org/press/Pages/ECRI-Institute-Announces-Top-10-Health-Tech
nology-Hazards-for-2015.aspx


Il rapporto è stato tradotto in italiano da AIIC.

I 10 rischi più importanti sono:
1. Policy e pratiche di configurazione degli allarmi inadeguate;
2. Dati errati o mancanti nella cartella clinica elettronica ed altri sistemi informatici;
3. Inversione di linee per terapia endovenosa e conseguente errata somministrazione di farmaci;
4. Rigenerazione inadeguata di endoscopi e strumenti chirurgici;
5. Mancata rilevazione di scollegamento dei ventilatori, a causa di allarmi mal-impostati o non avvertiti;
6. Errori nell'utilizzo e malfunzionamento di dispositivi per la movimentazione del paziente;
7. "Dose Creep": Insidiose variazioni nell'esposizione a radiazioni diagnostiche;
8. Complicazioni conseguenti a formazione inadeguata su chirurgia robotica;
9. Protezioni inadeguate per dispositivi e sistemi medicali da attacchi informatici;
10. Collassamento dei programmi per la gestione di richiami e avvisi di sicurezza.

Marco mi ha fatto notare che 3 su 10 sono di sicurezza informatica (il 2, il 9 e il 10). Tutto ciò è sintomo di un interesse degli operatori per questi temi (i rischi non sono stati rilevati da statistiche degli incidenti registrati, ma da altre fonti) e quindi da considerare.

martedì 21 aprile 2015

Attacco ad una TV francese

Questa notizia la trovo strabiliante:
- http://arstechnica.com/security/2015/04/hacked-french-network-exposed-its-own-passwords-during-tv-interview/

Dal SANS NewsBites: in un'intervista video (peraltro relativa ad un hacking di un satellite), alle spalle dell'intervistato (un giornalista della rete francese TV5Monde) si trovavano dei foglietti con user-id e password. Come è andata a finire, potete immaginarlo (11 stazioni hanno avuto delle interruzioni di segnale).

Questo ci ricorda che ci vuole veramente poco per essere attaccati con successo.

NIST SP 800-161 su supply chain risk management

Il NIST ha pubblicato la Special Publication 800-161, Supply Chain Risk Management Practices. Essa è indirizzata agli enti federali degli USA ma potrebbe essere interessante per tutti:
- http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf

Io sono un fan delle pubblicazioni del NIST, ma questa non mi ha soddisfatto. Infatti spende 36 pagine per illustrare un metodo di risk assessment (come se il NIST non avesse già un'altra pubblicazione dedicata a questo o come se gli autori di questa pubblicazione volessero dire la loro sulla materia) per poi elencare lungamente dei controlli di sicurezza non sempre applicabili a tutti i fornitori. Anche l'elenco delle minacce non mi sembra particolarmente illuminante.

Mi sarebbe piaciuto infatti trovare considerazioni sui rischi relativi ai fornitori e alla filiera di fornitura, mentre invece non si trova quasi nulla di tutto ciò. E così pure sui controlli di sicurezza.

Bisogna dire che mi sembra quindi un'occasione persa, soprattutto se consideriamo quanta letteratura (di qualità non sempre eccelsa...) è stata fatta sui servizi cloud (ossia su una tipologia specifica di fornitori) e quanta poca ve ne sia sugli altri fornitori. Poteva essere l'occasione per ricordare che gran parte delle questioni di sicurezza delle informazioni relative ai servizi cloud sono in realtà comuni a più tipologie di fornitori e che, pertanto, andrebbero affrontate.

domenica 19 aprile 2015

Linee guida del CERT sulla codifica

Vi segnalo i "CERT Coding Standards" per C, C++, Java, Perl e Android:
- https://www.securecoding.cert.org/confluence/display/seccode/CERT+Coding+Standards

Il un'altra pagina, sono a disposizione le "Java Coding Guidelines":
- https://www.securecoding.cert.org/confluence/display/java/Java+Coding+Guidelines

La differenza tra gli "standard" e le "linee guida" al momento mi sfugge.

sabato 18 aprile 2015

Sul web

Mi rendo conto che questa notizia non c'entra nulla. Ma appaio per un secondo (il quinto) in questo spot di McDonald's e mi sembra ancora incredibile:
- http://www.ilpost.it/2015/04/15/hamburger-mcdonalds-blind-taste-milano-italia/

mercoledì 8 aprile 2015

Sviluppo - Worst practice

Mi è capitato un caso interessante. Visto che fatturo (poco) all'estero,
devo produrre dichiarazioni doganali. Da www.agenziadogane.it devo usare un
servizio "Intrastat". Ogni anno mi dà dei problemi e ogni anno devo chiamare
l'assistenza.

Vi segnalo quindi la pagina con le istruzioni per quest'anno (ogni anno
cambiano, ovviamente):
- http://assistenza.agenziadogane.it/SRVS/CGI-BIN/WEBCGI.EXE?St=274,E=00000000
00249617387,K=5081,Sxi=17,Solution=1946,t=Solution


Per chi non ha voglia di leggersi il documento, ecco cosa bisogna fare:
- usare una versione obsoleta di JRE;
- abbassare il livello di sicurezza del Java;
- abbassare il livello di sicurezza di Internet Explorer.
- osservare che i certificati usati sono auto-firmati.

Aggiungo che il mio pc con Windows 8, nonostante tutte queste cose, ha fatto
cilecca e ho dovuto usare un "vecchio" Windows Vista.

Questo è decisamente un caso di "worst practice" relativa allo sviluppo.

Un'ulteriore considerazione: l'assistenza mi ha risposto in modo molto
veloce e puntuale (anche se poi ho comunque dovuto cambiare pc). Questo mi
porta a credere che il fornitore dell'Agenzia delle Dogane ha un sistema
gestionale per cui l'assistenza (reattiva) funziona bene, ma la qualità
(preventiva) funziona molto male (la navigazione del sito è anch'essa molto
discutibile, con informazioni sparse in modo apparentemente casuale). C'è di
che pensar male (o perché la Direzione non sa fare il suo lavoro, oppure
perché così può risparmiare su una serie di elementi ma farsi pagare di più
a causa di altri).

martedì 7 aprile 2015

CIO si lamentano dell'inutilità dei report

Sul SANS NewsBites del 3 aprile trovo la seguente notizia: secondo
un'indagine del Government Accountability Office (GAO) presso responsabili
dell'IT (CIO, Chief Information Officer) di 24 agenzie federali tra le più
grandi, i report richiesti dal Office of Management and
Budget (OMB) sono in gran parte inutili e costosi:
- http://www.nextgov.com/cio-briefing/2015/04/survey-cios-say-many-it

Si tratta certamente di cose molto specifiche, ma il report del GAO mi ha
incuriosito:
- http://www.gao.gov/assets/670/669434.pdf

Se ho capito correttamente, i report richiesti sono 36 e riguardano la
pianificazione strategica, la pianificazione capitale e degli investimenti,
la sicurezza IT, l'acquisizione e integrazione dei sistemi IT e altre
iniziative. Solo 4 di questi sono reputati utili e riguardano la
pianificazione strategica e la pianificazione capitale e degli investimenti.
Tra i report "moderatamente significativi" si trovano quelli sulle
"significative debolezze di sicurezza" e sulle "metriche di sicurezza IT".

Perché la sicurezza è "moderatamente significativa"? In parte, sul report si
legge che si tratta di report con dati ridondanti l'uno con gli altri o con
dati da inserire manualmente da diverse fonti. In parte immagino che molte
misure non siano ritenute effettivamente significative e questo è uno dei
problemi della sicurezza: si può misurare il numero di incidenti e poco più.
Il resto serve solo a dare un'illusione di controllo "oggettivo".

lunedì 6 aprile 2015

Controllo del codice

Sulla mailing list ml di Sikurezza.org, un partecipante ha chiesto consigli
sugli strumenti di controllo automatico del codice.

Gli altri partecipanti hanno fornito diverse indicazioni: Fortify, ZAproxy,
pylint (per Python), Brakeman, Dawnscanner (per Ruby), Coverity (C++),
Veracode (su cloud).

Ancora più interessante è il link alla pagina del NIST, con una serie di
strumenti:
- http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html

In molti hanno segnalato alcuni problemi di questi strumenti, soprattutto i
falsi positivi e la necessità di valutarne i risultati con la dovuta
cautela, visto che ogni prodotto ha le sue specificità.

In questi anni, lo confesso, ho sempre ignorato questi strumenti, usati sia
per il controllo della qualità sia della sicurezza del codice. Credo che
invece siano da prendere in considerazione.