Questa non la conoscevo, ma sembra fondamentale: una mailing list dove sono
riportate le vulnerabilità dei sistemi informatici:
- http://insecure.org/news/fulldisclosure/
Notizia tratta dal SANS NewsBites.
Sicurezza delle informazioni, IT service management e qualità da Cesare Gallotti
sabato 29 marzo 2014
lunedì 17 marzo 2014
UNI CEI ISO/IEC 27001:2014
E' stata pubblicata la traduzione italiana della ISO/IEC 27001:2013.
Ahimè... non ce l'abbiamo fatta a pubblicarla con data 2013!
La trovate su http://store.uni.com.
Ahimè... non ce l'abbiamo fatta a pubblicarla con data 2013!
La trovate su http://store.uni.com.
Direttiva UE Network and Information Security (NIS)
Massimo Cottafavi di Security Reply mi ha segnalato questo articolo sulla
Direttiva Europea "Network and Information Security (NIS)":
-
http://www.networkworld.com/news/2014/031314-new-eu-cybersecurity-law-avoids
-279681.html
Massimo mi fornisce già un commento che copio e incollo: "Interessante
l'estensione dell'obbligo di data brech alle infrastrutture critiche anche
se ancora oggi questo termine viene utilizzato in modo improprio e con un
focus "parziale" rispetto a quelle che nella realtà potrebbero essere
considerate infrastrutture critiche. Da vedere poi i tempi di recepimento
della Direttiva a livello nazionale…".
Infatti, si intendono come strutture critiche solo quelle previste dal Dlgs
61 del 2011 (energia e trasporti); gli operatori di telecomunicazione non
sono ritenuti infrastrutture critiche (nel 2014!).
Direttiva Europea "Network and Information Security (NIS)":
-
http://www.networkworld.com/news/2014/031314-new-eu-cybersecurity-law-avoids
-279681.html
Massimo mi fornisce già un commento che copio e incollo: "Interessante
l'estensione dell'obbligo di data brech alle infrastrutture critiche anche
se ancora oggi questo termine viene utilizzato in modo improprio e con un
focus "parziale" rispetto a quelle che nella realtà potrebbero essere
considerate infrastrutture critiche. Da vedere poi i tempi di recepimento
della Direttiva a livello nazionale…".
Infatti, si intendono come strutture critiche solo quelle previste dal Dlgs
61 del 2011 (energia e trasporti); gli operatori di telecomunicazione non
sono ritenuti infrastrutture critiche (nel 2014!).
domenica 16 marzo 2014
Attacco a Target e uso scorretto dei controlli di sicurezza
Dal SANS NewsBites segnalo un articolo in merito all'attacco alla Target, un
fornitore di servizi collegati alle carte di credito:
-
http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic
-hack-of-credit-card-data#p1
L'attacco alla Target è avvenuto a fine 2013 e la notizia è stata pubblicata
da molte parti. Non mi dilungo, ma ricordo solo che dei malintenzionati sono
riusciti a rubare 40 milioni di numeri di carte di credito.
La cosa interessante, a mio parere, è soprattutto questa: Target aveva
superato l'audit PCI per gestire i dati delle carte di credito e aveva
installato il prodotto FireEye (da affiancare ad un prodotto Symantec) per
rilevare malware sui propri sistemi. Il prodotto FireEye era costato 1,6
milioni di dollari e ha funzionato: quando i malintenzionati avevano
installato il malware sui server della Target per poi recuperare i numeri di
carte di credito, FireEye ha lanciato allarmi al SOC e... nessuno ne ha
fatto nulla.
Qui si sono sommate due pratiche nefaste:
- certificarsi per avere il pezzo di carta e avviare progetti solo per dare
prove agli auditor (tra l'altro, allo stesso costo del miglioramento reale,
perché 1,6 milioni di dollari non sono uno scherzo);
- acquistare e, forse, installare prodotti (a costo elevato) e non pensare
ai processi.
Temo che, come sempre, nessuno imparerà la lezione.
fornitore di servizi collegati alle carte di credito:
-
http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic
-hack-of-credit-card-data#p1
L'attacco alla Target è avvenuto a fine 2013 e la notizia è stata pubblicata
da molte parti. Non mi dilungo, ma ricordo solo che dei malintenzionati sono
riusciti a rubare 40 milioni di numeri di carte di credito.
La cosa interessante, a mio parere, è soprattutto questa: Target aveva
superato l'audit PCI per gestire i dati delle carte di credito e aveva
installato il prodotto FireEye (da affiancare ad un prodotto Symantec) per
rilevare malware sui propri sistemi. Il prodotto FireEye era costato 1,6
milioni di dollari e ha funzionato: quando i malintenzionati avevano
installato il malware sui server della Target per poi recuperare i numeri di
carte di credito, FireEye ha lanciato allarmi al SOC e... nessuno ne ha
fatto nulla.
Qui si sono sommate due pratiche nefaste:
- certificarsi per avere il pezzo di carta e avviare progetti solo per dare
prove agli auditor (tra l'altro, allo stesso costo del miglioramento reale,
perché 1,6 milioni di dollari non sono uno scherzo);
- acquistare e, forse, installare prodotti (a costo elevato) e non pensare
ai processi.
Temo che, come sempre, nessuno imparerà la lezione.
sabato 15 marzo 2014
Prossimi appuntamenti
Il giovedì 20 marzo parlo al Security Summit di Milano, con Fabio Guasconi,
di "Le nuove norme della famiglia 27000":
- https://www.securitysummit.it/milano-2014/
Il 5 giugno organizzo, come membro del Consiglio direttivo di DFA
(www.perfezionisti.it), alla Statale di Milano, il DFA Open Day 2014 su
questi due argomenti:
- OSINT e Investigazioni Digitali
- Security e Incident Response aziendale
Maggiori informazioni saranno date nei prossimi mesi.
di "Le nuove norme della famiglia 27000":
- https://www.securitysummit.it/milano-2014/
Il 5 giugno organizzo, come membro del Consiglio direttivo di DFA
(www.perfezionisti.it), alla Statale di Milano, il DFA Open Day 2014 su
questi due argomenti:
- OSINT e Investigazioni Digitali
- Security e Incident Response aziendale
Maggiori informazioni saranno date nei prossimi mesi.
mercoledì 5 marzo 2014
Presentazione audit
Il 27 febbraio ho tenuto una lezione sugli audit presso la Facoltà di
giurisprudenza dell'Università statale di Milano per il modulo "Le ispezioni
e gli accertamenti del Garante: modalità di svolgimento, sanzioni comminate
e strategie di difesa " del Corso di perfezionamento in privacy e data
protection:
- http://www.cesaregallotti.it/Pdf/Pubblicazioni/2014-Audit.pdf
La pagina web da cui scaricarla:
- http://www.cesaregallotti.it/Pubblicazioni.html
giurisprudenza dell'Università statale di Milano per il modulo "Le ispezioni
e gli accertamenti del Garante: modalità di svolgimento, sanzioni comminate
e strategie di difesa " del Corso di perfezionamento in privacy e data
protection:
- http://www.cesaregallotti.it/Pdf/Pubblicazioni/2014-Audit.pdf
La pagina web da cui scaricarla:
- http://www.cesaregallotti.it/Pubblicazioni.html
Progettazione, ingegnerizzazione e sviluppo (ossia, "Parole")
A febbraio mi ero chiesto e avevo chiesto quali fossero le differenze tra
progettazione (design) e ingegnerizzazione (engineering):
- http://blog.cesaregallotti.it/2014/02/principi-di-sicurezza-per.html
Premetto che, in effetti, non avevo dubbi tra progettazione e
ingegnerizzazione, ma tra sviluppo (development) e ingegnerizzazione.
Scrivendo mi sono confuso (era S. Valentino...), ma poi le risposte di
Andrea Rui e Fabrizio Monteleone (DNV GL) mi hanno segnalato l'errore.
Fabrizio Monteleone mi ha anche ricordato che " la progettazione equivale a
ideare un prodotto sulla base di requisiti; l'ingegnerizzazione significa
cercare il miglior modo di realizzarlo (quali pezzi usare, possibilità di
riutilizzare cose di un prodotto simile, futura manutenzione, ....) prima di
poter rilasciare il progetto per la produzione". In poche parole:
"l'ingegneria del software cerca di fornire le regole per il processo di
produzione e quindi le regole di ingegnerizzazione sicura e le regole di
sviluppo sicuro sono la stessa cosa".
Altri, a cui ho confidato il medesimo dubbio, la pensano più o meno allo
stesso modo, ma usano il termine "sviluppo" solo per la realizzazione del
software, ossia per la codifica. Usano il termine "ingegnerizzazione" per
modellare sistemi, oggetti e database. Loro potrebbero ingegnerizzare senza
sviluppare. Non ho approfondito oltre, ma sicuramente dovranno configurare
dei sistemi per produrre il servizio ingegnerizzato.
Per Andrea Rui (e anche per la ISO 9001, che differenzia "progettazione e
sviluppo" e "realizzazione"), invece "lo sviluppo è quella fase che ti
porta dalle specifiche al prototipo; l'ingegnerizzazione è quella fase che
ti porta da questo al prodotto finale".
Rileggendo la NIST SP 800-27, vedo che i principi di ingegnerizzazione si
applicano a tutte le fasi del ciclo di vita di un sistema: initiation,
sviluppo o acquisizione, test e installazione, conduzione e manutenzione,
eliminazione.
Riassumendo: per Fabrizio Monteleone prima si ha la progettazione, poi
l'ingegnerizzazione e infine lo sviluppo; per Andrea Rui prima si ha la
progettazione, poi lo sviluppo e infine l'ingegnerizzazione; per la NIST SP
800-27, l'ingegnerizzazione comprende la progettazione e lo sviluppo.
Questo dimostra ancora una volta come in informatica sia opportuno
condividere per bene i termini con i propri interlocutori, perché ciascuno
potrebbe utilizzarli in modi diversi. Per esperienza, quando chiedo
spiegazioni sull'uso di certi termini, mi guardano come se fossi uno
sciocco, quando sono invece loro che non hanno idea di cosa succede al di
fuori del loro piccolo mondo. Citando Andrea Rui: " sui termini occorre
spesso fare delle mappature tra i diversi significati attribuiti da enti
diversi e dai diversi contesti d'uso (insomma, occorre introdurre i
namespaces!)".
Per concludere, cito ancora Andrea Rui che mi ha ribadito dei concetti
fondamentali, a prescindere dalla terminologia utilizzata: "trattandosi di
fasi distinte, a cui lavorano figure e persone diverse attraverso attività
diverse, occorre che per ciascuna siano analizzati i rischi e definite le
appropriate misure di sicurezza da adottare; inizialmente occorre
identificare i requisiti di sicurezza legati alle caratteristiche e
funzionalità; per quanto riguarda la realizzazione, occorre identificare a
priori tutti i requisiti di sicurezza che il processo di realizzazione
(analisi, sviluppo, ecc.) deve avere per assicurare che il processo di
gestione del ciclo di vita del prodotto non limiti o riduca la sicurezza
progettata".
progettazione (design) e ingegnerizzazione (engineering):
- http://blog.cesaregallotti.it/2014/02/principi-di-sicurezza-per.html
Premetto che, in effetti, non avevo dubbi tra progettazione e
ingegnerizzazione, ma tra sviluppo (development) e ingegnerizzazione.
Scrivendo mi sono confuso (era S. Valentino...), ma poi le risposte di
Andrea Rui e Fabrizio Monteleone (DNV GL) mi hanno segnalato l'errore.
Fabrizio Monteleone mi ha anche ricordato che " la progettazione equivale a
ideare un prodotto sulla base di requisiti; l'ingegnerizzazione significa
cercare il miglior modo di realizzarlo (quali pezzi usare, possibilità di
riutilizzare cose di un prodotto simile, futura manutenzione, ....) prima di
poter rilasciare il progetto per la produzione". In poche parole:
"l'ingegneria del software cerca di fornire le regole per il processo di
produzione e quindi le regole di ingegnerizzazione sicura e le regole di
sviluppo sicuro sono la stessa cosa".
Altri, a cui ho confidato il medesimo dubbio, la pensano più o meno allo
stesso modo, ma usano il termine "sviluppo" solo per la realizzazione del
software, ossia per la codifica. Usano il termine "ingegnerizzazione" per
modellare sistemi, oggetti e database. Loro potrebbero ingegnerizzare senza
sviluppare. Non ho approfondito oltre, ma sicuramente dovranno configurare
dei sistemi per produrre il servizio ingegnerizzato.
Per Andrea Rui (e anche per la ISO 9001, che differenzia "progettazione e
sviluppo" e "realizzazione"), invece "lo sviluppo è quella fase che ti
porta dalle specifiche al prototipo; l'ingegnerizzazione è quella fase che
ti porta da questo al prodotto finale".
Rileggendo la NIST SP 800-27, vedo che i principi di ingegnerizzazione si
applicano a tutte le fasi del ciclo di vita di un sistema: initiation,
sviluppo o acquisizione, test e installazione, conduzione e manutenzione,
eliminazione.
Riassumendo: per Fabrizio Monteleone prima si ha la progettazione, poi
l'ingegnerizzazione e infine lo sviluppo; per Andrea Rui prima si ha la
progettazione, poi lo sviluppo e infine l'ingegnerizzazione; per la NIST SP
800-27, l'ingegnerizzazione comprende la progettazione e lo sviluppo.
Questo dimostra ancora una volta come in informatica sia opportuno
condividere per bene i termini con i propri interlocutori, perché ciascuno
potrebbe utilizzarli in modi diversi. Per esperienza, quando chiedo
spiegazioni sull'uso di certi termini, mi guardano come se fossi uno
sciocco, quando sono invece loro che non hanno idea di cosa succede al di
fuori del loro piccolo mondo. Citando Andrea Rui: " sui termini occorre
spesso fare delle mappature tra i diversi significati attribuiti da enti
diversi e dai diversi contesti d'uso (insomma, occorre introdurre i
namespaces!)".
Per concludere, cito ancora Andrea Rui che mi ha ribadito dei concetti
fondamentali, a prescindere dalla terminologia utilizzata: "trattandosi di
fasi distinte, a cui lavorano figure e persone diverse attraverso attività
diverse, occorre che per ciascuna siano analizzati i rischi e definite le
appropriate misure di sicurezza da adottare; inizialmente occorre
identificare i requisiti di sicurezza legati alle caratteristiche e
funzionalità; per quanto riguarda la realizzazione, occorre identificare a
priori tutti i requisiti di sicurezza che il processo di realizzazione
(analisi, sviluppo, ecc.) deve avere per assicurare che il processo di
gestione del ciclo di vita del prodotto non limiti o riduca la sicurezza
progettata".
mercoledì 26 febbraio 2014
Malware The Mask
Da Crypto-Gram rilancio la notizia dell'individuazione di un nuovo malware
APT detto The Mask:
- http://www.wired.com/threatlevel/2014/02/mask/
Sembra che questo malware sia usato da 7 anni per spiare agenzie governative
soprattutto in Marocco e Brasile.
APT detto The Mask:
- http://www.wired.com/threatlevel/2014/02/mask/
Sembra che questo malware sia usato da 7 anni per spiare agenzie governative
soprattutto in Marocco e Brasile.
sabato 22 febbraio 2014
Standard ETSI per accessibilità
Da UNINFO ricevo la notizia della pubblicazione di alcuni nuovi standard
ETSI relativi all'accessibilità dei prodotti ICT. Il comunicato stampa, con
link alla pagina dove trovare gli standard:
- http://www.cencenelec.eu/News/Press_Releases/Pages/PR-2014-03.aspx
In particolare è stato pubblicato lo standard EN 301 549 dal titolo "
Accessibility requirements suitable for public procurement of ICT products
and services in Europe". Lo standard riporta molti requisiti tecnici per
rendere accessibili gli strumenti ICT a tutti.
ETSI relativi all'accessibilità dei prodotti ICT. Il comunicato stampa, con
link alla pagina dove trovare gli standard:
- http://www.cencenelec.eu/News/Press_Releases/Pages/PR-2014-03.aspx
In particolare è stato pubblicato lo standard EN 301 549 dal titolo "
Accessibility requirements suitable for public procurement of ICT products
and services in Europe". Lo standard riporta molti requisiti tecnici per
rendere accessibili gli strumenti ICT a tutti.
mercoledì 19 febbraio 2014
Libertà di link
Segnalo questo articolo di Filodiritto dal titolo " Corte di Giustizia:
libero link in libera rete, purché verso contenuti liberamente disponibili
nel sito linkato":
-
http://www.filodiritto.com/corte-di-giustizia-libero-link-in-libera-rete-pur
che-verso-contenuti-liberamente-disponibili-nel-sito-linkato
In sintesi: " Un sito internet può contenere al suo interno diversi "link"
(collegamenti internet) con cui rinvia a opere protette dal diritto
d'autore, liberamente accessibili in altri siti, senza il consenso dei
titolari del diritto".
Meno male: sono anni che lo faccio sul blog e sulla newsletter e non mi era
mai sorto il dubbio di commettere reato. Infatti non lo facevo, ma ora ne ho
la conferma al 100%.
libero link in libera rete, purché verso contenuti liberamente disponibili
nel sito linkato":
-
http://www.filodiritto.com/corte-di-giustizia-libero-link-in-libera-rete-pur
che-verso-contenuti-liberamente-disponibili-nel-sito-linkato
In sintesi: " Un sito internet può contenere al suo interno diversi "link"
(collegamenti internet) con cui rinvia a opere protette dal diritto
d'autore, liberamente accessibili in altri siti, senza il consenso dei
titolari del diritto".
Meno male: sono anni che lo faccio sul blog e sulla newsletter e non mi era
mai sorto il dubbio di commettere reato. Infatti non lo facevo, ma ora ne ho
la conferma al 100%.
ATM e dispositivi medici
Sul SANS NewsBites del 18 febbraio ci sono due notizie a mio parere
collegate.
La prima riguarda gli ATM (ossia i Bancomat): in un Paese ignoto, dei
malfattori sono riusciti a manomettere gli ATM e, inserendo una chiave USB,
ottenere i soldi:
-
http://www.darkreading.com/attacks-breaches/criminals-control-cash-out-banks
-atm-mac/240166070
La seconda i dispositivi medici negli ospedali: il US Department of Health
and Human Services (HHS) Office of Inspector General (OIG) ha deciso di
effettuare degli audit presso gli ospedali per verificare se i loro
dispositivi sono configurati per garantire un adeguato livello di sicurezza
ai dati dei pazienti:
-
http://www.govinfosecurity.com/oig-to-review-medical-device-security-a-6490
Cosa hanno in comune queste due notizie? Traduco liberamente e modifico un
poco il commento sul caso degli ATM di Murray, editor del SANS NewsBites:
"un tempo questi dispositivi erano solidi, presso dei locali controllati,
utilizzavano del software proprietario ad hoc, con reti e protocolli ad hoc,
condotti e gestiti dall'ente stesso. Oggi questi dispositivi sono come degli
elettrodomestici, siti in locali non sempre controllati, con software
solitamente installato su Windows, su reti e protocolli pubblici, condotti e
gestiti da terze parti. Questo ha fatto aumentare le possibilità di attacco
e le vulnerabilità; le notizie sugli attacchi possono essere drammatiche, ma
non sorprendenti".
Qui, a mio parere, è sottintesa un'altra conclusione. Provo a riassumerla,
insieme all'ipotesi: "sono cambiate le architetture dei dispositivi e i loro
interfacciamenti, ma produttori, installatori, manutentori e utilizzatori
continuano a progettarli, installarli, mantenerli e usarli come se ciò non
fosse mai successo".
collegate.
La prima riguarda gli ATM (ossia i Bancomat): in un Paese ignoto, dei
malfattori sono riusciti a manomettere gli ATM e, inserendo una chiave USB,
ottenere i soldi:
-
http://www.darkreading.com/attacks-breaches/criminals-control-cash-out-banks
-atm-mac/240166070
La seconda i dispositivi medici negli ospedali: il US Department of Health
and Human Services (HHS) Office of Inspector General (OIG) ha deciso di
effettuare degli audit presso gli ospedali per verificare se i loro
dispositivi sono configurati per garantire un adeguato livello di sicurezza
ai dati dei pazienti:
-
http://www.govinfosecurity.com/oig-to-review-medical-device-security-a-6490
Cosa hanno in comune queste due notizie? Traduco liberamente e modifico un
poco il commento sul caso degli ATM di Murray, editor del SANS NewsBites:
"un tempo questi dispositivi erano solidi, presso dei locali controllati,
utilizzavano del software proprietario ad hoc, con reti e protocolli ad hoc,
condotti e gestiti dall'ente stesso. Oggi questi dispositivi sono come degli
elettrodomestici, siti in locali non sempre controllati, con software
solitamente installato su Windows, su reti e protocolli pubblici, condotti e
gestiti da terze parti. Questo ha fatto aumentare le possibilità di attacco
e le vulnerabilità; le notizie sugli attacchi possono essere drammatiche, ma
non sorprendenti".
Qui, a mio parere, è sottintesa un'altra conclusione. Provo a riassumerla,
insieme all'ipotesi: "sono cambiate le architetture dei dispositivi e i loro
interfacciamenti, ma produttori, installatori, manutentori e utilizzatori
continuano a progettarli, installarli, mantenerli e usarli come se ciò non
fosse mai successo".
lunedì 17 febbraio 2014
ISO/IEC 27000:2014 (errata corrige)
Avevo precedentemente annunciato la pubblicazione della ISO/IEC 27000:2012,
ma volevo annunciare la pubblicazione della versione del 2014. Grazie a
Franco Ruggieri e Fabio Guasconi per avermi avvisato per primi.
Mi scuso con tutti e confermo che la norma si può trovare a questo link:
- http://standards.iso.org/ittf/PubliclyAvailableStandards/
ma volevo annunciare la pubblicazione della versione del 2014. Grazie a
Franco Ruggieri e Fabio Guasconi per avermi avvisato per primi.
Mi scuso con tutti e confermo che la norma si può trovare a questo link:
- http://standards.iso.org/ittf/PubliclyAvailableStandards/
sabato 15 febbraio 2014
Ragazzi in rete
I ragazzi, come recentemente si è letto sulle prime pagine dei giornali, si
suicidano a causa del cyberbullismo:
-
http://www.corriere.it/cronache/14_febbraio_12/cerca-aiuto-online-ma-insulta
no-suicida-14-anni-c48f9e5a-93a8-11e3-84f1-d7c36ce692b4.shtml
Queste notizie non possono non turbarci.
Stefano Ramacciotti, Coordinatore GdL Educazione alla Sicurezza Informatica
per (ISC)2 Italy Chapter, ha inviato ai soci di (ISC)2 dei link
interessanti.
EU Kids Online, un'indagine effettuata a partire dal 2009 su incarico della
Commissione Europea in 25 paesi dell'Unione, con l'obiettivo di conoscere
cosa fanno i ragazzi in rete e il livello di competenza nell'utilizzo delle
TIC ha coinvolto 25.000 giovani dai 9 ai 16 anni e i genitori. Il report è
disponibile al link:
http://www.lse.ac.uk/media@lse/research/EUKidsOnline/EU%20Kids%20III/Reports
/PerspectivesReport.pdf
A guide for parents. Education and new media:
http://www.saferinternetday.org/c/document_library/get_file?uuid=15f5f3ac-e6
bb-4760-b6b0-eb4ca46a9829&groupId=10136
The Web We Want:
http://www.saferinternet.org/c/document_library/get_file?uuid=10c06ff7-9263-
4996-a7d3-116340b9fe6f&groupId=10137
suicidano a causa del cyberbullismo:
-
http://www.corriere.it/cronache/14_febbraio_12/cerca-aiuto-online-ma-insulta
no-suicida-14-anni-c48f9e5a-93a8-11e3-84f1-d7c36ce692b4.shtml
Queste notizie non possono non turbarci.
Stefano Ramacciotti, Coordinatore GdL Educazione alla Sicurezza Informatica
per (ISC)2 Italy Chapter, ha inviato ai soci di (ISC)2 dei link
interessanti.
EU Kids Online, un'indagine effettuata a partire dal 2009 su incarico della
Commissione Europea in 25 paesi dell'Unione, con l'obiettivo di conoscere
cosa fanno i ragazzi in rete e il livello di competenza nell'utilizzo delle
TIC ha coinvolto 25.000 giovani dai 9 ai 16 anni e i genitori. Il report è
disponibile al link:
http://www.lse.ac.uk/media@lse/research/EUKidsOnline/EU%20Kids%20III/Reports
/PerspectivesReport.pdf
A guide for parents. Education and new media:
http://www.saferinternetday.org/c/document_library/get_file?uuid=15f5f3ac-e6
bb-4760-b6b0-eb4ca46a9829&groupId=10136
The Web We Want:
http://www.saferinternet.org/c/document_library/get_file?uuid=10c06ff7-9263-
4996-a7d3-116340b9fe6f&groupId=10137
venerdì 14 febbraio 2014
US Government's Cybersecurity-Framework
Preannunciato dal SANS NewsBites, è stato pubblicato il US Government's
Cybersecurity Framework e lo si trova a questa pagina:
- http://www.nist.gov/cyberframework/
Ho cercato di capire di cosa si tratta. Riducendo al massimo, mi pare dica:
fate un risk assessment e stabilite quali funzioni di sicurezza applicare.
Mi ricorda un po' troppo la ISO/IEC 27001, se non che la descrizione delle
misure di sicurezza si riduce a circa 100 titoli.
Per la verità, per ciascun titolo sono riportati i documenti dove la
funzione è meglio descritta (CCS CSC, COBIT 5, ISA 62443-2-1:2009, ISA
62443-3-3:2013, ISO/IEC 27001:2013 e NIST SP 800-53 Rev. 4). Ma allora che
serve avere un nuovo elenco di misure (o controlli, o funzioni) di
sicurezza?
Un po' interessante è la suddivisione delle misure in 5 famiglie:
identificazione, protezione, rilevazione, risposta e ripristino.
Un altro aspetto interessante è la possibilità di stabilire il livello
(Tiers) di attuazione del framework, sulla base di valutazioni del processo
di risk managment, integrazione del programma di risk management e di
partecipazione di entità esterne. La descrizione dei livelli è ridotta
poche righe e mi pare un po' poco.
Se qualcuno vuole segnalare posizioni diverse è il benvenuto.
Cybersecurity Framework e lo si trova a questa pagina:
- http://www.nist.gov/cyberframework/
Ho cercato di capire di cosa si tratta. Riducendo al massimo, mi pare dica:
fate un risk assessment e stabilite quali funzioni di sicurezza applicare.
Mi ricorda un po' troppo la ISO/IEC 27001, se non che la descrizione delle
misure di sicurezza si riduce a circa 100 titoli.
Per la verità, per ciascun titolo sono riportati i documenti dove la
funzione è meglio descritta (CCS CSC, COBIT 5, ISA 62443-2-1:2009, ISA
62443-3-3:2013, ISO/IEC 27001:2013 e NIST SP 800-53 Rev. 4). Ma allora che
serve avere un nuovo elenco di misure (o controlli, o funzioni) di
sicurezza?
Un po' interessante è la suddivisione delle misure in 5 famiglie:
identificazione, protezione, rilevazione, risposta e ripristino.
Un altro aspetto interessante è la possibilità di stabilire il livello
(Tiers) di attuazione del framework, sulla base di valutazioni del processo
di risk managment, integrazione del programma di risk management e di
partecipazione di entità esterne. La descrizione dei livelli è ridotta
poche righe e mi pare un po' poco.
Se qualcuno vuole segnalare posizioni diverse è il benvenuto.
Principi di sicurezza per l'ingegnerizzazione IT
Lo confesso: di fronte al controllo A.14.2.5 "Principi per l'ingegnerizzazione sicura dei sistemi" della ISO/IEC 27001:2013 sono rimasto perplesso perché non capivo in cosa differisse dal controllo A.14.1.1 "Analisi e specifica dei requisiti per la sicurezza delle informazioni".
Ho trovato la SP800-27, meraviglioso documento del NIST dal titolo "Engineering Principles for Information Technology Security (A Baseline for Achieving Security)":
- http://csrc.nist.gov/publications/PubsSPs.html
Lo trovo molto interessante, anche se continuo a non capire quali possano essere le differenze tra "specificare i requisiti di sicurezza" e "applicare principi di ingegnerizzazione sicura". Non capisco neanche quali siano le differenze tra progettazione (design) e ingegnerizzazione. Forse qualche lettore mi aiuterà...
Ho trovato la SP800-27, meraviglioso documento del NIST dal titolo "Engineering Principles for Information Technology Security (A Baseline for Achieving Security)":
- http://csrc.nist.gov/publications/PubsSPs.html
Lo trovo molto interessante, anche se continuo a non capire quali possano essere le differenze tra "specificare i requisiti di sicurezza" e "applicare principi di ingegnerizzazione sicura". Non capisco neanche quali siano le differenze tra progettazione (design) e ingegnerizzazione. Forse qualche lettore mi aiuterà...
mercoledì 5 febbraio 2014
Un errore di battitura ed ecco il malware!
Dal SANS NewsBytes segnalo questa notizia sugli errori di programmazione:
- http://www.bbc.co.uk/news/technology-26016802
In breve: sui siti del National Health Service del UK alcuni link
rimandavano a siti pubblicitari o infestati da malware perché il
programmatore aveva scritto Googleaspis al posto di Googleapis. Mi chiedo
come abbiano fatto i test, ma questo caso rimane molto utile per ricordare
come la programmazione sia un lavoro molto delicato.
- http://www.bbc.co.uk/news/technology-26016802
In breve: sui siti del National Health Service del UK alcuni link
rimandavano a siti pubblicitari o infestati da malware perché il
programmatore aveva scritto Googleaspis al posto di Googleapis. Mi chiedo
come abbiano fatto i test, ma questo caso rimane molto utile per ricordare
come la programmazione sia un lavoro molto delicato.
venerdì 31 gennaio 2014
Phishing alla CNN
Questo caso mi sembra interessante da analizzare (dal SANS NewsBites):
-
http://www.darkreading.com/attacks-breaches/report-phishing-attacks-enabled-
sea-to-c/240165675
In sintesi:
- le spie siriane (SEA) hanno inviato messaggi di phishing ben fatti al
personale CNN;
- una persona di CNN ha creduto al messaggio e si è connessa con la propria
user-id e password ad un sito fasullo;
- quelli della SEA hanno quindi usato il suo account per inviare tweet e
post sul blog della CNN;
- la SEA ha usato il suo account anche per inviare altri messaggi di
phishing; 5 nuove persone ci hanno creduto e hanno fornito le proprie
credenziali al sito fasullo della SEA.
-
http://www.darkreading.com/attacks-breaches/report-phishing-attacks-enabled-
sea-to-c/240165675
In sintesi:
- le spie siriane (SEA) hanno inviato messaggi di phishing ben fatti al
personale CNN;
- una persona di CNN ha creduto al messaggio e si è connessa con la propria
user-id e password ad un sito fasullo;
- quelli della SEA hanno quindi usato il suo account per inviare tweet e
post sul blog della CNN;
- la SEA ha usato il suo account anche per inviare altri messaggi di
phishing; 5 nuove persone ci hanno creduto e hanno fornito le proprie
credenziali al sito fasullo della SEA.
lunedì 27 gennaio 2014
ISO/IEC 27000:2014
E' stata pubblicata la ISO/IEC 27000:2014 dal titolo "Information security
management systems — Overview and vocabulary". In poche parole, si tratta
delle definizioni delle norme della famiglia ISO/IEC 27000.
La norma è disponibile gratuitamente dall'URL:
- http://standards.iso.org/ittf/PubliclyAvailableStandards/
Sono anche disponibili le versioni del 2009 e del 2012, ma, ovviamente, sono superate.
management systems — Overview and vocabulary". In poche parole, si tratta
delle definizioni delle norme della famiglia ISO/IEC 27000.
La norma è disponibile gratuitamente dall'URL:
- http://standards.iso.org/ittf/PubliclyAvailableStandards/
Sono anche disponibili le versioni del 2009 e del 2012, ma, ovviamente, sono superate.
NIST SP 800-53 rev 4.1
Il NIST ha annuciato la pubblicazione della rev 4.1 della Special
Publication 800-53 dal titolo "Security and Privacy Controls for Federal
Information Systems and Organizations".
Si tratta di un bel malloppone di 460 pagine; le prime 157 sono di
introduzione, mentre le restanti riportano il catalogo di misure di
sicurezza.
Interessante è la messa a disposizione di un file xml delle 4.124 misure di
sicurezza, che può quindi essere utilizzato per check list o altro.
Certamente, 4.124 misure sono tante!
Il link:
- http://csrc.nist.gov/publications/PubsSPs.html#800-53
Publication 800-53 dal titolo "Security and Privacy Controls for Federal
Information Systems and Organizations".
Si tratta di un bel malloppone di 460 pagine; le prime 157 sono di
introduzione, mentre le restanti riportano il catalogo di misure di
sicurezza.
Interessante è la messa a disposizione di un file xml delle 4.124 misure di
sicurezza, che può quindi essere utilizzato per check list o altro.
Certamente, 4.124 misure sono tante!
Il link:
- http://csrc.nist.gov/publications/PubsSPs.html#800-53
venerdì 24 gennaio 2014
Creative Commons 4.0
Le Creative Commons sono licenze per chi desidera condividere i propri
lavori con "alcuni diritti riservati". Per saperne di più:
- http://www.creativecommons.it/
A novembre 2013 sono state aggiornate alla versione 4.0. Potete trovare le
novità sia sul sito italiano appena citato, sia qui:
- http://creativecommons.org/Version4
Ahimè... dovrò cambiare blog, sito e newsletter...
lavori con "alcuni diritti riservati". Per saperne di più:
- http://www.creativecommons.it/
A novembre 2013 sono state aggiornate alla versione 4.0. Potete trovare le
novità sia sul sito italiano appena citato, sia qui:
- http://creativecommons.org/Version4
Ahimè... dovrò cambiare blog, sito e newsletter...
Iscriviti a:
Post (Atom)