lunedì 28 luglio 2014

ISO 9001:2015 DIS report dell'IRCA

In molti prevedono la pubblicazione della nuova ISO 9001 nella prima metà
2015 e questo è confermato dalla velocità con cui i lavori stanno andando
avanti. A maggio 2014 è stato pubblicato il draft della norma, ossia il
penultimo passo prima della pubblicazione (l'ultimo passo è il final draft).

In molti stanno studiando le bozze e si interrogano sugli impatti dei molti
cambiamenti che la norma subirà. In particolare, bisogna discernere i
cambiamenti formali da quelli sostanziali.

IRCA (International Register of Certificated Auditors) ha preparato un
report di 65 pagine sulla nuova 9001 (a pagamento):
-
http://www.irca.org/en-gb/resources/INform/INform-July-August-2014/Dont-miss
-IRCA-ISO-90012015-DIS-report/


Personalmente non sono d'accordo con alcune interpretazioni perché
aggiungono nuovi requisiti non previsti in realtà dalla norma stessa.
Inoltre, trovo molto povera la parte relativa all'analisi dei rischi.

Questo report mi ha fatto riguardare i paragrafi relativi alle non
conformità. Purtroppo sono scritti in maniera da lasciar intendere che per
ogni non conformità si debba individuarne le cause e stabilire se attuare
delle azioni correttive. Questo è un meccanismo perverso: se per ogni
errore, senza alcuna selezione, bisogna ricercare le cause (attività che, se
fatta correttamente, è onerosa), allora siamo sicuri che molte di queste non
conformità saranno nascoste. Spero questi requisiti siano modificati.

Segnalo inoltre che non si parla più di "miglioramento continuo" (o
"miglioramento in continuo"), ma solo di "miglioramento", perché la
precedente espressione sembrava spingesse verso il solo "miglioramento a
piccoli passi" o "kaizen".

Segnalo infine alcune cose che le organizzazioni non devono necessariamente
fare:
- rimuovere i rappresentanti per la qualità, anche se la futura 9001 non li
richiederà più: se le loro responsabilità erano funzionali agli obiettivi
dell'organizzazione, nulla impedisce di mantenerli;
- eliminare le procedure documentate che la futura 9001 non richiederà più
(per esempio, quella sugli audit interni, che in Italia è comunque bene
mantenere): se erano veramente utili, allora vanno mantenute; forse il fatto
che non siano più esplicitamente richieste dalla norma spingerà le
organizzazioni a scrivere procedure veramente utili;
- rinumerare i documenti per allinearli alla nuova disposizione dei
requisiti della futura 9001: nessuno ha mai richiesto di numerare 7.2 la
procedura per le attività commerciali, nessuno richiederà di rinumerarla 8.2
(ho sempre scoraggiato l'inserimento dei riferimenti delle norme nelle
procedure perché le fanno interpretare come adempimenti formali e niente
altro);
- modificare i documenti per usare i nuovi termini della nuova 9001 (per
esempio, "informazioni documentate" al posto di "documenti", "procedure
documentate", "registrazioni" o "fornitori esterni" al posto di
"fornitori").

Ad ogni modo, ricordo che quanto detto riguarda una bozza e non la versione
finale; inoltre si prevede che per la transizione delle organizzazioni
verranno lasciati 3 anni dalla sua pubblicazione. Suggerisco quindi di
aspettare a trarre conclusioni e avviare progetti di modifica del proprio
sistema qualità.

giovedì 24 luglio 2014

Metodi per costruire password complesse

Sono proposti sempre nuovi metodi per creare "facilmente" password
complesse. Uno di questi prevede di utilizzare, con qualche variazione, le
prime lettere di una frase.

Stefano Ramacciotti mi ha segnalato questo link con questo commento che
condivido: "Capisco che l'autore del libro sia un appassionato di sudoku, ma
inventarsi un metodo così complesso per creare delle password... Molto
meglio quello indicato nel tuo libro":
-
http://www.infosecurity-magazine.com/view/39315/review-a-password-system-tha
t-favors-puzzle-over-ease/


Stefano non dice che il metodo riportato sul mio libro me l'ha fornito lui
insieme a tante altre idee (sarò sempre in debito).

sabato 19 luglio 2014

Flusso delle informazioni

Nel 1999 andai in vacanza in Irlanda. Formula fly & drive: volo fino a
Dublino e poi macchina a noleggio prenotata via servizio web (c'erano anche
allora!). Arrivati a Dublino, il noleggiatore non trova la mia prenotazione;
indaga un po' e poi scopre che avevano registrato Cork come luogo della
consegna. Ho capito quindi che io avevo inserito i dati sul loro sito web e
poi qualcuno li ha copiati manualmente nel loro sistema di prenotazione.
L'avventura finì bene e mi diedero anche un'auto di categoria superiore.

Questa pratica (trasferimento manuale di dati da un sistema informatico ad
un altro) non è tramontata negli anni, ma mi ero dimenticato dei rischi che
pone, nonostante ne abbia avuto esperienza diretta.

Recentemente un mio cliente ha richiamato la mia attenzione su questo
rischio e finalmente ho capito il significato del controllo A.10.8.5
"Business information systems" della ISO/IEC 27001:2005. Purtroppo il
controllo era spiegato male e, evidentemente, in pochi ne avevano colto
l'importanza. Fatto sta che nella nuova versione dello standard non c'è più.
Ci rimane il controllo A.14.1.3 "Protecting application services
transactions", anche se sembrerebbe applicabile alle sole applicazioni
informatiche e non a tutto un flusso di informazioni.

venerdì 18 luglio 2014

La lunga storia degli HSM

Vi ricordate degli HSM? Sono di dispositivi necessari al protocollo di firma
digitale previsto dalla Legge italiana e dovrebbero essere certificati
relativamente alla loro sicurezza da diversi anni.

Questo post, segnalatomi da Stefano Ramacciotti (che ringrazio), commenta
l'ennesima proroga:
- http://sinetqnlap.wordpress.com/2014/07/11/hsm_ultima_spiaggia/

mercoledì 16 luglio 2014

Report sulla qualità del codice di Coverity

Stefano Ramacciotti mi ha segnalato questo interessante report sulla qualità
del codice:
- http://softwareintegrity.coverity.com/register-for-scan-report-2013.html

Lo trovo interessante perché presenta un elenco dei tipi di difetti
riscontrati nelle analisi effettuate su sorgenti C/C++ e Java. In C/C++ il
più alto numero di errori rientra nei tipi "Resource leaks", "Null pointer
dereferences" e "Control flow issues", mentre in Java gli errori più comuni
riguardano "Null pointer dereferences", "Dodgy code" e "FindBugs:
Performance".

Quello che mi chiedo è: quanti sviluppatori Java usano strumenti di analisi
come FindBugs (http://findbugs.sourceforge.net/)? Quanti sviluppatori usano
altri strumenti?

Ho paura della risposta...

Le assicurazioni relative agli incidenti IT sono un pasticcio

Articolo segnalato da Crypto-Gram dal titolo " The $10 Million Deductible:
Why the cyberinsurance industry is a mess":
-
http://www.slate.com/articles/technology/future_tense/2014/06/target_breach_
cyberinsurance_is_a_mess.html


Continuo quindi la mia piccola campagna di sensibilizzazione: se neanche le
assicurazioni sanno quantificare i rischi, perché ostinarsi a voler
realizzare valutazioni del rischio quantitative? Per non parlare di quelle
semi-quantitative (un ossimoro)?

Attacco a Code Spaces

Il 17 giugno è stato attaccato il servizio Code Spaces, che è rimasto
indisponibile per molti giorni (oggi, 16 giugno, il servizio è ancora
indisponibile). Code Spaces offre un servizio cloud di configuration
management per i codici sorgenti e si basa sull'infrastruttura (sempre
cloud) di Amazon.

Pare che un attaccante abbia iniziato con un DDoS e abbia anche sfruttato
delle credenziali di accesso alla rete interna di Code Spaces ottenute con
del phishing. Obiettivo: chiedere un riscatto per sospendere l'attacco.

Gli analisti hanno subito cominciato a dibattere sul fatto che l'accesso ai
pannelli di amministrazione del servizio Code Spaces poteva essere prevenuto
se si fosse basato su un'autenticazione a multi-fattori (o con
one-time-password; insomma, come quando bisogna usare una password
temporanea che viene inviata via SMS o e-mail).

