martedì 29 marzo 2016

ISO/IEC 30121 - Governance of digital forensic

A marzo 2015 è stata pubblicata la ISO/IEC 30121 dal titolo "Governance of digital forensic risk framework":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53241.

Se togliamo copertina, indice, appendici e altre cose, rimangono 3 pagine. Queste 3 pagine non dicono nulla né di interessante né di utile. Mi chiedo perché l'abbiano voluta pubblicare.

In realtà lo so: qualcuno ha proposto al comitato (ISO/IEC JTC1 SC40) la norma e nessuno ha avuto la voglia di bocciare l'idea. In realtà, alcuni l'hanno appoggiata per potersi poi vantare con amici, parenti, clienti e potenziali clienti di aver scritto uno standard sulla digital forensics. Con la speranza che nessuno vada a vedere quale (nullo) contributo sia stato dato alla materia.

Se però sbaglio, vi prego di dirmelo e mi scuserò.

PS. Angus Marshall su LinkedIn mi ha fatto notare che questo standard ha almeno una funzione:  usando il termine "governance", rende la digital forensics aziendale un tema della Direzione e non solo dei tecnici. Io continuo a pensare che mi sembra un po' poco per un nuovo standard, ma almeno ne ho capito la finalità.

sabato 26 marzo 2016

SPID già in difficoltà

Segnalo questo posti di Daniele Tumietto:
- https://www.linkedin.com/pulse/il-consiglio-di-stato-annulla-definitivamente -i-criteri-tumietto.

Come noto, SPID è il sistema pubblico di identità digitale, lanciato ufficialmente il 15 marzo scorso.

Il Consiglio di Stato ha però bocciato i criteri di qualifica dei fornitori di SPID, che prevedevano 5 milioni di capitale sociale. Il modello era infatti incentrato sulla presenza di pochissimi fornitori di grandi proporzioni economiche.

Vedremo cosa succederà.

venerdì 25 marzo 2016

Rapporto Clusit 2016

Segnalo la pubblicazione del Rapporto Clusit 2016, forse la pubblicazione italiana più importante in materia di sicurezza informatica (tranne la mia newsletter, ovviamente!):
- http://clusit.it/rapportoclusit/.

