Dal SANS NewsBites segnalo questa notizia: le più grandi società
tecnologiche hanno comunicato che contribuiranno economicamente alla
Linux Foundation's Core Infrastructure Initiative per aiutare i progetti
open source. Il bug Heartbleed ha portato alla ribalta la situazione di
OpenSSL: il codice è diffusissimo, ma il progetto riceve donazioni per circa
2.000 dollari all'anno ed è seguito da un addetto a tempo pieno:
-
http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-
by-heartbleed-finally-agree-to-fund-openssl/
Trovo tutto questo stupendo: un tizio mantiene quasi gratuitamente un codice
che è utilizzato da tantissime società per guadagnare tanti tanti milioni di
dollari, senza che gliene diano neanche una briciola... fino al pasticcio,
ovviamente!
A questo proposito segnalo anche questo interessante articolo:
-
http://www.theregister.co.uk/2014/04/11/openssl_heartbleed_robin_seggelmann/
Ovviamente, per disperdere energie, qualcuno ha pensato bene di aprire un
nuovo progetto: LibreSSL. Non posso fare a meno di riflettere sulle
similitudini con i nostri partiti politici...
- http://threatpost.com/libressl-sticks-a-fork-in-openssl/105653
Sicurezza delle informazioni, IT service management e qualità da Cesare Gallotti
sabato 26 aprile 2014
2014 Data Breach Investigations Report
Anche quest'anno segnalo la pubblicazione del Data Breach Investigations
Report di Verizon:
- http://www.verizonenterprise.com/DBIR/2014/
La segnalazione l'ho avuta dalla newsletter SANS NewsBites che riporta un
link al seguente articolo (mi chiedo perché non riporti il link diretto al
report):
- http://www.nextgov.com/cybersecurity/2014/04/government-employees-cause-nearly-60-public-sector-cyber-incidents/82933/
Riassumo il riassunto del SANS: almeno metà degli incidenti registrati nel
settore pubblico sono dovuti al personale interno. Di questi, un terzo
riguarda incidenti "vari", tra cui e-mail inviate a persone sbagliate.
Spionaggio e sfruttamento di vulnerabilità dei siti web costituiscono meno
del 1% degli incidenti. I numeri delle imprese private sono diversi perché
gli incidenti nel settore pubblico devono essere documentati e quindi
piccoli errori molto frequenti predominano nella statistica.
Personalmente ritrovo le stesse difficoltà delle singole aziende che
vogliono elaborare statistiche sulla sicurezza delle informazioni: i dati
sono troppo eterogenei e variegati per ottenere qualcosa di realmente
significativo e, quindi, piuttosto che "misurare" è necessario "monitorare"
e "riferire"... ma di questo già scrissi a suo tempo
(http://blog.cesaregallotti.it/2013/04/se-non-lo-misuri-non-lo-conosci.html)
.
Report di Verizon:
- http://www.verizonenterprise.com/DBIR/2014/
La segnalazione l'ho avuta dalla newsletter SANS NewsBites che riporta un
link al seguente articolo (mi chiedo perché non riporti il link diretto al
report):
- http://www.nextgov.com/cybersecurity/2014/04/government-employees-cause-nearly-60-public-sector-cyber-incidents/82933/
Riassumo il riassunto del SANS: almeno metà degli incidenti registrati nel
settore pubblico sono dovuti al personale interno. Di questi, un terzo
riguarda incidenti "vari", tra cui e-mail inviate a persone sbagliate.
Spionaggio e sfruttamento di vulnerabilità dei siti web costituiscono meno
del 1% degli incidenti. I numeri delle imprese private sono diversi perché
gli incidenti nel settore pubblico devono essere documentati e quindi
piccoli errori molto frequenti predominano nella statistica.
Personalmente ritrovo le stesse difficoltà delle singole aziende che
vogliono elaborare statistiche sulla sicurezza delle informazioni: i dati
sono troppo eterogenei e variegati per ottenere qualcosa di realmente
significativo e, quindi, piuttosto che "misurare" è necessario "monitorare"
e "riferire"... ma di questo già scrissi a suo tempo
(http://blog.cesaregallotti.it/2013/04/se-non-lo-misuri-non-lo-conosci.html)
.
venerdì 25 aprile 2014
Storia e futuro della ISO 9001
Segnalo questo white paper del BSI dal titolo " The history and future of
ISO 9001 - Approaching change":
-
http://www.bsigroup.com/LocalFiles/en-GB/iso-9001/Revisions/ISO%209001%20Whi
tepaper%20-%20the%20history%20and%20future%20of%20ISO%209001.pdf
Il motivo per l'interesse è la storia, che avevo dimenticato: nata come BS
5750 e appoggiata dal Ministero della difesa UK, si occuapava della gestione
dei processi manifatturieri. Nel 1987 la BS 5750 fu recepita dall'ISO con il
codice 9001 e modificata per coprire più tipologie di business. L'edizione
ISO 9001:1994 era più orientata all'assicurazione qualità, con
l'introduzione delle azioni preventive. La successiva edizione ISO 9001:2000
introdusse l'approccio per processi e la loro misurazione. La ISO 9001:2008
è un raffinamento della versione del 2000.
Il white paper si dilunga sulle novità della futura versione prevista per il
2015. Questa è pura operazione di marketing sulla cui completa onestà ho
molto dubbi (il BSI promuove convegni a pagamento e l'acquisto dei draft
dello standard) . Infatti la norma si trova in stato di Committee Draft e
potrebbe subire consistenti cambiamenti da qui alla sua pubblicazione (come
peraltro ho sperimentato personalmente durante i lavori dell'SC 27 e in
particolare con la ISO/IEC 27001 e la ISO/IEC 27006). Pertanto, a meno che
non partecipiate ai lavori della futura ISO 9001 (in Italia è possibile
farlo attraverso l'UNI), il mio consiglio è di non far nulla.
ISO 9001 - Approaching change":
-
http://www.bsigroup.com/LocalFiles/en-GB/iso-9001/Revisions/ISO%209001%20Whi
tepaper%20-%20the%20history%20and%20future%20of%20ISO%209001.pdf
Il motivo per l'interesse è la storia, che avevo dimenticato: nata come BS
5750 e appoggiata dal Ministero della difesa UK, si occuapava della gestione
dei processi manifatturieri. Nel 1987 la BS 5750 fu recepita dall'ISO con il
codice 9001 e modificata per coprire più tipologie di business. L'edizione
ISO 9001:1994 era più orientata all'assicurazione qualità, con
l'introduzione delle azioni preventive. La successiva edizione ISO 9001:2000
introdusse l'approccio per processi e la loro misurazione. La ISO 9001:2008
è un raffinamento della versione del 2000.
Il white paper si dilunga sulle novità della futura versione prevista per il
2015. Questa è pura operazione di marketing sulla cui completa onestà ho
molto dubbi (il BSI promuove convegni a pagamento e l'acquisto dei draft
dello standard) . Infatti la norma si trova in stato di Committee Draft e
potrebbe subire consistenti cambiamenti da qui alla sua pubblicazione (come
peraltro ho sperimentato personalmente durante i lavori dell'SC 27 e in
particolare con la ISO/IEC 27001 e la ISO/IEC 27006). Pertanto, a meno che
non partecipiate ai lavori della futura ISO 9001 (in Italia è possibile
farlo attraverso l'UNI), il mio consiglio è di non far nulla.
giovedì 24 aprile 2014
Electronic Evidence Guide
E' stata recentemente pubblicata la "Guida alla prova digitale", traduzione
italiana della "Electronic Evidence Guide" del Council of Europe. Per
scaricare la guida dovete compilare il form online disponibile a questo
indirizzo:
-
https://docs.google.com/forms/d/1gwHSgAjlyKWT10FEh8JNIAt_OQBRaCV4Jgt_-SLUWhU
/viewform
La versione italiana nasce dallo sforzo congiunto delle associazioni Digital
Forensics Alumni, Tech and Law Center e DEFT Association. La guida è stata
presentata ieri a Deftcon 2014 e sarà nuovamente illustrata il prossimo 5
Giugno 2014 in occasione del DFA Open Day alla Statale di Milano.
La versione in inglese si trova a questo indirizzo:
-
http://www.coe.int/t/dghl/cooperation/economiccrime/cybercrime/Documents/Ele
ctronic%20Evidence%20Guide/default_en.asp
La lettura è molto interessante anche per chi vuole capire meglio cos'è la
digital forensics e presenta numerosi casi ed esempi.
italiana della "Electronic Evidence Guide" del Council of Europe. Per
scaricare la guida dovete compilare il form online disponibile a questo
indirizzo:
-
https://docs.google.com/forms/d/1gwHSgAjlyKWT10FEh8JNIAt_OQBRaCV4Jgt_-SLUWhU
/viewform
La versione italiana nasce dallo sforzo congiunto delle associazioni Digital
Forensics Alumni, Tech and Law Center e DEFT Association. La guida è stata
presentata ieri a Deftcon 2014 e sarà nuovamente illustrata il prossimo 5
Giugno 2014 in occasione del DFA Open Day alla Statale di Milano.
La versione in inglese si trova a questo indirizzo:
-
http://www.coe.int/t/dghl/cooperation/economiccrime/cybercrime/Documents/Ele
ctronic%20Evidence%20Guide/default_en.asp
La lettura è molto interessante anche per chi vuole capire meglio cos'è la
digital forensics e presenta numerosi casi ed esempi.
lunedì 21 aprile 2014
Delle definizioni di rischio (approfondimento)
Dopo il mio post "Delle definizioni di rischio"
(http://blog.cesaregallotti.it/2014/04/delle-definizioni-di-rischio.html),
Andrea Veneziani di Data Management mi ha proposto un approfondimento che
riporto di seguito (e lo ringrazio).
La definizione di rischio in seno al D. Lgs. 81/2008 può essere interpretato
come "probabilità che si verifichino degli eventi per cui si hanno dei danni
consistenti". In realtà si dovrebbe togliere la parola "consistenti" a meno
che non si voglia semplicemente dire "tangibili" ed in qualche modo
"misurabili" e non come si dovrebbe intendere "di notevole entità",
"ragguardevoli", "ricchi".
Infatti col D. Lgs. 81/2008 il focus è sulla salute e sicurezza dei
lavoratori per cui il rischio e soprattutto il concetto di "danno" è legato
alla salute misurabile in giorni di malattia o infortunio, che poi possono
essere quantificati in punti di invalidità. Il caso peggiore (caso morte)
non lo voglio contemplare, ma anche questo è configurabile come "misurabile"
secondo parametri assicurativi.
In buona sostanza anche un giorno di assenza dal lavoro per infortunio
causato potrebbe essere considerato un danno "consistente" ed andrebbe
contemplato, anche se fino a 20 gg. non è punibile penalmente. Si eccettuano
pertanto solo le piccole ferite guaribili senza grossi interventi da parte
di medici. Colgo l'occasione per citare che eventuali lesioni personali
colpose sopra i 20 gg. di calendario (causate da una non corretta
valutazione del rischio e azioni per ridurlo da parte del datore di lavoro)
potrebbero essere punibili con la reclusione fino a tre mesi….
In conclusione il "danno accettabile" spesso si riduce a "taglietti
provocati dalla carta" per i rischi da ufficio, mentre tutto il resto ahimè
andrebbe considerato come "consistente".
Da qui la differenza "logica" che deriva tra una definizione ISO del
concetto di rischio e quella data dal D. Lgs. 81/08. In quest'ultimo caso
l'asticella è tenuta ben focalizzata sui danni (anche minimi) anziché sulle
semplici valutazioni di accettabilità del rischio.
(http://blog.cesaregallotti.it/2014/04/delle-definizioni-di-rischio.html),
Andrea Veneziani di Data Management mi ha proposto un approfondimento che
riporto di seguito (e lo ringrazio).
La definizione di rischio in seno al D. Lgs. 81/2008 può essere interpretato
come "probabilità che si verifichino degli eventi per cui si hanno dei danni
consistenti". In realtà si dovrebbe togliere la parola "consistenti" a meno
che non si voglia semplicemente dire "tangibili" ed in qualche modo
"misurabili" e non come si dovrebbe intendere "di notevole entità",
"ragguardevoli", "ricchi".
Infatti col D. Lgs. 81/2008 il focus è sulla salute e sicurezza dei
lavoratori per cui il rischio e soprattutto il concetto di "danno" è legato
alla salute misurabile in giorni di malattia o infortunio, che poi possono
essere quantificati in punti di invalidità. Il caso peggiore (caso morte)
non lo voglio contemplare, ma anche questo è configurabile come "misurabile"
secondo parametri assicurativi.
In buona sostanza anche un giorno di assenza dal lavoro per infortunio
causato potrebbe essere considerato un danno "consistente" ed andrebbe
contemplato, anche se fino a 20 gg. non è punibile penalmente. Si eccettuano
pertanto solo le piccole ferite guaribili senza grossi interventi da parte
di medici. Colgo l'occasione per citare che eventuali lesioni personali
colpose sopra i 20 gg. di calendario (causate da una non corretta
valutazione del rischio e azioni per ridurlo da parte del datore di lavoro)
potrebbero essere punibili con la reclusione fino a tre mesi….
In conclusione il "danno accettabile" spesso si riduce a "taglietti
provocati dalla carta" per i rischi da ufficio, mentre tutto il resto ahimè
andrebbe considerato come "consistente".
Da qui la differenza "logica" che deriva tra una definizione ISO del
concetto di rischio e quella data dal D. Lgs. 81/08. In quest'ultimo caso
l'asticella è tenuta ben focalizzata sui danni (anche minimi) anziché sulle
semplici valutazioni di accettabilità del rischio.
Le frodi nella rete
Enrico Toso di DB Consorzio mi ha segnalato un interessante lavoro
presentato a Milano, al Security Summit 2014. Il titolo è "Le frodi nella
rete" e si trova a questo indirizzo:
- http://frodi.clusit.it/views/Homepage.html
La presentazione fatta al Security Summit si trova tra gli atti del 19
marzo:
- https://www.securitysummit.it/milano-2014/atti/atti-19-marzo/
Nel documento ho trovato interessante soprattutto la seconda parte, dove
sono analizzate le frodi tipiche di ogni settore (banche, telco,
assicurazioni, gaming, pagamenti on-line, mobile, carte di credito e
proprietà intelletuale) e sono indicate delle modalità per prevenirle e/o
rilevarle.
presentato a Milano, al Security Summit 2014. Il titolo è "Le frodi nella
rete" e si trova a questo indirizzo:
- http://frodi.clusit.it/views/Homepage.html
La presentazione fatta al Security Summit si trova tra gli atti del 19
marzo:
- https://www.securitysummit.it/milano-2014/atti/atti-19-marzo/
Nel documento ho trovato interessante soprattutto la seconda parte, dove
sono analizzate le frodi tipiche di ogni settore (banche, telco,
assicurazioni, gaming, pagamenti on-line, mobile, carte di credito e
proprietà intelletuale) e sono indicate delle modalità per prevenirle e/o
rilevarle.
giovedì 10 aprile 2014
Heartbleed (vulnerabilità in OpenSSL)
La minaccia oggi più discussa è chiamata Heartbleed.
In sostanza, se si usano delle versioni vulnerabili di OpenSSL si rischia
un'intrusione da parte di malintenzionati:
- http://heartbleed.com/
In sostanza, se si usano delle versioni vulnerabili di OpenSSL si rischia
un'intrusione da parte di malintenzionati:
- http://heartbleed.com/
giovedì 3 aprile 2014
Regole tecniche: protocollo e conservazione digitale
Sono state pubblicate le nuove regole tecniche in materia di protocollo per
la Pubblica Amministrazione e di conservazione sostitutiva.
Sono due provvedimenti importanti, soprattutto il secondo, applicabile anche
ai privati, perché stabilisce come deve essere fatto un sistema di
conservazione dei documenti informatici che assicuri l'identificazione certa
del soggetto che ha formato il documento e l'integrità del documento.
Le regole si trovano sulla pagina ufficiale dell'Agid:
-
http://www.agid.gov.it/notizie/protocollo-conservazione-digitale-gazzetta-le
-nuove-regole-tecniche
Segnalo anche un articolo in merito su iged.it (e mi lamento con chi si è
inventato il formato di lettura):
- http://issuu.com/stefanoforesti/docs/iged114_light/7?e=1523602/7213043
la Pubblica Amministrazione e di conservazione sostitutiva.
Sono due provvedimenti importanti, soprattutto il secondo, applicabile anche
ai privati, perché stabilisce come deve essere fatto un sistema di
conservazione dei documenti informatici che assicuri l'identificazione certa
del soggetto che ha formato il documento e l'integrità del documento.
Le regole si trovano sulla pagina ufficiale dell'Agid:
-
http://www.agid.gov.it/notizie/protocollo-conservazione-digitale-gazzetta-le
-nuove-regole-tecniche
Segnalo anche un articolo in merito su iged.it (e mi lamento con chi si è
inventato il formato di lettura):
- http://issuu.com/stefanoforesti/docs/iged114_light/7?e=1523602/7213043
Delle definizioni di rischio
Stefano Ramacciotti mi ha segnalato le diverse definizioni di rischio nelle
norme ISO e nella legislazione italiana:
- ISO Guide 73 (e anche ISO/IEC 27000): effetto dell'incertezza degli
eventi. Le note poi dicono che il rischio è spesso caratterizzato da una
combinazione di eventi potenziali e le loro conseguenze.
- il Dlgs 81: probabilità di raggiungimento del livello potenziale di danno
nelle condizioni di impiego o di esposizione ad un determinato fattore o
agente oppure alla loro combinazione;
- Direttiva Seveso III: probabilità che un determinato evento si verifichi
in un dato periodo o in circostanze specifiche.
Ecco quindi il mio (nostro) punto di vista.
La ISO Guide 73 usa la definizione di rischio legata agli "effetti", ossia
agli impatti. Essa è originata dalla formula "rischio = probabilità x
conseguenza". Esemplificando, essa deriva dall'uso del rischio così: se mi
rubano 10 penne all'anno di 1 Euro ciascuna, allora ho una perdita annua di
10 Euro all'anno; quindi il rischio relativo al furto di penne è pari a 10
euro all'anno.
La Direttiva Seveso III usa il termine rischio come sinonimo di minaccia.
Così come è scritta è una sciocchezza. Che senso ha valutare la probabilità
di una minaccia senza considerarne gli impatti? Si potrebbero avere minacce
estremamente probabili (pioggia e neve, per esempio) i cui impatti sono
risibili; i terremoti a Milano ci sono eccome, ma non hanno impatti perché
la pianura li attenua.
Però la prima definizione della Treccani (www.treccani.it) è proprio
"Eventualità di subire un danno" e quindi riguarda solo la minaccia. Ahinoi.
La definizione del Dlgs 81 è un poco più e pare voglia dire "probabilità che
si verifichino degli eventi per cui si hanno dei danni consistenti" e già
qui gli impatti si collegano ai danni. Mentre le norme ISO chiedono di
stabilire l'accettabilità del rischio (e quindi, potenzialmente, dei danni
complessivi annui, il Dlgs 81 chiede di stabilire il danno accettabile e poi
di valutare le minacce (i rischi, in quel caso) che li potrebbero provocare.
norme ISO e nella legislazione italiana:
- ISO Guide 73 (e anche ISO/IEC 27000): effetto dell'incertezza degli
eventi. Le note poi dicono che il rischio è spesso caratterizzato da una
combinazione di eventi potenziali e le loro conseguenze.
- il Dlgs 81: probabilità di raggiungimento del livello potenziale di danno
nelle condizioni di impiego o di esposizione ad un determinato fattore o
agente oppure alla loro combinazione;
- Direttiva Seveso III: probabilità che un determinato evento si verifichi
in un dato periodo o in circostanze specifiche.
Ecco quindi il mio (nostro) punto di vista.
La ISO Guide 73 usa la definizione di rischio legata agli "effetti", ossia
agli impatti. Essa è originata dalla formula "rischio = probabilità x
conseguenza". Esemplificando, essa deriva dall'uso del rischio così: se mi
rubano 10 penne all'anno di 1 Euro ciascuna, allora ho una perdita annua di
10 Euro all'anno; quindi il rischio relativo al furto di penne è pari a 10
euro all'anno.
La Direttiva Seveso III usa il termine rischio come sinonimo di minaccia.
Così come è scritta è una sciocchezza. Che senso ha valutare la probabilità
di una minaccia senza considerarne gli impatti? Si potrebbero avere minacce
estremamente probabili (pioggia e neve, per esempio) i cui impatti sono
risibili; i terremoti a Milano ci sono eccome, ma non hanno impatti perché
la pianura li attenua.
Però la prima definizione della Treccani (www.treccani.it) è proprio
"Eventualità di subire un danno" e quindi riguarda solo la minaccia. Ahinoi.
La definizione del Dlgs 81 è un poco più e pare voglia dire "probabilità che
si verifichino degli eventi per cui si hanno dei danni consistenti" e già
qui gli impatti si collegano ai danni. Mentre le norme ISO chiedono di
stabilire l'accettabilità del rischio (e quindi, potenzialmente, dei danni
complessivi annui, il Dlgs 81 chiede di stabilire il danno accettabile e poi
di valutare le minacce (i rischi, in quel caso) che li potrebbero provocare.
Normative e procedure
Come già scritto in precedenza, ho tenuto un intervento sulle tecniche di auditing per il Corso di perfezionamento in privacy e data
protection
- http://blog.cesaregallotti.it/2014/03/presentazione-audit.html
In quell'occasione spiegai che gli audit interni vanno condotti intervistando il personale e verificando le loro attività facendo riferimento alle procedure interne. Qualcuno mi ha chiesto: "ah... non sulla norma? non sul Codice Privacy e i Provvedimenti del Garante?".
La risposta è... nì.
Infatti, è mia opinione che il personale non possa essere chiamato a seguire un testo di Legge così com'è. Sia per carenza di competenze (alcuni articoli sono di difficile interpretazione anche a chi segue la materia da anni), sia perché ogni organizzazione è diversa dall'altra e l'attuazione dei requisiti normativi varia di volta in volta. Per esempio, chi deve fare il riesame delle utenze con accesso ai dati personali (gli amministratori di sistema o i responsabili dei diversi uffici)? come deve essere attuato operativamente il meccanismo di "custodia delle password"? che livello di controllo va esercitato sui fornitori? eccetera.
Quindi: il requisito normativo deve essere riportato in procedure (o istruzioni o regolamenti) a cui il personale deve attenersi.
Quindi l'audit dovrebbe essere diviso in due parti: la prima, a tavolino, per verificare se i requisiti normativi sono stati incorporati correttamente nelle procedure; la seconda, sul campo, per verificare se le procedure sono seguite dalle persone.
- http://blog.cesaregallotti.it/2014/03/presentazione-audit.html
In quell'occasione spiegai che gli audit interni vanno condotti intervistando il personale e verificando le loro attività facendo riferimento alle procedure interne. Qualcuno mi ha chiesto: "ah... non sulla norma? non sul Codice Privacy e i Provvedimenti del Garante?".
La risposta è... nì.
Infatti, è mia opinione che il personale non possa essere chiamato a seguire un testo di Legge così com'è. Sia per carenza di competenze (alcuni articoli sono di difficile interpretazione anche a chi segue la materia da anni), sia perché ogni organizzazione è diversa dall'altra e l'attuazione dei requisiti normativi varia di volta in volta. Per esempio, chi deve fare il riesame delle utenze con accesso ai dati personali (gli amministratori di sistema o i responsabili dei diversi uffici)? come deve essere attuato operativamente il meccanismo di "custodia delle password"? che livello di controllo va esercitato sui fornitori? eccetera.
Quindi: il requisito normativo deve essere riportato in procedure (o istruzioni o regolamenti) a cui il personale deve attenersi.
Quindi l'audit dovrebbe essere diviso in due parti: la prima, a tavolino, per verificare se i requisiti normativi sono stati incorporati correttamente nelle procedure; la seconda, sul campo, per verificare se le procedure sono seguite dalle persone.
SCADA e Ufficio acquisti
Sul gruppo LinkedIn Italian Security Professional è stata
lanciata una discussione sugli SCADA, ossia sui sistemi industriali, prendendo
lo spunto dalla presentazione di Alessio L.R. Pennasilico e Cristiano Cafferata
al Security Summit di Milano 2014 dal titolo " Quando il frigorifero
inizia ad inviare Phishing, forse andrebbe rivalutata la strategia di security":
Ci tengo a copiare e incollare un ottimo intervento che
condivido al 100% (sarà che in questo periodo sono coinvolto in un paio di
attività in ambienti manifatturieri):
<<
1) Bisogna lavorare sul procurement. Gli apparati e i
sistemi devono rispondere a requisiti di sicurezza. Corretto prendersela con
produttori poco attenti e sensibili, ma ancor peggio c'è chi questi apparati li
compra. Anni fa l'ignoranza era una buona scusa, ora non più
2) Se non si possono fare modifiche, il cliente dovrebbe
valutare il costo/beneficio di passare a soluzioni più sicure, se non subito,
al prossimo upgrade tecnologico. Informerei il vendor e il venditore, anche se
questo potrebbe portare a poco.
Il settore dovrebbe lavorare su standard specifici, in
modo da "certificare" i prodotti compliant e aiutare gli operatori
nella scelta. C'è ancora MOLTA strada da fare.
>>
E una risposta a questo commento è anch'essa molto interessante
(parafraso un poco):
<<
E' vero: il procurement va citato, ma se non ha delle
linee guida in materia di sicurezza, beh, il "fallo" è dietro
l'angolo.
>>
Dlgs 21/2014 - Contratti a distanza e Codice del consumo
Da Altalex segnalo le modifiche al Codice del consumo per
quanto riguarda i contratti a distanza introdotti dal Dlgs 21/2014 di
recepimento della Direttiva Europea 2011/83/UE:
In sintesi e copiando quanto riportato da Altalex, e
ricordando che l'informativa precontrattuale comprende tutte le clausole da
prevedere anche negli acquisti Internet, le maggiori novità sono:
- obbligo di informativa precontrattuale più gravoso
rispetto al precedente e di forma scritta;
- diritto di ripensamento: il consumatore può recedere
dall'acquisto entro 14 giorni ma se l'informativa è incompleta ha 12 mesi;
- restituzione del prodotto: il consumatore ha la
possibilità di restituire il prodotto, anche se deteriorato.
L'articolo di Filodiritto è più esaustivo:
Stato Regolamento europeo privacy
Da Filodiritto segnalo questo articolo sul Regolamento in materia di protezione dei dati personali:
In sintesi, c'eravamo
quasi, ma il Parlamento è in scadenza e passerà la pratica al futuro (elezioni
in Italia il 25 maggio). Ricordo che l'UK sta spingendo per posticipare il più
possibile l'approvazione di questo provvedimento.
Password sempre necessarie?
Da una discussione sul gruppo LinkedIn "Italian Security Professional", trovo
questo interessantissimo intervento di Luca Savoldi che permette di riflettere
sulla necessità o meno delle password. La conclusione, mia, è ovvia: sono
sempre necessarie, ma ci possono essere alcune limitate e controllate
eccezioni.
<<
Dimostrazione che anche l'IT e la sicurezza IT, se non pensata
per l'ambiente industriale, può essere pericolosa. La regola fondamentale e
imprescindibile in ambienti SCADA è che la Security (IT) deve supportare la
Safety e quindi i sistemi di Safety.
In una sala controllo di un importante
raffineria si conclude l'audit di importante ente inglese che si occupa di dare
la valutazione agli impianti industriali. Viene assegnato un bollone rosso
perché le postazioni della sala controllo non rispettano le policy di sicurezza
per le password degli account di dominio (nominale, 7 o 11 caratteri,
maiuscola, numero, carattere speciale, logoff automatico).
Con quale criterio
si può pensare di assegnare una simile policy ad una postazione la cui priorità
è l'accessibilità in caso di emergenza?
La sala controllo ha un controllo
accessi con badge nominale e riconoscimento visivo. Solo 10 persone possono
entrare. L'interno è ovviamente videosorvegliato. Per cui chi è dentro ad
operare è un operatore riconosciuto.
Pensate se per caso succede un'emergenza
e bisogna premere il comando di apertura o chiusura di una valvola per impedire
un esplosione. Bisogna intervenire in tempi rapidissimi. E se nel momento di
panico l'operatore non riesce a digitare la sua password? o se sviene e deve
intervenire il collega sulla sua postazione?
<<
questo interessantissimo intervento di Luca Savoldi che permette di riflettere
sulla necessità o meno delle password. La conclusione, mia, è ovvia: sono
sempre necessarie, ma ci possono essere alcune limitate e controllate
eccezioni.
<<
Dimostrazione che anche l'IT e la sicurezza IT, se non pensata
per l'ambiente industriale, può essere pericolosa. La regola fondamentale e
imprescindibile in ambienti SCADA è che la Security (IT) deve supportare la
Safety e quindi i sistemi di Safety.
In una sala controllo di un importante
raffineria si conclude l'audit di importante ente inglese che si occupa di dare
la valutazione agli impianti industriali. Viene assegnato un bollone rosso
perché le postazioni della sala controllo non rispettano le policy di sicurezza
per le password degli account di dominio (nominale, 7 o 11 caratteri,
maiuscola, numero, carattere speciale, logoff automatico).
Con quale criterio
si può pensare di assegnare una simile policy ad una postazione la cui priorità
è l'accessibilità in caso di emergenza?
La sala controllo ha un controllo
accessi con badge nominale e riconoscimento visivo. Solo 10 persone possono
entrare. L'interno è ovviamente videosorvegliato. Per cui chi è dentro ad
operare è un operatore riconosciuto.
Pensate se per caso succede un'emergenza
e bisogna premere il comando di apertura o chiusura di una valvola per impedire
un esplosione. Bisogna intervenire in tempi rapidissimi. E se nel momento di
panico l'operatore non riesce a digitare la sua password? o se sviene e deve
intervenire il collega sulla sua postazione?
<<
mercoledì 2 aprile 2014
Regolamento Agcom diritto d'autore online
Dal 31 marzo è entrato in vigore il Regolamento Agcom per la tutela del
Diritto d'autore online.
-
http://www.marchiebrevettiweb.it/29-diritto-di-autore/2397-entra-in-vigore-o
ggi-il-regolamento-per-la-tutela-del-diritto-d-autore-online.html
Esso prevede che i soggetti titolari o licenziatari di un diritto d'autore
possano segnalare all'Autorità le violazioni avvenute via Internet. Per
questo è a disposizione il sito:
- https://www.ddaonline.it
Notizia dal gruppo infotechlegale.it di LinkedIn.
Diritto d'autore online.
-
http://www.marchiebrevettiweb.it/29-diritto-di-autore/2397-entra-in-vigore-o
ggi-il-regolamento-per-la-tutela-del-diritto-d-autore-online.html
Esso prevede che i soggetti titolari o licenziatari di un diritto d'autore
possano segnalare all'Autorità le violazioni avvenute via Internet. Per
questo è a disposizione il sito:
- https://www.ddaonline.it
Notizia dal gruppo infotechlegale.it di LinkedIn.
Quaderno su PCI-DSS
Segnalo la pubblicazione del Quaderno Clusit "PCI-DSS: Payment Card
Industry. Data Security Standard" di Fabio Guasconi.
Il quaderno è aggiornato alla versione del PCI-DSS 3.0.
Ottimo per chi vuole cominciare a conoscere questo standard:
- http://clusit.it/download/index.htm
Industry. Data Security Standard" di Fabio Guasconi.
Il quaderno è aggiornato alla versione del PCI-DSS 3.0.
Ottimo per chi vuole cominciare a conoscere questo standard:
- http://clusit.it/download/index.htm
Rapporto Clusit 2014 e atti Security Summit
E' stato pubblicato il Rapporto Clusit 2014 sulla sicurezza informatica in
Italia. Confermo che è molto interessante:
- http://clusit.it/rapportoclusit/
Sono stati anche pubblicati gli atti del Security Summit:
- https://www.securitysummit.it/milano-2014/atti/
Confesso che non ho trovato cose molto interessanti in questi atti. Ma credo
sia un problema del formato "presentazione". Se però qualcuno vuole
segnalare qualcosa che mi sono perso, lo faccia!
Italia. Confermo che è molto interessante:
- http://clusit.it/rapportoclusit/
Sono stati anche pubblicati gli atti del Security Summit:
- https://www.securitysummit.it/milano-2014/atti/
Confesso che non ho trovato cose molto interessanti in questi atti. Ma credo
sia un problema del formato "presentazione". Se però qualcuno vuole
segnalare qualcosa che mi sono perso, lo faccia!
Iscriviti a:
Post (Atom)