Source: https://www.studiomoceo.it/category/agenda-digitale/
Timestamp: 2020-08-15 18:07:20+00:00
Document Index: 93397268

Matched Legal Cases: ['art. 640', 'art. 640', 'art. 640', 'sentenza ', 'sentenza ', 'art. 615', 'art. 640', 'art. 615', 'art. 615', 'art. 615']

agenda digitale – Studio Moceo
La Polizia Postale segnala l’invio di email che offrono servizi connessi all’emergenza coronavirus o che danno indicazioni su importanti prescrizioni mediche. Vediamo quali sono le truffe più diffuse, cosa può fare chi è stato colpito da queste frodi e quali sono le ipotesi di reato prefigurabili
ono al massimo storico i reati connessi a truffe e frodi online – phishing (web, mail), vishing (via telefonata vocale), smishing (via sms). Già, perché in un momento in cui tutta Italia è sul web, aumenta la vulnerabilità di ciascuno di noi. Assistiamo così al triste fenomeno di false raccolte fondi, siti fasulli per la vendita di mascherine e prodotti igienizzanti per le mani oppure la vendita a prezzi aumentati anche del 5000%.
Non è un caso che il 25 marzo 2020 il ministero dell’Interno abbia evidenziato un aumento significativo di tentativi di truffe on line.
La Polizia Postale segnala l’invio di e-mail che offrono servizi connessi all’emergenza Coronavirus o che danno indicazioni su importanti prescrizioni mediche. Torna alla ribalta anche il cosiddetto Vishing: attraverso telefonate fake soprattutto agli utenti più bisognosi di tutela, i truffatori promettono utilità o danno informazioni fasulle per farsi dare dati utili, di solito password per accedere a conti correnti home banking o pin di carte di credito.
Forniamo, quindi, di seguito una visione d’insieme delle ipotesi di reato astrattamente configurabili ed un breve commento della normativa in materia.
Reati di phishing, vishing e smishing, cosa sono e come difendersi
Che reato è il phishing?
I reati legati a vishing e smishing
Partiamo subito dall’unico vero strumento di tutela dalle truffe online (e da quelle “classiche”): la prudenza.
Non fornire dati a chi li richiede con una chiamata e/o con un messaggio (qualunque sia lo strumento di messaggistica). Le email inattese con allegati sono una potenziale minaccia e vanno trattate con la massima attenzione.
Il phishing è nato come strumento di reperimento di credenziali bancarie o di carte di credito attraverso email con il logo contraffatto – normalmente – di un istituto di credito, in cui si invita il destinatario a fornire dati riservati (numero di carta di credito, password di home banking, ecc.), motivando la richiesta con ragioni tecniche.
Dal password phishing si è passati al voice phishing (da cui vishing): la richiesta di dati bancari o credenziali di carte di credito arriva con chiamate da call center che fingono di tutelare la vittima da…tentativi di frode.
Un famoso caso della fine 2019 vedeva i dati degli utenti reperiti, in prima battuta, direttamente dagli Istituti bancari: i truffatori si fingevano agenti delle Forze dell’Ordine, chiedendo nomi e dati di clienti, millantando il sequestro di numerose carte di credito in operazioni di polizia.
Lo smishing, infine, è un’operazione analoga per mezzo di sms, da Short message phishing.
Cosa fare in caso di telefonate, messaggi o email sospette? Oltre ad essere prudenti, evitando ogni riferimento a dati, password e pin, è opportuna la segnalazione alla Polizia postale.
Cosa può fare chi è stato colpito da queste frodi? Si deve fare denuncia o querela (se richiesta). Ora vedremo per quali ipotesi basta la denuncia e per quali è necessaria la querela.
Può sembrare incredibile ai non addetti ai lavori, ma le frodi descritte in precedenza possono integrare reati diversi a seconda delle modalità concrete con cui vengono effettuati e, comunque, la giurisprudenza della Corte di cassazione non ha definito in maniera univoca quali ipotesi vadano ricondotte ad un determinato delitto e quali ad un altro.
La questione si “gioca” tra due reati, ossia la truffa “classica”, reato previsto dall’art. 640 Codice penale, eventualmente aggravata, e la frode informatica, prevista dall’art. 640 ter Codice penale.
Entrambe le fattispecie richiedono che vi sia un danno economico per la vittima, di solito consistente nel prelievo di somme di denaro dal conto corrente o dalla carta d credito.
Mentre il delitto di truffa prevede l’induzione in errore della vittima con artifizi e raggiri, la frode informatica richiede solo l’alterazione del funzionamento di un sistema informatico o telematico o l’intervento senza diritto ed in qualsiasi modo su dati, informazioni o programmi contenuti in un sistema informatico o telematico.
Per questa ragione dottrina e giurisprudenza sono concordi nel ritenere che il phishing effettuato con malware o altri programmi autoinstallanti, debba essere ricondotto al delitto di frode informatica.
Le ipotesi di phishing in cui la vittima fornisce i propri dati accedendo al link inviato a mezzo email, invece, sono considerate truffe ai sensi dell’art. 640 Codice penale.
In quest’ultima ipotesi, infatti, la vittima è indotta in errore da email con loghi contraffatti e con richieste verosimili.
Va detto che gli ultimi arresti giurisprudenziali affermano la responsabilità penale per frode informatica (640 ter) anche per il phishing effettuato mediante email con dati forniti direttamente (così la sentenza n. 21987 della Cassazione, Sezione Seconda penale, del 14 gennaio 2019).
Altra questione rilevante è comprendere se vi siano altre ipotesi di reato astrattamente configurabili.
Nella sentenza ultima citata oltre alla frode informatica, gli autori del phishing sono stati condannati anche per il reato di cui all’art. 615 ter Codice penale (Accesso abusivo a un sistema informatico o telematico), aprendo alla possibilità di concorso tra il reato di cui all’art. 640 ter Codice penale (frode informatica) e quello di cui all’art. 615 quater Codice penale (Detenzione e diffusione abusiva di codici di accesso a sistemi informatici).
La fattispecie di cui all’art. 615 ter Codice penale è un reato comune, a forma libera, di mera condotta (quantomeno per le ipotesi alternative non aggravate), con dolo generico, che punisce l’introduzione o il mantenimento in un sistema informatico o telematico.
L’art. 615 quater Codice penale è reato comune, a forma libera, di mera condotta, con dolo specifico e punisce chi si procura abusivamente codici o parole chiave per profitto e con danno ad altri.
A seconda delle ipotesi, quindi, la Cassazione ha ritenuto che il phishing integri o la frode informatica e l’accesso abusivo, o la frode informatica e la detenzione o diffusione di codici o password.
Seguendo l’interpretazione delle ultime sentenze della Cassazione, i due fenomeni rientrano nella frode informatica e vale quanto detto poc’anzi sugli altri reati configurabili. La dottrina, per la verità, resta divisa e ritiene, in parte, che si debba comunque parlare solo di truffa “classica”.
Quali sono gli strumenti di tutela per le vittime di questi reati?
Sia la truffa che la frode informatica sono reati punibili a querela della persona offesa: per i non addetti ai lavori, significa chiedere all’Autorità giudiziaria di procedere penalmente nei confronti di un soggetto entro tre mesi dal momento in cui si è verificato il fatto (in questo caso, da quando si ha la certezza di essere stati truffati).
Nelle ipotesi aggravate, sia di truffa che d frode informatica, invece, è sufficiente la denuncia.
fonte: https://www.agendadigitale.eu/sicurezza/tutti-i-reati-delle-frodi-informatiche-tra-phishing-vishing-e-smishing/
I problemi di sicurezza cyber da affrontare nello sviluppo di un sistema/app per il tracciamento dei contatti anti coronavirus sono diversi.
Analizziamoli, con le possibili contromisure per massimizzare l’efficacia delle tecnologie volte a limitare la diffusione dei contagi covid-19 14 minuti fa Fabrizio Baiardi Università di Pisa Molte applicazioni di contact tracing per il coronavirus non garantiscono la sicurezza dei dati raccolti e (di conseguenza) la privacy delle persone. Ad esempio, nel mondo esistono 43 applicazioni per il tracciamento ma circa il 30% di loro non adotta nessun meccanismo di sicurezza. Un dato di fatto con cui bisognerà fare i conti, mentre è opinione comune che una app per lo smartphone sia la soluzione più semplice ed efficace per tracciare persone potenzialmente infette a cui applicare misure sanitarie. Molte delle strategie di progetto di queste applicazioni utilizzano l’approccio di “aggiungere” la sicurezza informatica a posteriori dimenticando come questo approccio abbia prodotto le decine di data breach degli ultimi anni con la diffusione dei dati personali di milioni di persone. Si utilizza l’approccio della sicurezza “aggiunta” quando, ad esempio, si adotta un approccio “data driven” per scegliere applicazioni per il tracciamento delegando la sicurezza informatica ad altri che devono operare successivamente. Anche quando ci si preoccupa della privacy si dimentica della sicurezza informatica, come se fosse possibile avere la prima senza la seconda. Indice degli argomenti I diversi problemi di sicurezza e privacy per le app coronavirus La peer review del codice del sistema, prima soluzione I problemi di sicurezza di un sistema per il contesto strategico I problemi di sicurezza di un sistema per il contesto personale I diversi problemi di sicurezza e privacy per le app coronavirus Per descrivere i problemi di sicurezza e privacy da affrontare nello sviluppo di un sistema per il tracciamento è utile distinguere tra due tipi di sistema che corrispondono ai fondamentali contesti di utilizzo dei dati generati dal sistema stesso 1, 2, 3. Il primo tipo di sistema è progettato per un contesto che, per brevità, indichiamo sinteticamente con strategico perché il sistema viene sviluppato per raccogliere dati di supporto alle decisioni politiche sulla gestione dell’emergenza e per fornire al singolo cittadino informazioni sul suo stato di salute e le potenziali infezioni. Tipica decisione politica che utilizza i dati raccolti da un sistema strategico è se terminare il lockdown o ripartire, in quali luoghi geografici ed in quali contesti – industria, centri commerciali, scuole o università – si ha una maggiore diffusione del virus. Le informazioni per il singolo cittadino riguardano il suo stato di salute, la sua potenziale infezione, il rischio che sta correndo e quello per gli altri. Il secondo contesto di utilizzo che, con altrettanta sinteticità, indicheremo con personale, è quello in cui il sistema raccoglie e gestisce unicamente le informazioni su contatti avuti dalla singola persona, senza informazioni di dove e quando i contatti sono avvenuti o sull’identità delle persone coinvolte. Assumiamo per il momento che la distinzione tra i due contesti sia netta ed esaminiamo i problemi di sicurezza condivisi o specifici di ogni contesto. Un sistema per un contesto strategico raccoglie informazioni geolocalizzate sulle posizioni di ogni smartphone, e quindi sui contatti di ogni persona. I dati raccolti devono necessariamente essere geolocalizzati perché questo è l’unico modo di scoprire i luoghi più esposti ai pericoli di infezioni. I dati raccolti vengono memorizzati e gestiti in un backoffice che comprende un insieme di server interconnessi. I server del backoffice analizzano i dati per scoprire quante persone erano in un certo luogo ma anche per rintracciare i potenziali infetti e pianificare dove servire un certo servizio sanitario o dove creare ospedali di emergenza. La granularità della localizzazione varia, ad esempio quella inglese usa i codici postali ma comunque esiste. Anche se assumiamo che l’informazione raccolta dal singolo smartphone sia anonima, perché non contiene informazioni sull’identità del proprietario, numerose ricerche hanno dimostrato che la localizzazione permette di risalire facilmente alle identità specialmente se chi gestisce il sistema ha a disposizione altre informazioni, ad esempio le carte di credito utilizzate in un centro commerciale. Il problema della deanonimizzazione dei dati raccolti può essere meno rilevante se il sistema è gestito da un ente pubblico ma questo può porre il problema dei tempi e delle risorse per la costruzione del sistema su cui torneremo nel seguito. Un sistema per il contesto personale utilizza strategie p2p per gestire in modo decentralizzato la raccolta di informazioni sui contatti. In un sistema di questo tipo, la app eseguita su ogni smartphone genera in maniera pseudocasuale degli identificatori temporanei che distribuisce agli altri smartphone con cui entra in contatto via Bluetooth. L’uso di identificatori temporanei impedisce il tracciamento della persona che usa lo smartphone. L’applicazione inoltre ricorda su ogni smartphone gli identificatori temporanei ricevuti da quelli delle persone con cui si è entrati in contatto. In questo sistema problemi di prestazioni del backoffice sono meno critici perché il backoffice viene utilizzato solo per caricare gli identificatori temporanei utilizzati da un infetto e trasmetterli a tutti gli altri smartphone. Questa diffusione permette a tutti gli smartphone che ricordano almeno uno degli identificatori temporanei trasmessi di avvertire il proprietario della potenziale infezione. Uno smartphone elimina gli identificatori ricevuti dopo un tempo che dipende dal tempo di incubazione della malattia, circa 14 nel caso del CoVid-19. Gli smartphone cancellano autonomamente e gradualmente tutti gli identificatori quando l’infezione viene eliminata. La peer review del codice del sistema, prima soluzione Un primo requisito, del tutto ovvio e scontato quando si parla di sicurezza informatica e che vale per entrambi i contesti, è la peer review del codice del sistema. La review deve applicare un insieme di analisi standard che vanno dal vulnerability scanning al fuzzing. Ovviamente, il fatto che il codice della app sia open source facilita la peer review ed aumenta il numero dei reviewer. Un punto che però è spesso trascurato è che la review deve analizzare il codice di tutto il sistema per la raccolta e gestione dei dati e non solo l’applicazione per lo smartphone. Ogni sistema ha un backoffice, una infrastruttura formata da sistemi hardware e software per la raccolta, la memorizzazione e la gestione dei dati di raccolti. Per questo occorre considerare tutto il sistema e non solo l’applicazione. Focalizzarsi sull’applicazione ci fa dimenticare che quando un cellulare scambia una qualunque informazione con il backoffice deve essere autenticato, occorre creare dei backup dei dati raccolti, patchare le vulnerabilità del backoffice ed eseguire le normali attività di amministrazione. Queste attività sono critiche perché i dati gestiti dal backoffice non sono anonimi. Inoltre, lo scambio di dati tra i vari smartphone offre numerose opportunità ai malintenzionati di inviare dati manipolati che potrebbero essere usati per attaccare il backoffice. Ciò richiede rigorosi controlli sui dati che il backoffice riceve per individuare dati malevoli. Le indicazioni suggerite da ENISA 4 per la sicurezza informatica devono essere applicare a tutto il sistema e non solo alla app. Dimenticare il backoffice e focalizzarsi solo sull’adozione di un app open source può far trascurare problemi di sicurezza altrettanto importanti. Sarebbe bello ragionare sulla sicurezza di un sistema in modo modulare, valutando la sicurezza del singolo modulo, ma sappiamo da tempo che la sicurezza non può essere affrontata in questo modo. I problemi di sicurezza di un sistema per il contesto strategico L’analisi dei problemi di sicurezza di un sistema per il contesto strategico è già stata magistralmente sviluppata da Ross Anderson 5 che solleva problemi non banali. Il primo è l’anonimato che è difficile da garantire quando la persona che viene segnalata infetta o potenziale infetta deve essere contattata dal servizio sanitario. Il problema è indipendente dalla specifica tecnologia o soluzione utilizzate perché ogni sistema, indipendentemente dal contesto in cui opera, deve trasmettere i dati delle persone infette all’ufficio competente del servizio sanitario. Da questo momento, ogni anonimato cessa. Questo vale, o dovrebbe valere, anche per un sistema per il contesto personale perché pare assurdo non coinvolgere il servizio sanitario nella gestione delle informazioni su infetti o potenziali infetti. In questo caso, ad esempio, la persona potenzialmente infetta può decidere volontariamente di fornire le proprie informazioni personali, che il backoffice raccoglie e gestisce in appositi database da proteggere opportunamente. Se teniamo conto del volume delle informazioni di cui stiamo parlando, alcuni milioni di cittadini se consideriamo i potenziali infetti, anche il progetto di un sistema per il contesto personale deve decidere come gestire le infrastrutture del backoffice, se e quando eliminarle, come distruggere i dati ancora contenuti. Infatti, questa parte del sistema non viene cancellata quando gli smartphone smettono di raccogliere informazioni sui contatti. Ciò pone problemi di privacy altrettanto importanti di quelli del tracciamento e delle applicazioni.