"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

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/

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/

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

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

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.

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.

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

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

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.

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.

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.