A parte gli scherzi, una prima e veloce lettura mi è sembrata molto interessante. Per esempio ho imparato che il nostro CERT nazionale è attivo e ha un sito web interessante (https://www.certnazionale.it/), con diverse segnalazioni utili. C'è anche il CERT di Poste Italiane (www.picert.it), ma il loro sito mi è sembrato meno interessante e meno aggiornato.

C'è altro ancora, ma, per saperlo, vi consiglio di leggerlo.

mercoledì 23 marzo 2016

Analisi attacco a centrale elettrica ucraina

ll SANS ha pubblicato un'analisi dell'attacco del 23 dicembre 2015 ad una centra elettrica ucraina:
- http://www.darkreading.com/vulnerabilities---threats/lessons-from-the-ukraine-electric-grid-hack/d/d-id/1324743.

Ho segnalato l'articolo di Darkreading perché è una pagina web dove si trova il link al pdf del SANS. E poi riporta le stesse cose ma più sinteticamente.

Io l'ho capita così: gli attaccanti hanno inviato email mirate (spear phishing) a degli addetti della centrale. Hanno anche allegato dei file (Word, Excel) con delle macro nocive. Gli addetti hanno aperto i file ed è stato l'inizio della fine.

L'articolo prosegue indicando le misure di sicurezza da prevedere per evitare questi attacchi. A me sembrano decisamente complicate. Io tornerei alle basi: se si lavora in un impianto critico, la rete industriale deve essere completamente separata da quella usata per navigare su Internet e per ricevere l'email. Se gli operatori ne hanno bisogno, date loro 2 pc collegati alle due diverse reti.

Troppo semplice? Dove sbaglio?

PS: Su LinkedIn, Damiano Bolsoni mi ha risposto dicendo che non pensa sia possibile avere due reti completamente separate. Infatti altre aree aziendali hanno la necessità di avere dati sulla produzione in tempo reale. Si possono attuare strategie di controllo di questo traffico, ma non è semplice.

Damiano Bolsoni, inoltre, mi ha fatto notare che l'attacco iniziale in Ucraina ha permesso ai malintenzionati di individuare le credenziali per usare le connessioni VPN. Se le VPN avessero avuto un meccanismo di autenticazione basato su due fattori e la rete ben segmentata, questo avrebbe migliorato le difese.

lunedì 21 marzo 2016

Diffamare via mail è reato, ma non aggravato

Questa sentenza mi sembra interessante: inviare un'email "diffamatoria" via email ad un preciso insieme di destinatari, per quanto numeroso, è sì reato, ma non aggravato:
- http://www.penalecontemporaneo.it/area/2-/6-/15-/4506-diffamazione_tramite_e_mail__aggravante_del_fatto_commesso___col_mezzo_della_stampa_o_con_qualsias
i_mezzo_di_pubblicit_____ed_eventuale_competenza_del_giudice_di_pace__una_se
ntenza_del_tribunale_di_milano/

La notizia l'ho ricevuta da un tweet di @Silvia_Mar_, che fornisce il seguente link, ma questo richiede la registrazione:
- http://www.quotidianogiuridico.it/documents/2016/03/18/diffamare-via-mail-e-reato-ma-non-aggravato.

Il caso dell’attacco informatico a Staminus Communications

Da un tweet di @TechEcon, una descrizione di un attacco (in italiano):
- http://www.techeconomy.it/2016/03/18/92899/.

Lascia perplessi l'elenco delle vulnerabilità sfruttate per condurre l'attacco. Alcune cose sono sì diffuse, ma presso una società di sicurezza fa effetto.

Nota sociale: la Staminus Communications è una società USA, quindi non è vero che gli italiani non applicano la sicurezza per "questioni culturali", ma è vero che molte aziende non applicano la sicurezza perché alla Direzione non interessa.

Cisco 2016: Annual Security Report

Fabrizio Cirilli mi ha segnalato il "Cisco 2016: Annual Security Report".

In inglese:
- http://www.cisco.com/c/m/en_us/products/security/offers/cybersecurity-reports.html?Keycode=001124371.

In Italiano:
- http://www.cisco.com/c/dam/m/it_it/offers/assets/pdfs/cisco_2016_asr_011116_it.pdf.

giovedì 17 marzo 2016

Ricette mediche elettroniche - riferimenti normativi

Mi hanno segnalato un riferimento autorevole per approfondire il decreto del Ministero economia e finanze del 2 novembre 2011, che norma la dematerializzazione della ricetta medica per le prescrizioni a carico del Servizio sanitario nazionale:
http://sistemats1.sanita.finanze.it/wps/content/portale_tessera_sanitaria/sts_sanita/home/sistema+ts+informa/medici+in+rete/ricetta+dematerializzata+dm+2+novembre+2011.

Inoltre, questo DM, che riguarda la tessera sanitaria, un collettore di svariati dati personali (!), non è stato sottoposto al parere del Garante privacy, come denunciato dal Garante stesso nella sua relazione del 2011:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/2148180.

Un grazie al mio anonimo corrispondente.

Fornitori e ruoli privacy (parte 2)

NOTA del 2018: questo articolo era di inizio 2016 ed è evidentemente sbagliato. Ha trovato risposte con la pubblicazione del GDPR.

In merito alla mia riflessione su fornitori e ruoli privacy (http://blog.cesaregallotti.it/2016/03/fornitori-e-ruoli-privacy.html), mi hanno fatto notare quanto segue.

Il Garante non si è mai espresso poiché il ricorso a sub-fornitori non è una pratica vista di buon occhio (anzi, ci sono delle posizioni negative). In altre parole, il titolare può nominare il responsabile, che però non può demandare a terzi.

Ma…..poiché la realtà è quella che è, la linea da seguire è analoga a quanto previsto nei diversi provvedimenti per i trasferimenti all'estero: ci deve essere un mandato generale o specifico affinché il responsabile possa contrarre accordi con sub-fornitori, purché ne informi il titolare e ne abbia l'approvazione.

Ecco quindi che la situazione non migliora! E il Garante, ahinoi, continua a pensare che:
a) una filiera di fornitura corta sia meglio di una lunga; non avrebbe torto, ma dovrebbe considerare che in Italia il 99% delle aziende sono PMI ultra specializzate, ed è meglio avere una filiera lunga di gente capace che una filiera corta di gente incapace; e anche all'estero è così;
b) le aziende si possano adeguare ad avere una filiera di fornitura corta; dovrebbe invece dare istruzioni chiare e praticabili su come gestire una filiera lunga;
c) tutti dovremmo nominare certi grandi operatori (o i suoi concorrenti) come responsabili esterni e chiedere di autorizzare i suoi sub-fornitori...

Differenze tra SPID e servizi fiduciari eIDAS

