Siamo al secondo articolo dedicato alle peculiarità delle perquisizioni dirette alla ricerca di evidenze informatiche, che ho voluto dedicare alle operazioni immediatamente conseguenti a quella che abbiamo definito l’individuazione del target.

Per ovvie ragioni di sintesi nel prosieguo farò essenzialmente riferimento a: PC Desktop, Laptop, Notebook, Netbook ed altri supporti quali hard-disk e pen-drive e pertanto volutamente tralascerò al momento, Tablet, Smartphone e “resto del mondo” intendendo in quest’ultima categoria tutto ciò che non risulta ricompreso nelle precedenti.

Sento già i primi mormorii, che ci portano inevitabilmente alla prima delle considerazioni, ovvero che una volta individuato il target, il passaggio immediatamente successivo e necessario è quello di tentare di ricondurlo ad una delle categorie suindicate. Operazione tutt’altro che facile ed immediata quella di capire cosa si ha davanti, e che richiede non poche conoscenze tecnico-informatiche, atteso che ormai quotidianamente si rinvengono nuovi dispositivi spesso sconosciuti o ancora peggio “ibridi” che in ogni caso non solo non facilitano la loro identificazione, ma rendono anche più complessa e difficile la loro successiva gestione in termini di individuazione, acquisizione e repertamento.

Invero, quanto alla loro gestione, nei termini suindicati, uno dei fondamentali problemi da affrontare è la comprensione dello “stato” di acceso o spento in cui si trova il dispositivo in questione, attese le profonde e spesso irreversibili modifiche che il dispositivo subisce allorquando è acceso e viene spento o viceversa; ma anche gli inevitabili riverberi sul piano processuale strettamente correlati a tale “stato” quanto alla consapevolezza di trovarsi a compiere accertamenti ripetibili (ex art. 359 c.p.p.) o irripetibili (ex art. 360 c.p.p.). Lasciando ai giuristi più esperti il dibattito che ormai da tempo orbita intorno alla qualificazione di accertamenti ripetibili/irripetibili, in questo articolo mi soffermerò in particolare sugli aspetti tecnico-pratici.

Ora se stabilire se ciò che abbiamo davanti è acceso o spento, appare (sottolineo appare) facile, per alcuni dispostivi, in altri è tutt’altro che così agevole ed immediato, cito a titolo di esempio tutti quegli stati di “stand-by” di alcuni dispositivi, non sempre accompagnati da spie luminose che ne indichino in qualche modo tale stato; o ancora quei dispositivi di nuova generazione comandati da remoto nei quali non sempre sono presenti spie luminose o altro (tasti on/off) utili a comprenderne/dedurne lo stato di acceso/spento.

È risaputo come le canoniche fasi di ACQUISIZIONE e PRESERVAZIONE che consistono in una serie di BEST PRATICES da applicarsi per assicurare i migliori risultati in termini di integrità e disponibilità dei dati digitali, sono strettamente correlate e dipendenti dallo stato di acceso o spento del dispositivo oggetto d’attenzione; tant’è che a seconda dello stato del target si è soliti distinguere tra l’esecuzione di dette fasi in post mortem forensic o live forensic.

Tale distinzione è tutt’ora presa a riferimento, tant’è che potremo affermare che non esiste “corso di digital forensics” e derivati che non parta da tale fondamentale assunto (strettamente collegato allo “stato” di acceso/spento del dispositivo), prima di specificare le “best pratices” da applicarsi per una corretta acquisizione e gestione del dispositivo attenzionato.

La L. 48/2008  ha di fatto sancito l’introduzione nel nostro ordinamento dei principi fondanti la digital forensics o per dirla meglio, con quel mantra: “adottando misure tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne l’alterazione”[1], il legislatore nazionale ha voluto richiamare l’adozione delle “best pratices” internazionali prevedendone importanti aspetti legati alla gestione  di  quegli  elementi  di  prova “digitali” che, presentano  peculiari caratteristiche di volatilità, fragilità e modificabilità.

Non mi addentrerò negli aspetti prettamente giuridici che a 10 anni dall’introduzione della L. 48/2008[2] costituiscono ancora un fertile terreno di dibattito tra le parti processuali interessate, ma mi vorrei soffermare su alcune considerazioni legate alla gestione dei dispositivi accesi/spenti che si possono rinvenire in sede di perquisizione.

Va premesso, che le considerazioni espresse nel prosieguo andranno sempre distinte e calibrate  in ordine al soggetto/operatore che materialmente si troverà faccia a faccia con il dispositivo, dovendosi considerare e non sottovalutare che talune operazioni tecniche sono patrimonio e  riservate a personale specializzato/qualificato che per ragioni di sintesi definirò in seguito “esperto”, usando invece al contrario, la definizione di “ordinario” per indicare tutti quei soggetti, privi di particolari qualifiche/specializzazioni, ma che comunque, si trovano per svariati motivi e cause a dover affrontare un target[3], nel corso delle operazioni di polizia.

È innegabile, anche se costituisce “amara” considerazione, rilevare come oggi più che mai chi perviene a contatto con i dispositivi digitali nel corso delle operazioni di perquisizione non sia sempre personale qualificato/specializzato, ma un “ordinario” operatore di polizia giudiziaria. Invero, nonostante le sollecitazioni della L.48/2008 ad oltre un decennio dalla sua introduzione, ancora tanta strada resta da fare su questo piano. Il panorama “anglo-americano” che vede la presenza di diverse figure nell’ambito della digital forensics (il riferimento è ad esempio alla ISO/IEC 27037 Guidelines for identification, collection an/or acquisition and preservation of digital evidence, la quale individua differenti soggetti che intervengo nel governo e nella gestione della prova digitale e precisamente: Digital Evidence First Responder (DEFR); Digital Evidence Specialist (DES); Incident Responder Specialist, Forensics Laboratory Manager (FLM)) fatica ancora, a prendere piede nel nostro paese, salvo recenti tentativi da parte delle FF.PP. che stanno sempre più orientandosi verso la formazione di personale specializzato/qualificato (assimilabile al DES suindicato) che verrà affiancato/coaudiuvato soprattutto nelle preliminari fasi della digital-forensic da personale assimilabile al succitato DEFR.

Cito ad esempio la Guardia di Finanza, ove nell’ultima circolare n. 1/2018 – Manuale Operativo in materia di contrasto all’evasione e alle frodi fiscali – Vol. II pag. 28, si legge che: “In linea generale, pertanto, in tutti gli accessi nel corso dei quali si ritenga ragionevolmente di dover eseguire acquisizioni informatiche, è opportuno disporre la partecipazione di personale in possesso di adeguate cognizioni tecniche, ancorché non munito di specifiche qualifiche. Con riguardo alla formazione del personale, questo Comando Generale ha avviato iniziative volte alla definizione di specifici percorsi formativi per la preparazione dei cosiddetti first responder, cui saranno trasferite specifiche competenze proprio nella fase di acquisizione, in linea con le previsioni degli standard internazionali in materia (ISO/IEC 27037 – Guidelines for identification, collection, acquisition, and preservation of digital evidence – Annex A).”

