Il vero motore del Bitcoin

Il Bitcoin sta subendo un'impennata importante, non passa giorno che i telegiornali non ne parlino. Ma perchè improvvisamente è incrementata la richiesta?

Chi conosce questo blog, sa che mi occupo di bitcoin da quanto quotava appena 70 euro (qui parlavo del mining nel 2016, e qui spiegavo cosa fosse il mining nel 2013), le cose sono cambiate perchè la finanza speculativa è entrata prepotentemente all'interno dei meccanismi della valuta virtuale.

Faccio una premessa, sono molto critico su tutte le altre valute virtuali, perchè la domanda è quasi nulla e sono praticamente inspendibili. Solo il Bitcoin ha guadagnato il privilegio di poter essere speso in alcuni posti in alternativa ad una valuta tradizionale, e questo non è affatto poco. Oltretutto solo il Bitcoin è utilizzato da chi richiede soldi illegalmente, ma andiamo con ordine.

Vi siete mai chiesti qual è il vero motore di questa impennata?

(qui il grafico aggiornato in tempo reale)

Come in ogni mercato, la domanda fa incrementare il prezzo. Il Bitcoin non è diverso e non segue regole differenti da quelle del classico trading (di cui ho una modesta esperienza, da semplice curioso/matematico/logico che ha operato su alcuni mercati azionari). E qui la sicurezza informatica caratterizza pesantemente il mercato del Bitcoin.

Da gennaio 2016 la domanda sale, il bitcoin ha un inizio di rialzo che si mantiene costante. Chi sta comprando bitcoin?

Secondo  F-Secure il 2016 è l'anno in cui il fenomeno dei virus ransomware, ovvero quei software che crittografano i dati e li rendono inaccessibili salvo pagare un riscatto, esplode. Le vittime che rivogliono indietro i propri dati, devono pagare in Bitcoin (non tracciabili). E' più semplice di un bonifico in costa d'avorio oppure di una transazione western union. La vittima quindi cerca di convertire i propri Euro o Dollari in Bitcoin. La domanda sale, il prezzo del Bitcoin incrementa.

Il 2017 è stato l'anno in cui il ransomware si è consolidato, le previsioni sono di circa il 130% rispetto al 2016. Vari ransomware famosi hanno creato scompiglio, i vari TeslaCrypt et simila hanno dato una spinta, così arriviamo a Luglio 2017 con un incremento da 900$ a 2600$ in poche settimane.

A questo punto sono entrati gli speculatori professionisti, non i piccoli trader, ma chi fa questo di mestiere e muove volumi significativi. Lo si vede dal picco di fine luglio, il Bitcoin prende quasi il 100%. Scattano i take-profit, gli speculatori a breve termine vendono, il Bitcoin scende. Qualcuno ha duplicato il proprio capitale, questo nel trading tradizionale non esiste nè in cielo nè in terra. La notizia fa scalpore ed entrano i big, che acquistano nuovamente grandi quantitativi.

Scatta la corsa all'oro, si passa da 4300$ agli attuali 16000$. I telegiornali ne parlano, i piccoli investitori entrano. I grandi probabilmente attendono il minimo segnale per vendere. Ora tutto fa credere ad una bolla, chi si farà male sono i piccoli che non hanno messo degli stop-loss adeguati. Quando i big lasceranno la scena, con il 300% di margine, il Bitcoin crollerà, e lo farà violentemente perchè innescherà una serie di stop-loss uno dietro l'altro, creando un momentum negativo. La discesa sarà violenta.

Conviene investire ora? Io sono un informatico con la passione per il trading. Nessuno sa quanto ancora potrà camminare il Bitcoin. A grandi possibilità di margine corrisponde un grande, grandissimo rischio di perdere una somma di capitale molto alta. Se qualcuno ha una sfera magica in grado di capire il prossimo momento, se rialzista o ribassista, mi avverta. Ad ogni modo, perdonatemi la deviazione finanziaria, ma non sono andato del tutto OffTopic, la sicurezza informatica mai come in questo caso ha permeato la finanza mondiale condizionando il mercato.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Privacy e GDPR: nuovi adempimenti normativi (generici)

A fine maggio 2018 entrerà in vigore il GDPR, ovvero il Regolamento sulla Protezione dei Dati, approvato direttamente dal Parlamento Europeo. Sebbene in alcuni casi sia meno stringente della nostra normativa sulla privacy, vi sono sostanziali modifiche. Proviamo a schematizzare le variazioni che toccano direttamente le aziende e come queste devono gestire le informazioni.