Andrea Caccia mi ha segnalato questo suo articolo dal titolo "Regolamento eIDAS: differenza tra i servizi di identificazione come SPID e i servizi fiduciari":
- https://www.linkedin.com/pulse/regolamento-eidas-differenza-tra-i-servizi-di-come-spid-andrea-caccia.

In questo post, come mi segnala Andrea, anche collegato al tema assicurazioni, viene illustrato il grosso dibattito in corso con riferimento alle modifiche presenti nella proposta di modifica al CAD.

Avevo un dubbio sulla PEC e Andrea (grazie!) mi ha risposto così: la PEC nella terminologia eIDAS, è un "servizio di recapito elettronico certificato".

Come si pronuncia "auditor"?

A marzo avevo dato la notizia della pubblicazione delle nuove versioni di ISO 9000 e ISO/IEC 27000, dedicate alle definizioni in ambito qualità e sicurezza delle informazioni.

Fabrizio Cirilli, che ringrazio, ha approfittato di questo per segnalarmi questo articolo dell'Accademia della crusca in merito alla pronuncia di audit, auditor, eccetera:
- http://www.accademiadellacrusca.it/it/lingua-italiana/consulenza-linguistica/domande-risposte/storia-pronuncia-termine-audit.

Pare che, in Italia, sia preferibile pronunciare "audit" alla latina e non "odit" all'inglese.

L'articolo fa riferimento a una raccomandazione riportata nella ISO 9000:2005. Confesso che non ho trovato il passaggio, ma mi adeguerò.

ISO 8000-8:2015

Franco Ferrari di DNV GL mi ha segnalato la pubblicazione della ISO 8000-8:2015 dal titolo "Information and data quality: Concepts and measuring":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=60805.

Mi sembra interessante perché definisce cosa si intende per "qualità dei dati" nelle tre categorie di sintassi, semantica e pragmatica (questa è la più complessa, in quanto comprende sicurezza, accessibilità e completezza).

Vedo che si tratta di uno standard di "requisiti", ossia certificabile, in quanto usa la forma verbale "shall".

Da notare un'altra cosa: è pubblicata anche un'altra norma sulla qualità dei dati. È la ISO/IEC 25012:2008 dal titolo "Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Data quality model". Giusto per creare un po' di confusione.

Presentazione UNINFO al Security summit

Ringrazio Domenico Squillace, presidente UNINFO, per aver messo a disposizione le slide della nostra presentazione del 16 marzo al Security summit di Milano.

L'incontro aveva come titolo "Norme tecniche nazionali e internazionali sulla sicurezza delle informazioni: ultime novità" e si trovano a questo link:
- http://www.slideshare.net/uninfoit/norme-tecniche-nazionali-e-internazionali-sulla-sicurezza-delle-informazioni-ultime-novit.

Google Vendor Security Assessment Questionnaire (VSAQ) Framework

Google ha reso disponibile il questionario che sottopone ai propri fornitori.

Il questionario è dinamico. Se la risposta non è "perfetta", l'utente è indirizzato verso una spiegazione del perché quanto dichiarato rappresenta un rischio e verso un campo in cui elencare eventuali controlli compensativi.

Penso sia il caso di leggerlo con attenzione e trarne esempio.

La pagine di Google, da cui scaricare il sorgente del questionario o accedere alla demo:
- http://google-opensource.blogspot.it/2016/03/scalable-vendor-security-reviews.html.

La notizia mi arriva dal gruppo "Certified Information Systems Auditor" di LinkedIn, che ha inoltrato un post, sempre su LinkedIn, di Aurav Agarwal.

martedì 15 marzo 2016

16 marzo: sarò al Security summit

Mercoledì 16 marzo alle 16.30 terrò un intervento al Security summit di Milano su "Norme tecniche nazionali e internazionali sulla sicurezza delle informazioni: ultime novità":
- https://www.securitysummit.it/milano-2016/seminari-associazioni/talk-244/.

Cambiare le password più raramente?

Da un tweet di @MarcoCiappelli, segnalo questo articolo dal titolo "Want safer passwords? Don't change them so often":
- http://www.wired.com/2016/03/want-safer-passwords-dont-change-often/.

In breve l'autore dice che, se si cambiano le password troppo spesso, queste risultano o banali o sempre le stesse (per esempio pippo01, pippo02, pippo03, eccetera). Si dovrebbe invece prevedere un cambio meno frequente, per esempio annuale, e chiedere di creare password più robuste e più lunghe.

