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.
venerdì 24 aprile 2015
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.
- 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.
- 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.
- 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/
- 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).
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".
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.
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.
Iscriviti a:
Post (Atom)