Non solo questo, però, va considerato. Ma anche: la mancanza di un business
continuity plan, l'errore di un utente che ha risposto ad un'email
fraudolenta e non se ne è accorto neanche in un secondo momento (o forse non
ha avvisato nessuno), il fatto che questo utente (mia deduzione) abbia usato
una password con molti privilegi per un sito che può essere oggetto di
phishing. Tutte cose, tra l'altro, non applicabili al solo cloud.

La notizia l'ho ricevuta dal SANS NewsBites che a sua volta segnala questa
pagina web:
-
http://searchsecurity.techtarget.com/news/2240224102/Multifactor-authenticat
ion-key-to-cloud-security-success

Pianificare data center

Interessante questo articolo di ZeroUno:
-
http://www.zerounoweb.it/osservatori/data-center-management/pianificare-il-d
ata-center-un-metodo-per-evitare-errori.html


Alcuni dei 9 errori di pianificazione di un data center sono:
1- sottovalutazione dei costi operativi (da aggiungere a quelli di
realizzazione iniziale);
2- stima imprecisa dei costi di realizzazione;
3- sovradimensionamento;
4- pianificazione prematura dello spazio;
5- non pensare ai possibili ampliamenti futuri;
6- progetti troppo complicati.

Viene da pensare che questi errori, con le dovute specificità, siano comuni
a tanti progetti, non necessariamente di data center.