Credo si debba riflettere su questo punto, non solo ricordando che la normativa italiana in materia di privacy richiede di cambiare la password ogni 3 o 6 mesi.

Se la password è lunga meno di 15 caratteri, un attaccante la individua dopo pochi minuti e quindi cambiarla dopo 3 mesi, 6 mesi o mai non cambia nulla. E oggi, forse, anche 15 caratteri non sono sufficienti.

Si potrebbe richiedere di usare dei generatori-archivi di password complesse (come ricordato dall'autore dell'articolo), ma poi nessuno vorrà bloccare il pc quando lo lascia incustodito per la pausa caffè.

In realtà, non dimentichiamocelo, uno dei motivi per chiedere di cambiare periodicamente la password è che troppi utenti, nonostante le regole fornite, la comunicano ad amici, colleghi e parenti. Cambiarla periodicamente, almeno, riduce il numero di persone che ne è in possesso. Purtroppo gli amministratori di sistema sono i primi a condividere tra loro le password e non cambiarle mai, nonostante negli anni le persone che le conoscono, a causa dei cambi di mansione o di dimissioni, sono sempre più numerose.

Fornitori e ruoli privacy

NOTA del 2018: questo articolo era di inizio 2016 ed è evidentemente sbagliato. Ha trovato risposte con la pubblicazione del GDPR.

