Full disclosure mailing list

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.

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.

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!).

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.

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.

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

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".