Tribunale di Napoli ed efficacia probatoria dei log

Un'azienda ha provato che un suo dipendente accedeva abusivamente alle
caselle di e-mail dei colleghi. Il dipendente è ricorso è ha vinto.

La storia è interessante perché, una volta tanto, il ricorso non è stato
vinto a causa di informative inesistenti o scritte male o per regole di
sicurezza informatica carenti, ma perché non è stata provata l'efficacia
probatoria dei log.

Infatti è stato nominato un CTU (Consulente tecnico d'ufficio) che "ha
constatato come sia stato possibile recuperare solo una copia dei log senza
possibilità di verifica della conservazione sui sistemi di origine. I
sistemi aziendali prevedono, infatti, un sistema di sovrascrittura dei file
di log originari che sono andati così distrutti e l'implementazione di copia
dei file di log" e pertanto "i sopra citati dati non siano attendibili né
affidabili. L'azienda non ha adottato adeguate misure per attestare e
precostituirsi l'immodificabilità e attendibilità dei file di log". " Nel
momento in cui è stata effettuata la copia dei log che ricollegano al pc del
ricorrente l'indirizzo Ip utilizzato – il contenuto del file non è stato
sottoposto a nessun controllo di integrità al fine di sancire l'identità
assoluta con il dato nel suo contenuto originale, così come prodotto dal
sistema. Secondo il CTU, in assenza di tali garanzie, il dato dei file di
log è alterabile. I log sono stati infatti esportati su file di testo,
consultabili e alterabili con un normale strumento di edizione".

Si legge quindi che: "Osserva il CTU che, pur potendosi prospettare in
astratto varie modalità di conservazione dei dati che avrebbero
inconfutabilmente determinato la loro immodificabilità e attendibilità, le
stesse non sono state adottate dal datore di lavoro; il sistema avrebbe
dovuto produrre log firmati digitalmente e marcati temporalmente.

L'articolo di Altalex:
-
http://www.altalex.com/index.php?idu=264948&cmd5=021c46ab76df2fd7050bbc8c56e
d7fe1&idnot=67750


Di esso non condivido assolutamente le conclusioni (che gli adempimenti
privacy erano formalistici e non sostanziali, la necessità di adottare
sistemi di audit esterni certificati, la necessità di formazione per le
aziende (che ci stanno a fare gli avvocati e i consulenti?). Condivido
invece il richiamo al Provvedimento del Garante privacy del 1 marzo 2007.

Eliminare da ITIL il processo di Configuration management

In questo articolo, segnalato dal gruppo ITIL & ISO20000 Service Management
+ ITSM di LinkedIn, è proposta l'eliminazione del processo di configuration
management da ITIL:
-
https://community.servicenow.com/community/learn/blog/2014/06/27/dear-itil-p
lease-kill-off-the-configuration-management-process


Il punto chiave è che troppe persone cercano di avere un database
omnicomprensivo e accuratissimo degli asset collegati all'informatica.
Solitamente, chi non adotta ITIL ma cerca di lavorare bene ha più "database"
(degli asset personali come pc e cellulari, dei sorgenti se sviluppano, dei
sistemi collegati alla rete, degli impianti, eccetera) e, quando possibile,
con automatismi che permettono di identificare le variazioni da un momento
all'altro.

Non credo, quindi, che il processo di configuration management vada
eliminato. Piuttosto va riconosciuto e promosso nel modo più corretto e più
funzionali alle reali esigenze di chi offre servizi e delle diverse funzioni
coinvolte (ciascuna con le sue diverse esigenze).

Da questo argomento ne viene fuori un altro: spesso, chi applica ITIL o
altri standard parla di "processo" unico, quando invece lo stesso processo
deve essere istanziato in più parti. Per esempio, il change management di un
mainframe non può essere lo stesso del change management di un sistema
Windows (per non parlare poi del fatto che il loro responsabile deve essere
diverso). Così il configuration management degli asset personali deve essere
gestito con strumenti e da persone diverse del configuration management
della rete o dei server.

lunedì 7 luglio 2014

Blackphone

Ormai in molti ne parlano: il cellulare a prova di privacy. Il blackphone si
basa su Android e utilizza un insieme di apps per la sicurezza, per navigare
senza essere tracciati, eccetera:
-
http://arstechnica.com/security/2014/06/exclusive-a-review-of-the-blackphone
-the-android-for-the-paranoid/


Al momento li hanno esauriti (cosa "solo" 630 Euro):
- https://store.blackphone.ch/

Tutto molto interessante, se solo non avete già dato tutti i vostri dati a
Google o Apple o Microsoft. Difficile...