Tempo addietro mi ero lamentato di come la normativa privacy attuale (non) tratta compiutamente le filiere di fornitura (il post iniziale, a cui ne sono seguiti altri 3, è il seguente:
http://blog.cesaregallotti.it/2011/04/privacy-dei-titolari-e-dei-responsabili.html).

In sostanza, un titolare (controller) può scegliere un responsabile (processor), ma un responsabile (processor) non può scegliere un sub-responsabile (sub-processor) per gli stessi trattamenti.

In molti casi si vedono dei responsabili che nominano i propri fornitori come... responsabili, anche se solo il titolare può nominare i responsabili.

Questi casi, purtroppo, non sono stati discussi compiutamente in questi 20 anni di normativa privacy, nonostante le filiere di fornitura diventino sempre più lunghe a causa del principio di specializzazione. In Italia, senza pensarci troppo, si nominano i fornitori come "responsabili esterni", nonostante questo sia discutibile.

L'ultima bozza d dicembre del Regolamento europeo sulla privacy sembra considerare il problema e permette ai responsabili di "coinvolgere altri responsabili", purché ne informino il titolare.

Però anche questa soluzione non è ottimale, né è adeguata ai nostri tempi. Si pensi ad una PMI che usa dei servizi di un grande operatore di telecomunicazioni o di servizi cloud: deve essere aggiornata su ogni cambiamento operato dal grande operatore? il grande operatore deve informare tutti i suoi clienti?

Pensiamo ad una normale catena di fornitura: un'azienda ha un fornitore per i servizi di predisposizione buste paga, il quale ha un fornitore per il servizio applicativo con cui predisporre le buste paga, il quale ha un fornitore di hosting, il quale ha un fornitore di manutenzione (per non parlare poi di consulenti, legali, auditor e altri coinvolti nelle attività).

Ma pensiamoci bene. Un operatore di telecomunicazioni non è un titolare? È lui quello che "determina le finalità e i mezzi per elaborare i dati personali". Un suo cliente compra quei servizi e, nella migliore delle ipotesi, dovrebbe chiedere dettagli su tali finalità e mezzi, valutare se sono allineate con le proprie finalità e misure di sicurezza, decidere se continuare ad averlo come fornitore. Il viceversa (ogni cliente chiede ai propri fornitori di seguire le proprie regole) è inapplicabile quando i numeri diventano grandi, ossia quando un fornitore ha tanti clienti e non può modificare i propri processi e meccanismi di sicurezza per ogni singolo cliente.

La bozza di Regolamento introduce le "terze parti", ma non è chiaro come interpretarle.

Speriamo questo argomento sia discusso con maggiore attenzione nel prossimo futuro.

domenica 13 marzo 2016

Check list amministratori di sistema

Luciano Quartarone (che ringrazio per la seconda volta) mi ha segnalato un'altra sua pubblicazione: una checklist per i controlli sugli Amministratori di sistema previsti dal Provvedimento del Garante privacy:
- http://www.lucianoquartarone.it/wp/?p=687.

Sono contento che abbia ripreso e migliorato il mio lavoro di qualche anno fa. Mi dimostra che si può fare sempre di meglio. E io da domani userò la sua check list.

Luciano teme che la normativa sugli Amministratori di sistema abbia "i giorni contati". Io non ne sono così convinto perché dovremo vedere gli impatti del Regolamento europeo privacy (se e quando sarà approvato) sulla normativa secondaria fin qui prodotta dal Garante. Se qualcuno ha già delle idee, lo/la prego di condividerle.

Materiale per verifiche presso CA

Luciano Quartarone (che ringrazio perché distribuisce il proprio sapere) mi ha segnalato il suo post "Framework per Certification Authority che pubblicano Certificati di Root". Oltre alla solita sbrodolata di link necessari per mettere in fila i requisiti normativi, in fondo c'è una checklist che ho utilizzato come self-assessment per impostare degli audit presso alcune CA: spero possa essere interessante.

Questo è il link:
- http://www.lucianoquartarone.it/wp/?p=670.

venerdì 11 marzo 2016

Scopre falla Facebook, premiato hacker buono

Una persona ha segnalato a Facebook una vulnerabilità (credo in una versione beta del software). Facebook ha riparato il bug e premiato il segnalante:
- http://www.ansa.it/sito/notizie/tecnologia/internet_social/2016/03/09/hacker-scopre-falla-facebook-premiato_b0fe4987-8fbf-4087-96dd-9112d5f96bfb.html.

Lo segnalo non tanto per il premio, ma per il fatto che, evidentemente, Facebook ha aperto un canale per ricevere segnalazioni e lo usa. Esempio da seguire.

mercoledì 9 marzo 2016

SPID al via

SPID è il "Sistema pubblico di identità digitale", che dovrebbe permettere un più facile interfacciamento con la Pubblica amministrazione. Nelle prossime settimane gli identity provider inizieranno a rilasciare le prime identità digitali.

Per saperne di più, segnalo questo articolo (da tweet di @FrankFormisano):
- http://www.chefuturo.it/2016/03/le-5-cose-da-sapere-su-spid/

martedì 8 marzo 2016

eIDAS: domande e risposte

Da un tweet di @andreacaccia, segnalo la pagina della Commissione EU dedicata ai servizi fiduciari del Regolamento eIDAS:
- https://ec.europa.eu/digital-single-market/news/questions-answers-trust-services-under-eidas.

Per chi si fosse perso qualche puntata: i servizi fiduciari sono quelli di firma elettronica, di sigilli elettronici, di marca temporale e di autenticazione dei siti web. Questi servizi sono oggi oggetto del Regolamento europeo eIDAS (e quindi il nostro CAD, o Codice dell'amministrazione digitale, dovrà essere emendato).

L’evoluzione della sicurezza nazionale italiana

Per chi fosse interessato, segnalo questo studio dal titolo "L'evoluzione della sicurezza nazionale italiana":
- http://www.sicurezzanazionale.gov.it/sisr.nsf/approfondimenti/levoluzione-della-sicurezza-nazionale-italiana.html.

Si parla anche di sicurezza del cyber spazio (e, ahimè, anche di minacce "cibernetiche").

DROWN

DROWN è una vulnerabilità dell'HTTPS e quindi di SSL e TLS:
- https://drownattack.com/.

La soluzione è aggiornare i server e disabilitare SSL. L'articolo fornisce chiare indicazioni.

Ovviamente sono ancora tanti (e ne ho ahimè le prove) gli amministratori di sistema che non hanno ancora disabilitato l'SSL, nonostante le numerose vulnerabilità. Anzi, alcuni amministratori di sistema non sanno neanche se l'SSL è attivo e se possono abilitare il TLS. Quando si parla della formazione...

Scheda informativa GDP sul Regolamento EU

Il Garante privacy ha tradotto il manifesto dell'Art. 29 WP sul futuro (forse!) Regolamento EU privacy (GDPR). Lo si trova a questo link, sotto "Altri documenti":
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/4443361.

Non so quanto sia chiaro per i profani, ma le illustrazioni mi piacciono.

Ricette mediche elettroniche

Segnalo questo articolo del Sole 24 Ore dal titolo "La ricetta diventa elettronica. Su carta solo un promemoria":
http://www.ilsole24ore.com/art/norme-e-tributi/2016-02-28/la-ricetta-diventa-elettronica-carta-solo-promemoria-183542.shtml.

Mi paiono interessanti alcune questioni:
- il sistema prevede un piano di continuità operativa basato sulla "vecchia" ricetta cartacea;
- come sempre si vede resistenza al cambiamento;
- però si è cautamente ottimisti ("una semplificazione delle procedure è ancora possibile"), cosa rara.

Non ne so altro (se per esempio sono state fornite indicazioni ai medici di base su come garantire la sicurezza del sistema). Sarà un tema da osservare nel tempo.

Studio sulle assicurazioni informatiche

Segnalo questo bello studio sulle "cyber-assicurazioni":
- http://www.fp7-camino.eu/assets/files/TR-17-2015.pdf.

Mi piace perché presenta una tabella con un'analisi delle assicurazioni oggi sul mercato (ne presenta 14) e ne specifica i limiti.

Ovviamente mi piace perché conferma cose che dico da tempo (come per esempio l'assenza di dati adeguati per calcolare la probabilità di una minaccia) e perché presenta uno studio approfondito sulle tecniche di gestione del rischio.

Ovviamente, non mi piace il termine "cyber-insurance" (che peraltro non viene definito), ma lo si sapeva già.

Privacy shield: testo finale ma ancora non approvato

Stanno girando molte notizie sull'approvazione del Privacy shield, ossia dell'accordo EU-USA per il trasferimento di dati personali che dovrebbe sostituire l'abrogato Safe harbour.

L'ultima notizia riguarda l'accordo sul testo, che però deve essere ancora approvato, come riportato dal comunicato stampa del 29 febbraio (segnalo il testo in inglese, perché quello in italiano è ottenuto tramite traduzione automatica):
- http://europa.eu/rapid/press-release_IP-16-433_en.htm.

Caso Apple - FBI

Il caso FBI - Apple è ormai noto a tutti. L'FBI ha chiesto all'Apple di creare delle backdoor sui propri prodotti in modo da poter condurre indagini quando necessario; Apple si è rifiutata, riaccendendo un dibattito in corso da decenni (ricordate Zimmermann e il PGP? era il 1991) ed evidentemente non concluso.

Mi astengo da ogni commento e segnalo questo confronto su Il quotidiano giuridico tra Giovanni Ziccardi (professore) e Patrizia Caputo (magistrato), forse il modo migliore per affrontare l'argomento senza inutili polemiche:
- http://www.quotidianogiuridico.it/documents/2016/03/02/apple-vs-fbi-voi-cosa-ne-pensate.

lunedì 7 marzo 2016

ISO 5500x su Asset management

Il comitato ISO SC27 (più correttamente ISO/IEC JTC 1/SC 27/WG 1; quello che si occupa della ISO/IEC 27001) di cui faccio parte ha ricevuto un aggiornamento dal comitato ISO/TC 251, che si occupa di "Asset management".

Questa introduzione per spiegare come mi sono imbattuto nelle norme della serie ISO 5500x, dedicate all'asset management. Esse sono 3 e sono tutte del 2014:
- ISO 55000, di introduzione;
- ISO 55001, con i requisiti (certificabili) di un sistema di gestione per gli asset;
- ISO 55002, guida alla gestione degli asset.

Esse derivano dalla PAS 55 del BSI.

Mi sembrano norme decisamente generali, di cui non riesco a capire i confini. Sembra si occupino di tutto (il termine "asset" può denotare sia beni intangibili che beni tangibili di ogni tipo) e in effetti i requisiti sono decisamente generici.

Ho provato anche a leggere la pubblicazione "Asset Management – an anatomy" del The institute of asset management e i miei dubbi sono rimasti tali. Essa è reperibile su:
- https://theiam.org/what-is-asset-management/anatomy-asset-management.

Ogni contributo su questo argomento è benvenuto.

ISO/IEC 27000:2016 - Vocabolario

Franco Ferrari di DNV GL mi ha segnalato l'uscita della nuova versione della ISO/IEC 27000 dal titolo "Overview and vocabulary".

Tra qualche tempo, credo, dovrebbe essere disponibile come standard pubblico al seguente sito (dove si trova ancora la versione del 2014):
- http://standards.iso.org/ittf/PubliclyAvailableStandards/.

Verizon Data breach digest

Segnalo, anche complice la pubblicità che si sono fatti, il "Data breach digest. Scenarios from the field" di Verizon. Si tratta, in definitiva, di 20 scenari di attacco. Nulla di nuovo, ma utile:
- http://www.verizonenterprise.com/verizon-insights/data-breach-digest/2016/.

Un altro elemento interessante è la relazione tra le 20 minacce e i 20 CIS Critical Security Controls, di cui già scrissi qualche tempo fa (http://blog.cesaregallotti.it/2015/11/cis-critical-security-controls.html).