Il NIST ha pubblicato la prima revisione della guida 800-88, dedicata alla
"cancellazione sicura". La guida si trova qui:
- http://csrc.nist.gov/publications/PubsSPs.html#800-88
Il titolo esatto è "sanitizzazione" (treccani.it lo dà come sinonimo di
"sanificazione", ma questo è derivato dall'inglese "sanification") e
riguarda tutti i dispositivi (carta e altri supporti inclusi).
Devo dire: un po' deludente perché è indicato precisamente come fare la
cancellazione dei cellulari (con tanto di sequenza di comandi da seguire sui
vari sistemi disponibili), ma non quella degli hard disk o delle memorie
USB: non fornisce alcun suggerimento sugli strumenti da utilizzare e segnala
di seguire dei forum o dei siti nei quali non c'è nulla. Forse sono io che
ho sbagliato a cercare?
Dall'altra parte, segnalo che la maggior parte delle volte indica come
sufficiente una passata di zeri; altre volte suggerisce due o tre passaggi.
E se lo dice il NIST, forse è il caso che i fautori delle 7, delle 20 e
delle 37 volte si aggiornino (anche perché quella non è più "cancellazione",
ma "distruzione" del supporto; opzione comunque da scegliere nei casi di
dati particolarmente critici; ma un buon martello è più economico, più
veloce e spiritualmente più soddisfacente).
mercoledì 24 dicembre 2014
venerdì 19 dicembre 2014
Ricerca sulla criminalità informatica nelle PMI
Dalla mailing list di Sikurezza.org, segnalo questa ricerca dal titolo "La
criminalità informatica e i rischi per l'economia e le imprese a livello
italiano ed europeo". Non credo che aggiunga molto a quanto già si sa e a
studi già noti (peraltro la ricerca, molto correttamente, li cita), ma
fornisce qualche spunto di riflessione sulle nostre aziende.
La presentazione sulla pagina web è in inglese, mentre la pubblicazione e la
presentazione sono in italiano:
- http://www.unicri.it/in_focus/on/Cybercrime_risks_economy
criminalità informatica e i rischi per l'economia e le imprese a livello
italiano ed europeo". Non credo che aggiunga molto a quanto già si sa e a
studi già noti (peraltro la ricerca, molto correttamente, li cita), ma
fornisce qualche spunto di riflessione sulle nostre aziende.
La presentazione sulla pagina web è in inglese, mentre la pubblicazione e la
presentazione sono in italiano:
- http://www.unicri.it/in_focus/on/Cybercrime_risks_economy
Home banking: responsabilità parziale in caso di attacco
Enzo Ascione di Intesa Sanpaolo mi ha segnalato questa notizia: per il
tribunale di Caltanisetta, il fatto che l'accesso all'home banking avvenga
"solo" tramite user-id e password (nonostante comunque l'istituto bancario
abbia sollecitato ai clienti l'adozione di un meccanismo di OTP), fa sì che
un accesso abusivo al sistema sia da ritenere colpa dell'istituto bancario
perché avrebbe potuto anche mettere a disposizione un servizio di SMS o
simile.
Questo se ho capito correttamente gli articoli relativi alla sentenza. Ne
propongo due; nel secondo è possibile trovare un link alla sentenza
completa:
- http://www.quotidianodiritto.ilsole24ore.com/art/amministrativo/2014-11-26/c
olpa-parziale-se-cliente-non-nota-l-hacker--194747.php?uuid=ABZqZXIC;
- http://www.creditofinanzanews.it/2014/12/03/home-banking-responsabilita-parz
iale-del-cliente-che-non-nota-lhacker/
Trovo un po' inquietante il fatto che il giudice dica che la banca (ossia il
fornitore del servizio informatico) "non aveva dimostrato che il cliente non
aveva custodito con diligenza le credenziali d'accesso". Però, ancora una
volta, una sentenza che ribadisce la necessità di predisporre servizi sicuri
sia tecnicamente che funzionalmente.
tribunale di Caltanisetta, il fatto che l'accesso all'home banking avvenga
"solo" tramite user-id e password (nonostante comunque l'istituto bancario
abbia sollecitato ai clienti l'adozione di un meccanismo di OTP), fa sì che
un accesso abusivo al sistema sia da ritenere colpa dell'istituto bancario
perché avrebbe potuto anche mettere a disposizione un servizio di SMS o
simile.
Questo se ho capito correttamente gli articoli relativi alla sentenza. Ne
propongo due; nel secondo è possibile trovare un link alla sentenza
completa:
- http://www.quotidianodiritto.ilsole24ore.com/art/amministrativo/2014-11-26/c
olpa-parziale-se-cliente-non-nota-l-hacker--194747.php?uuid=ABZqZXIC;
- http://www.creditofinanzanews.it/2014/12/03/home-banking-responsabilita-parz
iale-del-cliente-che-non-nota-lhacker/
Trovo un po' inquietante il fatto che il giudice dica che la banca (ossia il
fornitore del servizio informatico) "non aveva dimostrato che il cliente non
aveva custodito con diligenza le credenziali d'accesso". Però, ancora una
volta, una sentenza che ribadisce la necessità di predisporre servizi sicuri
sia tecnicamente che funzionalmente.
mercoledì 17 dicembre 2014
Privacy e Dossier sanitario
Dal gruppo Clusit di LinkedIn è stato segnalato questo articolo che riguarda
le difficoltà di un'azienda sanitaria (AS9 ad adeguarsi alle disposizioni
del Garante privacy in materia di fascicolo sanitario elettronico (FSE) fino
a dire che si dovrà tornare alle cartelle di carta:
- http://altoadige.gelocal.it/bolzano/cronaca/2014/12/13/news/privacy-si-torna
-alle-cartelle-di-carta-1.10493365.
In realtà, l'articolo aiuta molto poco a capire. Ma si può consultare il
Provvedimento del Garante relativo a questa AS:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3325808
La storia: si scopre che una dipendente dell'ospedale consultava le cartelle
cliniche del proprio reparto, fino a diffondere la notizia della
sieropositività di un'altra collega. C'è un processo e si scopre che nella
ASL non c'è alcuna segregazione delle autorizzazioni di accesso alle
cartelle cliniche. Il Garante privacy, a luglio 2014 ha imposto all'AS il
recepimento delle misure di sicurezza per i fascicoli sanitari elettronici,
come previsto dalle "Linee guida in tema di Fascicolo sanitario elettronico
(Fse) e di dossier sanitario" del 16 luglio 2009 [doc web 1634116]. L'AS ha
poi chiesto una proroga dei tempi al Garante e ora sembra che non sia in
grado di completare l'attuazione delle misure.
La notizia mi ha colpito perché, nel Provvedimento del Garante, è scritto
che l'AS ha chiesto aiuto ad una società di consulenza nel 2013 (4 anni dopo
la pubblicazione delle linee guida e 6 anni dopo la costituzione dell'AS
dalla fusione di 4 AS pre-esistenti!): certamente la privacy non è stata una
priorità!
Altra notizia molto simile mi è arrivata da CINDI e riguarda invece l'Emilia
Romagna:
- http://www.privacyofficer.pro/dossier-sanitario-elettronico-a-prova-di-privacy/
le difficoltà di un'azienda sanitaria (AS9 ad adeguarsi alle disposizioni
del Garante privacy in materia di fascicolo sanitario elettronico (FSE) fino
a dire che si dovrà tornare alle cartelle di carta:
- http://altoadige.gelocal.it/bolzano/cronaca/2014/12/13/news/privacy-si-torna
-alle-cartelle-di-carta-1.10493365.
In realtà, l'articolo aiuta molto poco a capire. Ma si può consultare il
Provvedimento del Garante relativo a questa AS:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3325808
La storia: si scopre che una dipendente dell'ospedale consultava le cartelle
cliniche del proprio reparto, fino a diffondere la notizia della
sieropositività di un'altra collega. C'è un processo e si scopre che nella
ASL non c'è alcuna segregazione delle autorizzazioni di accesso alle
cartelle cliniche. Il Garante privacy, a luglio 2014 ha imposto all'AS il
recepimento delle misure di sicurezza per i fascicoli sanitari elettronici,
come previsto dalle "Linee guida in tema di Fascicolo sanitario elettronico
(Fse) e di dossier sanitario" del 16 luglio 2009 [doc web 1634116]. L'AS ha
poi chiesto una proroga dei tempi al Garante e ora sembra che non sia in
grado di completare l'attuazione delle misure.
La notizia mi ha colpito perché, nel Provvedimento del Garante, è scritto
che l'AS ha chiesto aiuto ad una società di consulenza nel 2013 (4 anni dopo
la pubblicazione delle linee guida e 6 anni dopo la costituzione dell'AS
dalla fusione di 4 AS pre-esistenti!): certamente la privacy non è stata una
priorità!
Altra notizia molto simile mi è arrivata da CINDI e riguarda invece l'Emilia
Romagna:
- http://www.privacyofficer.pro/dossier-sanitario-elettronico-a-prova-di-privacy/
Sicurezza IT nel settore energia
Dal Gruppo Clusit su LinkedIn segnalo questo whitepaper dedicato alla
sicurezza informatica nel settore "produzione":
- http://download.schneider-electric.com/library/downloads/WW/en/document/998-
2095-07-21-14AR0_EN
Ovviamente, è concentrato sul settore energia. Colgo allora l'occasione per
ricordare il Quaderno Clusit numero 7 dal titolo "Introduzione alla
protezione di reti e sistemi di controllo e automazione (DCS, SCADA, PLC,
ecc.)", che ho riletto recentemente e mi è sembrato molto utile, anche se
del 2007. Lo si può scaricare dal seguente link:
- http://www.clusit.it/download/index.htm
sicurezza informatica nel settore "produzione":
- http://download.schneider-electric.com/library/downloads/WW/en/document/998-
2095-07-21-14AR0_EN
Ovviamente, è concentrato sul settore energia. Colgo allora l'occasione per
ricordare il Quaderno Clusit numero 7 dal titolo "Introduzione alla
protezione di reti e sistemi di controllo e automazione (DCS, SCADA, PLC,
ecc.)", che ho riletto recentemente e mi è sembrato molto utile, anche se
del 2007. Lo si può scaricare dal seguente link:
- http://www.clusit.it/download/index.htm
Certificati digitali gratuiti
Su Crypto-Gram del 15 dicembre, Bruce Schneier ha segnalato una nuova
Certification Authority che fornisce certificati digitali gratuiti: Let's
Encrypt, progetto a cui partecipano EFF, Mozilla, Cisco, Akamai e
l'Università del Michigan.
Leggendo il blog di Bruce Schneier, alcuni partecipanti (con toni ovviamente
critici, come si conviene quando si partecipa a forum!) hanno segnalato
altre CA gratuite. Ecco quindi l'elenco:
- Let's Encrypt: https://letsencrypt.org;
- CAcert: http://wiki.cacert.org;
- StartSSL: https://cert.startcom.org.
Tutte offrono certificati per web server (Let's Encrypt propone anche
l'aggiornamento automatico); CAcert permette anche di usare dei certificati
per l'e-mail. Ovviamente non si tratta di certificati digitali utili per
apporre firme digitali come previsto dalla normativa italiana in vigore.
Qualche breve riflessione:
1- forse saranno meno numerosi i siti web con i certificati scaduti; c'è da
chiedersi perché vengono inizialmente attivate delle funzionalità di
sicurezza (cifratura con certificato digitale) per poi non mantenerle;
2- oggi quasi nessuno si preoccupa più di cifrare le e-mail e quindi,
ahinoi, non farà notizia la disponibilità di certificati digitali gratuiti
per questo servizio.
Certification Authority che fornisce certificati digitali gratuiti: Let's
Encrypt, progetto a cui partecipano EFF, Mozilla, Cisco, Akamai e
l'Università del Michigan.
Leggendo il blog di Bruce Schneier, alcuni partecipanti (con toni ovviamente
critici, come si conviene quando si partecipa a forum!) hanno segnalato
altre CA gratuite. Ecco quindi l'elenco:
- Let's Encrypt: https://letsencrypt.org;
- CAcert: http://wiki.cacert.org;
- StartSSL: https://cert.startcom.org.
Tutte offrono certificati per web server (Let's Encrypt propone anche
l'aggiornamento automatico); CAcert permette anche di usare dei certificati
per l'e-mail. Ovviamente non si tratta di certificati digitali utili per
apporre firme digitali come previsto dalla normativa italiana in vigore.
Qualche breve riflessione:
1- forse saranno meno numerosi i siti web con i certificati scaduti; c'è da
chiedersi perché vengono inizialmente attivate delle funzionalità di
sicurezza (cifratura con certificato digitale) per poi non mantenerle;
2- oggi quasi nessuno si preoccupa più di cifrare le e-mail e quindi,
ahinoi, non farà notizia la disponibilità di certificati digitali gratuiti
per questo servizio.
NIST SP 800-53 - Assessing Security
Il NIST ha pubblicato la versione 4 della "Special Publication (SP) 800-53
A, Assessing Security and Privacy Controls in Federal Information Systems
and Organizations: Building Effective Assessment Plans".
Il link:
- http://csrc.nist.gov/publications/PubsSPs.html#800-53ar4
Si tratta di un librone in pdf di 487 pagine. Di queste, quasi 400
costituiscono l'elenco dei controlli da verificare. Si tratta quindi di una
lettura quanto meno esaustiva.
A, Assessing Security and Privacy Controls in Federal Information Systems
and Organizations: Building Effective Assessment Plans".
Il link:
- http://csrc.nist.gov/publications/PubsSPs.html#800-53ar4
Si tratta di un librone in pdf di 487 pagine. Di queste, quasi 400
costituiscono l'elenco dei controlli da verificare. Si tratta quindi di una
lettura quanto meno esaustiva.
martedì 16 dicembre 2014
Richieste di responsabili sicurezza
Dal Crypto-gram di dicembre, segnalo questa notizia che traduco:
<< Questo articolo segnala che le richieste di Chief Information Security Officers eccede di gran lunga l'offerta:
Non ho neanche verificato l'articolo, ma mi pare interessante il commento di Bruce Schneier, che sottoscrivo per quanto mi riguarda: << Non mi sorprende. E' un lavoro duro: budget sempre insufficiente, e si è sempre criticati quando si è inevitabilmente attaccati. E richiede un insieme difficile di competenze: abbastanza competenze tecniche per capire la sicurezza IT e sufficienti abilità gestionali per navigare tra i dirigenti. Non vorrei mai un lavoro così>>.
venerdì 12 dicembre 2014
Aggiornamento sul Regolamento europeo sulla privacy
Alessandro Cosenza di BTicino mi ha segnalato il seguente articolo:
- http://www.diritto24.ilsole24ore.com/art/avvocatoAffari/mercatiImpresa/2014-
12-11/regolamento-europeo-privacy-ancora-discussione-162857.php
Riassumo: bisogna aspettare e non fare nulla, al momento, poiché l'entrata
in vigore richiederà almeno 2 anni e mezzo. Insomma, le stesse cose che vado
dicendo da tempo, ma in modo molto più preciso.
Comunque, se e quando sarà approvato questo Regolamento, spero che tutti si
ricordino dei cosiddetti esperti che ne hanno annunciato l'approvazione nel
2013, poi a inizio 2014, poi a fine 2014, e così via. Tutto per vendere
corsi e consulenze basate sul "forse".
- http://www.diritto24.ilsole24ore.com/art/avvocatoAffari/mercatiImpresa/2014-
12-11/regolamento-europeo-privacy-ancora-discussione-162857.php
Riassumo: bisogna aspettare e non fare nulla, al momento, poiché l'entrata
in vigore richiederà almeno 2 anni e mezzo. Insomma, le stesse cose che vado
dicendo da tempo, ma in modo molto più preciso.
Comunque, se e quando sarà approvato questo Regolamento, spero che tutti si
ricordino dei cosiddetti esperti che ne hanno annunciato l'approvazione nel
2013, poi a inizio 2014, poi a fine 2014, e così via. Tutto per vendere
corsi e consulenze basate sul "forse".
giovedì 11 dicembre 2014
Regolamento UE 910 del 2014 e CAD
Franco Ferrari del DNV GL mi ha segnalato il Regolamento UE 910 del 2014 "in materia di identificazione elettronica e servizi fiduciari per le transazioni elettroniche nel mercato interno e che abroga la direttiva1999/93/CE". Esso è noto anche come eIDAS "electronic IDentification Authentication and Signature" e disciplina le modalità di apposizione della firma elettronica a convalida di documenti con valore probatorio. Il regolamento è entrato in vigore dal 17 settembre e sarà applicabile dal 1° luglio 2016.
I "servizi fiduciari" riguardano il mutuo riconoscimento attraverso mezzi elettronici e sono: firme elettroniche, sigilli elettronici, marche temporali, servizi di consegna, autenticazione di siti web".
Su http://eur-lex.europa.eu/ è possibile ricercarlo e scaricarlo.
Ho chiesto aiuto a Franco Ruggieri che mi ha scritto quanto segue. << La UE ha fatto una cosa buona: adeguare le normative sulla firma elettronica, stabilite nel lontano 1999 con la Direttiva 1999/993/CE. Con questo Regolamento UE 910/2014 si aggiorna qualche cosa sulle firme elettroniche, si inseriscono i "sigilli elettronici", cioè le firme elettroniche delle persone giuridiche, si apre la strada a qualcosa che assomiglia alla nostra PEC, si parla di time stamping, di authentication, e roba del genere.
Inoltre, sulla base dei pasticci dovuti alle diverse interpretazioni della Direttiva 1999/93/CE, hanno deciso di emettere un Regolamento. A differenza di una Direttiva, che deve essere recepita dagli Stati Membri della UE, un Regolamento entra in vigore automaticamente in tutti gli EUMS, il che dovrebbe consentire finalmente l'interoperabilità. E, poiché un Regolamento non può che essere una specie di legge primaria, stanno già lavorando intensamente agli implementing acts (atti attuativi). >>
A questo punto gli ho chiesto cosa ne sarebbe stato del Dlgs 82/2005, ossia il CAD (Codice dell'Amministrazione Digitale). La risposta: << Il CAD non sarà abrogato, perché tratta sì di eIDAS, ma anche di altre cose. Alcune parti dovranno essere eliminate o modificate. Dobbiamo avere notizie da AgID>>.
Ho chiesto lumi anche ad Andrea Caccia, nella speranza di mettere insieme più risposte e, forse, capirci qualcosa. Andrea dice che <<se il Parlamento non modifica il CAD, dal 1 luglio 2016 ci penserà il Regolamento a farne uno spezzatino: resterà in vigore solo ciò che non è in contrasto col Regolamento>>.
Andrea ha anche illustrato, in occasione della 10a riunione del SC27 di UNINFO alcune slide, confermando la partecipazione ai lavori di ETSI (ai cui lavori partecipa, tra gli altri, proprio Andrea Caccia).
Anche il sotto-comitato ISO/IEC JTC1 SC27 ha stabilito di occuparsi della materia con l'aggiornamento di un vecchio Technical Report del WG4, il TR14516 col nuovo titolo "Guidelines for use and management of Trust Service Provider"
Una cosa che mi sono segnato dalla presentazione di Andrea Caccia è questa: in base all'articolo 20 del Regolamento, "I prestatori di servizi fiduciari qualificati sono sottoposti, a proprie spese almeno ogni 24 mesi, a una verifica da parte di un organismo di valutazione della conformità" ... "ai sensi... del regolamento (CE) n. 765/2008 accreditato a... effettuare la valutazione della conformità del prestatore di servizi fiduciari qualificato e dei servizi fiduciari qualificati da esso prestati", "in base agli standard che la Commissione indicherà nei propri decreti attuativi in base all'articolo 20 (3)".
In Italia, quindi, Accredia dovrebbe promuovere questo schema di certificazione dei Trust service providers (TSP). Nulla impedisce di affidarsi ad organismi accreditati da altri organismi non italiani. EA (European Cooperation for Accreditation), a cui Accredia aderisce, ha già approvato un piano di migrazione predisposto da ETSI. Gli organismi di accreditamento si devono predisporre tra novembre 2014 e maggio 2015, mentre gli organismi di certificazione dovranno migrare da giugno 2015 a luglio 2016 (si preferiscono organismi con già esperienza di certificazioni rilasciate su standard ETSI). Ne vedremo delle belle...
Per intanto, Andrea suggerisce di leggere la presentazione di Riccardo Bianconi del 1 dicembre, che si può trovare a questo link (poi cliccare su "Convegno - Roma, 1 e 2 dicembre 2014"; anche le altre presentazioni sono di interesse):
- http://www.euronotaries.eu/news-ed-eventi/rassegna-stampa/
I "servizi fiduciari" riguardano il mutuo riconoscimento attraverso mezzi elettronici e sono: firme elettroniche, sigilli elettronici, marche temporali, servizi di consegna, autenticazione di siti web".
Su http://eur-lex.europa.eu/ è possibile ricercarlo e scaricarlo.
Ho chiesto aiuto a Franco Ruggieri che mi ha scritto quanto segue. << La UE ha fatto una cosa buona: adeguare le normative sulla firma elettronica, stabilite nel lontano 1999 con la Direttiva 1999/993/CE. Con questo Regolamento UE 910/2014 si aggiorna qualche cosa sulle firme elettroniche, si inseriscono i "sigilli elettronici", cioè le firme elettroniche delle persone giuridiche, si apre la strada a qualcosa che assomiglia alla nostra PEC, si parla di time stamping, di authentication, e roba del genere.
Inoltre, sulla base dei pasticci dovuti alle diverse interpretazioni della Direttiva 1999/93/CE, hanno deciso di emettere un Regolamento. A differenza di una Direttiva, che deve essere recepita dagli Stati Membri della UE, un Regolamento entra in vigore automaticamente in tutti gli EUMS, il che dovrebbe consentire finalmente l'interoperabilità. E, poiché un Regolamento non può che essere una specie di legge primaria, stanno già lavorando intensamente agli implementing acts (atti attuativi). >>
A questo punto gli ho chiesto cosa ne sarebbe stato del Dlgs 82/2005, ossia il CAD (Codice dell'Amministrazione Digitale). La risposta: << Il CAD non sarà abrogato, perché tratta sì di eIDAS, ma anche di altre cose. Alcune parti dovranno essere eliminate o modificate. Dobbiamo avere notizie da AgID>>.
Ho chiesto lumi anche ad Andrea Caccia, nella speranza di mettere insieme più risposte e, forse, capirci qualcosa. Andrea dice che <<se il Parlamento non modifica il CAD, dal 1 luglio 2016 ci penserà il Regolamento a farne uno spezzatino: resterà in vigore solo ciò che non è in contrasto col Regolamento>>.
Andrea ha anche illustrato, in occasione della 10a riunione del SC27 di UNINFO alcune slide, confermando la partecipazione ai lavori di ETSI (ai cui lavori partecipa, tra gli altri, proprio Andrea Caccia).
Anche il sotto-comitato ISO/IEC JTC1 SC27 ha stabilito di occuparsi della materia con l'aggiornamento di un vecchio Technical Report del WG4, il TR14516 col nuovo titolo "Guidelines for use and management of Trust Service Provider"
Una cosa che mi sono segnato dalla presentazione di Andrea Caccia è questa: in base all'articolo 20 del Regolamento, "I prestatori di servizi fiduciari qualificati sono sottoposti, a proprie spese almeno ogni 24 mesi, a una verifica da parte di un organismo di valutazione della conformità" ... "ai sensi... del regolamento (CE) n. 765/2008 accreditato a... effettuare la valutazione della conformità del prestatore di servizi fiduciari qualificato e dei servizi fiduciari qualificati da esso prestati", "in base agli standard che la Commissione indicherà nei propri decreti attuativi in base all'articolo 20 (3)".
In Italia, quindi, Accredia dovrebbe promuovere questo schema di certificazione dei Trust service providers (TSP). Nulla impedisce di affidarsi ad organismi accreditati da altri organismi non italiani. EA (European Cooperation for Accreditation), a cui Accredia aderisce, ha già approvato un piano di migrazione predisposto da ETSI. Gli organismi di accreditamento si devono predisporre tra novembre 2014 e maggio 2015, mentre gli organismi di certificazione dovranno migrare da giugno 2015 a luglio 2016 (si preferiscono organismi con già esperienza di certificazioni rilasciate su standard ETSI). Ne vedremo delle belle...
Per intanto, Andrea suggerisce di leggere la presentazione di Riccardo Bianconi del 1 dicembre, che si può trovare a questo link (poi cliccare su "Convegno - Roma, 1 e 2 dicembre 2014"; anche le altre presentazioni sono di interesse):
- http://www.euronotaries.eu/news-ed-eventi/rassegna-stampa/
venerdì 28 novembre 2014
ISO/IEC 27040 - Storage security
A breve sarà pubblicata la ISO/IEC 27040 dal titolo "Information technology
─ Security techniques ― Storage security". Si tratta di un libro di 122
pagine in totale, con molte cose tecniche interessanti.
Si potrà trovare sul sito dell'ISO: www.iso.org
─ Security techniques ― Storage security". Si tratta di un libro di 122
pagine in totale, con molte cose tecniche interessanti.
Si potrà trovare sul sito dell'ISO: www.iso.org
Social Network assimilato a luogo pubblico
Segnalo questo articolo a sua volta segnalatomi da Pasquale Stirparo sulla
lista di discussione della DFA:
- http://thinkinginforensics.net/2014/11/social-network-assimilato-ad-un-luogo
-aperto-al-pubblico/
In sintesi: La Corte di Cassazione ha assimilato una pagina (visibile a
chiunque sia registrato) di un social network come un luogo aperto al
pubblico, quindi idoneo alla configurabilità del reato di molestie o
disturbo alle persone.
Non è la prima volta che segnalo questa notizia (e, anzi, penso sia lo
stesso caso attraverso i vari gradi di giudizio), ma questa volta la
sentenza è della Corte di Cassazione.
lista di discussione della DFA:
- http://thinkinginforensics.net/2014/11/social-network-assimilato-ad-un-luogo
-aperto-al-pubblico/
In sintesi: La Corte di Cassazione ha assimilato una pagina (visibile a
chiunque sia registrato) di un social network come un luogo aperto al
pubblico, quindi idoneo alla configurabilità del reato di molestie o
disturbo alle persone.
Non è la prima volta che segnalo questa notizia (e, anzi, penso sia lo
stesso caso attraverso i vari gradi di giudizio), ma questa volta la
sentenza è della Corte di Cassazione.
giovedì 27 novembre 2014
ISO/IEC 27018 - Code of practice for PII protection in public clouds acting as PII processors
L' Istituto Italiano Privacy e Alessandro Cosenza di BTicino mi hanno
informato dell'uscita dello standard ISO/IEC 27018 "Code of practice for PII
protection in public clouds acting as PII processors". L'articolo
dell'Istituto:
- http://www.istitutoitalianoprivacy.it/it/dati-personali-e-cloud-computing-ad
esso-la-nuvola-ha-il-suo-standard/
La ISO/IEC 27018 presenta alcuni requisiti aggiuntivi rispetto alla ISO/IEC
27002 applicabili ai fornitori di servizi cloud.
Personalmente, non mi pare un documento particolarmente illuminante. Ma è
un'opinione personale.
informato dell'uscita dello standard ISO/IEC 27018 "Code of practice for PII
protection in public clouds acting as PII processors". L'articolo
dell'Istituto:
- http://www.istitutoitalianoprivacy.it/it/dati-personali-e-cloud-computing-ad
esso-la-nuvola-ha-il-suo-standard/
La ISO/IEC 27018 presenta alcuni requisiti aggiuntivi rispetto alla ISO/IEC
27002 applicabili ai fornitori di servizi cloud.
Personalmente, non mi pare un documento particolarmente illuminante. Ma è
un'opinione personale.
VA, sicurezza e OWASP - Contributo 2
Enos D'Andrea, in merito alle mie piccole critiche sull'uso di OWASP e,
soprattutto, sul fatto che la sicurezza applicativa si riduce ai test, mi ha
segnalato una pagina dell'OWASP Top 10 dal titolo "What's Next for
Organizations".
Qui sono scritte cose molto interessanti che richiedono appunto di non
ridurre ai soli test la sicurezza applicativa. Infatti richiede di "porre
delle basi solide", e tra queste vi sono "politiche e standard per gli
sviluppatori, guide per la progettazione e lo sviluppo, formazione". Nella
pagina "What's Next for Developers" si richiede di "progettare la sicurezza
fin dall'inizio".
Raccomando quindi di rileggere la "OWASP Top 10 - 2013" senza fermarsi a
pagina 16, ma proseguendo fino a pagina 27. Trovate la guida sul sito
dell'OWASP:
- https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
soprattutto, sul fatto che la sicurezza applicativa si riduce ai test, mi ha
segnalato una pagina dell'OWASP Top 10 dal titolo "What's Next for
Organizations".
Qui sono scritte cose molto interessanti che richiedono appunto di non
ridurre ai soli test la sicurezza applicativa. Infatti richiede di "porre
delle basi solide", e tra queste vi sono "politiche e standard per gli
sviluppatori, guide per la progettazione e lo sviluppo, formazione". Nella
pagina "What's Next for Developers" si richiede di "progettare la sicurezza
fin dall'inizio".
Raccomando quindi di rileggere la "OWASP Top 10 - 2013" senza fermarsi a
pagina 16, ma proseguendo fino a pagina 27. Trovate la guida sul sito
dell'OWASP:
- https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
mercoledì 26 novembre 2014
Provvedimento Garante biometria (e firma grafometrica)
Mi segnala Pierfrancesco Maistrello di Vecomp che è appena uscito il
Provvedimento definitivo del Garante privacy su biometria:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3556992
Pierfrancesco commenta: "è scomparso il riferimento alla ISO/IEC 15408 per i
sistemi di firma grafometrica, ma è comparso un interessante modulino di
notifica data breach".
Io invece ho notato il seguente periodo: "I titolari dotati di
certificazione del sistema di gestione per la sicurezza delle informazioni
(SGSI) secondo la norma tecnica UNI CEI ISO/IEC 27001:2005 e successive
modificazioni..." perché la norma citata non è mai esistita (esitono invece
la ISO/IEC 27001:2005 e la UNI CEI ISO/IEC 27001:2006), cosa che segnalai
quando si potevano inviare commenti. Ma io mi chiedo: chi sono i consulenti
del Garante? perché il Garante non si interfaccia con UNINFO? perché questa
autoreferenzialità? Comunque oggi bisognerà usare la ISO/IEC 27001:2013 (o
la UNI CEI ISO/IEC 27001:2014).
Segnalo anche questo articolo di riassunto:
- http://lamiaprivacy.wordpress.com/2014/12/07/provvedimento-e-linee-guida-in-materia-di-biometria-12-11-2014/
Provvedimento definitivo del Garante privacy su biometria:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3556992
Pierfrancesco commenta: "è scomparso il riferimento alla ISO/IEC 15408 per i
sistemi di firma grafometrica, ma è comparso un interessante modulino di
notifica data breach".
Io invece ho notato il seguente periodo: "I titolari dotati di
certificazione del sistema di gestione per la sicurezza delle informazioni
(SGSI) secondo la norma tecnica UNI CEI ISO/IEC 27001:2005 e successive
modificazioni..." perché la norma citata non è mai esistita (esitono invece
la ISO/IEC 27001:2005 e la UNI CEI ISO/IEC 27001:2006), cosa che segnalai
quando si potevano inviare commenti. Ma io mi chiedo: chi sono i consulenti
del Garante? perché il Garante non si interfaccia con UNINFO? perché questa
autoreferenzialità? Comunque oggi bisognerà usare la ISO/IEC 27001:2013 (o
la UNI CEI ISO/IEC 27001:2014).
Segnalo anche questo articolo di riassunto:
- http://lamiaprivacy.wordpress.com/2014/12/07/provvedimento-e-linee-guida-in-materia-di-biometria-12-11-2014/
VA, sicurezza e OWASP
Stefano Ramacciotti commenta il mio articolo "I VA sono la sicurezza
applicativa?":
- http://blog.cesaregallotti.it/2014/11/i-va-sono-la-sicurezza-applicativa.html
Stefano, leggendo il mio commento "in molti riducono il tutto non solo ai
VA, ma alle sole vulnerabilità Top 10 segnalate da OWASP", commenta quanto
segue:
“la cosa ancora più grave è che OWASP si riferisce alle sole web applications, ma se un'applicazione non è web? Ci sarebbero i "CWE/SANS TOP 25 Most Dangerous Software Errors" (http://www.sans.org/top25-software-errors/), e potrebbe essere d’aiuto l’elenco su http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html, ma in molti sembrano non conoscerli.
Con questo nessuno vuole disconoscere l’enorme importanza di OWASP. Diciamo solo che di OWASP se ne avvantaggiano i soli sviluppatori web, che forse sono anche la maggioranza, ma non tutti gli altri.
applicativa?":
- http://blog.cesaregallotti.it/2014/11/i-va-sono-la-sicurezza-applicativa.html
Stefano, leggendo il mio commento "in molti riducono il tutto non solo ai
VA, ma alle sole vulnerabilità Top 10 segnalate da OWASP", commenta quanto
segue:
“la cosa ancora più grave è che OWASP si riferisce alle sole web applications, ma se un'applicazione non è web? Ci sarebbero i "CWE/SANS TOP 25 Most Dangerous Software Errors" (http://www.sans.org/top25-software-errors/), e potrebbe essere d’aiuto l’elenco su http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html, ma in molti sembrano non conoscerli.
Con questo nessuno vuole disconoscere l’enorme importanza di OWASP. Diciamo solo che di OWASP se ne avvantaggiano i soli sviluppatori web, che forse sono anche la maggioranza, ma non tutti gli altri.
Inoltre
ci si dimentica che la Top 10 di OWASP elenca solo le prime dieci
vulnerabilità, ma non è che ce ne siano solo 10, in realtà ce ne sono molte di
più. Lo stesso sito di OWASP ne riporta anche altre che però sono meno
visibili e forse meno tenute in considerazione dagli sviluppatori".
martedì 25 novembre 2014
Certificazioni privacy e Europa
Alessandro Cosenza di BTicino mi ha segnalato il Bando di concorso
dell'Ufficio europeo di selezione del personale (EPSO) per amministratori
(AD 6) nel settore della protezione dei dati:
- http://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=OJ:C:2014:391A:FULL&
from=EN
La cosa interessante è la richiesta di formazione. E' infatti richiesta "Una
formazione certificata in materia di protezione dei dati (IAPP, EIPA, GDD o
equivalente, conseguita a seguito di esami)".
La cosa è interessante perché il tutto è lasciato molto all'interpretazione,
oltre a ridurre gli organismi di certificazione a 3 (come interpretare il
termine "equivalente"?).
Il primo è l'IAPP che offre ben 3 certificazioni ed è un'associazione USA
(non europea!):
- https://privacyassociation.org/certify/programs/
Il secondo è l'EIPA, forse il più istituzionale, supportato economicamente
dall'Unione Europea (ma temo sia un organismo privato). Il catalogo presenta
diversi corsi, il cui più interessante potrebbe essere quello per "Training
and Certification Programme for Data Protection Officers and Other Data
Protection Professionals - Basic and Advanced Module".
- http://www.eipa.eu/en/pages/display/&tid=152
L'ultimo (GDD) è la German Association for Data Protection and Data
Security. E questo la dice lunga su come è orientata l'Europa, anche per
quanto riguarda la sicurezza delle informazioni. Io poi sul sito non ho
trovato proposte di certificazione:
- https://www.gdd.de/international/english
dell'Ufficio europeo di selezione del personale (EPSO) per amministratori
(AD 6) nel settore della protezione dei dati:
- http://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=OJ:C:2014:391A:FULL&
from=EN
La cosa interessante è la richiesta di formazione. E' infatti richiesta "Una
formazione certificata in materia di protezione dei dati (IAPP, EIPA, GDD o
equivalente, conseguita a seguito di esami)".
La cosa è interessante perché il tutto è lasciato molto all'interpretazione,
oltre a ridurre gli organismi di certificazione a 3 (come interpretare il
termine "equivalente"?).
Il primo è l'IAPP che offre ben 3 certificazioni ed è un'associazione USA
(non europea!):
- https://privacyassociation.org/certify/programs/
Il secondo è l'EIPA, forse il più istituzionale, supportato economicamente
dall'Unione Europea (ma temo sia un organismo privato). Il catalogo presenta
diversi corsi, il cui più interessante potrebbe essere quello per "Training
and Certification Programme for Data Protection Officers and Other Data
Protection Professionals - Basic and Advanced Module".
- http://www.eipa.eu/en/pages/display/&tid=152
L'ultimo (GDD) è la German Association for Data Protection and Data
Security. E questo la dice lunga su come è orientata l'Europa, anche per
quanto riguarda la sicurezza delle informazioni. Io poi sul sito non ho
trovato proposte di certificazione:
- https://www.gdd.de/international/english
giovedì 20 novembre 2014
Errata corrige: Poodle non Poddle
Enos D'Andrea mi ha fatto notare che ho scritto più volte Poddle al posto di
Poodle. Me ne scuso con i lettori.
Enos aggiunge anche che, per contrastare Poodle, la soluzione in SSL3
consiste nel disabilitare i block cyphers e lasciare solo gli stream
cyphers.
Poodle. Me ne scuso con i lettori.
Enos aggiunge anche che, per contrastare Poodle, la soluzione in SSL3
consiste nel disabilitare i block cyphers e lasciare solo gli stream
cyphers.
domenica 16 novembre 2014
UNI EN ISO 22301:2014 - Errata corrige
Franco Ferrari di DNV GL mi ha fatto notare che la UNI EN ISO 22301:2014 non
è in italiano, ma solo in inglese. Pertanto è uguale alla ISO 22301:2012.
Mi scuso per l'errore. Avevo dato per scontato che il recepimento italiano
della norma comprendesse la traduzione, visto che so che alcune persone ci
stavano lavorando.
è in italiano, ma solo in inglese. Pertanto è uguale alla ISO 22301:2012.
Mi scuso per l'errore. Avevo dato per scontato che il recepimento italiano
della norma comprendesse la traduzione, visto che so che alcune persone ci
stavano lavorando.
I VA sono la sicurezza applicativa?
Negli ultimi tempi ho notato che a fronte della domanda
"come assicurate la sicurezza delle applicazioni?" mi viene risposto:
"facciamo dei vulnerability assessment, dei penetration test e delle code
review". Peccato che queste pratiche siano realizzate a fine lavori (in
rari casi, anche in fasi intermedie), mentre la sicurezza andrebbe considerata
sin dall'inizio, quando si stabiliscono i requisiti funzionali, si progetta il
software e la sua architettura e si scelgono gli strumenti di sviluppo e i
compilatori; un poco dopo, ma sempre prima dei VA-PT-CR, si dovrebbero
stabilire degli standard di codifica.
Perché quindi in molti riducono la sicurezza applicativa
ai VA-PT-CR? Provo con delle deduzioni, ma è bene precisare che si applicano a
coloro che veramente intendono assicurare un buon livello di sicurezza alle
applicazioni; non è questa un riflessione sul perché molti non si interessano all'argomento.
In molti riducono la sicurezza applicativa ai VA-PT-CR
perché:
1- i venditori dei servizi di VA-PT-CR sono molto più
bravi dei venditori dei servizi di sicurezza a supporto dell'analisi,
progettazione, sviluppo e realizzazione dei software;
2- quasi nessuno offre buoni servizi di sicurezza a
supporto dell'analisi, progettazione, sviluppo e realizzazione dei software; i
tecnici migliori e più preparati si dedicano a fare VA-PT-CR, anche per
attitudine (è molto più divertente cercare di bucare un'applicazione che
scrivere documenti o scrivere codice); questa non è una critica, ma una presa
d'atto delle diverse attitudini di ciascuno;
3- in effetti, chi offre servizi di sicurezza a supporto dell'analisi,
progettazione, sviluppo e realizzazione dei software o è un consulente con pochissima
conoscenza tecnica dello sviluppo (e quindi si limita a dire "individuate
i requisiti di sicurezza fin dalla fase di analisi" senza poi dare
ulteriori consigli), oppure riduce il tutto all'OWASP Top 10 (che riguarda
alcuni aspetti della progettazione e non dell'analisi e dello sviluppo);
4- gli sviluppatori sono orientati a realizzare
funzionalità, non la sicurezza; quindi è ben lontano dalla loro mentalità
affrontare questo argomento sin dall'inizio;
5- i libri che trattano di questi argomenti sono
pochissimi, molto voluminosi e molto costosi; ottime scuse per evitare di
affrontarli, sia per gli sviluppatori (che quindi preferiscono affidarsi ad
esterni che, per il punto 1, vendono solo VA-PT-CR) sia per i consulenti (che
vendono già altri servizi più "di moda" senza doversi impegnare in
una nuova materia difficile e poco richiesta).
Per dimostrare ulteriormente il punto 2, si osservi
l'andamento dei progetti OWASP (owasp.org): la testing guide è stata aggiornata
nel 2007, 2008 e 2014. La development guide, invece, è stata scritta
inizialmente nel 2002, aggiornata nel 2005 e poi basta, anche se da diverso
tempo stanno lavorando ad una nuova versione.
sabato 8 novembre 2014
Messaggistica sicura
Dal gruppo Italian Security Professional di LinkedIn giro questo link:
- https://www.eff.org/secure-messaging-scorecard
Mette a confronto la sicurezza degli strumenti di messaggistica. Accanto a
quelli molto noti come Whatsup, Skype e Viber, ce ne sono altri molto più
sicuri.
- https://www.eff.org/secure-messaging-scorecard
Mette a confronto la sicurezza degli strumenti di messaggistica. Accanto a
quelli molto noti come Whatsup, Skype e Viber, ce ne sono altri molto più
sicuri.
Nogotofail
Dal gruppo infotechlegale.it di LinkedIn giro la notizia: Google ha
pubblicato uno strumento di verifica della sicurezza della rete denominato
Nogotofail. Sembra essere dedicato alle vulnerabilità relative a TLS/SSL:
- https://github.com/google/nogotofail
Sarebbe interessante vedere se saranno pubblicate delle estensioni per un
maggiore controllo della sicurezza di altri aspetti.
Chiedo ai lettori come questo strumento si affianca a un Nessus (o, meglio,
OpenVAS che è gratuito): da quanto ho studiato, dovrebbe rilevare queste e
altre vulnerabilità.
pubblicato uno strumento di verifica della sicurezza della rete denominato
Nogotofail. Sembra essere dedicato alle vulnerabilità relative a TLS/SSL:
- https://github.com/google/nogotofail
Sarebbe interessante vedere se saranno pubblicate delle estensioni per un
maggiore controllo della sicurezza di altri aspetti.
Chiedo ai lettori come questo strumento si affianca a un Nessus (o, meglio,
OpenVAS che è gratuito): da quanto ho studiato, dovrebbe rilevare queste e
altre vulnerabilità.
mercoledì 5 novembre 2014
Istituti di vigilanza privati: DM 115 del 2014 e certificazione
Copio e incollo dal sito di DNV GL quanto segue.
Secondo il nuovo decreto n.115/2014, gli istituti di vigilanza privati per
poter operare devono obbligatoriamente ottenere il certificato di conformità
dei propri servizi, impianti e professionisti secondo le norme UNI 10891
(istituti di vigilanza privata); UNI 50518 (centri di monitoraggio) e 10459
(professionista della security), da parte di un organismo di certificazione
accreditato da un Ente designato, quale Accredia in Italia.
Il decreto ministeriale prevede un passaggio immediato per le nuove licenze
e nuovi istituti e una transizione di 36 mesi per chi è già certificato per
le disposizioni del precedente decreto 269 del 2010.
Ricordo che la vigilanza e la sicurezza fisica sono controlli importanti per
assicurare la sicurezza alle informazioni.
La pagina del sito di DNV GL:
-
http://www.dnvba.com/it/information-resources/news/Pages/Servizi_Vigilanza_P
rivati.aspx
Secondo il nuovo decreto n.115/2014, gli istituti di vigilanza privati per
poter operare devono obbligatoriamente ottenere il certificato di conformità
dei propri servizi, impianti e professionisti secondo le norme UNI 10891
(istituti di vigilanza privata); UNI 50518 (centri di monitoraggio) e 10459
(professionista della security), da parte di un organismo di certificazione
accreditato da un Ente designato, quale Accredia in Italia.
Il decreto ministeriale prevede un passaggio immediato per le nuove licenze
e nuovi istituti e una transizione di 36 mesi per chi è già certificato per
le disposizioni del precedente decreto 269 del 2010.
Ricordo che la vigilanza e la sicurezza fisica sono controlli importanti per
assicurare la sicurezza alle informazioni.
La pagina del sito di DNV GL:
-
http://www.dnvba.com/it/information-resources/news/Pages/Servizi_Vigilanza_P
rivati.aspx
ISO Survey 2013
E' stata pubblicata la ISO Survey del 2013, relativa alla diffusione nel
mondo dei certificati ISO 9001 (qualità), ISO 14001 (ambiente), ISO 50001
(energia), ISO/IEC 27001 (sicurezza delle informazioni), ISO 22000
(sicurezza alimentare), ISO/TS 16949 (qualità nel settore Automotive) e ISO
13485 (qualità dei dispositivi medici):
- http://www.iso.org/iso/home/standards/certification/iso-survey.htm
Dalla pagina dell'ISO è possibile scaricare l'executive summary e i dati di
dettaglio. Vedo anche che l'Italia ha "ben" 901 certificati ISO/IEC 27001 e
si colloca al quinto posto (dopo Giappone, India, UK e Cina).
La notizia me l'ha fornita la newsletter del DNV GL:
-
http://www.dnvba.com/it/information-resources/news/Pages/iso-survey-2013.aspx
mondo dei certificati ISO 9001 (qualità), ISO 14001 (ambiente), ISO 50001
(energia), ISO/IEC 27001 (sicurezza delle informazioni), ISO 22000
(sicurezza alimentare), ISO/TS 16949 (qualità nel settore Automotive) e ISO
13485 (qualità dei dispositivi medici):
- http://www.iso.org/iso/home/standards/certification/iso-survey.htm
Dalla pagina dell'ISO è possibile scaricare l'executive summary e i dati di
dettaglio. Vedo anche che l'Italia ha "ben" 901 certificati ISO/IEC 27001 e
si colloca al quinto posto (dopo Giappone, India, UK e Cina).
La notizia me l'ha fornita la newsletter del DNV GL:
-
http://www.dnvba.com/it/information-resources/news/Pages/iso-survey-2013.aspx
martedì 4 novembre 2014
UNI EN ISO 22301:2014
Franco Ferrari di DNV GL mi informa che il giorno 11-09-2014 è stata
pubblicata la UNI EN ISO 22301:2014.
- http://store.uni.com/magento-1.4.0.1/index.php/uni-en-iso-22301-2014.html
Si tratta della versione ufficiale in lingua inglese della norma europea EN
ISO 22301 (edizione luglio 2014), che a sua volta è il recepimento della ISO
22301:2012.
Nulla cambia tra le diverse versioni, a parte, ovviamente, che la UNI è in
italiano e non in inglese.
Post scriptum: la UNI EN ISO 22301 in realtà non è in italiano e ne ho scritto un errata corrige: http://blog.cesaregallotti.it/2014/11/uni-en-iso-223012014-errata-corrige.html. Mi lascia perplesso perché io, anni fa, avevo visto una bozza di traduzione.
pubblicata la UNI EN ISO 22301:2014.
- http://store.uni.com/magento-1.4.0.1/index.php/uni-en-iso-22301-2014.html
Si tratta della versione ufficiale in lingua inglese della norma europea EN
ISO 22301 (edizione luglio 2014), che a sua volta è il recepimento della ISO
22301:2012.
Nulla cambia tra le diverse versioni, a parte, ovviamente, che la UNI è in
italiano e non in inglese.
Post scriptum: la UNI EN ISO 22301 in realtà non è in italiano e ne ho scritto un errata corrige: http://blog.cesaregallotti.it/2014/11/uni-en-iso-223012014-errata-corrige.html. Mi lascia perplesso perché io, anni fa, avevo visto una bozza di traduzione.
lunedì 3 novembre 2014
Stato delle norme ISO/IEC 270xx
Venerdì 24 ottobre si è concluso a Santa Fe (Messico) il 49mo meeting
dell'SC 27 dell'ISO/IEC JTC 1. Purtroppo, causa cancellazione del volo, non
ho potuto partecipare. A rappresentare l'Italia c'erano solo Fabio Guasconi
(Presidente SC 27 italiano) e Andrea Caccia.
Provo comunque, sulla base del documento finale "WG 1 Recommendations,
Resolutions and Acclamations", ad indicare lo stato di avanzamento delle
norme in discussione:
- ISO/IEC 27000 (Panoramica e vocabolario); il documento è stato proposto
per il passaggio in DIS;
- ISO/IEC 27003 (Guida alla ISO/IEC 27001); il documento è stato proposto
per il passaggio in CD;
- ISO/IEC 27004 (Monitoraggi, misurazioni, analisi e valutazioni); il
documento è stata proposta per il passaggio in CD;
- ISO/IEC 27005 (Gestione del rischio); rimane in stato di WD;
- ISO/IEC 27006 (Requisiti per gli organismi di certificazione rispetto alla
ISO/IEC 27001); è stata proposta per il passaggio in DIS;
- ISO/IEC 27007 (Linee guida per gli audit dei sistema di gestione per la
sicurezza delle informazioni); rimane in stato di WD;
- ISO/IEC 27008 (Linee guida per gli audit dei controlli di sicurezza delle
informazioni); rimane in stato di WD;
- ISO/IEC 27009 (Requisiti per l'applicazione della ISO/IEC 27001 in settori
specifici); rimarrà in stato CD;
- ISO/IEC 27010 (Sicurezza nelle comunicazioni tra settori e
organizzazioni); il documento è stato proposto per il passaggio in DIS;
- ISO/IEC 27011 (controlli di sicurezza per il settore delle
telecomunicazioni); rimarrà in stato CD;
- ISO/IEC 27013 (relazioni tra ISO/IEC 27001 e ISO/IEC 20000-1); è stata
proposta per il passaggio in DIS;
- ISO/IEC 27017 (controlli di sicurezza per il cloud computing); è stata
proposta per il passaggio in DIS;
- ISO/IEC 27021 (Competenze per i professionisti dei sistemi di gestione per
la sicurezza delle informazioni); rimane in stato di WD;
- ISO/IEC 27023 (Mappa dei requisiti delle versioni del 2005 e del 2013
delle ISO/IEC 27001 e ISO/IEC 27002).
E' opportuno ricordare che i documenti attraversano diversi stadi prima
della pubblicazione: WG (Working draft), CD (Committee Draft), DIS (Draft),
FDIS (Final Draft).
Altre discussioni hanno riguardato:
- il futuro riesame della ISO/IEC 27019 (controlli di sicurezza per il
settore energia);
- la redazione di un " Cloud Adapted Risk Management Framework";
- la redazione di un documento relativo alla "Information Security Library";
Essendo io assente, il povero Fabio Guasconi ha dovuto difendere da solo i
miei numerosi commenti sulla ISO/IEC 27003 e non ho potuto aiutarlo sulle
sue proposte sulle altre norme. Con queste poche righe, rendo merito alla
sua capacità di portare avanti le istanze italiane.
Molta discussione si è fatta sulla ISO/IEC 27006 su due punti. Il primo
riguarda la durata degli audit: attualmente le giornate previste per le
organizzazioni piccole o molto piccole sono, a parere di alcuni, troppo
numerose (per le aziende di 5 persone si richiede un minimo non derogabile
di 4 giornate). Il secondo riguarda la necessità o meno di prevedere
esplicitamente negli audit la verifica di come sono attuati i controlli di
sicurezza previsti dall'Appendice A della ISO/IEC 27001. Come Italia, siamo
ovviamente favorevoli a verificare i controlli di sicurezza, ma in un numero
di giornate ragionevoli (purtroppo, troppi auditor si accontentano di
verificare solo i documenti o di fare interviste ai top manager, senza
verifiche sul campo). La nostra posizione è quindi difficile perché richiede
di bilanciare due esigenze diverse (tempi e costi degli audit ragionevoli e
adeguato livello di profondità).
Il prossimo meeeting sarà a inizio maggio 2015 a Kuching, in Malesia (isola
di Borneo).
dell'SC 27 dell'ISO/IEC JTC 1. Purtroppo, causa cancellazione del volo, non
ho potuto partecipare. A rappresentare l'Italia c'erano solo Fabio Guasconi
(Presidente SC 27 italiano) e Andrea Caccia.
Provo comunque, sulla base del documento finale "WG 1 Recommendations,
Resolutions and Acclamations", ad indicare lo stato di avanzamento delle
norme in discussione:
- ISO/IEC 27000 (Panoramica e vocabolario); il documento è stato proposto
per il passaggio in DIS;
- ISO/IEC 27003 (Guida alla ISO/IEC 27001); il documento è stato proposto
per il passaggio in CD;
- ISO/IEC 27004 (Monitoraggi, misurazioni, analisi e valutazioni); il
documento è stata proposta per il passaggio in CD;
- ISO/IEC 27005 (Gestione del rischio); rimane in stato di WD;
- ISO/IEC 27006 (Requisiti per gli organismi di certificazione rispetto alla
ISO/IEC 27001); è stata proposta per il passaggio in DIS;
- ISO/IEC 27007 (Linee guida per gli audit dei sistema di gestione per la
sicurezza delle informazioni); rimane in stato di WD;
- ISO/IEC 27008 (Linee guida per gli audit dei controlli di sicurezza delle
informazioni); rimane in stato di WD;
- ISO/IEC 27009 (Requisiti per l'applicazione della ISO/IEC 27001 in settori
specifici); rimarrà in stato CD;
- ISO/IEC 27010 (Sicurezza nelle comunicazioni tra settori e
organizzazioni); il documento è stato proposto per il passaggio in DIS;
- ISO/IEC 27011 (controlli di sicurezza per il settore delle
telecomunicazioni); rimarrà in stato CD;
- ISO/IEC 27013 (relazioni tra ISO/IEC 27001 e ISO/IEC 20000-1); è stata
proposta per il passaggio in DIS;
- ISO/IEC 27017 (controlli di sicurezza per il cloud computing); è stata
proposta per il passaggio in DIS;
- ISO/IEC 27021 (Competenze per i professionisti dei sistemi di gestione per
la sicurezza delle informazioni); rimane in stato di WD;
- ISO/IEC 27023 (Mappa dei requisiti delle versioni del 2005 e del 2013
delle ISO/IEC 27001 e ISO/IEC 27002).
E' opportuno ricordare che i documenti attraversano diversi stadi prima
della pubblicazione: WG (Working draft), CD (Committee Draft), DIS (Draft),
FDIS (Final Draft).
Altre discussioni hanno riguardato:
- il futuro riesame della ISO/IEC 27019 (controlli di sicurezza per il
settore energia);
- la redazione di un " Cloud Adapted Risk Management Framework";
- la redazione di un documento relativo alla "Information Security Library";
Essendo io assente, il povero Fabio Guasconi ha dovuto difendere da solo i
miei numerosi commenti sulla ISO/IEC 27003 e non ho potuto aiutarlo sulle
sue proposte sulle altre norme. Con queste poche righe, rendo merito alla
sua capacità di portare avanti le istanze italiane.
Molta discussione si è fatta sulla ISO/IEC 27006 su due punti. Il primo
riguarda la durata degli audit: attualmente le giornate previste per le
organizzazioni piccole o molto piccole sono, a parere di alcuni, troppo
numerose (per le aziende di 5 persone si richiede un minimo non derogabile
di 4 giornate). Il secondo riguarda la necessità o meno di prevedere
esplicitamente negli audit la verifica di come sono attuati i controlli di
sicurezza previsti dall'Appendice A della ISO/IEC 27001. Come Italia, siamo
ovviamente favorevoli a verificare i controlli di sicurezza, ma in un numero
di giornate ragionevoli (purtroppo, troppi auditor si accontentano di
verificare solo i documenti o di fare interviste ai top manager, senza
verifiche sul campo). La nostra posizione è quindi difficile perché richiede
di bilanciare due esigenze diverse (tempi e costi degli audit ragionevoli e
adeguato livello di profondità).
Il prossimo meeeting sarà a inizio maggio 2015 a Kuching, in Malesia (isola
di Borneo).
mercoledì 29 ottobre 2014
"Sicurezza delle informazioni" su carta
Vi segnalo, sempre a mo' di pubblicità, che ora è possibile acquistare il
libro "Sicurezza delle informazioni", di cui sono autore, anche in formato
cartaceo su www.lulu.com.
L'ho messo a 15 Euro (a cui aggiungere i costi di spedizione di circa 8
Euro). Il libro è acquistabile solo on-line. Spero che funzioni il link
diretto:
-
http://www.lulu.com/shop/cesare-gallotti/sicurezza-delle-informazioni-valuta
zione-del-rischio-i-sistemi-di-gestione-per-la-sicurezza-delle-informazioni-
la-norma-isoiec-270012013/paperback/product-21861741.html
libro "Sicurezza delle informazioni", di cui sono autore, anche in formato
cartaceo su www.lulu.com.
L'ho messo a 15 Euro (a cui aggiungere i costi di spedizione di circa 8
Euro). Il libro è acquistabile solo on-line. Spero che funzioni il link
diretto:
-
http://www.lulu.com/shop/cesare-gallotti/sicurezza-delle-informazioni-valuta
zione-del-rischio-i-sistemi-di-gestione-per-la-sicurezza-delle-informazioni-
la-norma-isoiec-270012013/paperback/product-21861741.html
sabato 25 ottobre 2014
Poddle e SSL
Il protocollo SSL 3.0 è obsoleto e vulnerabile, anche a causa della tecnica
di attacco Poddle. Si consiglia di usare il TLS anche perché una soluzione
non è stata ancora realizzata.
La notizia è di settembre e quindi non così nuova. Quello che trovo
interessante è un'altra notizia (arrivata con il SANS NewsBites): Apple
migrerà su TLS e questa sarà una forte spinta al cambiamento.
Mi chiedo quanti siti e servizi web stiano per migrare e ho un timore.
Un articolo interessante, che riporta anche il link all'articolo che
descrive Poddle:
-
http://www.cnet.com/news/apple-dumps-ssl-3-0-for-push-notifications-due-to-p
oodle-flaw/
di attacco Poddle. Si consiglia di usare il TLS anche perché una soluzione
non è stata ancora realizzata.
La notizia è di settembre e quindi non così nuova. Quello che trovo
interessante è un'altra notizia (arrivata con il SANS NewsBites): Apple
migrerà su TLS e questa sarà una forte spinta al cambiamento.
Mi chiedo quanti siti e servizi web stiano per migrare e ho un timore.
Un articolo interessante, che riporta anche il link all'articolo che
descrive Poddle:
-
http://www.cnet.com/news/apple-dumps-ssl-3-0-for-push-notifications-due-to-p
oodle-flaw/
giovedì 23 ottobre 2014
Rapporto semestrale MELANI
Io continuo ad apprezzare il lavoro fatto da MELANI della Confederazione
Svizzera, che ogni 6 mesi pubblica il suo rapporto sulla sicurezza delle
informazioni e in questi giorni è uscito quello della prima metà 2014:
-
http://www.melani.admin.ch/dienstleistungen/archiv/01588/index.html?lang=it
E' opportuno ricordare il lavoro fatto in Italia dal Clusit (per dire che
gli svizzeri sono bravi, ma anche noi lo siamo):
- http://clusit.it/rapportoclusit/
Svizzera, che ogni 6 mesi pubblica il suo rapporto sulla sicurezza delle
informazioni e in questi giorni è uscito quello della prima metà 2014:
-
http://www.melani.admin.ch/dienstleistungen/archiv/01588/index.html?lang=it
E' opportuno ricordare il lavoro fatto in Italia dal Clusit (per dire che
gli svizzeri sono bravi, ma anche noi lo siamo):
- http://clusit.it/rapportoclusit/
mercoledì 22 ottobre 2014
Atti del Privacy Academy and CSA Congress 2014
Antonio Salis di Tiscali, che ringrazio, segnala gli atti del Privacy
Academy and CSA Congress 2014:
- https://privacyassociation.org/conference/privacy-academy-2014/sessions/
Devo dire che le presentazioni sono numerose e interessanti. Quasi mai
dicono "le solite cose" su privacy, cloud, sicurezza, audit, eccetera.
Anzi...
Academy and CSA Congress 2014:
- https://privacyassociation.org/conference/privacy-academy-2014/sessions/
Devo dire che le presentazioni sono numerose e interessanti. Quasi mai
dicono "le solite cose" su privacy, cloud, sicurezza, audit, eccetera.
Anzi...
venerdì 17 ottobre 2014
Cosa vuol dire "Certificazione ISO/IEC 27001"?
Questo articolo, segnalatomi dal gruppo "Certified Information Systems
Auditor" di LinkedIn avrei voluto scriverlo io, per quanto è chiaro,
completo e sintetico:
-
https://parkersolutionsgroup.wordpress.com/2014/10/15/what-does-iso-27001-ce
rtification-really-mean/
Visto che è bello trovare difetti: io avrei scritto ISO/IEC 27001 (corretto)
al posto di ISO 27001 (scorretto).
Auditor" di LinkedIn avrei voluto scriverlo io, per quanto è chiaro,
completo e sintetico:
-
https://parkersolutionsgroup.wordpress.com/2014/10/15/what-does-iso-27001-ce
rtification-really-mean/
Visto che è bello trovare difetti: io avrei scritto ISO/IEC 27001 (corretto)
al posto di ISO 27001 (scorretto).
Nuove linee guida Confidustria per 231
Dalla newsletter di Protiviti segnalo che Confindustria ha pubblicato le
nuove Linee Guida per la costruzione dei "Modelli 231".
Il link è decisamente molto lungo (grazie a Nicola Valenza di Objectway per
avermelo dato):
-
http://www.confindustria.it/wps/portal/IT/AreeTematiche/Diritto-d-impresa/Do
cumenti/Dettaglio-doc-diritto-impresa/4eaa0336-f353-4bc8-aa05-35dfda228a50/4
eaa0336-f353-4bc8-aa05-35dfda228a50/!ut/p/a0/04_Sj9CPykssy0xPLMnMz0vMAfGjzOJ
9PT1MDD0NjLz83UxNDBxNgpwCfYzdLCzDTPQLsh0VAVhK9gI!/
Le linee guida sono divise in due parti: una generale con i requisiti e una
parte speciale, dedicata all'approfondimento dei reati e ad un metodo di
analisi.
nuove Linee Guida per la costruzione dei "Modelli 231".
Il link è decisamente molto lungo (grazie a Nicola Valenza di Objectway per
avermelo dato):
-
http://www.confindustria.it/wps/portal/IT/AreeTematiche/Diritto-d-impresa/Do
cumenti/Dettaglio-doc-diritto-impresa/4eaa0336-f353-4bc8-aa05-35dfda228a50/4
eaa0336-f353-4bc8-aa05-35dfda228a50/!ut/p/a0/04_Sj9CPykssy0xPLMnMz0vMAfGjzOJ
9PT1MDD0NjLz83UxNDBxNgpwCfYzdLCzDTPQLsh0VAVhK9gI!/
Le linee guida sono divise in due parti: una generale con i requisiti e una
parte speciale, dedicata all'approfondimento dei reati e ad un metodo di
analisi.
Linee guida hardening (puntata 2)
Il mese scorso ho scritto un articolo sulle linee guida per l'hardening:
- http://blog.cesaregallotti.it/2014/10/linee-guida-hardening.html
Stefano Ramacciotti (che ringrazio) mi ha fatto notare che non ho citato le
linee guida della NSA:
-
https://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/ind
ex.shtml
In effetti avevo guardato quelle relative ai sistemi operativi e alle
applicazioni e mi erano sembrate troppo orientate ai sistemi domestici.
Stefano però mi ha fatto notare che quelle per gli apparati CISCO sono
eccezionali.
- http://blog.cesaregallotti.it/2014/10/linee-guida-hardening.html
Stefano Ramacciotti (che ringrazio) mi ha fatto notare che non ho citato le
linee guida della NSA:
-
https://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/ind
ex.shtml
In effetti avevo guardato quelle relative ai sistemi operativi e alle
applicazioni e mi erano sembrate troppo orientate ai sistemi domestici.
Stefano però mi ha fatto notare che quelle per gli apparati CISCO sono
eccezionali.
mercoledì 15 ottobre 2014
Correzioni alle ISO/IEC 27001 e 27002
Sono stati pubblicati due documenti di correzione rispettivamente della
ISO/IEC 27001 e della ISO/IEC 27002 (grazie a Franco Ferrari di DNV GL per
avermi avvisato).
Correzioni francamente non molto illuminanti. Ai controlli 8.1.1 e 8.1.3, in
un paio di punti si è corretto "asset" con "informazioni e altri asset".
La cosa interessante è che erano state proposte altre correzioni per
riferimenti incrociati sbagliati, frasi non concluse, eccetera, ma furono
bocciati perché quegli errori non compromettono la comprensione della norma.
Invece, meno male che sono state apportate queste correzioni.
A parte il sarcasmo, i più puntuali potranno trovare le correzioni sul sito
della ISO (www.iso.org) con i documenti dal titolo:
- ISO/IEC 27001:2013/Cor.1:2014(en);
- ISO/IEC 27002:2013/Cor.1:2014(en).
I documenti veri e propri, per quanto io li abbia visti, non sono riuscito a
scaricarli (manca proprio l'opzione). Ma è sufficiente chiedere di vedere la
preview e li si legge (però ho dovuto usare IE e non Firefox).
ISO/IEC 27001 e della ISO/IEC 27002 (grazie a Franco Ferrari di DNV GL per
avermi avvisato).
Correzioni francamente non molto illuminanti. Ai controlli 8.1.1 e 8.1.3, in
un paio di punti si è corretto "asset" con "informazioni e altri asset".
La cosa interessante è che erano state proposte altre correzioni per
riferimenti incrociati sbagliati, frasi non concluse, eccetera, ma furono
bocciati perché quegli errori non compromettono la comprensione della norma.
Invece, meno male che sono state apportate queste correzioni.
A parte il sarcasmo, i più puntuali potranno trovare le correzioni sul sito
della ISO (www.iso.org) con i documenti dal titolo:
- ISO/IEC 27001:2013/Cor.1:2014(en);
- ISO/IEC 27002:2013/Cor.1:2014(en).
I documenti veri e propri, per quanto io li abbia visti, non sono riuscito a
scaricarli (manca proprio l'opzione). Ma è sufficiente chiedere di vedere la
preview e li si legge (però ho dovuto usare IE e non Firefox).
sabato 11 ottobre 2014
Come non fare verifiche (3 di 3) - Le speranze
Negli ultimi mesi mi è capitato di discutere su "come fare verifiche", sia
come auditor, sia come consulente (dove le verifiche hanno lo scopo di
raccogliere informazioni per un "assessment").
Un terzo approccio sbagliato prevede di svolgere verifiche dei piani e delle
procedure, senza verificare come sono attualmente i processi. Questo
approccio è un derivato del precedente e anch'esso prevede l'uso di una
comoda sala riunioni per tutta la durata della verifica.
Certamente i piani di miglioramento futuri sono importanti perché danno
conto di quanto un'organizzazione sia attenta alla realtà che la circonda e
voglia adeguarsi, per quanta fatica questo comporti.
Però non riesco a considerare efficace un processo di sviluppo perché è
previsto che tra un mese saranno svolti i test di quanto consegnato ai
clienti, mentre fino ad oggi non lo si è mai fatto. Oppure efficace un
processo di continuità operativa perché oggi si sta finendo di redigere i
piani di continuità.
Interessante vedere come il "processo alle intenzioni" sia reputato una
cattiva pratica, ma invece si consideri corretto il "processo alle buone
intenzioni".
Ancora una volta: agli auditor e ai consulenti è richiesto di valutare la
conformità a standard, politiche e procedure o l'efficacia dei processi
attraverso prove materiali (o, per cattiva traduzione, a "evidenze"). Non
attraverso le buone intenzioni.
Ho purtroppo l'impressione che chi propugni altri metodi lo faccia per
pigrizia (lato auditor) o per furbizia (lato auditee), ma questo è fare solo
del male alla cultura di "buona gestione".
come auditor, sia come consulente (dove le verifiche hanno lo scopo di
raccogliere informazioni per un "assessment").
Un terzo approccio sbagliato prevede di svolgere verifiche dei piani e delle
procedure, senza verificare come sono attualmente i processi. Questo
approccio è un derivato del precedente e anch'esso prevede l'uso di una
comoda sala riunioni per tutta la durata della verifica.
Certamente i piani di miglioramento futuri sono importanti perché danno
conto di quanto un'organizzazione sia attenta alla realtà che la circonda e
voglia adeguarsi, per quanta fatica questo comporti.
Però non riesco a considerare efficace un processo di sviluppo perché è
previsto che tra un mese saranno svolti i test di quanto consegnato ai
clienti, mentre fino ad oggi non lo si è mai fatto. Oppure efficace un
processo di continuità operativa perché oggi si sta finendo di redigere i
piani di continuità.
Interessante vedere come il "processo alle intenzioni" sia reputato una
cattiva pratica, ma invece si consideri corretto il "processo alle buone
intenzioni".
Ancora una volta: agli auditor e ai consulenti è richiesto di valutare la
conformità a standard, politiche e procedure o l'efficacia dei processi
attraverso prove materiali (o, per cattiva traduzione, a "evidenze"). Non
attraverso le buone intenzioni.
Ho purtroppo l'impressione che chi propugni altri metodi lo faccia per
pigrizia (lato auditor) o per furbizia (lato auditee), ma questo è fare solo
del male alla cultura di "buona gestione".
Come non fare verifiche (2 di 3) - La sala riunioni
Negli ultimi mesi mi è capitato di discutere su "come fare verifiche", sia
come auditor, sia come consulente (dove le verifiche hanno lo scopo di
raccogliere informazioni per un "assessment").
Un secondo approccio sbagliato prevede di svolgere verifiche solo della
"governance" o del "sistema di gestione".
Il termine "sistema di gestione" è quello usato per gli standard ISO 9001
("Sistema di gestione per la qualità"), ISO/IEC 20000 ("Sistema di gestione
per i servizi") e 27001 ("Sistema di gestione per la sicurezza delle
informazioni"). Qui, alcuni intendono "sistema di gestione" come "sistema
direzionale", dimenticando che la definizione non si limita ai soli
"elementi per stabilire obiettivi, politiche e processi", ma anche agli
"elementi per raggiungere gli obiettivi", tra cui, ovviamente, ci sono anche
le attività operative.
Questo approccio, quindi, prevede di verificare solo le politiche, le
procedure, la pianificazione e il monitoraggio delle azioni dei manager e
altre cose documentali. Questo avviene spesso in una comoda sala riunioni.
Però, per comprendere se i processi sono veramente efficaci, e quindi se la
governance o il sistema di gestione lo sono, non ci sono altri mezzi che
vederli sul campo.
Sempre nell'ambito delle norme ISO più legate all'informatica come le
ISO/IEC 20000 e 27001 (ma credo che ciò avvenga anche negli altri settori)
alcuni teorizzano la natura particolare delle norme in questione. Però ho
visto fare audit in sala riunioni anche per la qualità e vedo fare audit sul
campo per tutte le altre. Temo che nel settore dell'informatica ci siano
troppi "professionisti" che sanno discettare di processi in senso generale,
ma hanno difficoltà a capire le differenze nella gestione dei sistemi e
delle applicazioni (giusto per fare un esempio) o a capire perché Telnet non
sia sicuro (questo l'ho visto con i miei occhi).
Il fatto che la ISO 9001 sia ritenuta una norma "semplice" o "inutile" è
proprio dovuto al fatto che alcuni la interpretano erroneamente come un
"insieme di documenti". E quindi pregherei i professionisti seri e preparati
di non fare altrettanto con altre norme perché questo approccio ci porterà a
degradare il mercato.
come auditor, sia come consulente (dove le verifiche hanno lo scopo di
raccogliere informazioni per un "assessment").
Un secondo approccio sbagliato prevede di svolgere verifiche solo della
"governance" o del "sistema di gestione".
Il termine "sistema di gestione" è quello usato per gli standard ISO 9001
("Sistema di gestione per la qualità"), ISO/IEC 20000 ("Sistema di gestione
per i servizi") e 27001 ("Sistema di gestione per la sicurezza delle
informazioni"). Qui, alcuni intendono "sistema di gestione" come "sistema
direzionale", dimenticando che la definizione non si limita ai soli
"elementi per stabilire obiettivi, politiche e processi", ma anche agli
"elementi per raggiungere gli obiettivi", tra cui, ovviamente, ci sono anche
le attività operative.
Questo approccio, quindi, prevede di verificare solo le politiche, le
procedure, la pianificazione e il monitoraggio delle azioni dei manager e
altre cose documentali. Questo avviene spesso in una comoda sala riunioni.
Però, per comprendere se i processi sono veramente efficaci, e quindi se la
governance o il sistema di gestione lo sono, non ci sono altri mezzi che
vederli sul campo.
Sempre nell'ambito delle norme ISO più legate all'informatica come le
ISO/IEC 20000 e 27001 (ma credo che ciò avvenga anche negli altri settori)
alcuni teorizzano la natura particolare delle norme in questione. Però ho
visto fare audit in sala riunioni anche per la qualità e vedo fare audit sul
campo per tutte le altre. Temo che nel settore dell'informatica ci siano
troppi "professionisti" che sanno discettare di processi in senso generale,
ma hanno difficoltà a capire le differenze nella gestione dei sistemi e
delle applicazioni (giusto per fare un esempio) o a capire perché Telnet non
sia sicuro (questo l'ho visto con i miei occhi).
Il fatto che la ISO 9001 sia ritenuta una norma "semplice" o "inutile" è
proprio dovuto al fatto che alcuni la interpretano erroneamente come un
"insieme di documenti". E quindi pregherei i professionisti seri e preparati
di non fare altrettanto con altre norme perché questo approccio ci porterà a
degradare il mercato.
Come non fare verifiche (1 di 3) - Gli orali
Negli ultimi mesi mi è capitato di discutere su "come fare verifiche", sia
come auditor, sia come consulente (dove le verifiche hanno lo scopo di
raccogliere informazioni per un "assessment").
Un primo approccio sbagliato prevede di svolgere verifiche solo attraverso
interviste orali ai manager.
Tutti però dovremmo conoscere la relatività della narrazione. Si ricordi il
racconto "Nel bosco" di Akutagawa o il film "Rashomon" di Kurosawa, che
hanno reso artisticamente quanto non esistano narratori onniscenti e
affidabili; per racconti più recenti, consiglio la prima stupenda stagione
del telefilm "True detective".
Questo per dire che gli intervistati tendono a non raccontare difetti nei
processi in cui sono coinvolti ed enfatizzano invece le carenze che
giustificano l'avvio di progetti che invece vorrebbero iniziare. Quando
queste narrazioni sono raccolte da una persona che le ordina non
costituiscono però il risultato di una verifica professionale, che dovrebbe
essere invece completa, esaustiva e il più possibile imparziale. Solo una
verifica sul campo presso gli operatori e l'analisi diretta dei processi e
dei loro risultati possono testimoniare come sono nella realtà, se sono
adeguati, se presentano dei rischi che un manager spesso non rileva (in caso
contrario, a cosa servirebbero gli specialisti?).
Ogni volta che ho avuto l'opportunità di fare verifiche sul campo ho trovato
carenze più numerose e diverse di quelle segnalate dai manager nelle
interviste.
Nell'ambito della sicurezza questo approccio presenta un'ulteriore difetto:
ai consulenti viene spesso chiesto (e i consulenti spesso propongono) di
fare una valutazione dellla sicurezza solo attraverso interviste ai manager
e dei vulnerability assessment tecnologici, senza però mai analizzare quanto
sta in mezzo, ossia le attività del personale tecnico.
Questo perché succede? Perché i manager non vogliono vedere messa in
discussione la loro competenza e i verificatori temono la complessità di una
verifica sul campo (per esempio, un conto è prendere nota del fatto che sono
svolti e documentati i test, un altro è capire se sono completi e adeguati).
come auditor, sia come consulente (dove le verifiche hanno lo scopo di
raccogliere informazioni per un "assessment").
Un primo approccio sbagliato prevede di svolgere verifiche solo attraverso
interviste orali ai manager.
Tutti però dovremmo conoscere la relatività della narrazione. Si ricordi il
racconto "Nel bosco" di Akutagawa o il film "Rashomon" di Kurosawa, che
hanno reso artisticamente quanto non esistano narratori onniscenti e
affidabili; per racconti più recenti, consiglio la prima stupenda stagione
del telefilm "True detective".
Questo per dire che gli intervistati tendono a non raccontare difetti nei
processi in cui sono coinvolti ed enfatizzano invece le carenze che
giustificano l'avvio di progetti che invece vorrebbero iniziare. Quando
queste narrazioni sono raccolte da una persona che le ordina non
costituiscono però il risultato di una verifica professionale, che dovrebbe
essere invece completa, esaustiva e il più possibile imparziale. Solo una
verifica sul campo presso gli operatori e l'analisi diretta dei processi e
dei loro risultati possono testimoniare come sono nella realtà, se sono
adeguati, se presentano dei rischi che un manager spesso non rileva (in caso
contrario, a cosa servirebbero gli specialisti?).
Ogni volta che ho avuto l'opportunità di fare verifiche sul campo ho trovato
carenze più numerose e diverse di quelle segnalate dai manager nelle
interviste.
Nell'ambito della sicurezza questo approccio presenta un'ulteriore difetto:
ai consulenti viene spesso chiesto (e i consulenti spesso propongono) di
fare una valutazione dellla sicurezza solo attraverso interviste ai manager
e dei vulnerability assessment tecnologici, senza però mai analizzare quanto
sta in mezzo, ossia le attività del personale tecnico.
Questo perché succede? Perché i manager non vogliono vedere messa in
discussione la loro competenza e i verificatori temono la complessità di una
verifica sul campo (per esempio, un conto è prendere nota del fatto che sono
svolti e documentati i test, un altro è capire se sono completi e adeguati).
venerdì 10 ottobre 2014
Definizioni di cloud
Dopo l'articolo di settembre sul cloud forensics
(http://blog.cesaregallotti.it/2014/08/cloud-forensics.html), mi hanno
inviato due commenti interessanti.
Il primo, di Andrea Rui:
<< Mi permetto di dissentire su un requisito utilizzato per dare la
definizione tecnica del concetto di Cloud: "Da un punto di vista meramente
pratico un cloud esiste se esiste almeno un hypervisor (VMM)".
L'utilizzo di un hypervisor che consenta la coesistenza di più VM su un
unico hardware è utile (anzi è necessario) nel caso che si vogliano far
coesistere sistemi virtuali indipendenti e concorrenti. Esistono soluzioni
'Cloud' (tipicamente del tipo SaaS) che non necessitano di hypervisor, in
quanto la separazione dei dati degli utenti viene garantita a livello
architetturale ed applicativo, senza che sia indispensabile
l'intermediazione di uno strato di virtualizzazione. >>
Il secondo, di Maurizio Nastro:
<< Il NIST, nella sua definizione di Cloud ("The NIST Definition of Cloud
Computing", SP800-145), fa riferimento alla virtualizzazione nella parte
relativa al "Resource Polling": The provider's computing resources are
pooled to serve multiple consumers using a multi-tenant model, with
different physical and virtual resources dynamically assigned and reassigned
according to consumer demand ...
Dalla definizione non è chiaro se il NIST intenda la virtualizzazione come
condizione necessaria per un servizio Cloud.
La Cloud Security Alliance la interpreta come condizione non necessaria
(https://cloudsecurityalliance.org/education/white-papers-and-educational-ma
terial/white-papers/, white paper "Virtualization Security By Chris
Brenton", slide 3,4,5), in accordo con quanto scrive Andrea Rui. >>
Grazie Andrea e Maurizio per il vostro contributo. Vediamo se altri
concordano o dissentono.
(http://blog.cesaregallotti.it/2014/08/cloud-forensics.html), mi hanno
inviato due commenti interessanti.
Il primo, di Andrea Rui:
<< Mi permetto di dissentire su un requisito utilizzato per dare la
definizione tecnica del concetto di Cloud: "Da un punto di vista meramente
pratico un cloud esiste se esiste almeno un hypervisor (VMM)".
L'utilizzo di un hypervisor che consenta la coesistenza di più VM su un
unico hardware è utile (anzi è necessario) nel caso che si vogliano far
coesistere sistemi virtuali indipendenti e concorrenti. Esistono soluzioni
'Cloud' (tipicamente del tipo SaaS) che non necessitano di hypervisor, in
quanto la separazione dei dati degli utenti viene garantita a livello
architetturale ed applicativo, senza che sia indispensabile
l'intermediazione di uno strato di virtualizzazione. >>
Il secondo, di Maurizio Nastro:
<< Il NIST, nella sua definizione di Cloud ("The NIST Definition of Cloud
Computing", SP800-145), fa riferimento alla virtualizzazione nella parte
relativa al "Resource Polling": The provider's computing resources are
pooled to serve multiple consumers using a multi-tenant model, with
different physical and virtual resources dynamically assigned and reassigned
according to consumer demand ...
Dalla definizione non è chiaro se il NIST intenda la virtualizzazione come
condizione necessaria per un servizio Cloud.
La Cloud Security Alliance la interpreta come condizione non necessaria
(https://cloudsecurityalliance.org/education/white-papers-and-educational-ma
terial/white-papers/, white paper "Virtualization Security By Chris
Brenton", slide 3,4,5), in accordo con quanto scrive Andrea Rui. >>
Grazie Andrea e Maurizio per il vostro contributo. Vediamo se altri
concordano o dissentono.
sabato 4 ottobre 2014
Cybersecurity nei dispositivi medici
Massimo Cottafavi di Reply mi ha segnalato la pubblicazione della guida "
Content of Premarket Submissions for Management of Cybersecurity in Medical
Devices":
-
http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocume
nts/ucm356186.htm
Riporto quanto mi scrive:
<<
Questo link porta ad un articolo di presentazione della guida:
-
http://www.usatoday.com/story/tech/2014/10/01/fda-medical-devices-cybersecur
ity/16543731/
MI sembra un passo importante anche solo per rimarcare e consapevolizzare
rispetto alla criticità di un settore (quello medicale appunto) che ha fatto
passi da gigante in termini di evoluzione tecnologica negli ultimi anni
senza che a ciò sia corrisposta una altrettanto rapida ascesa nei sistemi di
governo ed indirizzamento della sicurezza.
>>
Condivido l'opinione di Massimo. La guida è più che altro un elenco di
principi ed un rimando ad altri documenti. Trovo positivo che non abbiano
scritto un altro elenco di controlli di sicurezza informatica.
Content of Premarket Submissions for Management of Cybersecurity in Medical
Devices":
-
http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocume
nts/ucm356186.htm
Riporto quanto mi scrive:
<<
Questo link porta ad un articolo di presentazione della guida:
-
http://www.usatoday.com/story/tech/2014/10/01/fda-medical-devices-cybersecur
ity/16543731/
MI sembra un passo importante anche solo per rimarcare e consapevolizzare
rispetto alla criticità di un settore (quello medicale appunto) che ha fatto
passi da gigante in termini di evoluzione tecnologica negli ultimi anni
senza che a ciò sia corrisposta una altrettanto rapida ascesa nei sistemi di
governo ed indirizzamento della sicurezza.
>>
Condivido l'opinione di Massimo. La guida è più che altro un elenco di
principi ed un rimando ad altri documenti. Trovo positivo che non abbiano
scritto un altro elenco di controlli di sicurezza informatica.
Linee guida hardening
L'iniziativa del CIS di pubblicazione di guide sulla configurazione sicura
dei sistemi risale a diversi anni fa, ma io la segnalo solo ora (anche
grazie ad un cliente che me l'ha fatta ricordare):
- https://benchmarks.cisecurity.org/downloads/multiform/index.cfm
Le guide sono molto varie: dai sistemi operativi noti, ad alcuni middleware
e apparati. C'è anche una guida sulle metriche (tra l'altro, mi pare
interessante).
Solitamente i sistemisti "sanno" come configurare server, apparati,
applicazioni e altro. Mi chiedo spesso come abbiano acquisito questo sapere.
Secondo me si tratta di "esperienza acquisita in modo non strutturato".
Forse l'uso di guide riconosciute potrebbe migliorare la sicurezza dei
sistemi; o forse no...
Per scaricare le guide è necessario fornire un indirizzo di e-mail, non
necessariamente esistente.
dei sistemi risale a diversi anni fa, ma io la segnalo solo ora (anche
grazie ad un cliente che me l'ha fatta ricordare):
- https://benchmarks.cisecurity.org/downloads/multiform/index.cfm
Le guide sono molto varie: dai sistemi operativi noti, ad alcuni middleware
e apparati. C'è anche una guida sulle metriche (tra l'altro, mi pare
interessante).
Solitamente i sistemisti "sanno" come configurare server, apparati,
applicazioni e altro. Mi chiedo spesso come abbiano acquisito questo sapere.
Secondo me si tratta di "esperienza acquisita in modo non strutturato".
Forse l'uso di guide riconosciute potrebbe migliorare la sicurezza dei
sistemi; o forse no...
Per scaricare le guide è necessario fornire un indirizzo di e-mail, non
necessariamente esistente.
sabato 27 settembre 2014
Assumere un hacker per sbaglio
Questa è una storia interessante e starebbe bene in un libro o in un film:
- https://www.norse-corp.com/blog-140926.html
In poche parole: una donna con competenze da hacker trova lavoro nel settore
marketing di una grande azienda.
Nel frattempo si legge qualcosa su OSINT e se ne capiscono le potenzialità e
i rischi.
- https://www.norse-corp.com/blog-140926.html
In poche parole: una donna con competenze da hacker trova lavoro nel settore
marketing di una grande azienda.
Nel frattempo si legge qualcosa su OSINT e se ne capiscono le potenzialità e
i rischi.
venerdì 26 settembre 2014
Cyber Defence Symposium
Toto Zammataro di Intellium mi ha segnalato gli atti del Cyber Defence
Symposium:
- http://www.rid.it/index~phppag,3_id,314.html
La lettura di alcuni articoli, tra cui quello di Toto Zammataro stesso
("Anatomia di un CERT") e quello di Marco Mattiucci ("Cybersecurity, Cyber
Forensics e Digital Forensics: stato, evoluzioni ed attività dell'Arma dei
Carabinieri"), è molto interessante, per quanto didattica.
Altri interventi, purtroppo, sono troppo commerciali.
Symposium:
- http://www.rid.it/index~phppag,3_id,314.html
La lettura di alcuni articoli, tra cui quello di Toto Zammataro stesso
("Anatomia di un CERT") e quello di Marco Mattiucci ("Cybersecurity, Cyber
Forensics e Digital Forensics: stato, evoluzioni ed attività dell'Arma dei
Carabinieri"), è molto interessante, per quanto didattica.
Altri interventi, purtroppo, sono troppo commerciali.
mercoledì 24 settembre 2014
Application whitelisting technology
Confesso la mia ignoranza sull'esistenza di tecnologie di application
whitelisting. Ma andiamo con ordine.
La newsletter SANS NewsBites del 23 settembre riporta una notizia successiva
ad un attacco alla catena Home Depot. L'attacco, molto semplice, era questo:
un malware ha infettato i PC collegati ai POS dei negozi, in modo da
inoltrare i dettagli delle carte di credito a quale malintenzionato (ma
sembra che poi non siano stati usati per derubare i 56 milioni di
malcapitati):
- http://www.theregister.co.uk/2014/09/18/home_depot_56m_cards_compromised/
Il danno è stato quantificato in quasi 250 milioni di dollari.
La notizia successiva riportava lamentele degli addetti alla sicurezza
informatica di Home Depot perché le vulnerabilità erano state segnalate ma
non considerate dai manager.
La cosa interessante è l'analisi di John Pescatore, sempre sul SANS
NewsBites, ricorda che Home Depot poteva utilizzare delle tecnologie di
application whitelisting, come segnalato dai "Critical security controls"
del SANS stesso:
- http://www.sans.org/critical-security-controls/controls
Il controllo che ci interessa è il 2-1 che recita "Usa una tecnologia di
application whitelisting che permette ai sistemi di far funzionare del
software solo se è incluso in una lista e di bloccare ogni altro software.
La lista può essere molto estesa e quindi può non avere impatti sugli
utenti, oppure molto ridotta per sistemi critici".
Una breve ricerca su Google mi ha fatto incontrare il prodotto della
Kaspersky (http://whitelist.kaspersky.com/).
Ora, io ho visto solo un'azienda che utilizza una versione ridotta di questa
tecnologia (ogni notte analizza i PC degli utenti e disinstalla i programmi
non autorizzati), ma non l'ho ancora vista ben pubblicizzata. Forse il
motivo è in un'altra frase di John Pescatore: "Nel peggiore dei casi, la
messa in funziona di una tecnologia di application whitelisting sarebbe
costata a Home Depot 25 milioni di dollari, molto meno dei 250 che hanno
perso". Diciamo che 25 milioni di dollari sono tanti...
Comunque, se qualche mio lettore vuole inviare dei contributi in materia,
sarò ben lieto di pubblicarli.
whitelisting. Ma andiamo con ordine.
La newsletter SANS NewsBites del 23 settembre riporta una notizia successiva
ad un attacco alla catena Home Depot. L'attacco, molto semplice, era questo:
un malware ha infettato i PC collegati ai POS dei negozi, in modo da
inoltrare i dettagli delle carte di credito a quale malintenzionato (ma
sembra che poi non siano stati usati per derubare i 56 milioni di
malcapitati):
- http://www.theregister.co.uk/2014/09/18/home_depot_56m_cards_compromised/
Il danno è stato quantificato in quasi 250 milioni di dollari.
La notizia successiva riportava lamentele degli addetti alla sicurezza
informatica di Home Depot perché le vulnerabilità erano state segnalate ma
non considerate dai manager.
La cosa interessante è l'analisi di John Pescatore, sempre sul SANS
NewsBites, ricorda che Home Depot poteva utilizzare delle tecnologie di
application whitelisting, come segnalato dai "Critical security controls"
del SANS stesso:
- http://www.sans.org/critical-security-controls/controls
Il controllo che ci interessa è il 2-1 che recita "Usa una tecnologia di
application whitelisting che permette ai sistemi di far funzionare del
software solo se è incluso in una lista e di bloccare ogni altro software.
La lista può essere molto estesa e quindi può non avere impatti sugli
utenti, oppure molto ridotta per sistemi critici".
Una breve ricerca su Google mi ha fatto incontrare il prodotto della
Kaspersky (http://whitelist.kaspersky.com/).
Ora, io ho visto solo un'azienda che utilizza una versione ridotta di questa
tecnologia (ogni notte analizza i PC degli utenti e disinstalla i programmi
non autorizzati), ma non l'ho ancora vista ben pubblicizzata. Forse il
motivo è in un'altra frase di John Pescatore: "Nel peggiore dei casi, la
messa in funziona di una tecnologia di application whitelisting sarebbe
costata a Home Depot 25 milioni di dollari, molto meno dei 250 che hanno
perso". Diciamo che 25 milioni di dollari sono tanti...
Comunque, se qualche mio lettore vuole inviare dei contributi in materia,
sarò ben lieto di pubblicarli.
sabato 20 settembre 2014
TrueCrypt e CipherShed
Fabio Teoldi mi ha segnalato questa notizia: una società svizzera stari-ingegnerizzando TrueCrypt, ritenuto il miglior software per creare partizioni cifrate, e lo chiamerà CipherShed:
- http://www.esecurityplanet.com/open-source-security/truecrypt-getting-a-new-life.html
Il nome è terribile, ma spero si tratti di un buon prodotto, fatto da persone serie:
- https://ciphershed.org/
Per intanto, visto che funziona anche su Windows 8, io continuo a usare TrueCrypt felice e contento. Spero poi che il prodotto possa diffondersi e spingere il maggior numero di persone a prestare attenzione alla sicurezza.
- http://www.esecurityplanet.com/open-source-security/truecrypt-getting-a-new-life.html
Il nome è terribile, ma spero si tratti di un buon prodotto, fatto da persone serie:
- https://ciphershed.org/
Per intanto, visto che funziona anche su Windows 8, io continuo a usare TrueCrypt felice e contento. Spero poi che il prodotto possa diffondersi e spingere il maggior numero di persone a prestare attenzione alla sicurezza.
PGP è da buttare?
Su Crypto-gram di settembre è riportata la notizia di un articolo molto
critico su PGP:
- http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
Per un riassunto meno tecnico (sempre da Crypto-gram):
-
http://thehackernews.com/2014/08/cryptography-expert-pgp-encryption-is_19.ht
ml
Per una critica all'articolo critico (sempre da Crypto-gram):
- https://pthree.org/2014/08/18/whats-the-matter-with-pgp/
La mia riflessione è un'altra, indipendentemente dai problemi tecnologici:
oggi nessuno usa più strumenti crittografici per inviare e-mail in cui sono
riportate informazioni o allegati molto riservati. Secondo me tutto ha
origine dal fatto che nel 2002 la NAI ha smesso il supporto a PGP e gli
altri progetti open-source hanno reso disponibili delle facili interfacce
dopo troppo tempo (buffo, visto che una delle caratteristiche di PGP che lo
resero popolare era proprio l'interfaccia grafica).
Oggi, si potrebbe fare riferimento a www.gnupg.org, ma in pochi lo fanno.
critico su PGP:
- http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
Per un riassunto meno tecnico (sempre da Crypto-gram):
-
http://thehackernews.com/2014/08/cryptography-expert-pgp-encryption-is_19.ht
ml
Per una critica all'articolo critico (sempre da Crypto-gram):
- https://pthree.org/2014/08/18/whats-the-matter-with-pgp/
La mia riflessione è un'altra, indipendentemente dai problemi tecnologici:
oggi nessuno usa più strumenti crittografici per inviare e-mail in cui sono
riportate informazioni o allegati molto riservati. Secondo me tutto ha
origine dal fatto che nel 2002 la NAI ha smesso il supporto a PGP e gli
altri progetti open-source hanno reso disponibili delle facili interfacce
dopo troppo tempo (buffo, visto che una delle caratteristiche di PGP che lo
resero popolare era proprio l'interfaccia grafica).
Oggi, si potrebbe fare riferimento a www.gnupg.org, ma in pochi lo fanno.
La lunga storia degli HSM (seconda puntata)
A luglio segnalai (su indicazione di Stefano Ramacciotti) un post sulla
lunga storia degli HSM:
- http://blog.cesaregallotti.it/2014/07/la-lunga-storia-degli-hsm.html
Andrea Caccia, che di queste cose si occupa, mi ha aggiornato e io copio e
incollo la sua gentile e-mail:
<< Proprio oggi (15 settembre 2014), l'OCSI ha pubblicato il primo
certificato di un HSM per firma remota, che è quindi certificato CC EAL4+
secondo i requisiti di legge:
-
http://www.ocsi.isticom.it/index.php/elenchi-certificazioni/prodotti-certifi
cati#c0214
Il problema è che questo prodotto non è stato certificato entro i termini
indicati dal decreto per predisporre i piani di migrazione.
Quindi, se è pur vero che ora l'apparato c'è, dopo tanti anni di
autocertificazione, è anche vero che non è arrivato secondo i tempi che il
decreto richiedeva e credo che questo porterà a parecchie discussioni. >>
lunga storia degli HSM:
- http://blog.cesaregallotti.it/2014/07/la-lunga-storia-degli-hsm.html
Andrea Caccia, che di queste cose si occupa, mi ha aggiornato e io copio e
incollo la sua gentile e-mail:
<< Proprio oggi (15 settembre 2014), l'OCSI ha pubblicato il primo
certificato di un HSM per firma remota, che è quindi certificato CC EAL4+
secondo i requisiti di legge:
-
http://www.ocsi.isticom.it/index.php/elenchi-certificazioni/prodotti-certifi
cati#c0214
Il problema è che questo prodotto non è stato certificato entro i termini
indicati dal decreto per predisporre i piani di migrazione.
Quindi, se è pur vero che ora l'apparato c'è, dopo tanti anni di
autocertificazione, è anche vero che non è arrivato secondo i tempi che il
decreto richiedeva e credo che questo porterà a parecchie discussioni. >>
giovedì 18 settembre 2014
Apple e le forze dell'ordine
Pasquale Stirparo ha segnalato alla mailing list di DFA
(www.perfezionisti.it) il fatto che Apple ha pubblicato delle "Legal Process
Guidelines" con le istruzioni che devono seguire le forze dell'ordine di
USA, EMEIA, Giappone e APAC quando vogliono svolgere delle indagini e
richiedono informazioni "sugli utenti che usano prodotti e servizi Apple o
da dispositivi Apple":
- http://www.apple.com/privacy/government-information-requests/
Trovo questa iniziativa molto interessante. Secondo me, quasi nessuna
azienda italiana ha una linea guida per gestire eventuali richieste da parte
dell'autorità giudiziaria. Non dico si debba diffonderle per dare istruzioni
alle forze dell'ordine come fa Apple (figurarsi!), ma qualcosa bisognerebbe
fare. Al minimo, indicare internamente un referente interno nel caso
arrivino richieste di questo tipo e disprre di un riferimento di un legale
competente da consultare.
(www.perfezionisti.it) il fatto che Apple ha pubblicato delle "Legal Process
Guidelines" con le istruzioni che devono seguire le forze dell'ordine di
USA, EMEIA, Giappone e APAC quando vogliono svolgere delle indagini e
richiedono informazioni "sugli utenti che usano prodotti e servizi Apple o
da dispositivi Apple":
- http://www.apple.com/privacy/government-information-requests/
Trovo questa iniziativa molto interessante. Secondo me, quasi nessuna
azienda italiana ha una linea guida per gestire eventuali richieste da parte
dell'autorità giudiziaria. Non dico si debba diffonderle per dare istruzioni
alle forze dell'ordine come fa Apple (figurarsi!), ma qualcosa bisognerebbe
fare. Al minimo, indicare internamente un referente interno nel caso
arrivino richieste di questo tipo e disprre di un riferimento di un legale
competente da consultare.
lunedì 15 settembre 2014
LinkedIn e social network
Questa è una delle mie piccole storie personali che propino ai miei lettori,
ma ha una morale relativa alla sicurezza delle informazioni.
Negli ultimi mesi ho scritto, per dei clienti, delle regole in merito
all'uso dei social network. Le solite cose: non parlate con gli sconosciuti,
non scrivete cose relative all'azienda per cui lavorate, se dovete usare i
social network per finalità aziendali prestate attenzione a questo e a
quello.
Nello stesso periodo mi sono accorto delle e-mail di LinkedIn che mi
consigliavano di fare gli auguri o di congratularmi con perfetti sconosciuti
con cui però avevo una connessione. In effetti, anche con la speranza di
farmi pubblicità, negli ultimi anni accettavo le connessioni da parte di
tutti. Poi mandavo l'invito ad iscriversi alla mia newsletter e quasi
nessuno accettava.
Non accettavo le connessioni solo quando avevo il sospetto che mi avessero
scambiato per un altro Gallotti, anch'egli ex dipendente di DNV. A questi
chiedevo se per caso avessero fatto confusione, ma anche qui le risposte
sono state pochissime.
Infine ho fatto caso alle richieste che mi arrivavano: erano quelle
standard. E quindi originate da persone intente a preparare qualche phishing
o che per errore hanno premuto qualche bottone di troppo su LinkedIn.
Quindi, visto che un consulente deve essere il primo a dare l'esempio, ho
deciso: a) di rispondere gentilmente agli sconosciuti che mi chiedono la
connessione dicendo che mi connetto solo a persone che conosco nella vita
reale; b) cancellare le connessioni con sconosciuti.
Una prima pulizia mi ha portato da 466 connessioni a 395. Ma ancora molto
resta da fare. Mi scuso con quanti ho cancellato perché mi sono dimenticato
di averli effettivamente conosciuti (però, se non ho mantenuto i contatti o
i ricordi, un motivo ci sarà; o forse è solo l'effetto del mio impegno alla
riservatezza che è diventato smemoratezza?).
La morale finale credo sia ovvia: seguite voi stessi le regole che credete
siano giuste per gli altri.
ma ha una morale relativa alla sicurezza delle informazioni.
Negli ultimi mesi ho scritto, per dei clienti, delle regole in merito
all'uso dei social network. Le solite cose: non parlate con gli sconosciuti,
non scrivete cose relative all'azienda per cui lavorate, se dovete usare i
social network per finalità aziendali prestate attenzione a questo e a
quello.
Nello stesso periodo mi sono accorto delle e-mail di LinkedIn che mi
consigliavano di fare gli auguri o di congratularmi con perfetti sconosciuti
con cui però avevo una connessione. In effetti, anche con la speranza di
farmi pubblicità, negli ultimi anni accettavo le connessioni da parte di
tutti. Poi mandavo l'invito ad iscriversi alla mia newsletter e quasi
nessuno accettava.
Non accettavo le connessioni solo quando avevo il sospetto che mi avessero
scambiato per un altro Gallotti, anch'egli ex dipendente di DNV. A questi
chiedevo se per caso avessero fatto confusione, ma anche qui le risposte
sono state pochissime.
Infine ho fatto caso alle richieste che mi arrivavano: erano quelle
standard. E quindi originate da persone intente a preparare qualche phishing
o che per errore hanno premuto qualche bottone di troppo su LinkedIn.
Quindi, visto che un consulente deve essere il primo a dare l'esempio, ho
deciso: a) di rispondere gentilmente agli sconosciuti che mi chiedono la
connessione dicendo che mi connetto solo a persone che conosco nella vita
reale; b) cancellare le connessioni con sconosciuti.
Una prima pulizia mi ha portato da 466 connessioni a 395. Ma ancora molto
resta da fare. Mi scuso con quanti ho cancellato perché mi sono dimenticato
di averli effettivamente conosciuti (però, se non ho mantenuto i contatti o
i ricordi, un motivo ci sarà; o forse è solo l'effetto del mio impegno alla
riservatezza che è diventato smemoratezza?).
La morale finale credo sia ovvia: seguite voi stessi le regole che credete
siano giuste per gli altri.
giovedì 11 settembre 2014
Consiglio di Amministrazione e rischi aziendali
A giugno, Protiviti ha pubblicato un interessante documento dal titolo "Il
ruolo del Consiglio di Amministrazione nel governo dei rischi aziendali".
Esso analizza le disposizioni del Codice di Autodisciplina per le Società
Quotate, che prevede che il CdA definisca le linee di indirizzo affinché i
principali rischi risultino correttamente identificati, misurati, gestiti e
monitorati.
Il documento è di 36 pagine e mi sembra completo e ben fatto, considerando
le diverse tipologie di rischio da affrontare (includendo ovviamente quelli
di sicurezza delle informazioni). Si capisce bene, leggendolo, quanto sia
importante avere un orizzonte ampio, senza però essere dei tuttologi.
Il documento sottolinea come l'analisi del rischio di impresa non debba
ridursi al soddisfacimento del compitino richiesto dal Codice, ma debba
essere visto come potento strumento di governo.
Il link per scaricare il documento:
-
http://www.protiviti.com/it-IT/Documents/Protiviti-Il-ruolo-del-CdA0-nel-gov
erno-dei-rischi-ed-luglio-2014.pdf
ruolo del Consiglio di Amministrazione nel governo dei rischi aziendali".
Esso analizza le disposizioni del Codice di Autodisciplina per le Società
Quotate, che prevede che il CdA definisca le linee di indirizzo affinché i
principali rischi risultino correttamente identificati, misurati, gestiti e
monitorati.
Il documento è di 36 pagine e mi sembra completo e ben fatto, considerando
le diverse tipologie di rischio da affrontare (includendo ovviamente quelli
di sicurezza delle informazioni). Si capisce bene, leggendolo, quanto sia
importante avere un orizzonte ampio, senza però essere dei tuttologi.
Il documento sottolinea come l'analisi del rischio di impresa non debba
ridursi al soddisfacimento del compitino richiesto dal Codice, ma debba
essere visto come potento strumento di governo.
Il link per scaricare il documento:
-
http://www.protiviti.com/it-IT/Documents/Protiviti-Il-ruolo-del-CdA0-nel-gov
erno-dei-rischi-ed-luglio-2014.pdf
Iscriviti a:
Post (Atom)