• Cambiano i concetti e gli assiomi di partenza. Non si parla più di privacy, ma di protezione dei dati come componente primaria della privacy dei dati stessi. E non vi è più il concetto di "misura minima" ma subentra quello di "misura adeguata" nella protezione delle infrastrutture IT.

• Tutte le aziende che trattano dati sensibili di cittadini Europei devono adeguarsi, anche se non hanno sede all'interno della UE.

• Le aziende devono redirigere un registro delle attività di trattamento in cui sia ben esplicitato la finalità del trattamento stesso, il ciclo di gestione e le misure di sicurezza adottate per proteggere i dati (qualcosa di simile al vecchio DPSS).

• Solo i dati sensibili veramente indispensabili devono essere processati, e limitatamente a chi li deve elaborare. Questo sostanzialmente comporta nella maggior parte dei casi una riprogettazione dei sistemi che trattano i dati e di come questi debbano essere gestiti nel quotidiano.

• In caso di fuga di informazioni, l'azienda è obbligata a comunicarlo agli interessati entro e non oltre 72 ore dall'identificazione dell'accaduto.

• Le aziende avranno una nuova figura (l'equivalente del nostro "Responsabile della Privacy"), ovvero il DPO (Data Protector Officier), un esperto in materia giuridica, indipendente, che vigilerà anche sui processi aziendali. Il ruolo è obbligatorio in determinate casistiche (PA, società con più di 250 dipendenti o aziende che del trattamento dei dati fanno il loro core business).

• Similarmente a quanto accade ora, le aziende dovranno garantire la possibilità di cancellare i dati personali degli utenti in ogni momento. Cambia, tuttavia, la sanzione che può arrivare al 4% del fatturato annuo globale o ad un massimo di 20 milioni di euro.

• I sistemi informatici devono essere oggetto di un'analisi di rischio preventiva.

• I sistemi IT devono essere protetti da professionisti e consulenti. Seppur sia noto a tutti che una "medicina universale" non esista e che l'attacco informatico sia sempre in agguato, è necessario che le aziende dimostrino di aver investito nell'IT Security ed abbiano gestito la problematica con adeguata attenzione. La normativa italiana prevedeva l'adozione di misure di sicurezza perimetrale (un firewall, ad esempio) e di sicurezza dei client (un antivirus), è evidente tuttavia che questo adempimento risulta oramai perlopiù insufficiente. 

• Proprio il concetto di "misura adeguata" espone il titolare del trattamento a dimostrare, in caso di fuga di informazioni, perchè le misure adottate siano state reputate sufficienti. 

• Il titolare del trattamento dovrà occuparsi di formare tutti i collaboratori aziendali circa le tematiche in oggetto. Proviamo a dare una sfaccettatura più informatica: è opportuno che le risorse aziendali sappiano riconoscere un attacco di tipo Social Engineering in cui, ad esempio, un attaccante cerca di reperire informazioni via telefono.

• I locali ove risiedono i dati, anche elettronici, andranno adeguatamente protetti.

• Le tecnologie di backup e disaster recovery assumono un ruolo estremamente importante, soprattutto in ottica anti-estorsiva. La normativa attuale prevede già degli adeguamenti (ad esempio che i backup siano locati in plessi differenti), tuttavia il GDPR estende questi adeguamenti ad un'analisi più completa di tutto il processo di disaster recovery.

• I dati devono essere cifrati e la profilazione non deve essere riconducibile al singolo.

• Gli accessi illeciti ai dati devono essere obbligatoriamente notificati agli organi di competenza.

In un prossimo articolo andremo nel dettaglio degli adempimenti tecnologici riguardanti i responsabili IT e dell'infrastruttura informatica, entrando nel merito di come si stanno muovendo i vari vendor.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Alterazione del campo IBAN nelle fatture: nuove superfici di attacco alle aziende

A volte un'operazione normale come inviare una fattura via email può trasformarsi in un problema.

Immaginate di inviare una fattura in PDF ed immaginate che il vostro interlocutore riceva la stessa identica fattura, sempre in formato PDF, ma con il campo IBAN cambiato o popolato da un codice bancario non vostro.

Questo è quanto accaduto di recente in un caso che ho avuto modo di seguire.


Fattura originaria (in questo caso senza IBAN):

Fattura alterata, pervenuta all'interlocutore:

Una telefonata del destinatario, insospettito da un IBAN insolito (seppur italiano!), ha messo in luce la problematica prima che potesse essere dannosa.

E' bene precisare che il destinatario utilizza un dominio generico erogato da un noto ISP italiano ed oggetto di innumerevoli recenti attacchi e problemi di sicurezza. Utilizzare email con domini aziendali non è mai un errore, oltre ad essere sinonimo di professionalità.

Va aggiunto che il proprietario dell'IBAN italiano su cui avviene materialmente la truffa spesso è coinvolto con la formula "ci giri il denaro che ti arriva e ti trattieni una percentuale", nella classica formula "vuoi guadagnare soldi online?" che spesso si legge su qualche banner. Ciò non toglie che il reato sia e rimanga quello di riciclaggio, che lo si faccia con o meno cognizione di causa, non si scherza.

Si consiglia la massima attenzione, spesso una telefonata può salvare migliaia di euro.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Qualche accorgimento per passare delle buone ferie da responsabile EDP!

Il responsabile EDP, si sa, è sempre più o meno in servizio e ad Agosto spesso le ferie si trasformano in un vero e proprio "incubo da reperibilità".

Nel corso degli anni ho maturato una certa sfiga il 13 di Agosto. Giorno in cui immancabilmente sono dovuto scappare, ogni anno, per un problema sempre diverso. Sfighe a parte, a cui difficilmente sarà possibile porvi rimedio (e di sicuro un blog non vi sarà d'aiuto), una pianificazione e qualche consiglio potrà aiutare il responsabile informatico a minimizzare i propri interventi ed il proprio stress da "telefonata molesta". E no, la risposta non è "spegnete il telefono", non siate biricchini!

Ecco qualche personalissimo consiglio da mettere in pratica qualche giorno prima di andare in ferie:

1. Assicuratevi che tutti gli utenti abbiano ben chiare le proprie necessità, quando sono in ferie le esigenze cambiano! Quindi assicuratevi che gli utenti che necessitano di un autorisponditore ve lo dicano con anticipo (possibilmente non il 14 Agosto);

2. Come sopra: assicuratevi che gli utenti che necessitano di una VPN o di un Desktop Remoto vi diano il tempo di configurare il tutto e fare le verifiche dal proprio dispositivo (immagino non vogliate chiamate alle 21,00 perchè "non funziona la VPN dal MAC di mia figlia");

3. Spegnere i server non necessari! Meno superficie d'attacco lascio esposta, meglio è. Se ho un server di update ed il reparto RD è in ferie, non serve lasciare la macchina accesa;

4. Controllare la refrigerazione. E' impressionante la mole di problematiche legate alla refrigerazione che accadono ad Agosto! Con effetti anche spesso tutt'altro che banali (dischi che si guastano, server che vanno in protezione e si spengono, etc.). Se possibile dotatevi di un "piano B", al malfunzionamento di una macchina di condizionamento, fate intervenire degli aspiratori d'aria, spesso salva da guasti ben più gravi;

5. I backup vanno controllati sempre, ma prima di andare in ferie non è una cattiva idea investire del tempo per provare un piano di disaster recovery e verificare che realmente i backup siano utilizzabili e ripristinabili;

6. Inasprite le regole del firewall, anche se ad Agosto gli attacchi diminuiscono (dietro gli attacchi ci sono delle persone che, come voi, vanno in ferie), dare una controllata a tutte le regole (soprattutto quelle temporanee e diagnostiche, attivate per un fine specifico ma obsoleto) e spegnete quelle non più necessarie. A Settembre vi sarete dimenticati del perchè quella regola è stata attivata!

7.  Verificate che il vostro accesso all'infrastruttura sia perfettamente funzionante ed in sicurezza. Poter entrare rapidamente sulle proprie macchine spesso fa la differenza tra rientrare in azienda o risolvere tutto in pochi minuti da remoto;

8. Se disponete di sistemi di monitoraggio automatico, controllateli e verificate che facciano correttamente il loro lavoro (inviare email di alert, segnalare guasti, etc.);

9. Controllate le scadenze di tutto ciò che può scadere nel bel mezzo delle vostre ferie. Certificati SSL (HTTPS, IMAP, etc.), scadenza password, rinnovi di domini, etc.; 

E poi non resta che incrociare le dita e godersi delle meritate vacanze estive!

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Keylogger e sistemi di protezione... quando tutto funziona bene

Raramente su questo blog parlo di prodotti e, quando e se lo faccio, cerco di essere estremamente obiettivo. Questo perchè è mia espressa volontà mantenere questo blog slegato dall'attività lavorativa di consulenza di cui mi occupo. Questo caso specifico, tuttavia, merita menzione.

Di recente le maggiori testate del settore (e non) hanno portato alla luce uno spiacevole scivolone di HP (http://www.zeusnews.it/n.php?c=25288, http://securityaffairs.co/wordpress/59013/hacking/hp-keylogger-conexant-audio-driver.html) per cui il software conexant della scheda audio fungeva da keylogger catturando ogni input della tastiera e scrivendo tutto "allegramente" in un file di log. 

(Fonte ZeusNews)

Tralasciando l'incredibile leggerezza degli sviluppatori, la cui accezione sto generosamente attribuendo, esistono sistemi che in automatico intervengono per evitare questo problema potenzialmente catastrofico (immaginate bene cosa significhi per un amministratore di rete vedersi sottratte tutte le password di accesso ai suoi sistemi). Uno di questi sistemi è Stormshield SES a cui io attribuisco personalmente la categoria di "analizzatore comportamentale". SES è un software molto leggero in grado di analizzare svariati aspetti del sistema ed intervenire su comportamenti specifici. Non è un antivirus, ma va considerato come supplemento alla protezione standard del client. 

Appresa la notizia abbiamo aperto un incidente di sicurezza interno ed avviato un'indagine sui clienti dotati di questa tecnologia e che possiedono portatili HP.

Quanto è emerso è evidente, il sistema ha bloccato l'eseguibile fin dal principio e prima ancora che questo fosse stato oggetto di approfondimento da parte dei ricercatori che ne hanno scoperto la problematica.

Tutto è bene quel che finisce bene. ...e gli altri?

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Case Study: Quando il WISP ti fa saltare la Spanning Tree Topology

Lo Spanning Tree Protocol, con le sue varianti (RapidSTP), consente di raggiungere tipicamente due obiettivi:

• La ridondanza dei collegamenti tra più switch (ma non solo)
• La risoluzione di fenomeni di Broadcast Storm (comunemente chiamati loop)

Come funziona

Il funzionamento del protocollo RSTP è bene approfondirlo un attimo, seppur brevemente e semplificando alcuni concetti, così da entrare nel vivo del Case Study.

Immaginiamo di avere questa banale topologia di rete, ovvero uno switch di centro stella e due switch (A e B) secondari chiusi ad anello tra di loro.

E' subito evidente che, per prima cosa, in assenza del protocollo RSTP abilitato, la rete collasserebbe in un loop tale da renderla del tutto inutilizzabile. Il protocollo RSTP per sua natura impone il forward dei frame sulla porta solo dopo essersi accertato che non si tratta di un percorso ridondante. Quindi nella nostra architettura, della bretella A-B lo switch B blocca la porta mettendola in uno stato di non inoltro del traffico tradizionale (ma di inoltro delle BPDU, ovvero del traffico generato dall'RSTP degli switch stessi e necessario a trasferirsi informazioni circa la topologia di rete).

Altrettanto evidente è che l'interruzione di un qualsiasi percorso tra A e Root oppure tra B e Root, causerà (dopo un tempo minimo di convergenza) un cambio di topologia che vedrà protagonista la riattivazione completa della porta originariamente bloccata da B.

Ora immaginiamo uno scenario più articolato, ma che sostanzialmente è assimilabile a quello precedente:

Poniamo quindi il caso che le tratte nere siano in Fibra Ottica e le tratte rosse siano in Rame. Per sua natura, la Fibra Ottica ha una priorità superiore a quella in Rame, pertanto ogni switch intento a capire quale porta ridondante spegnere, tenderà a privilegiare la Fibra Ottica.

Tutto questo identifica, in maniera sommaria, una topologia di rete. Ad onor del vero ci sarebbe da parlare per ore su come gli switch eleggono una topologia e su come stabiliscono (in assenza di indicazioni specifiche) chi è il Root Switch e la gerarchia che ne deriva.

A noi, per non annoiarci in dettagli tecnici degni del miglior studente CCNA, interessa solo un principio: lo Spanning Tree abilitato per prevenire i loop, può essere lasciato di default. Ma lo Spanning Tree con percorsi ridondanti va configurato correttamente per non ritrovarsi con percorsi erroneamente lunghi oppure con lo switch dello scantinato come Root Switch a capo di tutta la topologia.

Questa configurazione si fa forzando l'autorevolezza di un apparato che deve imporsi su tutti gli altri.

Case Study

Poniamo il caso di avere un WISP che ci eroga connettività tramite un bridge radio (Layer 2, occhio, non Layer 3 come un router di un operatore tradizionale). Il bridge, ovviamente, fa passare le BPDU che lavorano a Livello 2 della pila ISO/OSI. Se siete particolarmente sfortunati ed il WISP ha impostato il Priority a 0 su uno dei suoi switch nella sua infrastruttura, esso si imporrà su tutto il nostro sistema in LAN forzando un cambio di topologia di rete che farà saltare ogni percorso minuziosamente studiato su carta.

L'aspetto più insidioso è che questo tipo di fenomeno spesso è apparentemente invisibile e si traduce in rallentamenti e micro-disconnessioni che, ad una prima e superficiale osservazione, possono essere sottovalutati o attribuiti "al solito server lento".

Soluzione

I log sono nostri amici: una volta identificato il problema disabilitare lo Spanning Tree sulle porte direttamente connesse ai gateway. E siccome non costa nulla, diciamo che è buona norma farlo sempre. 

Del resto, è del tutto sconsigliato creare una rete con percorsi ridondati senza controllare nei giorni successivi lo stato delle porte RSTP per capire se realmente il traffico sta facendo il percorso da noi voluto.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Desktop Virtualization (VDI): una breve panoramica nel mondo Horizon Vmware

Architetture VDI: cosa sono

Quando parliamo di architetture VDI (Virtual Desktop Infrastructure) parliamo di un'infrastruttura in grado di ospitare i desktop remoti degli utenti su server centralizzati spostando, di fatto, capacità elaborativa e di storage da un normale PC (con i limiti che questo possiede, da un punto di vista di ridondanza hardware, ad esempio) ad un pool di server adeguatamente vestiti per questo scopo.

Fondamentalmente, i PC diventano "stupidi" a tal punto da poter essere dei Thin Client, ovvero delle macchine con bassissima capacità (e dal bassissimo consumo energetico), appena sufficiente ad effettuare solo un banale collegamento con il server. In un'accezione più ampia, la propria postazione diviene accessibile da qualsiasi piattaforma, anche mobile, svincolando l'utente che ne trae (soprattutto se errante come un'agente di commercio) tipicamente molti benefici.

In ambito VDI dobbiamo però dividere delle architetture che caratterizzeranno completamente la nostra infrastruttura.

Architettura Full Clone Desktop Pool

L'architettura Full Clone è quella più vicina a chi ha dimestichezza con gli ambienti virtuali, ogni utente "atterra" su una sua macchina virtuale completamente dedicata. Questo comporta, come per ogni cosa, pregi e difetti. Ciò che acquistiamo come autonomia lo perdiamo come richieste hardware e costose licenze che vanno rinnovate ogni anno sui sistemi operativi desktop.

Architettura Linked Clone Desktop Pool

L'architettura Linked Clone necessita di una macchina chiamata Composer che si occupa di creare delle macchine figlie correlate che sono, in sostanza, dei differenziali tra la "Parent virtual machine" (o "Desktop Image") e le "Linked Clone Machine".

Avremo, quindi, un ambiente che racchiude i vantaggi principali della prima soluzione con quella che è la modalità più light della VDI e che vediamo di seguito.

Architettura Remote Desktop Session Host

L'architettura Remote Desktop Session Host è assimilabile (e si basa) al protocollo RDP/Microsoft Terminal Services. Per implementare questa modalità necessiteremo di un pool di server MS-TS in quanto le sessioni si sviluppano mediante questo meccanismo.

Anche qui, vantaggi e svantaggi si rincorrono. Da un punto di vista avremo un sistema poco esoso di risorse, dall'altro avremo altri costi di licenze (TS). Abbiamo, tuttavia, un grande vantaggio che apporta solo questa architettura, ovvero la possibilità di incapsulare delle applicazioni all'interno dell'ambiente VDI, in maniera completamente trasparente. 

Facciamo un esempio che personalmente adotto in ambienti dove la sicurezza è critica:

Ogni utente può avere il suo ambiente locale, ma la navigazione internet è demandata all'interno di una VDI. Sul desktop del client possiamo apprezzare una trasparenza impagabile, ovvero avere direttamente la chiamata verso (in questo caso) chrome in VDI senza fare alcun complesso accesso ad un altro ambiente virtuale in RDP.

Approfondiremo le tre modalità negli articoli successivi.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.