E’ evidente come il riferimento al personale munito di specifiche qualifiche vada invece ricondotto ai cosiddetti (C.F.D.A., di cui la medesima circolare si occupa nel successivo capoverso: “Nelle situazioni di maggiore complessità, invece, è necessario prevedere il supporto di personale qualificato Computer Forensics e Data Analysis (di seguito, CFDA), come, ad esempio, negli accessi rivolti a imprese appartenenti a gruppi multinazionali che potrebbero perciò impiegare sistemi di comunicazione e di memorizzazione delle informazioni condivisi al proprio interno, di talché l’estrazione informatica presso la singola entità in verifica potrebbe avere riverberi sulle altre consociate ovvero sul sistema nel suo complesso…”.

Anche in assenza di specifiche “denominazioni”, tuttavia, il panorama nazionale presenta diversi ed eterogenei corsi, incontri, giornate studio etc., nel corso dei quali, ad opera di formatori interni ed esterni alle FF.PP., si cerca di sensibilizzare il personale “tutto” ad un corretto approccio verso i dispositivi digitali contenenti probabili “evidenze” informatiche, mediante l’indicazione di poche ma essenziali “best pratices”.

E ciò, nell’ovvia ed inconfutabile considerazione che oggi non esiste “contesto operativo” privo di elementi “digitali” che direttamente o indirettamente risultano coinvolti nello stesso[4].

Tornando ai corsi sopra citati, si cerca da più parti con più o meno riuscite “full-immersion” di impartire ai discenti quel minimo di nozioni che gli permettano di orientarsi nel complesso, sempre in evoluzione e spesso sconosciuto mondo, della digital forensics.

Riguardando le “best pratices” ci si accorge come le stesse ricomprendano di fatto numerosi protocolli o linee guida internazionali per l’acquisizione della prova digitale. Protocolli e linee guida differenti per finalità e presupposti, ma riconosciuti internazionalmente come validi, ovvero, per dirla in sintesi, capaci di salvaguardare quegli aspetti fondamentali e vincolanti della “digital evidence” costituiti da integrità ed immodificabilità del dato acquisito.

Tali best pratices risultano ad oggi, elaborate essenzialmente da[5]:

– Agenzie Governative (DoD, USS, A.C.P.O, FBI, etc) finalizzati a coniugare aspetti tecnici a quelli procedurali/processuali;

– Elaborati a scopi commerciali: sono prevalentemente orientati all’incident response aziendale;

– Organizzazioni/agenzie nazionali o internazionali di standardizzazione (ISO 27037, RFC 3227, NIST), estremamente tecnici senza diretti rimandi al panorama giurisdizionale;

– Associazioni di “categoria” (ONIF Osservatorio Nazionale Informatica Forense[6], IISFA International Information System Computer association, DFA Digital Forensics Association, IACIS International Association of Computer Specialists , etc. ).

Ma torniamo al tema di questo articolo! Chi ha partecipato a corsi, convegni, incontri, dibattiti in materia di digital forensics avrà sentito almeno una volta un altro “mantra”…: “ se il PC è spento lo lasci spento se il PC è acceso lo spegni”, alla fine non è un ordine perentorio (vedremo poi il perché!), ma una sorta di formula di sintesi consolidatesi a parere di chi scrive, essenzialmente per questi motivi:

• Come ho già avuto modo di evidenziare la legge 48/2008, ha sollecitato ed indotto le FF.PP. a seguito della sua introduzione, ad allargare la platea del personale dotato di “sufficienti” conoscenze in materia di digital forensics, affinché come previsto dal vigente codice di procedura penale un sempre maggior numero di Ufficiali di polizia giudiziaria fosse in grado di effettuare una perquisizione informatica. Di qui la necessità, di pervenire all’effettuazione di corsi di istruzione, brevi, concisi e “only once in life” (non è detto che sia la soluzione giusta… anzi!) capaci di fornire un minimo di nozioni in prevalenza pratiche, capaci di essere apprese da chiunque ma soprattutto efficaci nel rispettare le prescrizioni imposte dal legislatore in materia. Appare evidente allora, come l’indicazione: “se il PC è spento lo lasci spento se il PC è acceso lo spegni” sia probabilmente quella che arreca “meno danni” nella generalità dei contesti operativi, ma soprattutto sia quella che può essere adottata da chiunque (intendo personale non specializzato/qualificato – digital forensics), atteso che fatte salve le difficoltà di individuazione circa il reale stato del dispositivo, il resto si risolve nella mera apprensione e repertamento del target (quando spento) o nello spegnimento dello stesso, attraverso diverse tecniche ancora oggetto di considerazione e dibattito tra i più esperti, che vanno dallo spegnimento ordinario (attraverso il tasto START di Windows per capirci), a metodi più “hard” quali il distacco dell’alimentazione elettrica dalla presa a muro o da dietro il “case”.. ..nei notebook e netbook ove possibile (sempre meno) ricordo anche di staccare la batteria![7] O ancora a metodi già più complessi per l’operatore ordinario in quanto richiedono l’apertura di una consolle e la digitazione di una stringa per esempio :  # shutdown -h now .
• Può risolversi in una situazione di “comodo” trovo il dispositivo spento, lo sequestro senza se e senza ma, lo trovo acceso lo spengo e lo sequestro lo stesso, ritrovandomi nel caso precedente. Tale assunto costituisce un fertile terreno di dibattito anche giurisprudenziale tra esigenze contrapposte di adeguatezza e proporzionalità da un lato, ed investigative e di prova informatica, dall’altro. Da un lato anche da ultimo la giurisprudenza con sentenza n.25527/2017[8], ha ribadito che non è censurabile sotto il profilo dell’adeguatezza e proporzionalità, il sequestro dell’intero PC con successiva estrazione della cosiddetta copia “bit a bit”, essendo l’attività di analisi per la selezione dei documenti contabili particolarmente complessa, ed investendo nel caso di specie l’intera attività “imprenditoriale dell’indagato”; aggiungendo a ciò,  che le operazioni di estrazioni di copia dei documenti “rilevanti” a tal fine non avrebbero potuto essere condotte in loco in un limitato arco temporale, in quanto la selezione avrebbe comportato una significativa attività di studio e analisi. Dall’altro lato sempre la giurisprudenza[9] tende a valutare il cd. Sequestro indiscriminato superfluo se non illegittimo allorquando viola il principio di proporzionalità ed adeguatezza. Per chi volesse approfondire quest’ultimo aspetto mi permetto di segnalare, anche, altro mio articolo su questa rivista, nel quale propongo analoghe riflessioni[10].
• Il personale “ordinario” spesso non è in grado di effettuare operazioni che vanno al di là del mero spegnimento e repertamento del dispositivo accesso e repertamento del dispositivo spento, non avendo alcuna cognizione circa l’ordine di volatilità del dato e purtroppo … non avendo neppure a disposizione il più delle volte l’hardware ed il software necessari all’effettuazione delle operazioni necessarie a preservarne lo stato in cui è stato trovato il reperto acceso. Neppure, detto personale “ordinario” si sente adeguatamente responsabilizzato o meglio non è adeguatamente formato ed informato sulle proprie responsabilità, preferendo nel dubbio delegare qualsivoglia operazione a personale “esperto” che però purtroppo ad oggi risulta ancora in numero inadeguato rispetto le concrete necessità operative.

Ne consegue che il mantra “se il PC è spento lo lasci spento se il PC è acceso lo spegni” può apparire una soluzione adatta alla maggior parte dei contesti operativi e che vedono la presenza di personale “ordinario” addetto alle operazioni di perquisizione.

Le cose, tuttavia, appaiono diametralmente opposte allorquando nel medesimo contesto venga invece a trovarsi personale “esperto”. In tal caso le operazioni potranno a seconda dello scenario distinguersi nelle canoniche “live” o “post mortem” forensics. Invero tale differenziazione prenderà spunto proprio dalla condizione di acceso/spento in cui verrà rinvenuto il target. Differente sarà quindi l’approccio che il personale esperto dovrà avere a seconda che il target sia rinvenuto in modalità acceso o spento.

Potremo vedere a mero titolo esemplificativo e pratico una situazione operativa nella quale vengono rinvenuti due PC uno acceso e uno spento.

Riguardo a quello spento verrà rimessa al personale esperto, eventualmente, l’opportunità di procedere attraverso l’utilizzo delle cd. “Live_Linux_Forensics” (es. DEFT, CAINE, PALLADIN, etc.) all’effettuazione di una “preview” volta ad apprenderne il contenuto. Tale operazione svolta in modalità RO (read-only) non andrà ad alterare in alcun modo i dati e permetterà al personale di perquisirne, il contenuto. In merito a tale operazione che in determinati contesti operativi e nel rispetto del decreto di perquisizione, deve trovare, ove possibile, applicazione, rimando per gli approfondimenti a quanto da me già evidenziato nell’articolo in nota 8 che precede. Ad ogni buon conto, e rimessa ogni migliore valutazione, ai responsabili dell’operazione, dopo la preview svolta sul pc spento si deciderà se procedere al sequestro dell’HD, di una partizione dello stesso o dell’intero PC (ricordo il problema spesso sottovalutato della confisca – 240 C.P.); ovvero ritenere lo stesso PC non interessante o comunque non rientrante nell’oggetto del decreto. Occorre da ultimo evidenziare come in tale ipotesi, il rischio di alterabilità dei dati presenti è più basso sempreché vengano adottate le cautele previste dalle best practices (a titolo di esempio accesso alle memorie in modalità RO (read only).

Di tutt’altra complessità è invece la gestione del PC rinvenuto acceso, al di là delle già complesse modalità di spegnimento che dovranno adottarsi. Nel caso di un dispositivo acceso e collegato alla rete è evidente come il disposto previsto dall’art. 247, comma 1-bis del codice di procedura penale assuma particolare discriminante, importanza ed attenzione, atteso l’alto tasso di modificabilità del sistema a cagione della sua continua, silente e non sempre palese dinamicità. Ecco che allora perquisire un sistema attivo diventa anche per l’“esperto” un’attività molto rischiosa in termini di genuinità, inalterabilità ed immodificabilità dei dati rinvenuti al momento dell’atto, nonché in termini di garanzie difensive da riconoscersi alla controparte.

Inoltre, e qui preme sottolineare ed evidenziare come quel mantra “se è acceso lo spegni”, non è detto che risulti essere la soluzione migliore ed ottimale… anzi!

Mi limito qui ad accennare che per eseguire una perizia informatica[11] lo spegnimento del PC comporta la perdita di tutta una serie di dati ed informazioni contenute nella RAM, purtroppo spesso sottovalutate,  ma che poi si rilevano di importanza fondamentale ad esempio: processi in esecuzione, volumi crittografati “aperti” (Truecrypt, Veracrypt, BitLocker etc.) connessioni attive, chat aperte, moduli caricati ed in utilizzo, ed aggiungerei una serie infinita di informazioni anche risalenti nel tempo che potrebbero comunque essere di interesse per il caso in trattazione. Non si esclude poi che il PC rinvenuto acceso costituisca in quel preciso momento uno stato di “flagranza di reato” che richiede un tempestivo ed immediato congelamento di determinati dati, costituenti prova del reato, che a seguito dello spegnimento dello stesso potrebbero andare persi (volumi criptati, connessioni on banking, etc).

Ancora una volta si richiede allora una sinergia tra personale esperto e responsabili delle attività finalizzata ad una accurata e precisa “analisi di contesto”.

Potrebbe invero rendersi necessario “un congelamento” dello stato della RAM del PC in esecuzione in tutti quei casi in cui uno degli elementi volatili sopra citati costituisse elemento necessario e strategico per l’indagine. Tale operazione tecnicamente di “dump” della RAM non è certo scevra di controindicazioni atteso che per procedervi sarà giocoforza necessario avviare specifici tool che in modo più o meno incisivo e diretto andranno comunque ad alterare lo stato preesistente anche della RAM. Di qui si comprende come l’analisi di contesto divenga allora imprescindibile costituendo l’ago della bilancia che andrà ad indicare all’esperto se procedere ad un mero spegnimento in tutti quei casi in cui il contenuto della RAM e le altre connessioni attive non assumono alcuna rilevanza ovvero procedere consapevolmente ad un “dump” della stessa, prima di procedere allo spegnimento del sistema. Ovviamente, analoga considerazione andrà effettuata in ordine agli eventuali volumi “decriptati” e a quelli di rete collegati in quel momento, nella considerazione che lo spegnimento del PC comporterà la perdita di detti collegamenti e della possibilità di accedere ai volumi criptati in assenza delle password/credenziali[12].

In assenza di personale esperto e dei necessari strumenti si potrà comunque procedere con metodi “alternativi” a cristalizzare in qualche modo “lo stato delle cose” video e foto sono ormai strumenti nelle mani di tutti (avete uno smartphone?), pertanto si potrà procedere anche con tali strumenti a documentare (il termine qui è giuridico) lo stato delle cose.

In conclusione l’analisi di contesto assurge ancora ad elemento strategico e fondamentale per la buona riuscita di qualsiasi operazione. Ancora una volta occorre fermarsi a riflettere, senza farsi prendere troppo la mano da indicazioni ed istruzioni che possono risultare corrette per la maggior parte dei casi ma non per tutti! Occorrerà quindi di volta in volta calarsi nel “caso” concreto e svolgere un’attenta valutazione, circa l’opportunità di procedere o meno allo spegnimento di un PC ovvero procedervi dopo aver posto in atto una serie di operazioni che quant’anche “prima facie” contrarie al dettato dell’art. 247 bis cpp possono poi invece risultare necessarie e strategiche.

Di qui il consiglio a ponderare sempre con attenzione le indicazioni fornite dalle best pratices che non a caso all’attento lettore appaiono spesso generiche e mai imperative lasciando a ragione, all’operatore un certo margine di discrezionalità circa il metodo da adottare.

Se i manuali e le indicazioni di massima assurgono a corretta indicazione per la generalità dei casi, occorre sempre valutare con attenzione il caso concreto, calandosi di volta in volta in un analisi di contesto che sappia adeguatamente valorizzare, valutare e ponderare ogni decisione intrapresa.

Troppo spesso la pedissequa applicazione delle indicazioni di massima (se acceso lo spegni, se spento lo lasci spento) non aiutano l’operatore a valutare attentamente gli effetti delle proprie azioni, purtroppo con effetti irreversibili sul piano investigativo.

Si auspica allora da parte di tutti i soggetti interessati un rinnovato interesse volto magari ad abbandonare certe definizioni asseritamente assolute e ad abbracciare invece un nuovo metodo di affrontare i variegati contesti con ferma e piena coscienza delle azioni che si intraprendono.

Pertanto e veramente in conclusione … da oggi prima di spegnere il PC … pensateci, “esperti” od “ordinari”, … pensateci!

Note

• [1] Cfr. artt. 244, 247 e 352 c.p.p.
• [2] https://www.csigbologna.it/referenze/giurisprudenza/la-legge-48-2008-a-dieci-anni-dalla-pubblicazione/
• [3] Per un approfondimento su tali aspetti rimando il lettore ad altro mio articolo: https://www.ictsecuritymagazine.com/articoli/legge-18-marzo-2008-n-48-lufficiale-polizia-giudiziaria-dieci-anni/
• [4] Anche quando non costituiscono elementi di prova, corpo del reato etc. , sempre più spesso gli elementi digitali risultano strategici nel fornire numerose informazioni utili al prosieguo delle indagini o altre informazioni indiziarie che pur non costituendo una prova vengono comunque  considerate in sede dibattimentale dall’organo giudicante.
• [5] Ringrazio per questo elenco di sintesi e l’approfondimento sul tema “best pratices” l’eccellente articolo di Maurizio Tonellotto – http://www.vittimologia.it/rivista/articolo_tonellotto_2014-02.pdf
• [6] www.onif.it
• [7] Il dibattito su come spengere il pc è tutt’altro che sopito tra gli esperti. I motivi si attestano sostanzialmente tra una posizione prudente volta alla tutela dell’hardware e software del PC (per capirci … non è sempre buona cosa interrompere bruscamente l’alimentazione ad un pc), tanto da consigliare sempre lo spegnimento attraverso le procedure “ordinarie”; che si scontra con altra prudenzialmente volta ad impedire che attraverso lo spegnimento “canonico”/ “ordinario” si possano attivare procedure di “erase” (cancellazione sicura dei dati) dei dati con ovvie irreparabili conseguenze sul piano della successiva acquisizione “probatoria”; tra i due estremi compaiono poi diverse tecniche “intermedie” che cercano di mediare le criticità dell’una e dell’altra.  Esistono diverse tecniche di spegnimento che non utilizzano le procedure indicate dal S.O. (attraverso START)  solo a titolo di esempio alcune combinazioni di tasti o l’utilizzo di comandi da terminale/shell che impediscono di cadere nella trappola del tasto START.
• [8] Sez. V  n.25527 del 27/10/2016 dep. 2017 Storari
• [9] Sez. VI n. 24617 del 24702/2015.
• [10] https://www.ictsecuritymagazine.com/articoli/bit-stream-image-dellintero-supporto-digitale-ieri-oggi-domani/
• [11] https://www.bit4law.com/servizi-offerti/perizia-informatica/
• [12] In tal caso si renderà necessario procedere con riferimento ad eventuali volumi criptati “aperti” alla loro copia attraverso tool specifici atteso che al seguito dello spegnimento ed in assenza delle password/credenziali necessarie alla loro “riapertura” sarà molto difficoltoso, se non impossibile procedervi successivamente.

Articolo a cura di Pier Luca Toselli

L’articolo Peculiarità delle perquisizioni dirette alla ricerca di evidenze informatiche. PC acceso/PC spento, cosa fare? proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/peculiarita-delle-perquisizioni-dirette-alla-ricerca-di-evidenze-informatiche-pc-acceso-pc-spento-cosa-fare/

Nella vita reale, quando due persone conoscono un segreto, sappiamo che non può più essere considerato un segreto. Nel mondo digitale, grazie al ‘secret sharing”, le cose possono andare diversamente. Vediamo come e testiamo un esempio del sistema che ci permette di condividere segreti in modo sicuro tra più soggetti.

“Quando due persone conoscono un segreto, non è più un segreto”, cita una famosa frase di Roberto Calvi, ultimo presidente del Banco Ambrosiano di Milano, ripresa poi nel film “Le conseguenze dell’amore” di Paolo Sorrentino. Concetto piuttosto semplice ma di una solidità incontrastabile: condividendo un segreto con una o più persone se ne perde il controllo, il segreto può essere divulgato senza il nostro consenso e senza che potenzialmente ne veniamo in alcun modo a conoscenza.

Questo ovviamente vale nella vita reale, dove la matematica trova spesso difficile applicazione nei rapporti tra le persone che invece vengono regolati da principi e regole comportamentali diverse basate sulla fiducia. Nel mondo digitale, fortunatamente, possiamo trovare soluzioni che superano i rapporti fiduciari costruendo le regole su principi matematici e algoritmi.

Per poter condividere un segreto tra più soggetti, infatti, sono state ideate diverse soluzioni, tutte finalizzate a impedire a un singolo elemento del gruppo di poter divulgare le informazioni riservate senza il consenso (o la collaborazione) di altri membri del gruppo. In sostanza, si vuole far sì che un segreto rimanga un segreto anche se conosciuto da più persone, a meno che queste (o una parte di queste stabilita a priori) non si sia accordata per “sbloccare” il segreto e rendere pubbliche le informazioni.

Una delle modalità più interessanti d’implementazione di un algoritmo di condivisione di segreti tra soggetti diversi è quella proposta da Adi Shamir, crittografo israeliano già noto per essere stato co-autore dell’algoritmo a chiave pubblica RSA insieme a Ron Rivest e Len Adleman. La lettera “S” in “RSA” è infatti proprio l’iniziale del suo nome, che quindi probabilmente molti di noi conoscono senza averlo mai associato agli algoritmi di condivisione segreti ma soltanto al noto sistema di cifratura asimmetrica.

Shamir si è posto il problema di come poter condividere un segreto tra un numero ‘n’ di persone in modo tale che per poterlo “svelare” debbano essere presenti e concordi almeno un numero ‘k’ di persone, inferiore o uguale a ‘n’.

Semplifichiamo con un esempio: i pirati e lo scrigno sepolto

In sostanza, immaginiamo che tre pirati vogliano mantenere segreto il punto esatto di un tratto di spiaggia sotto il quale è sepolto uno scrigno, con la condizione che nessuno sia in grado di andare da solo a scavare ma nello stesso tempo che la scomparsa di uno dei tre non impedisca ai due rimanenti di appropriarsi del bottino. Non possono dividere la mappa con le coordinate in tre, perché da un lato, non è garantito che due di loro saranno in grado d’interpretarla, dall’altro uno da solo potrebbe avere elementi sufficienti per scoprire il punto in cui scavare.

Molto semplicemente, possono tracciare con uno spago una retta che interseca la spiaggia nel punto in cui è sotterrato il tesoro e posizionarsi ognuno su un punto della retta, distanti in modo da non vedere dove sono posizionati gli altri, segnandosi ognuno le coordinate del suo punto. Abbiamo quindi tre punti (le coordinate dei tre pirati) lungo i quali passa una retta (lo spago teso) che interseca la spiaggia in un punto esatto (il tesoro).

Si comincia a questo punto a scoprire il “trucco”: se due pirati vogliono recuperare il tesoro senza coinvolgere il terzo, possono autonomamente posizionarsi nei due punti loro assegnati, tendere uno spago e farlo proseguire diritto verso la spiaggia, intersecando così il punto in cui scavare. Non serve il terzo pirata, che aggiungerebbe un punto “inutile” sulla stessa retta. Non importa quale pirata manca e quali due sono presenti, sono tutti intercambiabili per raggiungere lo scopo d’intersecare con lo spago la spiaggia. Un pirata da solo, nello stesso tempo, non avrebbe idea di dove “fissare” la retta che passa verso di lui, avendo tutti i 360 gradi di rotazione a disposizione, mantenendo così il segreto… un segreto fino a che non riesce a trovare un altro pirata.

Utilizzi pratici del sistema

L’algoritmo di Shamir (e algoritmi che risolvono problemi simili) hanno numerose applicazioni pratiche. Ad esempio, vengono utilizzati pesantemente nel mondo delle criptomonete per generare portafogli definiti “multisig”, nei quali per poter spendere il contenuto di un indirizzo è necessario che siano presenti più partecipanti contemporaneamente. Il wallet è in questo modo “blindato” perché nessun singolo sarà mai in grado di svuotarlo. In alcuni casi, uno dei partecipanti può essere l’exchange stesso (così come avviene, ad esempio, con il wallet GreenAddress) rendendo quindi la sua presenza indispensabile per poter disporre dei fondi (con possibilità di sblocco in caso di scomparsa dell’exchange) ma, nello stesso tempo, garantendo gli utilizzatori circa il fatto che l’exchange da solo non è in grado di sottrarre criptomoneta.

In ambito di sequestro di criptomoneta, anche, la proprietà di condivisione sicura di chiavi dei wallet è un elemento strategico, per non lasciare la responsabilità delle, spesso enormi, cifre sequestrate al singolo operatore. Una volta creato il wallet di destinazione dei fondi sequestrati, chiunque può proseguire con le attività di raccolta dei fondi e trasferimento verso di esso, ma il dissequestro (o l’accesso ai fondi, per qualunque motivò) sarà consentito soltanto ai membri del gruppo nominato dall’Autorità. Questo tutela non soltanto il proprietario dei fondi sequestrati, ma anche gli operatori, che quindi non potranno mai essere coinvolti in eventuali fuoriuscite di fondi, né tentati a farlo personalmente, come purtroppo si è visto in alcune indagini oltreoceano relative ai Black Market a seguito delle quali si è scoperto come parte delle criptomonete dell’indagato erano finite nei wallet di qualche operatore, convinto di poterla fare franca.

In ambito di sicurezza informatica, spesso è necessario custodire segreti con condizioni tali per cui l’apertura degli stessi deve avvenire solamente in presenza di un certo numero di soggetti. Possiamo parlare di file di log di sistemi con dati sensibili, dati di traffico, persino password, credenziali, “seed” di sistemi crittografici. Tutti dati che possono essere intesi come accedibili soltanto a più di una persona.

Immaginiamo poi, in ambito giudiziario, la situazione in cui un certo numero di periti vogliono poter accedere a dei dati solo quando sono tutti presenti e, nel contempo, si vuole tollerare l’assenza di uno o due periti che potrebbero non essere disponibili. Non è sufficiente suddividere la password con la quale sono stati cifrati i dati in “n” pezzi, anche creando sovrapposizioni, perché se non fatto con le dovute attenzioni rischierebbe di fornire a un gruppo inferiore al minimo stabilito la possibilità di accedere ai dati o, dall’altra parte, di richiedere più persone di quelle effettivamente disponibili durante un incontro.

Sono persino allo studio da anni sistemi d’intercettazione che archivino quanto acquisito dalle sonde (es. telefonate, traffico telematico, etc…) in modo che gli operatori non siano in grado – da soli – di accedere al materiale intercettato, rendendo invece indispensabile la presenza, ad esempio, di un Magistrato o un Giudice. Una delle questioni cardine delle attività d’intercettazione – spesso citate dai legali e dai fautori della privacy – è proprio il fatto che è corretto che la Giustizia operi attività d’ispezione anche all’insaputa dei soggetti coinvolti, è meno corretto che qualcuno possa autonomamente visionare tale materiale. Una soluzione come il Secret Sharing di Shamir risolverebbe in modo matematico questo problema, garantendo la tutela della privacy e la riservatezza dei dati acquisiti, utilizzabili sì ma sotto determinate condizioni.

Proviamo in pratica l’algoritmo di Shamir

L’algoritmo di Adi Shamir implementa – in modo scalabile su gruppi e membri variabili – proprio il sistema di condivisione di segreti accennato sopra. Il vincolo del codice è proprio quello di rendere determinabile in modo certo un segreto se sono presenti almeno k elementi su un gruppo di n, ma indeterminabile se non viene raggiunto il numero minimo di partecipanti.

Per chiarire dal punto di vista tecnico il funzionamento dell’algoritmo, ne abbiamo sviluppato una semplice applicazione (per semplice uso didattico, quindi non priva d’imperfezioni) pubblicandola per chi vuole cimentarvisi al link https://github.com/nannib/crypto/blob/master/shamir_nb.py.

Il codice si apre con l’inserimento della chiave segreta S₀, si inserisce il numero di “shares” (ossia quanti membri del gruppo avranno un pezzo della chiave ed infine il numero minimo di partecipanti (soglia) che servono per ricostruire la chiave.

Ad esempio, scegliamo come chiave segreta “1234”, come membri del gruppo decidiamo di avere sei persone e come numero minimo necessario per “sbloccare” il segreto ne impostiamo almeno tre. Quindi se anche tre persone dovessero mancare, con quest’impostazione ne saranno sufficienti tre per ricostruire la chiave.

Esempio:

Chiave:1234
Partecipanti:6
Numero minimo: 3

Nel programma è impostato un numero primo abbastanza grande:

Si passa quindi alla scelta casuale dei coefficenti del polinomio, presi tra 0 e p-1

Dato che sembra tutto troppo facile, osserviamo un attimo la formula matematica:

f(x)=S₀+r₀x¹+r₁x²+…+r_k-1x^(k-1)

 Nella funzione f(x), S₀ è la chiave segreta, gli r sono i coefficienti e alle x possiamo assegnare numeri arbitrari (1, 2, 3, etc…). Se calcoliamo f(0), cioè alla x assegniamo il valore ‘0’, otteniamo f(0)=S₀ perché tutti gli altri componenti del polinomio si azzerano.

Al fine di dividere la chiave segreta dobbiamo calcolare i polinomi per ogni valore di X relativo a ciascun partecipante, quindi se abbiamo 6 partecipanti dobbiamo calcolare f(1), f(2), f(3), f(4), f(5), f(6) per x=1, 2, 3, 4, 5 e 6.

Il programma genera i polinomi da sommare a S₀ e calcolare il modulo col numero primo p:

A questo punto abbiamo i pezzi (le cosiddette “shares”) per tutti i partecipanti,

Adesso, cerchiamo di ricostruire il codice segreto: per ricavare la chiave servono almeno k partecipanti, che nel nostro esempio abbiamo impostato a tre. Con meno di tre soggetti, non sarà possibile in alcun modo ricavare la chiave, questo perché quando abbiamo generato i singoli pezzi, abbiamo impostato che la soglia minima doveva essere quel numero. Se avessimo voluto permettere a un numero inferiore di partecipanti di ottenere il segreto, sarebbe bastato impostare a ‘2’ il parametro.

La ricostruzione avviene tramite interpolazione di Lagrange, che nell’implementazione pratica per X=0 diventa così:

Quindi passiamo a calcolare prima la produttoria:

In seguito calcoliamo il prodotto intero del pezzo per la produttoria relativa, quindi pezzo(1) * produttoria(1), pezzo(2)*produttoria(2), ecc.

Infine, calcoliamo la sommatoria dei vari SS[i] ed il modulo con P:

Si ottiene, a questo punto, il segreto originale “1234” a patto che appunto il numero di partecipanti sia almeno quanto è stato impostato durante la creazione come minimo necessario per lo “sblocco”.

Articolo a cura di Paolo Dal Checco e Nanni Bassetti

L’articolo Secret sharing: come mantenere un segreto pur condividendolo con più soggetti proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/secret-sharing-come-mantenere-un-segreto-pur-condividendolo-con-piu-soggetti/

Introduzione

Capita spesso di associare gli attacchi informatici effettuati attraverso l’uso di software malevolo (“malware”, o più volgarmente “virus”) a dei file eseguibili o alla navigazione in siti web infetti. In realtà, le tecniche di diffusione di software malevolo sono molteplici, e si basano spesso sull’utilizzo di strategie di social engineering. In altre parole, dal punto di vista dell’attaccante, è molto più semplice che la vittima apra una mail contenente un documento relativo a delle sue “debolezze” (ad esempio, una determinata bolletta da pagare) che direttamente un file eseguibile, il quale risulterebbe molto più sospetto. Per questo motivo, i documenti digitali sono dei vettori perfetti per veicolare attacchi informatici di vario tipo, in quanto sfruttano non solo le vulnerabilità informatiche del sistema target, ma anche quelle psicologiche della vittima.

Gli attaccanti possono nascondere attacchi sofisticati in documenti digitali: i formati più utilizzati sono certamente PDF e Microsoft Office (doc, xls…). Anche se, negli ultimi tempi, il secondo formato è preferito dagli attaccanti per la maggiore facilità di infezione, i file PDF sono ancora ampiamente usati per effettuare attacchi (ad esempio, [1]). In questa serie di articoli, composta da due parti, cercheremo di capire come un attaccante possa effettuare un attacco informatico attraverso l’uso di un file PDF.

In questo primo articolo, si fornirà una panoramica del funzionamento di un file PDF e della sua struttura. Nel secondo articolo, si andrà più in profondità nelle problematiche di sicurezza relative ai file PDF, mostrando un esempio reale di attacco informatico effettuato attraverso questo formato.

Struttura File PDF

PDF sta per Portable Document Format, ed è uno dei formati più popolari, assieme a Microsoft Office, per visualizzare documenti digitali.

La sua caratteristica principale è quella di supportare diverse funzionalità che rendono più interattiva l’esperienza dell’utente, come l’uso di form, la possibilità di visualizzare video, immagini e molto altro. Inoltre, supporta l’utilizzo di codice JavaScript per implementare funzionalità aggiuntive che migliorano l’esperienza complessiva dell’utente.

In linea generale, un file PDF può essere definito come un grafo di oggetti direttamente interconnessi fra di loro. Per poter capire come funziona, è possibile aprirlo direttamente con un programma come Notepad (o ancora meglio, Notepad++ [2]). Si può pertanto evincere che ogni file PDF è composto da quattro parti principali, mostrate nella Figura 1:

Figura 1 – Struttura generale di un file PDF

• Header. La prima riga del file, indicante la versione del formato PDF (attualmente, l’ultima versione del formato è la 1.7, rilasciata nel 2008). La versione del formato è importante perché ci sono state modifiche importanti fra un formato e l’altro, fra cui la possibilità di usare misure di sicurezza più avanzate. È possibile visionare le specifiche complete del formato qui: [3].
• Body. Una lista di oggetti che rappresentano il vero e proprio “cuore” del file. Ognuno di questi oggetti contiene delle informazioni sulla propria funzionalità (ad esempio, se si riferisce ad un font, a del codice di scripting, o ad una immagine). Per descrivere la funzionalità si utilizzano dei dizionari (introdotti da “<< >>”) contenenti sequenze di keyword, introdotte da uno “/” (ad esempio, /Length, /Filter, /FlateDecode). Queste keyword sono generalmente espresse in coppia con un altro elemento del file, ad esempio un riferimento o un’altra keyword (ad esempio, /Filter /FlateDecode indica che si utilizza un filtro di compressione di tipo FlateDecode). Gli oggetti in un file PDF sono generalmente numerati seguendo la dicitura “NUM 0 obj”, dove NUM rappresenta il numero dell’oggetto. Inoltre, è possibile che questi contengano dei dati (solitamente compressi attraverso un meccanismo di filtraggio, di cui parleremo nel prossimo articolo) che vengono elaborati direttamente dal Reader. Questi dati vengono chiamati stream. Infine, ognuno di questi oggetti può contenere dei riferimenti ad altri oggetti del file. Tali riferimenti sono indicati dalla notazione “NUM 0 R”, dove NUM rappresenta, in questo caso, l’oggetto a cui riferirsi. È altresì importante sottolineare che gli oggetti non sono ordinati, ma la loro disposizione può anche essere casuale all’interno del body.
• Cross-Reference Table (X-Ref Table). Tabella contenente le informazioni sulla posizione di determinati oggetti all’interno del file PDF. In altre parole, tale tabella può essere rappresentata come un elenco di indirizzi relativi alla posizione (in termini di byte) di ogni oggetto nel file. Questo è fondamentale, in quanto Adobe Reader deve sapere da dove iniziare a processare ogni oggetto del file. Se l’oggetto non è presente nella Cross-Reference Table, NON verrà analizzato da Adobe Reader. La Cross-Reference Table è introdotta dal tag xref.
• Trailer. Il trailer è un oggetto speciale che contiene alcune informazioni basilari del file PDF. In particolare, contiene un riferimento al primo oggetto della gerarchia e dei riferimenti ad altri oggetti contenenti dei metadati, ovvero informazioni riguardanti l’autore del file o indicanti lo strumento con cui il file è stato creato (ad es. salvataggio da Microsoft Office). È introdotto dal tag trailer.

Per poter visualizzare un file PDF, pertanto, il Reader dovrà eseguire le seguenti operazioni:

• Dovrà validare l’header per capire la versione del formato PDF.
• Cercherà l’oggetto trailer, e da lì inizierà a caricare i vari oggetti contenuti nel body seguendo le indicazioni fornite dalla Cross-Reference Table.

Si consideri ora il seguente esempio di file PDF, avente il trailer mostrato in Figura 2:

Figura 2 – Trailer di esempio di un file PDF

Adobe Reader inizierà ad analizzare il file a partire da questo trailer (indicante che sono presenti 11 oggetti – incluso il trailer stesso – nella gerarchia, si veda la keyword /Size). L’oggetto rappresentato dalla keyword /Root indica che il primo oggetto della gerarchia sarà il numero 1 (il fatto che sia esattamente il numero 1 è, tuttavia, una coincidenza. L’oggetto /Root può avere un qualunque numero). Il trailer ci dice anche l’oggetto numero 10 contiene informazioni sui metadati del file (keyword /Info).

Supponiamo che il body sia strutturato come in Figura 3. Di seguito, indichiamo solo una porzione degli oggetti in modo da semplificare la visualizzazione.

Figura 3 – Distribuzione di oggetti nel body di un file PDF

Questa immagine fornisce una serie di informazioni importanti su come gli oggetti vengono trattati da Adobe Reader. Dato che il primo oggetto della gerarchia è il numero 1 (informazione ottenuta dal trailer precedente), Reader inizierà ad analizzare l’oggetto 1 0 obj. Questo oggetto possiede due keyword fondamentali, /Type e /Catalog, che stanno ad indicare che quello è l’oggetto principale della gerarchia. Inoltre, sono presenti due riferimenti agli oggetti 2 e 3. L’oggetto numero 2 contiene informazioni relative alla presenza di sommari (non ve ne sono, infatti il /Count nell’oggetto numero 2 riferito alle /Outlines è accompagnato da uno zero). L’oggetto 3, invece, contiene informazioni sulle pagine del documento. È facile osservare come l’oggetto si riferisca alla struttura, in termini di pagine, del documento (osservare le keyword /Type e /Pages). Il file avrà due pagine (/Count 2) e le informazioni relative alle due pagine sono contenute negli oggetti 4 e 6 (/Kids).

La struttura degli oggetti analizzati può essere pertanto riassunta come in Figura 4:

Figura 4 – Struttura degli oggetti nel body per il file PDF d’esempio

Come si può notare, il file PDF è organizzato in maniera precisa e solo gli oggetti presenti nel body (indicati nella Cross-Reference Table) sono effettivamente analizzati da Adobe Reader.

La Cross-Reference Table relativa al file è rappresentata in Figura 5:

Figura 5 – Cross-Reference Table relativa al file PDF in esame

L’aspetto principale che si può evincere da questa tabella è il fatto che vi siano esattamente 11 oggetti, come indicato nel trailer (la posizione indicata è però quella dei 10 oggetti del body, il trailer non è incluso). Notare come il marker n, alla fine di ogni indirizzo del file, indichi che quell’oggetto verrà effettivamente analizzato e visualizzato da Reader.

Queste sono le basi per poter comprendere il funzionamento di un file PDF (e che saranno fondamentali per capire il funzionamento degli attacchi). Per maggiori informazioni, si rimanda alle specifiche ufficiali del formato [3]. Nel prossimo articolo, analizzeremo la struttura di un vero e proprio malware in PDF con le basi apprese in questa prima parte.

Riferimenti

• [1] MorphiSec Blog. [CRITICAL ALERT] CVE-2018-4990 Acrobat Reader DC Double-Free Vulnerability. http://blog.morphisec.com/critical-alert-cve-2018-4990-acrobat-reader-dc-double-free-vulnerability
• [2] Notepad++. https://notepad-plus-plus.org/download/v7.5.8.html
• [3] Adobe. PDF Reference 1.7. https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Articolo a cura di Davide Maiorca

L’articolo La sicurezza nei documenti digitali: Il caso dei PDF (Parte 1) proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/la-sicurezza-nei-documenti-digitali-il-caso-dei-pdf-parte-1/

Premessa

L’avvento della digitalizzazione ha modificato profondamente il mondo aziendale. L’inarrestabile diffusione di internet e delle nuove tecnologie ha imposto alle aziende un grado sempre più elevato di informatizzazione aziendale. Questo processo, volto a, condizionare l’intera dimensione dell’impresa all’utilizzo di strumenti e sistemi informatici, è ormai divenuto condizione imprescindibile per ottimizzare l’organizzazione di diversi processi interni.

Il ricorso all’informatica ed al mondo virtuale rappresenta però un’“arma a doppio taglio” in quanto ha comportato non solo diversi effetti positivi, legati all’innegabile miglioramento del funzionamento di diverse aree di attività, ma anche un significativo innalzamento del rischio di commissione di comportamenti illeciti all’interno del contesto aziendale, dovuto al fatto che il sistema di protezione cyber non è sempre implementato alla stessa velocità, frequenza e grado rispetto all’informatizzazione dei processi produttivi.

Sebbene in maniera meno sistematica di quanto avrebbe meritato la materia, il legislatore ha previsto un compendio di norme volte a tutelare penalmente le condotte fraudolente nel settore informatico, con l’introduzione dei c.d. digital crimes (L. n. 48/2008).

A questa responsabilità – tipicamente personale – è stata opportunamente aggiunta quella amministrativa derivante da reato con l’inserimento dei delitti informatici nel novero dei reati-presupposto previsti ex D.Lgs. 231/2001 (art. 24 bis).

I reati informatici inseriti nel Decreto dalla novella normativa si possono distinguere in tre gruppi:

1. il primo gruppo comprende i reati che puniscono il danneggiamento di hardware, di software e di dati (artt. 615 ter, 617 quater, 617 quinquies, 635 bis, 635 ter, 635 quater e 635 quinquies c.p.): viene punito l’accesso abusivo ad un sistema e l’intercettazione o l’interruzione di dati compiuti attraverso l’installazione di appositi software o hardware e viene punita come aggravante la commissione degli stessi reati in sistemi informatici di pubblica utilità;
2. il secondo gruppo di reati è costituito dai reati che puniscono la detenzione e la diffusione di software e/o di attrezzature informatiche atte a consentire la commissione dei reati di cui alla precedente lett. a) (artt. 615 quater e 615 quinquies c.p.);
3. il terzo gruppo di reati comprende i reati con cui viene punita la violazione dell’integrità dei documenti informatici e della loro gestione attraverso la falsificazione di firma digitale (artt. 491 bis e 640 quinquies c.p.).

Tali reati sono spesso interconnessi tra loro e la prevenzione degli stessi è particolarmente difficile e complessa, soprattutto perché non necessitano di elaborati processi di gestione/organizzazione aziendale, né del coinvolgimento di un elevato numero di soggetti, atteso che, solitamente, l’attività fraudolenta è perpetrata da un singolo soggetto che sfrutta le proprie conoscenze informatiche e la larghezza delle maglie della rete di protezione cibernetica aziendale.

Il massiccio trasferimento della criminalità on-line ha fatto sì che ormai i digital crimes non costituiscano più solamente una minaccia interna al perimetro aziendale, ma colpiscano anche – anzi soprattutto – dall’esterno le società, attraverso attacchi cyber e data breach. Con il proliferare di episodi di violazione dei sistemi informativi aziendali perpetrati da parte di hacker anonimi sempre più esperti, i vertici aziendali hanno dovuto prendere coscienza della necessità di provvedere non solo alla difesa della rete aziendale interna, ma anche ad un’azione di tutela rivolta verso l’esterno.

L’occasione privilegiata per attuare questa protezione a doppio raggio d’azione dell’azienda si è rivelata proprio la redazione o l’implementazione del Modello adottato ai sensi del D.Lgs. 231/01.

Cybersecurity e gestione dei rischi di commissione di reati informatici

Nell’ambito dell’attività di predisposizione del Modello 231, la gestione dei rischi legati al mondo dell’informatica si fonda principalmente su tre pilastri:

1. Prevenzione
2. Controlli
3. Formazione

Il primo pilastro viene normalmente attuato attraverso la previsione di specifiche misure di sicurezza volte a ridurre la possibilità che vengano commessi reati all’interno della rete aziendale; il secondo attraverso l’introduzione di presìdi di controllo ad hoc, finalizzati a supervisionare la gestione ed il funzionamento dei diversi ambiti aziendali condizionati dall’uso di internet e di device tecnologici e l’ultimo consiste nella diffusione di una cultura aziendale in materia informatica attraverso la formazione del personale e la responsabilizzazione di alcune figure.

A livello di prevenzione, è importante che ogni azienda si doti di apposite regole comportamentali e di sicurezza per gli utenti sia interni che esterni.

Quanto agli utenti interni risulta fondamentale innanzitutto definire i livelli di accesso in base alla confidenzialità delle informazioni ed alla responsabilità di ogni soggetto. Si tratta, in particolare, di adottare una policy di sicurezza del sistema informatico (ICS policy), che regolamenti in maniera strutturata l’accesso ai documenti ed alle informazioni aziendali ed il loro utilizzo. Al fine di garantire la correttezza e la sicurezza dell’operatività dei sistemi informativi interni, ogni azienda dovrebbe provvedere all’adozione di un’ICS policy inserendovi quanto meno le seguenti previsioni:

• la protezione da software pericoloso ricorrendo all’uso di antivirus ed al loro monitoraggio/aggiornamento costante;
• i back-up periodici delle informazioni in possesso all’azienda e dei software dalla stessa utilizzati;
• la protezione dello scambio di informazioni attraverso l’uso di tutti i tipi di strumenti per la comunicazione anche con terzi (ad esempio regolamentando l’uso di dispositivi removibili quali USB);
• la tracciatura delle attività eseguite sulle applicazioni, sui sistemi e sulle reti e la protezione di tali informazioni contro accessi non autorizzati;
• la verifica periodica dei log che registrano le attività degli utilizzatori, le eccezioni e gli eventi concernenti la sicurezza;
• l’accesso ai servizi di rete esclusivamente da parte degli utenti che sono stati specificatamente autorizzati e le restrizioni della capacità degli utenti di connettersi alla rete;
• la rivisitazione dei diritti di accesso agli utenti ad intervalli di tempo predefiniti ed in caso di cambiamento del rapporto che attribuiva loro il diritto di accesso;
• il rinnovo periodico delle credenziali degli utenti;
• la segmentazione della rete affinché sia possibile assicurare che le connessioni e i flussi di informazioni non violino le norme di controllo degli accessi delle applicazioni aziendali;
• la chiusura di sessioni inattive dopo un predefinito periodo di tempo;
• la custodia dei dispostivi di memorizzazione (quali, ad esempio, chiavi USB, CD, hard disk esterni, ecc.) e l’adozione di regole di clear screen per gli elaboratori utilizzati;
• l’implementazione e lo sviluppo sull’uso dei controlli crittografici per la protezione delle informazioni e sui meccanismi di gestione delle chiavi crittografiche;
• l’esecuzione periodica di test di sicurezza informatica come presidio contro le minacce cyber.

Con riferimento ai casi di accesso da parte di utenti esterni, per tutelare la realtà aziendale risulta utile prevedere ad esempio la richiesta di abilitazione preventiva da parte del responsabile della funzione aziendale competente con la quale la terza parte dovrà interagire, la costruzione di una rete per soggetti terzi diversa da quella accessibile al personale aziendale, oltre che applicare – come detto – le procedure di sicurezza adottate con riferimento allo scambio di informazioni tramite strumenti di comunicazione quali USB o CD-ROM.

Per quanto riguarda i controlli, l’impresa deve provvedere a nominare un amministratore di sistema (c.d. S.I.A.), un esperto di IT che si occupi del monitoraggio dei sistemi informativi aziendali e che risponda a tutte le segnalazioni provenienti dalle varie funzioni. Inoltre, risultano fondamentali la programmazione di audit interni da eseguire periodicamente (anche mediante attività di penetrazione ed ingegneria sociale) ed il controllo costante sui cambiamenti apportati agli elaboratori e ai sistemi.

Tutti gli strumenti e le misure sopra indicate sono estremamente utili anche nella tutela dagli attacchi esterni.

L’implementazione del Modello 231 ad oggi può infatti rivelarsi uno strumento prezioso ed efficace anche per tutelare l’azienda da eventuali minacce cyber provenienti dall’esterno. Negli ultimi anni ormai sono diventati sempre più frequenti i reati (anche non ricompresi nell’elencazione di cui all’art. 24 bis) commessi nel cyberspace, i quali provocano gravissime conseguenze alle aziende sia a livello economico che a livello strutturale e di web reputation.

Basti pensare ai frequentissimi casi di phishing o di cyber-laundering oppure ancora di diffamazione on-line. Si tratta di reati (come detto, anche non rientranti nell’elenco ex D.Lgs. 231/01) perpetrati da autori che il più delle volte restano anonimi e sono collocati in Paesi esteri difficilmente rintracciabili. Tali soggetti conoscono perfettamente i punti deboli a livello tecnico-informatico delle loro principali vittime perciò li sfruttano per agire illecitamente causando considerevoli danni reputazionali ed economici.

L’incremento delle misure di prevenzione e controllo contenute nel Modello anche con strumenti di contrasto a tali fenomeni provenienti dall’esterno, si rivela sempre più vantaggioso per le aziende che vogliono una tutela a 360 gradi e, quindi, una continuità della loro attività. È importante, dunque, che le aziende non solo prevengano, ma anche costituiscano un sistema di disaster recovery per il trattamento degli incidenti e delle anomalie di qualsiasi tipo relativi alla sicurezza informatica. A questo proposito risulta estremamente utile l’introduzione di meccanismi di comunicazione immediata tramite alert automatici che segnalino eventuali episodi di hackeraggio e di appropriati canali gestionali per la comunicazione immediata degli incidenti e dei problemi oltre che l’analisi periodica di tutti gli incidenti singoli e ricorrenti e l’individuazione della rispettiva rootcause in modo da poter creare una rete di prevenzione-protezione sempre più ampia e sofisticata.

Un ulteriore strumento di tutela a livello informatico per il mondo aziendale è poi la certificazione ISO/IEC 27001:2017. Dal momento che l’informazione è un bene che aggiunge valore all’impresa, e che ormai la maggior parte delle informazioni aziendali sono archiviate su supporti informatici, ogni organizzazione deve essere in grado di garantire la sicurezza dei propri dati, in un contesto dove i rischi informatici causati dalle violazioni dei sistemi di sicurezza sono continuamente in crescita. L’obiettivo del nuovo standard ISO 27001:2017 è proprio la protezione dei dati e delle informazioni aziendali da minacce di qualsiasi tipo, allo scopo di assicurarne l’integrità, la riservatezza e la disponibilità e fornire alle società i requisiti per adottare un adeguato sistema di gestione della sicurezza delle informazioni (SGSI) finalizzato ad una gestione efficace e corretta dei dati sensibili dell’azienda.

Da ultimo, occorre sottolineare come per una tutela efficace delle aziende in tema digita/cyber crime oltre ad un’azione specifica sul piano tecnico-procedurale nell’ambito della sicurezza informatica, è indispensabile diffondere una cultura aziendale in tal senso. Sia l’attuazione effettiva del Modello 231 sia il contrasto agli attacchi hacker possono essere infatti più agevolmente realizzati se affiancati da un’intensa attività di formazione del personale aziendale.

Avere dipendenti e figure professionali specifiche che sappiano gestire eventuali segnalazioni di anomalie interne nonché riconoscere ed evitare le minacce informatiche della rete è fondamentale per proteggere l’impresa. La sensibilizzazione di tutto il personale e la responsabilizzazione di specifiche figure – referenti per la sicurezza informatica – favoriscono da un lato una migliore collaborazione nella gestione di dati ed informazioni interni all’azienda e dall’altro una maggiore tempestività d’intervento in caso di evento sinistro, sia esso accidentale o fraudolento.

Articolo a cura di Avv. Chiara Langé e Avv. Francesco Rubino

L’articolo Digital Crimes e Modello 231: gestione dei rischi (Information Security Policy), presìdi di controllo e formazione interna proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/digital-crimes-e-modello-231-gestione-dei-rischi-information-security-policy-presidi-di-controllo-e-formazione-interna/

Introduzione

Che si tratti di comportamenti dannosi o errori involontari, i dipendenti di un’azienda sono senza dubbio il punto debole che mette maggiormente a rischio i dati più sensibili ed il corretto funzionamento dei sistemi IT aziendali. Il recente 2018 Insider Threat Report  fornisce alcuni dati rilevanti a riguardo: il 90% delle organizzazioni si sente vulnerabile agli attacchi interni ed il 53% ha registrato attacchi ed incidenti provenienti dall’interno nei precedenti 12 mesi di attività (in genere meno di cinque attacchi).

Parlando di “minacce interne” troppo spesso le persone associano il termine solamente con i dipendenti malintenzionati che intendono danneggiare direttamente l’azienda attraverso furti o sabotaggi dei sistemi. In realtà, dipendenti o fornitori negligenti causano involontariamente un numero altrettanto elevato di violazioni della sicurezza e perdite per cause accidentali.

Operazioni quotidiane che ciascun dipendente aziendale compie ripetutamente come aprire una mail, inserire una chiave usb nel proprio laptop o aprire file Excel o PDF scaricati da Internet, sono tra gli esempi sulla carta più banali che possono essere fatti ma sono proprio quei comportamenti che maggiormente provocano danni ad un’azienda. Il dipendente è spesso inconsapevole della minaccia cyber e gli hacker lo sanno, sfruttando tali vulnerabilità per attaccare un’azienda. Il Report Clusit 2018 sottolinea come nel 2017 si è assistito in Italia ad un aumento del 34% di attacchi condotti con tecniche di Phishing / Social engineering. Inoltre, al giorno d’oggi, gli attaccanti possono sempre più fare affidamento anche sull’efficacia di malware “semplici” a costi sempre più decrescenti.

Risulta dunque di primaria importanza invertire tali tendenze, formando i propri dipendenti, aumentandone la consapevolezza rispetto ai comportamenti da seguire per fronteggiare le numerose minacce del cyber spazio.

Per fare ciò, oltre ai metodi di formazione tradizionali offerti (quando offerti) ai dipendenti sulle tematiche di cyber security, risulta estremamente utile introdurre soluzioni più coinvolgenti come la gamification. La gamification è quel processo utile a coinvolgere le persone e cambiarne i comportamenti utilizzando le meccaniche di gioco in un contesto non di gioco. In sostanza, è prendere la parte divertente dei giochi ed applicarla a situazioni che forse non sono così divertenti, come bloccare il prossimo hacker prima che lo stesso riesca ad infiltrarsi nella rete di un’azienda.

Grazie alla gamification, le organizzazioni stanno scoprendo nuovi modi per educare i dipendenti sull’importanza della sicurezza informatica, attraverso elementi di gioco come competizioni individuali, programmi di rewarding ed altro ancora.

Comprendere le esigenze

L’introduzione della gamification non deve ridursi solamente ad un divertimento per i dipendenti ma deve necessariamente perseguire scopi ed attività mirate, che rispondano a specifiche domande e necessità previamente analizzate. Ciascuna azienda dovrebbe rispondere propriamente almeno a quesiti come:

• Quali sono gli incidenti più frequenti che si sono verificati?
• Quale sarebbe l’incidente più dannoso per l’azienda?
• Il problema potrebbe essere risolto attraverso l’utilizzo di tecnologie?
• Quale tipologia di gioco avrebbe l’impatto maggiore sulla sicurezza aziendale?

Per ridurre al minimo i rischi IT e l’esposizione di un’azienda e far fronte alle inevitabili minacce interne, esistono infatti numerose tecnologie utili a mitigare tali minacce. L’adozione di tecnologie di Data Loss Prevention (DLP), Crittografia dei dati, Log Management, la corretta Gestione delle identità e degli accessi (IAM), la protezione degli endpoint e dei dispositivi mobili, sono solo alcuni strumenti che le aziende dovrebbero considerare ed implementare per minimizzare il rischio di attacchi interni o perdite di dati.

Considerati dunque gli strumenti tecnologici utili a far fronte almeno in parte alle minacce interne, resta ugualmente da colmare il gap dovuto alla inconsapevolezza e all’imprevedibilità dell’attività umana. Tale gap potrebbe essere colmato proprio coinvolgendo attivamente i dipendenti attraverso la gamification. Le attività tradizionali di formazione, infatti, non risultano sempre sufficienti poiché tipicamente sono basate su:

• Condivisione di video, immagini, newsletter spesso direttamente cestinate dal dipendente;
• Mancanza di controllo sui dipendenti circa il corretto utilizzo degli strumenti di formazione forniti;
• Imposizione di corsi agli utenti che in tale modo non si sentono stimolati ad apprendere;
• Utilizzo di metriche di valutazione limitate al termine dei corsi (passato/fallito) che non registrano l’effettivo apprendimento dell’utente;
• Formazione su argomenti specifici, che lasciano scoperti innumerevoli altri argomenti.

Attraverso la gamification è invece possibile perseguire obiettivi differenti rendendo tali attività, che dovranno necessariamente presentare una natura volontaria, un programma a lungo termine per aumentare la consapevolezza e dei dipendenti. Non potrà dunque consistere in un one-time effort da parte del management aziendale, ma in un’attività che si protrae nel tempo, che incoraggia ed invoglia i dipendenti stessi a cercare formazione e opportunità per aumentare la propria consapevolezza sui rischi cyber.

Definire le regole del gioco

Il gioco può rendere il processo di formazione più interessante e coinvolgente per i dipendenti, aumentando la consapevolezza dei dipendenti sulle pratiche di sicurezza informatica, incluso il modo corretto di affrontare gli attacchi. Come in ogni gioco, alla base c’è sempre la definizione di regole chiare che ciascun partecipante conosce.

Prima di tutto, è necessario stabilire obiettivi chiaramente definiti e raggiungibili e quali premi / ricompense possono essere ottenuti. I programmi di rewarding, attraverso premi in denaro, buoni regalo o vantaggi aziendali, per ricompensare i dipendenti quando rispettano le regole e raggiungono gli obiettivi, li incoraggerà anche ad adottare un comportamento più attento e proattivo. Al contrario, se un dipendente continua a mostrare uno scarso interesse nei confronti di tali iniziative o risultati sotto le aspettative, si può esibire un “cartellino rosso” all’interno dell’organizzazione al fine di evidenziare la necessità di ulteriore formazione sulla sicurezza informatica.

Le regole del gioco devono dunque chiarire in che modo i partecipanti possono raggiungere gli obiettivi, creando limitazioni per il raggiungimento degli stessi affinché il gioco sia più coinvolgente. I partecipanti devono essere ovviamente informati sul loro rendimento, attraverso ad esempio una graduatoria mensile consultabile da tutti i dipendenti, così che anche l’organizzazione sappia quali dipendenti sono più meritevoli. Un tale meccanismo di feedback è un ulteriore modo di incentivare la partecipazione al gioco.

Ovviamente, la gamification risulta efficace solamente se i dipendenti applicano le lezioni apprese agli scenari del mondo reale. Per questo motivo, è fondamentale che le aziende misurino l’efficacia della gamification riducendo il rischio reale di incidenti o attacchi cyber. Per fare ciò, le organizzazioni dovrebbero condurre audit periodici e valutazioni circa la sicurezza informatica all’interno dell’organizzazione per determinare quali dipendenti rappresentano ancora un rischio al di fuori dell’ambiente di gioco.

Let’s play!

Il recente report “Winning the Game” pubblicato da McAfee evidenzia come all’interno delle organizzazioni che adottano programmi di gamification, hackathon, capture-the-flag, red team – blue team o bug bounty programs sono i giochi più comuni.

Attraverso l’organizzazione di un Hackathon è possibile riunire programmatori, sviluppatori, esperti di cyber security ed operatori del web che, per un determinato periodo di tempo che varia generalmente da due giorni fino ad una settimana, collaborano in cerca della soluzione ad un problema informatico relativo ad un software o ad un hardware. I premi, che generalmente sono in denaro, possono raggiungere cifre anche molto consistenti fino ad 1 milione di dollari.

Un Capture the Flag consiste in un gioco di hacking dove squadre o singoli cercano vulnerabilità nei sistemi e software messi a disposizione dagli organizzatori della competizione al fine di sfruttarle e di collezionare le varie “bandiere” nascoste sul sistema bersaglio.

Red Team – Blue Team è un altro gioco di simulazione ed allenamento in cui i membri di un’organizzazione sono divisi in due squadre che devono competere in prove per identificare vulnerabilità nei sistemi e falle di sicurezza nell’infrastruttura di un’azienda. Il team rosso rappresenta gli attaccanti che, attraverso sofisticate attività di “penetration test”, effettuano un valido assessment delle capacità difensive dell’azienda. La fase difensiva, in questo scenario, è invece demandata al Blue Team. Le vulnerabilità possono essere individuate su tre dimensioni differenti: People, Process and Technology.

Infine, attraverso un Bug Bounty Program è possibile premiare coloro che scovano una vulnerabilità in un sistema e la riportano in maniera tempestiva a chi gestisce il sistema. Nella maggior parte dei casi le ricompense sono in denaro, ma non mancano altri esempi come nel caso della United Airlines che mette in palio le proprie miglia.

È ovviamente possibile organizzare anche giochi per dipendenti con competenze professionali meno tecniche ma che necessitano ugualmente lo stesso tipo di formazione. Si possono infatti predisporre apposite classifiche basate, ad esempio, su punteggi attribuiti ai clic effettuati per aprire e-mail inviate durante campagne di phishing simulate, alle segnalazioni di email di phishing effettuate tramite i corretti canali di comunicazione aziendali, restituzione di dispositivi USB trovati incustoditi oppure il completamento di un corso di formazione entro un certo periodo di tempo.

Conclusioni

Al fine di introdurre queste attività all’interno del contesto aziendale, il top management dovrà necessariamente considerare il trade-off costi / benefici. Investimenti economici ed aspetti organizzativi potrebbero avere impatti rilevanti sull’azienda ma, al contempo, i benefici derivanti dalla gamification potrebbero evitare danni economici e reputazionali molto più ingenti dell’investimento effettuato. Lo stesso report “Winning the Game” sottolinea come quasi tutte le organizzazioni (il 96%) che adottano la gamification in un contesto lavorativo riferiscono di trarne evidenti benefici. Tre quarti (77%) degli alti dirigenti intervistati concordano che la loro organizzazione sarebbe più sicura se sfruttassero di più programmi di gamification.

In conclusione, la gamification nelle sue varie forme è senza dubbio una delle soluzioni ideali per rafforzare positivamente la consapevolezza e la formazione dei dipendenti in ambito cyber security. Proporre giochi stimolanti ai propri dipendenti riduce inoltre i normali tempi di formazione, garantendo un’attenzione continua agli aspetti di sicurezza informatica ed aumentando di conseguenza il livello di resilienza dell’azienda ad attacchi ed incidenti cyber.

Articolo a cura di Emanuele Spagnoli

L’articolo Gamification: il gioco come opportunità di crescita proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/gamification-il-gioco-come-opportunita-di-crescita/

Molto spesso mi viene chiesto come poter sostituire il software obsoleto presente sulle applicazioni evitando gli elevati impatti economici, le riscritture di codice e soluzioni custom. Purtroppo non c’è una risposta o una soluzione definitiva, in quanto tutte le cose (e anche le applicazioni) hanno un loro ciclo di vita. È però possibile dare delle indicazioni su come trattare in modo efficace il fenomeno dell’obsolescenza, cosa che tenterò di fare con questo articolo.

Cosa è l’obsolescenza tecnologica?

È un fenomeno derivato dal fatto che una componente software (ad es. un sistema operativo, un framework di sviluppo, ma anche il firmware di uno smartphone o di una stampante) ha un periodo di supporto da parte del fornitore limitato nel tempo, che di solito risulta sufficientemente lungo. Superato questo periodo il fornitore cessa la fornitura di aggiornamenti e bug-fix (comprese le patch di sicurezza) causando l’accumulo e la stratificazione delle vulnerabilità nel tempo e rendendo i nostri sistemi facilmente violabili.

Si tratta di un rischio che consente vettori di attacco molto pervasivi come ad esempio i pericolosi RCE (Remote Code Execution) capaci di compromissioni e impatti di ogni natura e profondità. Purtroppo, spesso, la via più immediata per trattare un sistema obsoleto è riscriverlo o riadattarlo alle più recenti componenti software. Su applicazioni enterprise questo può risultare altamente costoso oltre a non dare vantaggi agli utenti in termini di CX. Ciò costituisce un ostacolo importante, che spesso porta l’utente a dire “sono pienamente soddisfatto del mio sistema e non vedo il motivo di dover spendere dei soldi per riaverlo esattamente come prima”.

Siamo realisti, non è facile trasmettere questi concetti ad utenti non esperti di sicurezza. Per mia esperienza aiuta molto dimostrare ciò che è possibile fare sfruttando l’obsolescenza tecnologica; l’utilizzo di messaggi diretti come: “Sottrazione di tutte le carte di credito degli utenti da rete internet in accesso anonimo a causa dell’obsolescenza tecnologica“, vi assicuro che vale più di altre mille altre parole.

Addentriamoci nel merito, come sempre la sicurezza passa per i soliti due concetti ovvero la “Security by Design” e “Long-Term Security” e questo fenomeno, ovviamente non è da meno.

Security by Design

• Scegliere il software con attenzione: nei nuovi progetti, porre massima attenzione a tutta la pila software utilizzata, in modo che sia opportunamente aggiornata e garantisca tempistiche di supporto adeguate. Ad esempio, se oggi avviamo un nuovo progetto su tecnologia Microsoft potremmo utilizzare SQL Server 2008 R2 (tuttora a listino) che va in end-of-life a settembre 2019. Una svista di questa natura è “clamorosa” in quanto tra meno di un anno tale release andrà in end-of-life e non verranno più rilasciate patch di sicurezza. Scegliendo invece SQL Server 2017, il problema verrà spostato a dicembre 2027, ben 9 anni di supporto in più, un’eternità nella gestione di un sistema.
• Non far decidere agli altri, decidete voi: molto spesso i fornitori tendono a creare sistemi su tecnologie datate per evitare costi di formazione su quelle più recenti. Occorre prestare la massima attenzione a questo fenomeno (in particolare su software open-source) in quanto non è raro avere nuovi sistemi con software già in end-of-life non appena questi varcano la soglia dell’esercizio.
• Componenti Open Source: fate molta attenzione. A parte il software Open riconosciuto a livello internazionale (ad es. MySql, Apache, Tomcat, Java, ecc..) con vendor o community di spessore alle spalle, scegliete le librerie e i framework che notoriamente non hanno problemi di sicurezza ricorrenti (ad es. Drupal, Joomla, Struts2, ecc…). Verificate anche che le relative community risultino attive prima di adottarle nella vostra architettura software, in quanto utilizzare software open-source con community in decommissioning porterà ad una veloce obsolescenza, e questo lo dobbiamo evitare.
• Framework e librerie open source & buy: come visto in precedenza se l’applicazione è scritta da noi, utilizzare il più possibile codice proprietario e librerie messe a disposizione dai framework di sviluppo (ad es. librerie native di Java, Namespaces Microsoft .NET) evitando di utilizzare componenti di terze parti per effettuare operazioni implementabili in modo “semplice”. Ad esempio, se in ambiente .NET ci occorre una libreria che invia mail, non acquistiamo una DLL di terze parti ma sviluppiamo le nostre classi estendendo il namespace “System.Net.Mail.SmtpClient”. Insomma, più autonomia e controllo abbiamo sul codice da noi prodotto, più facile risulterà agire.
• Patching automatizzato: per tutte le tecnologie che lo consentono (ad es. Prodotti Microsoft o Red Hat Satellite) abilitare il patching automatizzato e valutare, in caso di tecnologie che non lo consentono, prodotti di terze parti da implementare.

 Long-term Security

• Vulnerability Assessment ricorsivi: Effettuare scansioni cadenzate sulle applicazioni più critiche monitorando lo scostamento nel tempo (recycle) delle vulnerabilità sfruttabili ed effettuare tutte le mitigazioni del caso. Alle volte sono presenti servizi non necessari che introducono vulnerabilità gravi che se correttamente segregati possono mitigare o risolvere completamente il problema.
• Patching delle componenti obsolete: per le componenti obsolete, svolgere il patching fino all’ultima versione rilasciata dal fornitore. Questo garantisce una precisa identificazione delle potenziali minacce in fase di Assessment che, abbinata alle scansioni ricorsive, consente di tracciare un quadro ben preciso delle reali vulnerabilità presenti sui sistemi.
• Patching automatico: a regime, come visto nella security by design
• Rimozione o segregazione dei servizi non necessari: attivare i soli servizi necessari al funzionamento del sistema. Per quelli che risultano necessari ma vulnerabili, ridurre il più possibile l’esposizione all’esterno. Ad esempio, se abbiamo OS Windows 2000, il servizio RDP (altamente vulnerabile a RCE) deve essere reso disponibile ai soli IP/subnet/VLAN/interfacce necessarie all’amministrazione del servizio. Così facendo ridurremo drasticamente la superfice di rischio oltre ad identificare con precisione i possibili potenziali aggressori.
• Valutare sistemi di sanificazione degli input: qualora non sia possibile (o altamente costoso procedere al replatforming) valutare la possibilità di messa in rete su applicazioni critiche o esposte su internet di sistemi WAF di 3rd generazione / Virtual Patching. Questi sistemi consentono di limitare le richieste anomale in generale e possono essere molto utili per arginare l’obsolescenza tecnologica evitando l’iniezione di payload dannosi. Ricordiamoci che ogni applicazione è unica e occorre analizzare con attenzione i falsi positivi e negativi introdotti da questo genere di tecnologie sul sistema target.

Terminata la “Security by design” si entra nella “Long-term security” e alla successiva fase di gestione dell’obsolescenza.

Conclusioni

L’obsolescenza tecnologica è come la data di scadenza di una medicina. È una minaccia che, anche se oggi non è presente, prima o poi si manifesterà. Errori grossolani di progettazione sulle nuove applicazioni portano ad avvicinare frettolosamente questa data, quindi occorre prestare massima attenzione ai nuovi sistemi.

La strada del replatforming (qualora possibile) risulta sempre la migliore, ma sulle applicazioni legacy/enterprise già obsolete non sempre è percorribile, a causa dei massicci investimenti richiesti. Qualora non sia possibile un buon “cleaning” (hardenizzazione e messa in sicurezza delle vulnerabilità rilevate) può consentire una drastica riduzione – e alle volte una completa bonifica – del rischio dovuto all’obsolescenza tecnologica. Questo intervento (normalmente di basso costo) dovrà essere eseguito “da mani esperte” in quanto può bastare una sola vulnerabilità per rendere vano l’intero lavoro svolto.

E’ inoltre buona norma una volta completata l’attività di “cleaning”, verificare con cadenza ricorsiva (almeno una volta all’anno) la presenza di ulteriori vulnerabilità sfruttabili, per evitare l’”accumulo” e la “stratificazione” che l’obsolescenza genera nel tempo.

In tutto questo, ricordiamoci sempre che le applicazioni sono “allergiche” agli aggiornamenti software e che seppur sia corretto aggiornare i sistemi con cadenza regolare (rischio di compliance per tipologie di dati trattati) non è sempre possibile farlo per ragioni di servizio e di costo; conviene spesso concentrare le forze nella risoluzione puntuale delle minacce rilevate sugli host vulnerabili. Non sottovalutiamo anche il fatto che alcune volte le patch di sicurezza sui sistemi supportati risolvono vulnerabilità pregresse ma ne inseriscono di nuove (ad esempio la CVE-2017-10271 su Oracle, che introduceva una pericolosa RCE e DOS non presenti nella precedente CPU).
Inoltre – e paradossalmente – passato un certo tempo dall’inizio dell’obsolescenza si assiste ad un abbattimento del livello di rischio per una carenza di interesse nelle community underground e per assenza di letteratura sulle vulnerabilità presenti così come viene mostrato nel grafico di seguito.

Concludendo, se la “security by design” non è stata svolta o siamo entrati in obsolescenza è possibile agire efficacemente sul sistema ma questo deve essere fatto da “mani esperte”; resta a noi valutare con precisione gli skill di chi supervisionerà questo genere di attività decisamente molto più vicine all’offensive-security che al mondo sella Security high-level.

Rendere sicuro un sistema obsoleto è possibile ma richiede una grande precisione e attenzione sui dettagli. Purtroppo tutto questo si scontra con una grande carenza negli skill e una assenza di consapevolezza del rischio presente nella piccola, media e grande impresa e su cosa potrebbe accadere quando quella minaccia si trasformi in compromissione, ma questo è un altro problema.

Articolo a cura di Massimiliano Brolli

L’articolo Obsolescenza tecnologica; conoscerla per combatterla con efficacia proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/obsolescenza-tecnologica-conoscerla-per-combatterla-con-efficacia/

Uno slogan molto noto recita che è possibile migliorare solo ciò che si misura. E’ chiaro quindi che la misurazione permette di comprendere meglio la gestione: occorre però istituire un processo aziendale organico e realmente integrato con gli altri processi aziendali, al fine di raggiungere gli obiettivi di misurazione e assicurare la convergenza delle misurazioni con i più generali obiettivi di business. Ogni organizzazione, sulla base dell’analisi del contesto organizzativo, dovrebbe quindi individuare gli indicatori pertinenti; dovrebbe raccogliere e validare i dati a supporto degli indicatori; dovrebbe rendere ricorrente il processo di misurazione e reporting. Queste attività sono del tutto indipendenti da un eventuale software di reporting già adottato dall’organizzazione. La strutturazione di un processo di misurazione delle performance, ha come indubbio risultato sia una maggior consapevolezza della reale direzione aziendale, sia il miglioramento della sicurezza delle informazioni. Nel presente articolo sono condivisi gli strumenti minimi per creare un primo set di indicatori, con particolare riferimento al mondo della sicurezza delle informazioni.

La scelta degli indicatori più utili dipende da diversi elementi e può essere guidata da tre dimensioni: ambito, oggetto ed esigenza.

Ambito di misurazione: il concetto di sicurezza delle informazioni, nelle sue proprietà di disponibilità, integrità e riservatezza, si può essenzialmente suddividere nelle sue componenti gestionale e tecnologica. La somma di queste due parti si può ricondurre ad una visione di insieme che consente di avere il presidio dell’oggetto misurato.

Oggetto di misurazione: gli indicatori si basano su delle formule matematiche volte ad oggettivare aspetti che altrimenti potrebbero essere interpretati in modo soggettivo e non coerente. Queste formule dovrebbero individuare in modo inequivocabile i singoli elementi che concorrono alla misurazione.

Esigenza di misurazione: è pacifico che la misurazione non può essere fine a sé stessa e dovrebbe necessariamente essere supportata da una esplicita esigenza che trova fondamento nella formulazione degli obiettivi del business.

La definizione di uno schema di misurazione delle performance, affinché produca indicatori usabili e coerenti con gli obiettivi, dovrebbe tenere in considerazione che il sottostante processo debba essere organizzato su tre macro-fasi: monitoraggio, misurazione e valutazione delle performance. Lo schema seguente riporta una possibile definizione di ciascuna di queste tre fasi.

Figura 1: definizioni di Monitoraggio, Misurazione e Valutazione in ambito Information Security Performance

Il processo Information Security performance dovrebbe, inoltre, tenere in considerazione ulteriori aspetti. Il metodo di monitoraggio, misurazione e analisi delle valutazioni: per mantenere coerenza nel tempo, il processo dovrebbe mantenere lo stesso approccio alla misurazione sia in termini di input data, sia in termini di regole di calcolo della misurazione. L’istante temporale e, soprattutto, la frequenza di misurazione: indicatori diversi possono avere esigenze diverse di misurazione e reporting. Indicatori di sintesi possono essere misurati con cadenza annuale, indicatori di gestione con cadenza trimestrale e indicatori tecnologici potrebbero richiedere una frequenza mensile di misurazione. La frequenza di misurazione è determinata anche in funzione del destinatario della misurazione stessa: in ottica piramidale, è facile intuire che un indicatore di sintesi può essere condiviso con il top management, un indicatore di gestione con il middle management ed un indicatore tecnologico con i professionisti informatici. I criteri di valutazione: definiscono delle soglie che permettono di valutare la bontà del risultato raggiunto rispetto gli obiettivi. È prassi diffusa definire i KPI con le consuete soglie “verde-giallo-rosso”. Ogni organizzazione dovrebbe definire le proprie soglie di valutazione in funzione delle proprie priorità, risorse e contesto aziendale. Una proposta valida indipendentemente da tali considerazioni di contesto sarebbe fuorviante. Tutti questi elementi concorrono alla definizione di un indicatore, la cui importanza è tanto maggiore quanto più efficaci vogliono essere i risultati del processo di Information Security.

Nell’implementazione di questo processo è inevitabile imbattersi con aspetti operativi che vanno dalla raccolta dei dati necessari ai calcoli, fino all’automazione della misurazione. Tutti questi aspetti possono essere indirizzati solo dietro un esplicito commitment del top management che sponsorizzi le necessarie attività e chiarisca ruoli e responsabilità per eseguire le misurazioni, non tralasciando la congrua allocazione di risorse (umane, economiche e tecnologiche) necessarie per garantire il buon esito del processo.

Per raccogliere i dati è importante individuare gli attori aziendali che ne dispongono, i data owner, ed iniziare a fare misurazioni con un approccio che può anche essere “iterativo”. La raccolta delle prime fonti dati sarà probabilmente incompleta o con dati non esaustivi, quindi sarà importante capire quali azioni saranno necessarie per avere dati completi in un formato usabile. Ad esempio, il “Service Desk”, interno all’organizzazione o in outsourcing ad un fornitore esterno, è un interlocutore primario per indicatori riferiti ai dispositivi assegnati ad utenti finali, mentre “IT Operations” è il punto principale di contatto per gli indicatori relativi all’architettura aziendale. “L’Incident Manager” è l’interlocutore di riferimento per gli indicatori relativi a ticket di servizio, eventi, incidenti e crisi. Per gli aspetti di conformità, la funzione “Legal” o “Compliance” sono certamente il primo contatto per la valutazione dei relativi indicatori.

La raccolta dei dati, che alimenta il processo di Information security performance, dovrebbe essere ricorrente al fine di garantire un presidio sull’oggetto misurato. Assegnare quindi la responsabilità del processo di misurazione complessivo ad un manager, validare ownership degli indicatori e loro frequenza di misurazione, fissare meeting di condivisione di risultati e, soglie, redigere un piano di miglioramento in caso di indicatori “rossi” con gli owner degli indicatori, sono esempi di azioni che possono supportare il raggiungimento degli obiettivi di misurazione e conseguentemente del processo di Information security performance. Eventuali incentivi, come premi di risultato, possono essere presi in considerazione al fine di stimolare il raggiungimento di determinati risultati ritenuti strategici per il top management.

Come anticipato in precedenza, la scelta degli indicatori può essere guidata secondo tre dimensioni. Le tabelle seguenti riportano alcuni esempi di definizione di un indicatore, specificando per ognuno di essi una possibile metrica di misurazione e valutazione.

Figura 2: esempi di indicatori descritti tramite tabella

Altri indicatori possono essere definiti, ad esempio, considerando il numero ed i giorni necessari per la gestione degli incidenti, il costo di gestione degli incidenti, i sistemi correntemente sottoposti a backup, l’esercizio di test di disaster recovery, la frequenza di modifica delle password, il numero di sistemi con strong authentication ecc.

In conclusione, è possibile rimarcare come l’Information Security Performance sia un mezzo per migliorare la sicurezza delle informazioni aziendali. Il calcolo degli indicatori non deve essere fine a se stesso od all’implementazione di una nuova tecnologia, anche se fosse la moda del momento. Per evitare di investire tempo e denaro in misurazioni che non portano ad alcun miglioramento è fondamentale avere l’allineamento con gli obiettivi di sicurezza delle informazioni come perno centrale del sistema di monitoraggio, misurazione e valutazione.

E’ quindi più utile, per l’organizzazione, avere anche solo pochi indicatori, ma ben allineati con gli obiettivi di sicurezza, piuttosto che acquistare costose tecnologie da rendere giustificate con “montagne” di giornate di lavoro, perdendo il focus rispetto all’unica cosa che può contare: migliorare, in modo semplice se possibile, la sicurezza delle informazioni. Nel raggiungimento di questo macro obiettivo avere dipendenti o fornitori con competenze non improvvisate, costituisce un vantaggio oltre che un risparmio di tempo e denaro.

Articolo a cura di Thomas Castagna e Luciano Quartarone

L’articolo Information Security Performance proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/information-security-performance/

Il 30 agosto scorso l’European Union Agency for Network and Information Security[i] (ENISA) ha pubblicato il rapporto annuale sugli incidenti rilevati nel 2017 dalle imprese fornitrici di servizi di comunicazione elettroniche[ii]. Il rapporto trova il suo fondamento giuridico nell’art. 13 bis della direttiva UE 140/2009[iii] che ha introdotto importanti elementi di novità nel quadro normativo europeo, rispetto alle reti ed ai servizi di comunicazione elettronica.

L’art. 13 bis della direttiva 140 è stato attuato, in Italia, dal Dlgs. 70 del 2012[iv] che ha introdotto gli articoli 16 bis e 16 ter nel Codice delle comunicazioni elettroniche[v]. A norma dell’articolo 16 bis, dunque, esiste un obbligo per gli operatori che gestiscono reti pubbliche di comunicazione di:

• adottare le misure individuate dal Ministero dello Sviluppo Economico al fine di conseguire un livello di sicurezza delle reti adeguato al rischio esistente e di garantire la continuità della fornitura dei servizi su tali reti;
• comunicare al Ministero ogni significativa violazione della sicurezza o perdita dell’integrità.

A sua volta, nel caso di violazioni della sicurezza significative, il Ministero dello Sviluppo Economico ha l’obbligo di:

• informare le altre autorità nazionali competenti (per esempio, il Garante per la Protezione dei Dati Personali);
• informare le autorità di altri Paesi Membri;
• informare, direttamente o indirettamente (tramite lo stesso operatore interessato) gli utenti;
• informare l’ENISA.

Incidente di sicurezza: quando è significativo?

L’ENISA, quindi, riceve dall’Italia e dagli altri Paesi Membri le informazioni relative agli incidenti di sicurezza che riguardano le reti di comunicazione.

Per agevolare l’efficacia e l’efficienza dei meccanismi di analisi e reporting, l’ENISA e le autorità competenti degli Stati Membri hanno stabilito le soglie di significatività degli incidenti di sicurezza che la stessa ENISA ha formalizzato nelle “Linee Guida per il Reporting degli Incidenti”[vi] e nelle “Linee Guida per le Misure di Sicurezza”[vii]. Le soglie sono definite in base a parametri di:

• durata degli effetti dell’incidente;
• rapporto percentuale tra la platea degli utenti che subiscono gli effetti dell’incidente ed il numero di utenti totali dell’operatore per l’ambito di riferimento (telefonia mobile, telefonia fissa, accesso ad Internet da mobile, accesso ad Internet da fisso, ecc.).

Un incidente è considerato significativo e, quindi, da segnalare all’ENISA, quando:

• la durata è maggiore di un’ora e la percentuale di utenti coinvolti è superiore al 15%;
• la durata è maggiore di due ore e la percentuale di utenti coinvolti è superiore al 10%;
• la durata è maggiore di quattro ore e la percentuale di utenti coinvolti è superiore al 5%;
• la durata è maggiore di sei ore e la percentuale di utenti coinvolti è superiore al 2%;
• la durata è maggiore di otto ore e la percentuale di utenti coinvolti è superiore all’1%.

In ogni caso, l’incidente deve essere comunicato all’ENISA se il prodotto tra numero di utenti coinvolti e durata degli effetti è superiore a un milione (di ore‑utente).

I contenuti del rapporto

Il rapporto riguarda 169 incidenti segnalati, nel 2017, da 22 dei 28 paesi UE e da 2 paesi EFTA e propone alcuni elementi significativi:

• gli incidenti hanno riguardato soprattutto i servizi mobili (telefonia e internet); in particolare, il 51% degli incidenti ha interessato la telefonia mobile ed il 49% ha interessato l’accesso mobile ad Internet (tenendo presente che un incidente può interessare più di un servizio);
• gli incidenti sui servizi mobili, oltre ad essere più frequenti, hanno interessato, in media, un numero maggiore di utenti; in media, infatti, ogni incidente di questo tipo ha coinvolto circa mezzo milioni di utenti;
• la causa più frequente è stata il malfunzionamento di infrastrutture dovuto a guasti hardware o bug software; il 62% degli incidenti è derivato da questo tipo di problemi;
• l’errore umano è stato la causa che incidenti che hanno coinvolto, in media, il maggior numero di utenti; l’incidente causato dall’uomo ha avuto impatto, in media, su 1,2 milioni di utenti;
• gli incidenti causati da malintenzionati esterni sono stati rari e hanno registrato una frequenza pari al 2,5% del totale;
• sono aumentati, rispetto agli anni precedenti, gli incidenti causati da fenomeni naturali; la percentuale di questi incidenti, nel 2017, è stata pari al 18% mentre, nel periodo 2014‑2016, si era mantenuta stabile intorno al 5%.

Questi risultati ci dicono che la sicurezza delle infrastrutture di telecomunicazione è ampiamente migliorabile.

Occorre lavorare, in particolare:

• sull’affidabilità dei sistemi hardware e software per ridurre drasticamente gli incidenti;
• sulla progettazione di sistemi di backup che funzionino realmente e che, auspicabilmente, vengano testati periodicamente;
• sulla robustezza dei sistemi per resistere agli errori umani;
• sulla capacità dei sistemi di gestione di predire, prima di dare definitività ad ogni azione, le conseguenze di un errore umano, in termini di utenti coinvolti e di durata degli effetti;

• sulla riduzione della vulnerabilità dei sistemi agli eventi naturali; una recente ricerca[viii] dell’Università dell’Oregon ha dimostrato, ad esempio, che tra 15 anni potrebbero essere sott’acqua, nei soli Stati Uniti, 2.000 km di fibra ottica a lungo raggio, 4.000 km di fibra ottica a corto raggio e 1.100 nodi di scambio.

Incidenti e violazioni

Esiste, inoltre, una significativa sovrapposizione tra alcune definizioni presenti nella normativa europea (poi applicata a livello nazionale):

• l’ENISA, nell’applicare la Direttiva UE 140/2009, definisce incidente di sicurezza una violazione di sicurezza o una perdita di integrità che potrebbe avere un impatto sull’operatività delle reti e dei servizi di comunicazione elettronica;
• il Regolamento UE 679/2016[ix] (la regolamentazione generale per la protezione dei dati personali) definisce violazione dei dati personali una violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati;
• la Direttiva UE 1148/2009[x] (la direttiva NIS poi applicata in Italia dal Dlgs. 65/2018[xi]) definisce incidente ogni evento con un reale effetto pregiudizievole per la sicurezza della rete e dei sistemi informativi.

Basterebbero queste sovrapposizioni lessicali per stimolare una riflessione allargata sull’effetto domino che un incidente di sicurezza nelle comunicazioni elettroniche genera e, quindi, sulla necessità di costruire meccanismi di riduzione dei rischi e di reazione (auspicabilmente coordinata) che siano il frutto di un’approfondita analisi da parte di tutte le autorità governative coinvolte (Agid, Agcom, Garante per la Protezione dei Dati Personali, CSIRT).

Cosa cambia con il nuovo codice delle comunicazioni

Questo aspetto corale è sottolineato dal nuovo Codice Europeo per le Comunicazioni Elettroniche[xii], che vedrà definitivamente la luce il prossimo novembre: all’art. 40 (sostitutivo dell’art. 13 bis della Direttiva UE 140/2009, cioè l’articolo che disciplina la comunicazione degli incidenti di sicurezza nelle reti e servizi di comunicazione elettronica) il Codice indica con precisione quali dovranno essere i parametri da valutare per determinare la rilevanza dell’impatto di un incidente di sicurezza:

• il numero di utenti interessati dalla violazione;
• la durata della violazione;
• la diffusione geografica della zona interessata dalla violazione;
• la misura in cui il funzionamento del servizio è perturbato;
• l’incidenza sulle attività economiche e sociali.

Se i primi due parametri sono già considerati nell’attuale attività di reporting a cura dell’ENISA, per gli altri sarà necessaria un’attività coordinata di definizione delle soglie ma, prima ancora, di prevenzione diffusa affinché gli incidenti di sicurezza non rimangano una questione aperta.

Note

• [i] https://www.enisa.europa.eu/
• [ii] https://www.enisa.europa.eu/publications/annual-report-telecom-security-incidents-2017/at_download/fullReport
• [iii] https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ%3AL%3A2009%3A337%3A0037%3A0069%3AEN%3APDF
• [iv] http://www.normattiva.it/atto/caricaDettaglioAtto?atto.dataPubblicazioneGazzetta=2012-05-31&atto.codiceRedazionale=012G0091&queryString=%3FmeseProvvedimento%3D%26formType%3Dricerca_semplice%26numeroArticolo%3D%26numeroProvvedimento%3D70%26testo%3D%26annoProvvedimento%3D2012%26giornoProvvedimento%3D&currentPage=1
• [v] http://www.normattiva.it/atto/vediMenuHTML?atto.dataPubblicazioneGazzetta=2003-09-15&atto.codiceRedazionale=003G0280&currentSearch=ricerca_semplice
• [vi] https://resilience.enisa.europa.eu/article-13/guideline-for-incident-reporting/Article_13a_ENISA_Technical_Guideline_On_Incident_Reporting_v2_1.pdf
• [vii] https://resilience.enisa.europa.eu/article-13/guideline-for-minimum-security-measures/Article_13a_ENISA_Technical_Guideline_On_Security_Measures_v2_0.pdf
• [viii] http://ix.cs.uoregon.edu/~ram/papers/ANRW-2018.pdf
• [ix] https://eur-lex.europa.eu/legal-content/IT/TXT/PDF/?uri=CELEX:32016R0679&from=EN
• [x] https://eur-lex.europa.eu/legal-content/IT/TXT/PDF/?uri=CELEX:32016L1148&from=EN
• [xi] https://www.csirt-ita.it/files/dlgs_18_maggio_2018_n65.pdf
• [xii] https://eur-lex.europa.eu/resource.html?uri=cellar:c5ee8d55-7a56-11e6-b076-01aa75ed71a1.0015.02/DOC_1&format=PDF

Articolo a cura di Francesco Maldera

L’articolo La risposta agli incidenti: una questione aperta proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/la-risposta-agli-incidenti-una-questione-aperta/

Con il Regolamento UE 2016/679 (“GDPR”) è stata introdotta una normativa che, in realtà, semplifica molti aspetti nel settore, ma che una parte consistente – e non necessariamente autorevole – di coloro che hanno esposizione sui media e sui social, ha voluto battezzare come pietra miliare della privacy, presentandola, peraltro, come contorta e pericolosa in termini sanzionatori.

Molti dei tratti caratteristici del GDPR riguardano il metodo; quando, nel corso di una delle mie lezioni,  illustro il Regolamento, sono solito disegnare una linea, sulla quale, ad un dato punto, traccio una tacca: ciò, per spiegare che il GDPR, rispetto alla direttiva e alle relative norme attuative, sposta in avanti il momento del controllo (la tacca, appunto), comunicando a chi lo deve applicare: “implementa la sicurezza dei dati come ritieni opportuno, poi l’Autorità o l’interessato condurranno i propri controlli o eserciteranno i propri diritti”.

Ai fini del GDPR non è rilevante se la tua password sia di otto caratteri o di dodici, l’importante è che il tuo sistema non venga violato o, per lo meno, che il sistema sia pensato per abbattere i rischi che incombono sui trattamenti dei dati personali e, quindi, sui diritti fondamentali degli interessati.

Nel caso del rapporto tra un titolare e i terzi che trattano i dati, operando per lui, con lui, al suo posto, ho osservato un fenomeno che desta qualche preoccupazione: è come se si creasse una sorta di cortocircuito, tale per cui, nel rapporto con i terzi, viene individuata la maggior vulnerabilità/fonte di criticità dell’intero sistema.

Il titolare, perfetto e preciso nel proprio sistema di trattamento dei dati, vuole evitare che un terzo, pasticcione, rappresenti un “buco” – e possa quindi costituire un pericolo – nella propria muraglia di sicurezza.

D’altro canto, il Titolare cerca di semplificare (ma in modo grossolano), standardizzando, senza prima analizzare adeguatamente i trattamenti al fine di distinguere tra quelli condotti in prima persona e quelli condotti attraverso terzi.

Sovente, quando mi trovo a supportare enti che sono nella posizione di “Responsabili del trattamento”, mi capita che mi venga sottoposta la corrispondenza proveniente dai diversi Titolari, o presunti tali, contenente proposte di “accordo”, ove il titolare chiede al Responsabile di rendergli noto quali dati tratta e quali trattamenti conduce, oppure impone l’adozione della cifratura del dato, pur in presenza di trattamenti a basso rischio per i diritti e le libertà fondamentali degli interessati.

Altro errore ricorrente – che sembra dettato dalla paura, dall’arroganza o, forse, dall’ignoranza – è quello per cui si bollano tutti come propri “Responsabili del trattamento”, senza tentare interpretazioni e senza cercare di analizzare in maniera corretta la tutt’altro che banale locuzione che parla di “titolare come colui che determina mezzi e finalità del trattamento.”.

Da qui, il proliferare di lettere di minaccia del tenore: “se non accetti l’accordo interrompiamo il contratto”, oppure “devi dirmi quali misure adotti a protezione dei dati che non tratti” e via dicendo.

Ammetto che tutto ciò trae origine, tra l’altro, dal fatto che l’Autorità di controllo non ha preso tempestivamente una serie di decisioni, seppure per motivi spesso comprensibili.

I titolari e i responsabili hanno bisogno di sapere se determinate figure sono sempre, e comunque, in una certa posizione (cosa opinabile), o se le clausole unilaterali di Microsoft, quando dice “se sono tuo Responsabile del trattamento seguo le seguenti condizioni”, rappresentano un’accettabile  interpretazione del concetto di “accordo scritto”; oppure se, quando un titolare dice: “o accetti le mie condizioni o niente, non intendo ascoltare le tue obiezioni”, tale atteggiamento sia riconducibile al concetto di “accordo” di cui parla il Regolamento.

Tornando alla definizione adottata nel Regolamento, in essa si parla di “determinazione”, da parte del titolare, di mezzi e finalità.

Ora, il parere del 2010, ancora oggi riferimento quasi unico nel panorama interpretativo, si sofferma sul significato del verbo “determinare”, per come è stato utilizzato nella normativa de qua.

Il fatto che un “ente” determini il trattamento, si stabilisce principalmente sulla base di elementi “fattuali” o dalle circostanze del caso, rispondendo inizialmente alle seguenti domande “Qual è la ragione del trattamento?” e “Chi lo ha iniziato?”.

L’autorevole Opinion prosegue osservando che “un criterio puramente formale non sarebbe sufficiente per almeno due ragioni: in alcuni casi la designazione ufficiale – prevista ad esempio in un contratto […] – verrebbe a mancare; in altri casi tale designazione ufficiale potrebbe non rispecchiare la realtà.”.

Analoghe considerazioni che il Gruppo ex Articolo 29 ha formulato a proposito dell’attribuzione della figura di Responsabile del trattamento (attenzione, il Gruppo intendeva il nostro “Titolare”), possono essere richiamate, per analogia, quando si decide di costringere un ente ad essere nostro “Processor” (individuando noi come Titolari), malgrado questo determini “mezzi e finalità”.

Nel caso SWIFT, ad esempio, benché SWIFT sia stata considerata “incaricato” del trattamento, la “designazione contrattuale” non permette, in realtà, sempre secondo la Opinion del 2010, di stabilire in modo definitivo lo status effettivo, che invece deve essere basato su circostanze concrete.

Il Gruppo ex articolo 29 prosegue dicendo che può accadere che il contratto che regola i rapporti tra le parti sia esplicito riguardo l’individuazione di chi sia “Titolare” e di chi ricopra il ruolo di “Responsabile del trattamento”; in questo caso, viene chiarita una condizione per assecondare quanto espresso nel contratto ovvero “se non vi sono ragioni di dubitare che le clausole interessate rispecchino accuratamente la realtà dei fatti”.

Queste considerazioni sembrano non lasciare dubbi circa l’inidoneità delle designazioni “unilaterali”, “sovrabbondanti” e “automatiche”.

In ultimo, per individuare i “ruoli” nell’ambito della protezione dei dati, l’Opinion indica elementi come il “controllo generale esercitato da una parte”, “l’immagine data agli interessati” e “il legittimo affidamento degli interessati sulla base dell’immagine data”.

Il fatto, poi, che sotto la vigenza dell’articolo 29 del d.lgs. 30 giugno 2003, n. 196, il ruolo di Responsabile del trattamento sia stato attribuito, magari, con una certa faciloneria, non significa che in automatico la figura debba essere convertita nel Responsabile ex articolo 28 del GDPR.

Insomma, diffidate dall’uso di facili ragionamenti e aprite un confronto con gli interlocutori, per comprendere i ruoli di ciascuno; oggi, anche grazie al GDPR, le risorse per analizzare in modo accurato e non frettoloso le posizioni dei diversi player, in relazione a quanto previsto dal Regolamento UE 2016/679, ci sono, eccome (molti hanno un RPD o comunque almeno una risorsa specializzata).

Articolo a cura di Riccardo Abeti

L’articolo La tirannia del titolare del trattamento proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/la-tirannia-del-titolare-del-trattamento/

Quando nel 2004 Furio Honsell, matematico informatico e stimato rettore dell’Università di Udine, presenziò al XV congresso nazionale dell’Aipnet (Associazione Informatici Professionisti) alla consegna delle prime certificazioni europee EUCIP, disse: “L’informatica è una scienza multidisciplinare e i futuri professionisti dovranno tenere ben conto di questa caratteristica”. E fu del tutto naturale che i primi ad essere certificati fossero proprio quei professionisti provenienti da discipline tecniche, scientifiche e in qualche caso anche umanistiche che si associavano alla multidisciplinarietà dell’informatica. Si cominciò quindi, con quell’evento, a certificare quei professionisti che in qualche modo possiamo, oggi, definire “Pionieri” dell’informatica italiana. EUCIP, infatti, è stata la prima certificazione europea per professionisti informatici che non fosse l’emanazione diretta di aziende specializzate del settore, ed il proprio syllabus, che si diversificava in varie specializzazioni, era la sintesi di quelle esperienze pioneristiche.

Tuttavia, per ben comprendere l’importanza di questa certificazione, occorre pensare a chi prima dell’istituzione dei corsi di studio superiori e corsi di laurea in informatica – i primi negli anni ’70 presso le facoltà di scienze matematiche – aveva costruito la sua professione con un curriculum di studi spesso affine alla propria istruzione, nel settore della scuola, università, ricerca e libera professione.

D’altronde prima che venissero istituzionalizzati i corsi di studio universitari, erano già state scritte milioni di linee di codice in quasi tutti i linguaggi e gli ambienti di sviluppo ad oggi conosciuti, ad esclusione dei linguaggi ADA, C++ e JAVA sviluppati negli anni ’80 e ‘90. E di pari passo, sempre prima degli anni ‘70, furono progettati e costruiti elaboratori sempre più sofisticati e potenti e le prime infrastrutture di rete come Arpanet (Advanced Research Projects Agency NETwork) che consentivano la comunicazione in rete di più elaboratori. EUCIP è dunque la certificazione europea emanata dal CEPIS (Council of European Professional Informatics Societies), organismo europeo senza fini di lucro che riunisce trentasei associazioni di informatica in rappresentanza di trentuno paesi europei.

L’Italia è rappresentata da AICA che tramite test center accreditati, come università e associazione informatiche, certifica, anche con certificazioni in versioni e-Competence Framework (e-CF), studenti e professionisti. Pur tuttavia, con l’evoluzione del settore ICT, la certificazione delle competenze dei professionisti informatici passa anche attraverso enti preposti: in Italia con l’Ente Italiano di Normazione (UNI).

Diplomi e certificazioni ICT nella UE e in Italia

Negli ultimi quarant’anni con l’evoluzione del settore ICT il numero delle specializzazioni nel settore informatico è aumentato a dismisura, e, in Italia, il numero dei corsi per diplomi e lauree di primo e secondo livello ha raggiunto un livello di diversificazione che continuerà a crescerà ancora per parecchi anni. Tendenza confermata anche nell’Unione Europea, e la mancata armonizzazione dei titoli di studio tra gli Stati dell’Unione rende difficile ogni comparazione e valorizzazione degli stessi. Altra situazione, invece, per le certificazioni ICT che nascono già armonizzate in ambito UE con norme ben precise: e-Competence Framework (e-CF UNI EN 16234:2016), che indica il posizionamento e il monitoraggio della professionalità; e la certificazione dei profili professionali secondo quanto stabilito dagli standard UNI 11506:2017 e UNI 11621-2:2016.

Infatti con l’algoritmo del framework definito nella UNI EN 16234-1 è possibile identificare, con buona approssimazione, le competenze dei singoli professionisti, classificandole in modo univoco. Con la normazione tecnica, definita a livello europeo e successivamente con normazione tecnica nazionale, sono stati individuati profili professionali di prima generazione, che hanno consentito l’individuazione dei 23 profili professionali ICT di seconda generazione. E, considerato che tali profili possono essere non idonei a coprire tutte le eventuali specializzazioni, sono stati previsti profili successivi di terza generazione.

Tuttavia l’uscita di nuovi standard professionali del settore ICT non è sfuggita ad AGID (Agenzia per l’Italia digitale) che nel corso dello scorso anno ha emanato un suo documento di riferimento per l’individuazione di competenze ICT: “Linee guida per la qualità delle competenze digitali nelle professionalità ICT”,  sfruttando la norma “UNI 11621”. AGID si aggiunge quindi alla schiera delle associazioni professionali e universitarie come AICA, UNINFO, AIP, CINI, Ordine degli Ingegneri e associazioni delle imprese ICT a supporto dei nuovi standard.

I professionisti della sicurezza informatica

Tempo fa, fui contattato da una nota azienda della grande distribuzione per una consulenza sulla sicurezza del loro sistema informativo, a tale scopo ho interrogato i responsabili della sicurezza interna che nella fattispecie erano l’amministratore di rete e il suo responsabile. Nell’ambito dei miei obblighi chiesi loro quali misure avessero adottato per proteggere il CED e la rete aziendale, la risposta fu: “Proteggiamo la rete con un ottimo Firewall hardware e le macchine sono dotate di un buon antivirus”. Misure che tra l’altro ritenevano sufficienti a proteggere il tutto. Nei giorni successivi ho proseguito la mia attività di analisi della rete e dei server aziendali che ha portato, in breve, alle seguenti conclusioni: molte stazioni di rete e server infettate da virus e server violati, causa impostazioni errate degli antivirus e Firewall; misure minime di sicurezza comportamentali non rispettate, con classico caso di dipendente, probabilmente in buona fede, con copia di backup dei dati della procedura di contabilità su chiavetta USB personale. In totale riscontrai ben 46 violazioni di cui due gravi. Tra l’altro il personale addetto alla sicurezza del sistema informativo aziendale era stato formato da società specializzate del settore che evidentemente non erano state all’altezza del loro incarico. Questo caso, tuttavia, insegna due cose fondamentali: la prima, che non è sufficiente acquistare e installare antivirus e firewall se non si è in grado di configurarli correttamente, poiché ciò è indice di scarsa professionalità; e la seconda, che i protocolli comportamentali nell’ambito della sicurezza vanno applicati con severità.

E’ chiaro quindi che i dati vanno protetti con regole e professionalità. Un GDPR da solo, se non applicato, è inutile. I dati rappresentano un valore da proteggere per garantirne attendibilità e disponibilità. D’altronde la diffusione delle reti di comunicazione aumenta le probabilità di diffusione di virus e attacchi, per cui occorre sviluppare le competenze dei professionisti per metterli in grado di adottare adeguate soluzioni che non sono solo tecnologiche, ma soprattutto organizzative e comportamentali.

A tale scopo L’European Competence Framework (eCF 3.0), nell’ambito delle norme UNI EN 16234-1, ha definito le competenze di due profili specifici per affrontare la sicurezza in ambito ICT: il Security Manager e il Security Specialist che possono ricoprire ruoli specifici nei diversi contesti per assicurare la migliore sicurezza possibile.

Le richieste del mercato del lavoro

La domanda di professionisti ICT è in costante aumento, ma il mercato non riesce a trovarli. Tuttavia la nenia delle aziende alla ricerca di professionisti ICT è sempre la stessa: “in Italia non si trovano professionisti ICT”. La stessa nenia, ovviamente, viene ribadita poi in occasione di molti convegni.

A febbraio 2018 si è tenuto a Torino, presso il CSI Piemonte, un seminario dal titolo: “Competenze Digitali 4.0 – Le Società in house per digitalizzare il Sistema Paese”. In tale occasione è stato presentato il rapporto dell’Osservatorio delle Competenze Digitali 2017, promosso da Assinter Italia insieme alle principali associazioni ICT quali Aica, Assinform, Assintel insieme all’Agenzia per l’Italia Digitale e al Ministero dell’Istruzione, dell’Università e della Ricerca. In questo Osservatorio delle Competenze Digitali 2017 mancavano, tuttavia, le principali società di professionisti ICT come l’Ordine degli ingegneri, l’Associazione Informatici Professionisti e altre associazioni minori. Chissà perché. Nel seminario poi si è parlato di requisiti delle professioni future e dei numeri del gap di professionisti ICT, delle caratteristiche dei percorsi di formazione dei laureati e di aggiornamento della forza lavoro. Ricordando che il tema è quello delle competenze digitali che possono e devono diventare un acceleratore per la crescita digitale del Paese.

Durante i lavori è emerso un dato su tutti: il divario fra quello cercato dalle aziende e la preparazione professionale di quanti sono in cerca di occupazione. Ogni anno in Italia la richiesta di professionisti ICT cresce mediamente del 26%, con picchi del 90% per le nuove professioni legate all’innovazione digitale come i Business Analyst e gli specialisti dei Big Data. C’è decisamente più richiesta nel Nord Ovest, in cui si concentra il 48% della domanda.

Il lavoro dunque c’è, ma molte posizioni che richiedono specializzazione in ICT restano scoperte. Per queste posizioni il mercato richiede il 62% di laureati e il 38% di diplomati, ma il nostro sistema formativo propone troppi diplomati e troppo pochi laureati in percorsi ICT.

Leggendo questi dati, su cui alcuni dubbi sono leciti, mi chiedo come mai molti nostri specialisti ICT, con laurea o senza, hanno preso la valigia e sono emigrati in altri paesi dell’area UE, e non solo. Sono forse poco sapienti per l’Italia? Oppure le aziende italiane cercano solo neo laureati con “esperienza” ventennale da pagare poco? Certo, sarebbe una contraddizione, è alquanto improbabile un neolaureato con esperienza ventennale. E sono certo che nel caso ce ne fosse uno lavorerebbe già oltralpe, se non altro perché sarebbe ben pagato. Allora il problema italiano è un altro, d’altronde si pagano poco anche laureati con vent’anni di esperienza.

In conclusione, il numero dei Certificati è in aumento, come anche il numero dei laureati del settore ICT e lauree affini. Tuttavia un ulteriore sforzo potrebbe riguardare quei specialisti ICT di lungo corso diplomati o laureati in lauree affini che potrebbero accedere a master universitari specialistici per un’ulteriore riqualificazione. Offerta, questa, molto diffusa nei paesi del nord Europa.

Bibliografia:

• Agrillo, A., (2012), Professione ICT: Competenze e professionalità, Torino, MiT Press;
• Cattaneo, A., Boldrini Laura, (2007), Le competenze ICT del formatore. Carocci;
• Grange,S., (2002) Building a Digital World: ICT Skills for Health Care Professionals;
• Don Passey, Arthur Tatnall (2014), Key Competencies in ICT and Informatics, Potsdam, Springer

Sitografia:

• CEPIS – https://www.cepis.org/index.jsp?p=637&n=642
• AGID – http://open.gov.it/wp-content/uploads/2017/05/professioni-ICT.pdf

Articolo a cura di Agostino Agrillo

L’articolo Professionisti ICT e Sicurezza Informatica proviene da ICT Security Magazine.

https://www.ictsecuritymagazine.com/articoli/professionisti-ict-e-sicurezza-informatica/