Archivi categoria: Sicurezza

Come crittografare una VM su Azure utilizzando Key Vault e lo standard BitLocker

Microsoft Azure mette a disposizione nuovi strumenti per la sicurezza dei nostri dati. Utilizzando pochi comandi PowerShell e concetti base su Key Vault in questo articolo vedremo come crittografare il disco di una VM con lo standard BitLocker.

Prerequisiti:

  • Azure PowerShell
  • Configurazione di un Key Vault

Per soddisfare i prerequisiti potete consultare il precedente articolo https://www.ictpower.it/guide/configurare-microsoft-azure-keyvault.htm

Configurare la VM

Creiamo una nuova VM associata al resource group NewResourceGroup, che avevamo creato nel precedente articolo, utilizzando Resource Manager come modello di deployment.

Figura 1: Scelta del deployment model

Figura 2: parametri per la creazione della nuova VM

Assicuriamoci che tutte le configurazioni siano relative al resource group corretto, cioè quello dentro il quale abbiamo abilitato Key Vault.

Al termine della creazione della VM, cliccando su Disks è possibile constatare che il disco non è crittografato.

Figura 3: Verifica che il disco creato non è crittografato

Scarichiamo dal repository GitHub ufficiale di Azure lo script denominato Azure Disk Encryption Prerequisite Setup, che si occuperà di soddisfare i prerequisiti necessari.

Utilizzando PowerShell ISE, configuriamo il contesto nel quale lo script verrà eseguito con i comandi:

Login-AzureRmAccount

Set-AzureRmContext -SubscriptionId <SubscriptionID>

Eseguiamo lo script:

Figura 4: Esecuzione dello script che verifica i prerequisiti per Azure Disk Encryption

Durante l’esecuzione, lo script chiederà alcune informazioni:

  • Il resource group da utilizzare
  • Il nome di una chiave; se non presente sarà creata automaticamente
  • L’area geografica
  • Il nome di un’applicazione: questa verrà usata per scrivere il segreto nel Key Vault; se non presente, verrà anch’essa creata automaticamente.

Figura 5: Inserimento dei parametri nello script di verifica

Crittografare la VM

Per crittografare la VM è necessario alcuni comandi PowerShell. Dichiariamo qual è il resource group da utilizzare e il nome della VM interessata utilizzando i comandi:

$resourceGroupName ‘NewResourceGroup’

$vmName ‘VMtestKV’

Dopo aver configurato il contesto corretto, possiamo utilizzare il seguente comando per eseguire l’azione di crittografia:

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $resourceGroupName -VMName $vmName -AadClientID $aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $keyVaultResourceId -VolumeType All

Confermiamo per concludere l’operazione:

Figura 6: richiesta di conferma prima dell’abilitazione della crittografia del disco

Al termine dell’esecuzione, lo script ritorna il seguente output:

Figura 7: Crittografia del disco completata

Verificando nuovamente nei dettagli della macchina potremo constatare che l’operazione è avvenuta correttamente.

Figura 8: Il disco della VM risulta crittografato

Conclusioni

Azure fornisce diverse soluzioni in ambito crittografico e quella descritta in questo articolo è particolarmente utile soprattutto se il monitoraggio delle macchine viene effettuato tramite Azure Security Center. Inoltre, con pochi click è possibile applicare la stessa procedura agli storage account in merito a files e blob, rispettando lo standard BitLocker e aumentando la sicurezza delle nostre infrastrutture su cloud.

IBM: crittografia end to end per i mainframe Z

Fonte: Connie Zhou per IBM

IBM Z14

IBM punta sulla sicurezza. In base a quanto affermato in un comunicato stampa ufficiale, i mainframe Z14 saranno in grado di proteggere in modo permanente i dati delle aziende grazie alla crittografia end to end. Quest’ultima, prosegue la nota, potrà essere estesa anche ad altri dispositivi come sistemi di storage o anche server cloud. Z14 è stato inoltre pensato per rispettare ed eseguire automaticamente le direttive previste dal Regolamento generale sulla protezione dei dati (GDPR) in arrivo a Maggio 2018.

Ad oggi la diffusione delle crittografia nei data center enterprise è molto bassa (circa il 2% contro l’80% dei dispositivi mobile) per via di note problematiche insite nell’utilizzo di algoritmi complessi di cifratura, in particolar modo il decadimento delle prestazioni (occorre una discreta capacità computazionale per gestire il tutto) e più in generale dell’user experience – afferma IBM. I 4 miliardi di archivi compromessi (stima per il 2016) e l’incremento di furti digitali (+556% rispetto al 2015) dovrebbero tuttavia spingere all’adozione di sistemi di protezione più efficaci.

IBM dichiara di aver utilizzato il 400% in più di silicio per la sola gestione degli algoritmi. E rispetto alle corrispettive soluzioni Intel, i microprocessori custom adottati da Z14 risultano 18 volte più rapidi al 5% del costo delle cpu progettate a Santa Clara. L’avanzamento tecnologico interessa anche la gestione dei workload: +35% di capacità per i workload tradizionali e +50% per quelli Linux.

Altri dettagli

Il livello di sicurezza promesso da IBM è totale: oltre a prevenire situazioni “stile Snowden”, quindi insider o utenti privilegiati che tentano di impadronirsi e diffondere informazioni riservate (l’operato di Snowden è comunque tutt’altro che criticabile), assicura protezione anche durante processi di installazione.

Il sistema di gestione delle chiavi è in grado di salvaguardare milioni di chiavi, gestire le varie procedure ad esse legate (accesso, generazione, eliminazione) ed anche autodistruggerle e ricorstruirle nel caso in cui siano rivelate attività non autorizzate (tentativi d’intrusione o intrusioni in atto etc.).

L’engine pensato da IBM per gestire transazioni di questo tipo è servito come base per sviluppare le nuove funzionalità dei mainframe Z14, sottolinea IBM. L’engine, conclude, gestisce l’87% di tutte le transazioni effettuate via carta di credito, circa 8 bilioni di pagamenti all’anno e 30 miliardi di transazioni al giorno.

Fonte: 1

 

 

Configurare Microsoft Azure KeyVault

Azure KeyVault è un sistema di gestione di chiavi crittografiche e relativi segreti adoperati da applicazioni e servizi su Azure.

Con KeyVault è possibile crittografare chiavi di autenticazione, certificati .pfx, password ecc., utilizzando anche HSM.

Questo piccolo articolo è un’introduzione al concetto di sicurezza su Cloud e analizzerà come far comunicare un’applicazione con un’infrastruttura su Azure, attraverso l’utilizzo di una chiave crittografata. Tale configurazione viene effettuata tramite Azure PowerShell.

Per informazioni sui costi: https://azure.microsoft.com/it-it/pricing/details/key-vault/

Per velocizzare le cose utilizzeremo un’applicazione d’esempio che Microsoft mette a disposizione: https://www.microsoft.com/en-us/download/details.aspx?id=45343

Installare Azure PowerShell da PowerShell Gallery

Verifichiamo l’installazione di PowerShellGet:

Get-Module PowerShellGet -list Select-Object Name,Version,Path

Se il risultato è quanto segue, abbiamo già cosa serve:

In caso contrario, installiamo il seguente update:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Eseguendo PowerShell come amministratore, lanciamo il comando:

Install-Module AzureRM

Nel caso in cui fosse la prima volta che utilizziamo PowerShell Gallery, ci verrà richiesta una conferma prima di installare il modulo.

Confermiamo quindi l’installazione e, una volta terminata, importiamo i nuovi moduli con il comando:

Import-Module AzureRM

A questo punto siamo pronti per iniziare!

Configurare il KeyVault

Il primo passo consiste nell’effettuare il login alla propria sottoscrizione su Azure:

Login-AzureRmAccount

Selezioniamo la specifica sottoscrizione con i comandi:

Get-AzureRmSubscription

Set-AzureRmContext -SubscriptionId <subscription ID>

Creiamo un nuovo Resource Group, che con molta poca fantasia chiameremo “NewResourceGroup”, nel quale effettuare le nostre configurazioni:

New-AzureRmResourceGroup –Name ‘NewResourceGroup’ –Location ‘West Europe’

A questo punto possiamo creare un nuovo KeyVault associato al resource group:

New-AzureRmKeyVault -VaultName ‘FKeyVault’ -ResourceGroupName ‘NewResourceGroup’ -Location ‘West Europe’


L’output di quest’ultimo comando mostra una delle proprietà più importanti: il Vault URI. Tutte le applicazioni che dovranno utilizzare il nuovo KeyVault attraverso le API Rest lo faranno attraverso questo URI.

Aggiungiamo una key al nostro KeyVault:

$key Add-AzureKeyVaultKey -VaultName ‘FKeyVault’ -Name ‘NewKey’ -Destination ‘Software’

Per verificare l’URI, utilizziamo il comando:

$Key.key.kid


Per configurare una stringa a questa chiave, ad esempio una password chiamata “Segreto” il cui valore è “123password”, è necessario effettuare due operazioni:

  • convertire la stringa in una stringa sicura;
  • associare la stringa sicura alla chiave.

$secretval ConvertTo-SecureString ‘123password’ -AsPlainText –Force

$secret Set-AzureKeyVaultSecret -VaultName ‘FKeyVault’ -Name ‘Segreto’ -SecretValue $secretval

Per verificarne l’URI:

$secret.Id


Per verificare quanto appena configurato:

Get-AzureKeyVaultKey –VaultName ‘NKeyVault’

Get-AzureKeyVaultSecret –VaultName ‘NKeyVault’

Configurare l’applicazione

Dopo aver scaricato l’applicazione d’esempio, apriamo la solution con Visual Studio


Contestualmente nella directory scripts troveremo lo script GetAppConfigSettings.ps1 da modificare ed eseguire.


È sufficiente modificare le prime righe configurando ciò che abbiamo appena creato:

  • Nome del KeyVault
  • Nome del Resurce Group
  • Nome dell’applicazione


Eseguiamo lo script.

Quando richiesto, inseriamo una password per il certificato.

Al termine dell’esecuzione dello script in output avremo delle chiavi da inserire all’interno del file app.config dell’applicazione.


Caricando lo snap-in dei certificati relativi all’account locale è possibile comprovare l’avvenuta creazione del certificato, senza il quale l’applicazione non sarà in grado di verificare le credenziali su Azure.


Le applicazioni che utilizzano KeyVault devono autenticarsi utilizzando un token generato da Active Directory, nel nostro caso Azure Active Directory.

Per farlo, clicchiamo su “Azure Active Directory”, successivamente su “App registrations” e cerchiamo la nostra applicazione HelloKeyVault.


Abilitiamo l’applicazione all’utilizzo della chiave copiando il clientID (Application ID) e utilizziamo il seguente comando:

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘FKeyVault’ -ServicePrincipalName 341efa38-faf5-459e-903a-05e9a5ad7309 -PermissionsToKeys all

Per verificare che tutto sia andato a buon fine proviamo a eseguire l’applicazione dal sistema in cui è installato il certificato. In questo modo vedremo come questa utilizzi il KeyVault generato e la relativa chiave, con la possibilità di eseguire tutte le operazioni che il KeyVault stesso mette a disposizione:


Conclusioni

La sicurezza è sempre una tematica attuale e, spesso, sottovalutata.

In questo contesto, Azure fornisce delle soluzioni pratiche anche per quei clienti spaventati dall’avere i propri dati sul Cloud.

Fornire agli sviluppatori delle chiavi crittografate, centralizzandone la gestione e mantenendo uno standard di sicurezza adeguato è solo uno dei pregi di questa soluzione, benché sia facilmente intuibile di aver trattato solo scalfito la superficie di quest’ampia tematica.

I ransomware sono solo una parte del problema

Articolo sponsorizzato su ransomware e botnet

Questo articolo è sponsorizzato da Hosting Solutions e dalla gamma “Servizi per la Sicurezza”.

Tra Aprile e Giugno l’opinione pubblica si è scoperta interessata alle ondate di attacchi ransomware che hanno colpito i terminali di mezzo mondo. Ed il merito è stato principalmente dei giornali/siti non specializzati che hanno deciso di dare ampio risalto alla vicenda Wannacrypt, il malware “confezionato” da programmatori ancora sconosciuti in grado di crittare gli hard disk e rendere inutilizzabili i dati in essi contenuti – la chiave di decrittazione era ottenibile previo pagamento di un riscatto in BitCoin.

Il caso Petya ha ricevuto meno attenzione da parte dei media classici (TV, radio e giornali cartacei) acquisendo invece una buona “popolarità” online. Considerato inizialmente come un’evoluzione di Wannacrypt, basato quindi sull’expoilt NSA EternalBlue, il malware si è rivelato negli ultimi giorni qualcosa di profondamente differente da un semplice mezzo per raccimolare BitCoin: Eset ed altre aziende di sicurezza informatica hanno avanzato l’ipotesi che si sia trattato di un attacco ben congegnato e pensato esclusivamente per provocare danni – ecco perchè Petya è stato ribattezzato poi NotPetya e classificato come “wiper”, un programma che elimina i dati. Si è addirittura parlato di “attacco informatico ad uno Stato [l’Ucraina ndr] mascherato da campagna ransomware”.

Ransomware: a capo del problema

Uno degli elementi trascurati/dimenticati dal racconto mediatico degli attacchi sono le botnet, reti costituite da computer/webserver/altri device (es: dispositivi “intelligenti”) ed impiegate per svariate attività illegali: dall’invio di classici messaggi di spam fino al lancio di attacchi DDoS, campagne ransomware (che sono quindi una parte del problema, come afferma il titolo), “truffe” sul mercato finanziario (financial stock scam spam), utilizzo della capacità di calcolo per operazioni di BitCoin mining etc.

Le botnet hanno saputo fronteggiare con successo governi, agenzie ed aziende di sicurezza. E se queste ultime sono state in grado di portare a casa importanti risultati, come la chiusura della botnet Avalanche (vari arresti, 800.000 domini sequestrati, 200 server coinvolti ed 1 milione di “vittime” stimate), non sono riuscite (prevedibilmente)  a debellare completamente il problema botnet dalla Rete.

L’espediente di passare dal vecchio sistema client-server al p2p (peer to peer) ha trasformato ogni bot in un’entità capace sia di inviare che ricevere “ordini”, aumentando la resilienza della botnet stessa – dipendente dal client nel precedente modello “organizzativo”. L’innovazione passa anche dall’aggiramento di sistemi di blacklisting ed autenticazione come gli odiati (dagli utenti) captcha: la botnet (ora dismessa) Mumblehard, costituita da 4000 server, si appoggiava ad uno script in grado di monitorare costantemente la Spamhaus Composite Blocking List, tra le più note lista di indirizzi IP bloccati per SPAM, e portare a termine la richiesta di cancellazione dell’indirizzo IP dalla lista bypassando i captcha sfruttanto servizi esterni o soluzioni OCR (Optical character recognition).

Sotto osservazione

Necurs è la bot net di spam più grande attualmente “in servizio” e conta, affermano gli esperti, circa 5 milioni di bot. I gestori di Necurs si sono concentrati fino ad ora su attività di spam (classico, financial stock scam spam) ma la possibilità che possano lanciare attacchi DDoS sono elevate. Risale infatti al 2016 l’aggiunta di un modulo destinato proprio al lancio di attacchi DDoS – ma la sua implementazione è stata notata solo recentemente dagli esperti.

Considerando che il malware Mirai, disponendo di migliaia di telecamere di sorveglianza hackerate, è riuscito a raggiungere (sono sempre stime, il bersaglio dell’attacco DYN non ha divulgato i valori esatti) la soglia di 1Tbps (il precendente record era 620Gbps ed aveva interessato il blog Krebs On Security) quale volume di dati potrebbe “muovere” una botnet come Necarus?

Wannacrypt, uno dei ransomware che ha avuto più “successo”, almeno per numero di terminali colpiti, ha superato indicativamente quota 300.000. Botnet come Necarus o altre “minori” possono arrivare anche a milioni di “bot” sui quali è possibile agire (es: crittarli, cancellare i dati etc.) in qualsiasi momento con una percentuale di successo prossima al 100%.

Contromisure

Per prevenire e/o mitigare problematiche associate alle attività illegali menzionate in apertura è opportuno non solo istruire adeguatamente il personale aziendale (nozioni base di sicurezza spesso ignorate o non applicate) ma anche utilizzare i più noti servizi/sistemi di sicurezza: certificati SSL, filtri antivirus ed antispam per le caselle di posta, servizi di monitoraggio dei siti ed analisi del traffico, firewall, sistemi di mitigazione degli attacchi DDoS; non bisogna dimenticare infine l’aggiornamento periodico di software, plugin e sistemi operativi. Come dimostrato dalla vicenda Wannacrypt, l’applicazione degli aggiornamenti rilasciati solo due mesi prima da Microsoft avrebbe sostanzilamente reso vana la campagna ransomware degli hacker.

Fonti: 1,2,3

 

 

Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD

Privileged Access Management (PAM) è una funzionalità introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) e che permette di gestire quella che viene chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server.

JEA è un toolkit di Windows PowerShell che definisce un set di comandi per l’esecuzione di attività con privilegi. Limitando nel tempo i privilegi amministrativi è possibile anche aumentare il livello di sicurezza perché molto spesso si assegnano privilegi elevati e successivamente questi privilegi non vengono rimossi, o per dimenticanza o banalmente perché si sottovaluta il pericolo derivante dalla non adozione della modalità amministrativa del Least Administrative Privilege.

Se dobbiamo concedere ad esempio al gruppo di Help Desk o al consulente esterno di effettuare operazioni privilegiate adesso possiamo fare in modo che ci sia un limite di tempo all’appartenenza ad un gruppo amministrativo. Stesso discorso vale se dobbiamo eseguire degli script con un utente particolare.

Privileged Access Management (PAM) contribuisce quindi a risolvere il problema dell’accesso alle risorse di Active Directory ed evitare che gli autori di un attacco informatico possano ottenere le credenziali degli account amministrativi.

Prerequisiti

Per poter utilizzare PAM è necessario prima di tutto che il livello funzionale dalla Foresta di Active Directory sia Windows Server 2016. Inoltre PAM è una funzione che va abilitata, perché non è attiva di default.

Per verificare il livello funzionale della foresta e del dominio potete utilizzare la console Active Directory Administrative Center, come mostrato in figura:

Figura 1: Innalzamento del livello funzionale del Dominio e della Foresta

In alternativa potete anche usare i seguenti comandi PowerShell:

#Get the Active Directory Forest functional level

(Get-ADForest).ForestMode

#Get the Active Directory Domain functional level

(Get-ADDomain).DomainMode

Figura 2: Uso di PowerShell per la verifica dei livelli funzionali di dominio e di foresta

Per innalzare il livello funzionale del dominio e della foresta potete anche usare i comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016

Set-ADDomainMode -Identity demo.lab -DomainMode Windows2016

#Raise livello funzionale della foresta a Windows 2016

Set-ADForestMode -Identity demo.lab -ForestMode Windows2016

Abilitazione della funzionalità Privileged Access Management (PAM)

Una volta che vi siete accertati che la Foresta abbia il livello funzionale Windows Server 2016, potete installare la funzionalità PAM solo utilizzando PowerShell:

#Abilitazione della funzionalità Privileged Access Management (PAM)

Enable-ADOptionalFeature “Privileged Access Management Feature” -Scope ForestorconfigurationSet -Target demo.lab

Figura 3: Abilitazione della funzionalità Privileged Access Management (PAM)

Nota: Una volta abilitata la funzionalità non è possibile disabilitarla.

Per verificare se la funzionalità sia stata già installata è possibile usare la cmdlet

#Verifica dell’installazione della funzionalità Privileged Access Management (PAM)

Get-ADOptionalFeature “Privileged Access Management Feature”

Figura 4: Verifica dell’installazione della funzionalità Privileged Access Management (PAM) tramite PowerShell

Assegnazione temporanea dell’appartenenza di un utente ad un gruppo di Active Directory

Per poter assegnare temporaneamente uno o più utenti ad un gruppo di AD è necessario effettuare i seguenti comandi PowerShell:

#Definisco la durata di appartenenza al gruppo

$durata New-TimeSpan -Minutes 20

#Aggiungo al gruppo Domain Admind due utenti (attualmente Domain Users)

Add-ADGroupMember -Identity “Domain Admins” -Members nicferr,hector -MemberTimeToLive $durata

Figura 5: Aggiunta di due utenti al gruppo Domain Admins

Per verificare che i due utenti appartengano al gruppo Domain Admin vi basta poi lanciare la cmdlet

Get-ADGroup “Domain Admins” -Property Member -ShowMemberTimeToLive


Figura 6: Verifica dell’appartenenza al gruppo Domain Admins

Come si può notare dalla figura sopra, il risultato riporta:

Member : {<TTL=1068>,CN=Ettore Ferrini,CN=Users,DC=demo,DC=lab, <TTL=1068>,CN=Nicola Ferrini,CN=Users,DC=demo,DC=lab, CN=Administrator,CN=Users,DC=demo,DC=lab}

Accanto ai nomi dei due utenti aggiunti al gruppo Domain Admins c’è un campo TTL (espresso in secondi), che indica la durata rimanente dell’appartenenza al gruppo stesso.

Conclusioni

Privileged Access Management (PAM) è una funzionalità concepita appositamente per gli account amministrativi. Gli amministratori (o gli script) che necessitano solo occasionalmente dell’accesso per gruppi con privilegi, possono richiedere questo accesso e mantenerlo per un periodo limitato di tempo, garantendo la modalità amministrativa del Least Administrative Privilege ed aumentando di fatto la sicurezza della nostra infrastruttura di Active Directory.

Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/it-it/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

Come effettuare un PenTest – Parte 2: Information Gathering

Abbiamo visto nel precedente articolo cos’è il Penetration Testing o PenTest.

In questo capitolo cercheremo di affrontare la seconda fase di un PenTest, basata su esempi reali e spiegazione di alcuni tools utilizzabili. L’information Gathering può essere distinto in due metodologie: attivo o passivo.

L’obiettivo principale di questa fase è quello di raccogliere più informazioni possibili che possano essere utili nell’attività di PenTest: alcuni dati possono essere ricavati dal DNS, hostname, IP, tecnologie hardware usate, username, documenti sensibili, informazioni di password reset, informazioni di contatto, SOCIAL NETWORK vari ed altro ancora.

Tale attività risulta essere nevralgica e molto importante. Più informazioni riuscirò a carpire, più accurata sarà la mia ricerca.

Nella ricerca delle informazioni ATTIVA cercheremo di ottenere le informazioni, ad esempio, nel traffico di rete dove si trova il nostro target; nella modalità PASSIVA utilizzeremo servizi di terze parti come Google/Linkedin/Shodan ecc.

Nella Information Gathering che stiamo descrivendo non esiste una tecnica o approcci standard: vince chi ha più creatività ed inventiva.

I motori di ricerca possono essere i vostri migliori amici…

È importante aggiungere che, per una raccolta di informazioni meno intrusiva e anonima ma con più difficoltà nel reperire dati, l’approccio PASSIVO è preferibile. L’approccio ATTIVO, restituirà all’attaccante molte info ma il rischio di essere scoperto e bloccato potrebbe essere alto.

La tipologia di approccio può essere scelto dal cliente al momento della redazione del Test PLAN.

Passiamo ai fatti…

Immaginiamo di voler raccogliere più info possibili da un Sito Web sfruttando l’approccio Ibrido (ATTIVO + PASSIVO).

Dove potremmo reperire un numero adeguato di Info?

Siti Web pubblici (affacciati su Internet) possono essere considerati la vetrina di una vittima. Sono molto utili per mostrare ai clienti i loro servizi e prodotti, ma possono essere sfruttati per carpire informazioni di varia natura e successivamente sfruttate a proprio vantaggio.

NOTA: Se un sito web è hostato su un provider esterno, raccogliere informazioni può essere difficoltosa, se il sito è hostato in server proprietari la faccenda potrebbe diventare più interessante…

Risorse Pubbliche alla portata di tutti

Esistono nel web numerose applicazioni che permettono di ottenere alcune info importanti per il proseguimento del PenTest.

Facciamo alcuni esempi:

https://archive.org/ : Permette di avere uno storico dei siti web. Dalla versione più recente alla più vecchia;

http://whois.domaintools.com/: Permette, tramite protocollo whois, di avere molte informazioni utili;

https://centralops.net/co/: simile al secondo link, con il vantaggio di poter fare un port scan semplice via web. (attività anonima a danno del target)

L’utilizzo di risorse pubbliche disponibili su Web, è sempre da preferire in quanto permette di mantenere un certo anonimato. A discapito di ciò, vi è una difficoltà di adeguare i tool via web alle nostre esigenze.

Tools in Linux

WHOIS

In alcune distro Linux è possibile adoperare il protocollo di rete Whois direttamente da terminare di comando.

#whois ictpower.it

Whois permette di effettuare delle query al fine di ottenere informazioni riguardo la registrazione del dominio. È possibile avere informazioni riguardo DNS server e contatti di colui che ha registrato il dominio. Con un pizzico di malizia e una spolverata di “linkedin” è possibile divertirsi un pò.

Ripasso di alcuni record DNS:

SOA: Informazioni autorevoli sulla zona DNS, incluso server DNS principale.

NS: Delega una zona DNS ad essere gestita da un server DNS autorevole per quel dominio.

A: Indirizzo IPv4 dell’host.

MX: Collega un nome di dominio ad una lista di server di posta autorevoli per quel dominio.

AAAA: Indirizzo Ipv6 dell’host.

CNAME: Collega un nome DNS ad un altro.

DIG

Altri tools che possono essere molto utili per poter raccogliere alcune informazioni sono:

Dig permette di fare query DNS; il solo comando DIG restituirà solo record di tipo A. Per poter ottenere tutti i record basterà digitare:

#dig ictpower.it any

Il fattore vincente in DIG può essere quello che permette di eseguire query salvate in un file di testo.

DNSENUM

Una valida alternativa a DIG, può essere dnsenum che permette di restituire i record DNS sfruttando alcune implementazioni aggiuntive:

  • Permette di ottenere nomi e sottodomini aggiuntivi utilizzando Google;
  • Scoprire sottodomini utilizzando tecniche di brute forcing da file di testo;
  • Utilizzare thread per elaborare diverse query…
  • Etc…

#dnsenum ictpower.it

Utilizzando il semplice comando dnsenum, otterremo informazioni riguardo IP dell’host, nome server e IP del server di posta.

Altri tools che permettono un’analisi più automatizzata sono Fierce o DMitry che approcciano l’information gathering in maniera più aggressiva e approfondita.

DA USARE CON MODERAZIONE…

Network Routing Information

Altre informazioni che possiamo ricavare, sono quelle inerenti al “network routing information”; conoscere tali dati permette ad un PenTester di comprendere la rete nella quale si trova il proprio target ed evitare di essere scoperto. In questa fase è possibile anche osservare se vi è un firewall a protezione del target.

TCPtraceroute

Il primo per importanza è sicuramente TCPtraceroute.

Come si evince dal nome, sfrutta il comando traceroute che, combinato ad una serie di migliorie, permette di ottenere risultati sicuramente più efficaci.

Il traceroute packet, nonché “UDP o ICMP
echo
request” con TTL variabile, molto spesso sono filtrati da un firewall; TCPtraceroute sfrutta il TCP SYN (stealth Scan) nonchè pacchetti legittimi e difficilmente bloccabili.

Se TCPtraceroute riceve in risposta del TCP SYN, un SYN/ACK significa che la porta è aperta, se il flag viene settato con RST significa che la porta è chiusa.

Tctrace

Strumento alternativo a TCPtraceroute è tctrace, che sfrutta la stessa tecnica.

TheHarvester

Ladies and gentlemen, inchinatevi davanti al tool per eccellenza per information Gathering.

Uno dei tool più malvagi ed utili che siano stati mai creati è TheHarvester (Tradotto “Il raccoglitore”).

Tale strumento è utilizzato per raccogliere domini, indirizzi email e documenti con metadata inerenti il target. Esso si basa su un suo algoritmo di ricerca in grado di interrogare i maggiori motori di ricerca conosciuti, facendo sì che l’attaccante non visiti direttamente il target. Dunque il target sarà ignaro delle nostre attività.

Riprendendo dalla descrizione nella pagina Github <<https://github.com/laramies/theHarvester>>, elenco alcuni motori di ricerca che interroga:

  • Google
  • Yahoo
  • Baidu
  • Shodan
  • Twitter
  • Etc…

Come ultimo, ma non per importanza, abbiamo Metagoofil.

Cercate documenti inerenti un possibile target? Questo tool fa per voi.

Esso si basa sul fantastico Google, andando a ricercare tutti i documenti con metadati del dominio target.

Possiamo ricercare documenti word, excel, presentazioni powerpoint, PDF

I suoi passi sono fondamentalmente 4:

  1. Cerca tutti i documenti presenti nel web tramite Google, con le estensioni specificate;
  2. Scarica i documenti trovati in locale;
  3. Estrae i metadati dai documenti scaricati;
  4. Salva i dati in un file HTML.

I metadati possono essere username, Versioni software, nomi macchina. Facile No?

Nel prossimo articolo affronteremo il cosiddetto processo di Target Discover nella rete.

Penetration Test: non solo per Hacker…

Quello nel quale stiamo per addentrarci oggi e nei prossimi capitoli, è un’attività che può essere compiuta per scopi leciti o illeciti. Il Penetration Testing o PenTest può essere definito come il processo che permette di analizzare in profondità la sicurezza di uno o più sistemi. L’attività deve essere una parte importante dei processi aziendali in modo da assicurare la piena consapevolezza dei punti deboli dell’infrastruttura IT e non.

Per ogni PenTest può essere applicata una diversa metodologia; si intende un insieme di regole da poter seguire per condurre un PenTest in maniera corretta.

Tale pratica può essere condotta indipendentemente o come attività schedulata nel proprio ufficio di IT Security. Uno scheduling comporta l’implementazione di adeguate misure di sicurezza, redigere un documento di analisi dei rischi, revisione del Codice, creazione di modelli di minacce ed altro…

Esistono due approcci metodologici al PenTest:

  • Black Box
  • White Box

Parliamo di “Scatola Oscura” o Black Box quando colui o coloro che compiono l’attività di Penetration non hanno cognizione delle tecnologie implementate nell’organizzazione target. Devono essere adottate tutte le tecniche di hacking conosciute ed è importante saper classificare le vulnerabilità in base al loro livello di rischio. (es. Un sistema vulnerabile ad un Local Code Execution può essere considerato meno grave rispetto ad un Remote code execution)

Tale metodologia può essere più costosa in termini di tempo e risorse rispetto ad un approccio di tipo White Box ed è soggetto alle reali abilità dell’attaccante.

La metodologia White Box, al contrario, è una tipologia di PenTest dove l’attaccante è a conoscenza di tutto l’ambiente che andrà a testare. È il miglior modo per valutare e concentrarsi su tutte quelle tecnologie che possono risultare critiche. In questo caso si va a valutare i rischi esterni che l’azienda/organizzazione incorre, non valutando le vulnerabilità interne (es. Social Enginering / Dipendente Scontento).

Gli step sono simili alle fasi di Black Box, ma in qualche modo l’approccio White Box può essere integrato nei cicli di vita di implementazioni Hardware/Software per eliminare le possibili problematiche a monte di un possibile attacco.

Sentiamo spesso parlare di Vulnerability Assessment e Penetration testing. Ma qual è la differenza sostanziale?

La differenza basilare è che nel Vuln. Assessment si vanno ad evidenziare tutte le possibili vulnerabilità, andandole a valutare il possibile impatto, nel PenTest si procede ad identificare tutte le vulnerabilità ed sfruttare possibili exploit pubblici o custom (0-day) con l’aggiunta di privilege escalation e mantenimento dell’accesso ai sistemi target.

In questo viaggio impervio non siamo soli…

Esistono varie linee guida che possono essere d’aiuto per chi voglia incominciare ad implementare controlli periodici:

Altre metodologie e tecniche di PenTest possono essere “Blind”, “Double Blind”, “Gray Box”, “Double gray box”, “Tandem”, “Reversal”.

Compreso la base dell’argomento, vediamo come deve essere pianificata l’attività nel modo migliore.

Esistono tantissimi tools che possono essere adoperati per tale proposito ma è importante usarli con criterio e sapienza in modo da poter massimizzare il risultato con uno sforzo minore.

Le fasi del PenTest, che possono essere semplici o complessi in base all’ambiente target, sono:

  • Definizione del Target
  • Raccolta delle Informazioni
  • Identificare e Scoprire il Target
  • Enumerazione Target
  • Mapping delle Vulnerabilità
  • Ingegneria Sociale
  • Sfruttamento delle falle
  • Escalation dei privilegi
  • Mantenimento dell’accesso
  • Documentazione and Reporting

In base all’approccio white/black box, sarà sempre possibile modificare l’ordine delle fasi che potrà essere adattato in base alla tipologia di target da valutare.

Nei prossimi articoli affronteremo tutti i capitoli con vari esempi e casi reali. Partiamo dalla definizione del Target e Test Plan

Definizione del Target / Test Plan

Il primo capitolo che deve essere affrontato obbligatoriamente, parte da una unica semplice domanda: Cosa vogliamo testare? Perché?

Non aver ben chiaro la risposta alla domanda, porterà con sé uno spreco eccessivo di risorse.

In primis, è necessario creare un documento che elenchi le linee guida e le informazioni che dovranno essere estratte o trovate nei sistemi target. (es. informazioni dell’infrastruttura). Si procederà poi ad un Test Plan prevedendo l’allocazione delle risorse necessarie, analisi dei costi, NDA, regole di ingaggio ecc…

N.B: Il Plan potrà comprendere anche eventuali limitazioni o restrizioni nel condurre il PenTest.

Dovranno essere definiti anche i vantaggi fondamentali che il cliente ricevere in favore del raggiungimento degli obiettivi aziendali tramite PenTest. È una sezione che sarà utile a valutare il risultato ottenuto in termini qualitativi.

Si parte, da alcuni punti:

  • Raccolta di informazioni base come nome dell’azienda, indirizzo, sito web, contatti, numeri di telefono etc…
  • Si definisce il vero obiettivo del PenTest;
  • Si stabilisce la tipologia di PenTest (black/ white / Ingegneria sociale inclusa/esclusa…)
  • Quanti target devono essere testati;
  • Quali sistemi operativi utilizza la vostra infrastruttura (info dipendente dall’approccio scelto)
  • Device di rete da testare? (IDS/IPS/ load balancer…)
  • Disaster recovery plan definito?
  • Standard che l’azienda deve rispettare?
  • Contatti del capo progetto;
  • Tempo di esecuzione dei test;
  • Budjet;
  • Ulteriori info/richieste.

È importante comprendere anche come dovrà essere redatto il report finale:

  • Report per l’esecutivo;
  • Report tecnico;
  • Report per sviluppatori.

In che modo dovrà essere consegnato:

  • Email;
  • Email cifrata;
  • Stampato;
  • Consegna a mano…

Una volta raccolti tutti i requisiti di base del Test Plan, in ultima analisi occorre assegnare le adeguate risorse e calendarizzare tutte le attività; tramite alcuni strumenti è possibile gestire i progetti in corso e poterne mantenere facilmente traccia.

Nel prossimo articolo, si introdurrà il concetto ed esempi pratici di Information Gathering.

Sicurezza? Non siete mica la NASA…

Il ritorno a casa

Omar è tornato in italia proprio ieri e, come promesso, ci siamo subito visti per analizzare quello che era accaduto la scorsa settimana e per decidere come migliorare la sicurezza informatica – o IT – della Saltafossi.

Nella sala riunione, oltre a noi due, c’era anche Ermes Gutturnio, il loro responsabile IT.

Nel frattempo, neanche a farlo apposta, lo tsnunami WannaCry si è abbattuto sull’IT mondiale e la minaccia ransomware è uscita dai blog e dalle newsletter per “specialisti” e si è presa il posto sui giornali e sulla televisione.

Questo ha ulteriormente spaventato il nostro imprenditore che sempre meno si capacita di come l’informatica abbia un impatto così forte anche su di lui, che produce macchine per fare maglioni.

nasa-logo

Fare tutto in casa o affidarsi ad uno specialista?

“Stai a vedere che adesso per fare maglioni mi serve la laurea in informatica!” così mi ha detto appena ci siamo seduti nella sua sala riunioni.

“Mica bisogna essere degli chef stellati per mangiare un buon piatto al ristorante” gli ho risposto io.

 

Infatti la tentazione di Omar era stata quella di voler affrontare tutto quello che era successo in prima persona, partendo a studiare, ad installare, a programmare o lui direttamente o qualcuno dei suoi collaboratori.

Ma sarebbe come se, per affrontare una malattia ci mettessimo a navigare in rete, a comprare libri di medicina e di chimica per farci da soli la diagnosi e produrci in cantina le medicine… non funzionerebbe.

 

Ovviamente quando ci succede qualcosa di grave sentiamo subito una spinta ad informarci, a capire cosa succede e cosa potremmo fare. Questo non solo è naturale ma è giusto e necessario. Però se pensassimo ogni volta di reinventare la ruota da zero, cioè volessimo ignorare che esistono tanti specialisti a cui potremmo rivolgerci,  non godremmo degli sviluppi e del progresso che è stato fatto grazie ad altri prima di noi.

 

È per questo che i nostri sforzi, di fronte ad una situazione nuova, imprevista e seria dovrebbero essere concentrati nell’acquisire il minimo bagaglio di conoscenze che ci consenta di valutare quale, tra le soluzioni che altri hanno sviluppato prima di noi, sia la più adatta a risolvere il nostro problema.

 

Per non prendere delle cantonate

In questo modo potremo evitare di prendere “delle cantonate” e capire a chi affidarci e in chi potremo riporre la nostra fiducia.

Dobbiamo raggiungere un sano equilibrio tra affidarci ciecamente e scegliere consapevolmente il meglio per noi.

 

Se voglio mangiarmi una pasta al pomodoro non mi serve lo chef stellato, forse starei sprecando i miei soldi e non sarei in grado di apprezzare la differenza rispetto al “fai da te”. Se però voglio portare a cena un Cliente importante è meglio che mi concentri sul preparare la riunione d’affari e la presentazione dell’offerta ed invece affidarmi al ristorante di fiducia, concordando per bene il menù e la location.

Ad ognuno il suo si potrebbe dire…

 

Omar capisce la mia battuta e mi chiede: “ok, allora cosa c’è sul menù per oggi?”.

Il menù…

Il menù è, in effetti, ricco.

L’attacco ransomware della scorsa settimana ha messo in luce diverse debolezze della rete della Saltafossi e, contestualmente, ha instillato qualche dubbio nella mente di Omar su come la sua azienda fosse stata seguita fino ad allora nella gestione IT.

 

Inizio subito con lo spiegargli perché era necessario formattare il server che aveva subito l’attacco. Gli hacker, così come sono riusciti ad installare il programma di encryption, potrebbero avere installato mille altre schifezze su quella macchina.

Aggiungo anche che è ormai solo una questione di soldi, non c’è più l’hacker “romantico” che attacca i sistemi della NASA per farsi dire “che bravo, che genio”.

Oggi queste incursioni hanno lo scopo di rubare valore all’azienda. Nell’immediato può essere il riscatto per i file criptati ma è assolutamente possibile che vengano aperte backdoor ed installati malware che rimangano in ascolto per settimane o per mesi, pronti a rubare l’accesso all’home banking o a copiare i file più sensibili dell’azienda per poi minacciarne la pubblicazione online. Minaccia che può essere scampata pagando, guardacaso, un altro riscatto. Questa operazioni si chiama “doxware”, un misto tra doxier e malware…

Già qui Omar inizia sudare freddo e mi dice: “Ok. Spianiamo tutto. Date voi una mano ad Ermes?”

 

Passiamo quindi al furto delle credenziali che Omar ha subito in Cina. Gli ho spiegato che è molto pericoloso navigare su reti free di cui non si conosce il fornitore. Nessuno da niente per niente e spesso queste reti sono usate proprio per rubare informazioni importanti a chi le usa. Gli ho quindi consigliato di leggere un articolo che avevo scritto qualche mese fa proprio su questo argomento.

Omar ha promesso che d’ora in poi navigherà solo o tramite il cellulare (dove ha acquistato un po di GB in roaming) o attraverso reti wifi “ufficiali”, gestite quindi dal centro fiera, dall’hotel, da Starbucks,… ma da mister “free wifi”.

 

Abbiamo poi parlato del fatto che i cyber criminali hanno avuto buon gioco nell’accedere al server della Saltafossi perché hanno trovato “la porta aperta”.

Omar obietta che, avendogli rubato le credenziali di accesso, i farabutti avessero già in mano tutto quello che serviva per entrare nella rete.

“In realtà non è così”, gli spiego. Avere le credenziali d’accesso non sarebbe servito a molto se non fossero riusciti a trovarsi davanti una schermata in cui queste gli venivano chieste! In altre parole se avessero provato a connettersi ma avessero trovato la porta chiusa non sarebbero riusciti ad andare avanti.

“Eh ma allora mi stai dicendo che non posso più lavorare da remoto? Ma lo sai che io devo accedere al gestionale, devo poter usare le mie tabellone di Excel, che…”.

“Aspetta un attimo”, gli rispondo, “non ti sto dicendo questo. Ti sto dicendo che tutto questo può essere fatto in modo sicuro, senza dover aprire il server a tutto il mondo!”.

Omar sbarra gli occhi. “ah sì? Ma non mi avevano detto così…”. In effetti il loro consulente, quello che aveva installato il firewall e che la Saltafossi chiama ogni qualvolta qualcosa si guasti, aveva fatto questa configurazione un po “libera”.

Ermes annuisce. Infatti lui era da sempre stato un po scettico su questo consulentone che non aveva mai rilasciato uno straccio di schema di rete, che non documentava mai quello che faceva ed il cui motto era: “Ci penso io. Se qualcosa non funziona fammi uno squillo e non preoccuparti della sicurezza IT… tanto voi non siete mica la NASA, chi volete che venga a fregarvi i dati? Il firewall lo abbiamo messo perché ci ha obbligato la legge sulla privacy, ma in realtà a voi non sarebbe neanche servito…”.

Omar invece inizia ha lo sguardo visibilmente “inca—to”, gli vengono in mente le fatture pagate nel corso degli anni…

“Ci vuole un caffè”, mi dice, “facciamo un momento di pausa”. Andiamo tutti insieme alla macchinetta del caffè, quella – per il momento – non sembra risentire degli attacchi ransomware.

Facciamo anche noi una pausa. La prossima settimana vi scriverò degli altri punti di cui abbiamo discusso nella seconda parte della riunione.

L'articolo Sicurezza? Non siete mica la NASA… sembra essere il primo su ICT per Aziende.

E l’ultimo chiuda la porta (…almeno del firewall)

Tempo di lettura: 6 min

L’antefatto

Lo avevo salutato la settimana scorsa, era emozionato per questo viaggio in Cina.

Omar Saltafossi, mio amico imprenditore, si muove bene in europa ma un volo intercontinentale non è di tutti i giorni.

Sapevo che sarebbe stato via un paio di settimane per cui mi ha stupito che mi arrivasse una chiamata dal suo interno telefonico (non hanno ancora un centralino VoIP… ma di questo parleremo magari un’altra volta).

20170511-e-lultimo-chiude-la-porta-01

Rispondo e, in effetti, non era Omar. All’altro capo della linea c’era invece Ermes Gutturnio, responsabile IT della Saltafossi.

Era molto agitato, parlava a macchinetta e sono riuscito a cogliere solo alcuni passaggi “i dati, tutti andati…”, “criptati, sono tutti criptati,…”, “tutti fermi, tutti fermi”.

Capisco che la cosa è grave e cerco di farmi spiegare cosa fosse successo. E perché mi stesse chiamando dal telefono di Omar.

Quella mattina la Saltafossi aveva preso un Cryptolocker! Ermes era strasicuro che NESSUNO avesse cliccato su nessuna mail. L’azienda era ancora chiusa!

Ermes non è uno sprovveduto. Aveva fatto delle analisi sul server su cui c’erano i dati criptati e risultava che il programma di criptazione fosse stato lanciato proprio da Omar!

Ecco perché era andato alla sua scrivania, al suo computer. Ma lì era tutto spento. Anzi, Omar – che è un po “crosta” come diremmo a Brescia – aveva anche staccato la spina a video e computer, per “tenere a mano”, cioè per risparmiare sulla corrente elettrica.

Non poteva quindi essere stato lui! Cos’era successo e cosa si poteva fare adesso?

Bisogna distinguere i due aspetti:

  1. ripartire alla svelta
  2. analizzare l’accaduto

Ripartire alla svelta

Da poco più di un mese avevamo attivato per la Saltafossi il nostro servizio di cloud backup, cioè di backup con copia esterna del dato nel nostro datacenter.

Ho dato quindi subito istruzioni al nostro reparto tecnico di ripristinare i dati nel nostro laboratorio, per velocizzare le operazioni.

 

Analizzare l’accaduto

Ho quindi chiesto al mio alter ego tecnico, Stefano Corradetti di verificare cosa fosse successo. Dalla sua analisi è emerso che c’era stata una connessione di tipo “desktop remoto” proprio dalla Cina dalle 7.47 alle  8.01 ora italiana, fatta con l’utenza di Omar!

E che il giorno prima, stavolta da un indirizzo IP del Kazakistan, era stata fatta un’altra connessione di circa 39 minuti.

C’è stato quindi un “sopralluogo” e poi il furto vero e proprio!

Ma come avevano fatto a rubare le credenziali di Omar? Dopo averlo raggiunto telefonicamente in hotel ci spiega che, un paio di giorni prima, si era connesso in remoto al server della ditta ed era stato ben contento di trovare una bella rete wifi completamente gratuita, senza richiesta di credenziali, dal nome “free wifi”. Una pacchia!

Una pacchia anche per i furbacchioni che sono riusciti a cuccare un po di dati e di credenziali di accesso di chi si era connesso a quella rete, creare apposta per questo scopo.

Chiedo allora ad Ermes come si connettesse da remoto il buon Omar. E lui mi risponde: “in remote desktop!”. Quindi senza VPN, senza altre sicurezze? “No”, mi risponde, il loro consulente ha detto che così era più semplice.

Sicuramente è stato più semplice, anche per chi si è connesso da remoto al server della Saltafossi, per fare i suoi porci comodi!

C’erano un po troppe porte aperte, nel senso informatico del termine. La porta d’accesso per il remote desktop era aperta da tutto il mondo!

Do istruzioni al loro consulente di riconfigurare il firewall, per evitare che il fattaccio si ripetesse di lì a qualche ora.

Nel frattempo i nostri meravigliosi tecnici avevano recuperato su un disco USB i dati della Saltafossi e li stavano portando, insieme ad un server muletto, presso la sede della ditta. La mattina successiva al “disastro” la Saltafossi è potuta ripartire, un po zoppicante, ma era tornata in piedi.

 

C’è ancora tanto da fare

C’è però ancora tanto lavoro da fare!

  1. Il server oggetto dell’attacco andava formattato. Non ci si può fidare di quali porcherie siano state installate sulla macchina, oltre al programma di encryption.
  2. La sicurezza “del perimetro” della Saltafossi non poteva più essere gestita in questo modo.
  3. La sacrosanta esigenza di connettersi da remoto andava gestita in altro modo.
  4. Un giorno intero di fermo era troppo? Si sarebbe potuto fare di meglio?

 

Per dare una risposta a queste domande abbiamo deciso di aspettare che Omar ritorni dalla Cina la prossima settimana e vi terremmo aggiornati degli sviluppi. Bisogna sedersi con lui e con Ermes perché NON si tratta solo di questioni tecniche ma coinvolgono proprio il business, il cuore dell’azienda.

Nel frattempo, per citare Nick Carter e “SuperGulp – fumetti in TV”, “tutto è bene ciò che finisce bene…” e “l’ultimo chiuda la porta” (almeno quella sul firewall)!

L'articolo E l’ultimo chiuda la porta (…almeno del firewall) sembra essere il primo su ICT per Aziende.

Implementazione di SPID da parte dei Service Provider in ambiente Windows

Introduzione

Con il decreto della Presidenza del Consiglio dei Ministri del 24 ottobre 2014, pubblicato sulla Gazzetta Ufficiale n. 285 del 9 dicembre 2014 è stata aperta la strada all’attuazione sistema SPID che, come è possibile leggere sulle FAQ pubblicate sul sito governativo dedicato a SPID, rappresenta “il sistema di autenticazione che permette a cittadini ed imprese di accedere ai servizi online della pubblica amministrazione e dei privati aderenti con un’identità digitale unica“.

SPID è stato è stato progettato in conformità a eIDAS (electronic IDentification Authentication and Signature) descritto nel Regolamento UE n° 910/2014 che ha l’obiettivo di rafforzare la fiducia nelle transazioni nell’Unione Europea, fornendo una base normativa comune per interazioni elettroniche sicure fra cittadini, imprese e pubbliche amministrazioni. Le tecniche e protocolli su cui si basa SPID sono già stati sperimentati a livello europeo e adottate dai progetti sperimentali Stork e Stork II (Secure idenTity acrOss boRders linKed), a riguardo si veda SPID verso eIDAS.

Sempre come riportato nelle FAQ “l’identità SPID è costituita da credenziali (nome utente e password) che vengono rilasciate all’utente e che permettono l’accesso a tutti i servizi online”.

Per quanto riguarda le differenze tra SPID e la Carta nazionale sempre nelle FAQ viene riportato quanto segue:

“I due strumenti hanno usi e scopi in parte diversi e in questa prima fase di implementazione del sistema SPID coesisteranno.

A differenza della Carta Nazionale dei Servizi – che non è completamente dematerializzata – per l’uso dell’identità SPID non è necessario alcun lettore di carte e può essere utilizzata in diverse modalità (da computer fisso o da mobile).”

“Nella prima fase di avvio del sistema pubblico di identità digitale la necessità è quella di far coesistere il sistema di autenticazione tramite SPID con quelli già esistenti.

La progressiva implementazione del sistema da parte della pubblica amministrazione (che durerà 24 mesi) farà si che tutti i servizi online siano accessibili tramite SPID.”

SPID è diventato operativo Il 28 luglio 2015, con la Determinazione n. 44/2015 in cui sono stati emanati da AgID i quattro regolamenti (Accreditamento gestori, utilizzo identità pregresse, modalità attuative, regole tecniche) previsti dall’articolo 4, commi 2, 3 e 4, del DPCM 24 ottobre.

Il 7 ottobre 2016 è stata pubblicata la Determinazione 239/2016 che consente anche ai privati di accedere al sistema SPID in qualità di fornitori di servizi.

Le Pubbliche Amministrazioni dovranno aderire al circuito SPID per consentire l’identificazione elettronica dei cittadini per l’erogazione dei propri servizi on line entro il 31 dicembre 2017.

Per ulteriori informazioni si vedano Sistema Pubblico per la gestione dell’Identità Digitale – SPID, le FAQ su spid.gov.it, le FAQ su agid.gov.it e la pagina su Wikipedia dedicata a SPID.

Argomenti

  • Architettura di SPID
  • Requisiti per l’implementazione di SPID da parte di una Pubblica Amministrazione
  • Procedura per l’implementazione di SPID da parte di una Pubblica Amministrazione
    • Procedura Tecnica
    • Procedura Amministrativa
  • Conclusioni

Architettura di SPID

Scendendo nel dettaglio dell’architettura di SPID sono previsti tre ruoli:

  • Identity provider o gestore di identità digitale (IP) che fornisce le credenziali di accesso al sistema (identità digitali) e gestisce i processi di autenticazione degli utenti. Al momento gli IP accreditati sono Aruba, Infocert, Poste, Sielte e Tim, ma qualunque soggetto in possesso dei requisiti previsti dalle norme può fare richiesta di accreditamento all’Agenzia per l’Italia Digitale (per l’elenco aggiornato degli IP si veda Identity Provider Accreditati).
  • Service provider o fornitore di servizi (SP) che mette a disposizione servizi digitali accessibili tramite il login con credenziali SPID. Gli SP sono rappresentati dalle pubblica amministrazioni e dai privati aderenti.
  • Attribute provider o gestore di attributi qualificati (AP) che fornisce attributi che qualificano gli utenti (stati, ruoli, titoli, cariche), finalizzati alla fruizione dei servizi, per determinati servizi o processi, infatti, potrà essere necessario dimostrare il possesso di una specifica condizione o di un particolare requisito personale o professionale. Al m omento gli AP accreditati sono il Ministero dello Sviluppo Economico (in relazione ai dati contenuti nell’indice nazionale degli indirizzi Pec delle imprese e dei professionisti), i Consigli, gli Ordini e i Collegi delle professioni regolamentate (per attestare l’iscrizione agli albi professionali), le Camere di Commercio, Industria, Artigianato e Agricoltura (per l’attestazione di cariche e incarichi societari) e l’AgID (in relazione ai dati contenuti nell’indice degli indirizzi della pubblica amministrazione e dei gestori di pubblici servizi).

L’AgID è invece chiamato a svolgere il ruolo di vigilanza sui soggetti accreditati e il ruolo di garante della federazione, gestendo il registro che rappresenta l’insieme dei soggetti che hanno sottoscritto il rapporto di fiducia.

Di seguito lo schema di funzionamento di SPID e il flusso delle interazioni tra i vari ruoli al fine di concedere all’utente l’accesso ai propri dati.

Requisiti per l’implementazione di SPID da parte di una Pubblica Amministrazione

Le Pubbliche Amministrazioni, in qualità di Service Provider, per rendere i propri servizi online accessibili tramite SPID in modo da favorire e semplificare l’utilizzo dei servizi digitali da parte di tutti i cittadini devono attenersi a quanto indicato nella Come diventare fornitore di servizi SPID del sito governativo dedicato a SPID.

Le modalità di funzionamento di SPID sono quelle previste da SAML v2 per il profilo “Web Browser SSO”SAML V2.0 Technical Overview – Oasis par4.3.

Come riportato nella documentazione presente sul sito developers.italia.it (la comunità italiana degli sviluppatori di servizi pubblici) al link SPID – Regole Tecniche – Introduzione l’implementazione SPID deve rispettare le seguenti:

Devono essere previste le due versioni “SP-Initiated”:

  • Redirect/POST binding
  • POST/POST binding

Il meccanismo di autenticazione è innescato dalla richiesta inoltrata dall’utente tramite browser ad un Fornitore di Servizi (Service Provider o SP) che si rivolge al Gestore delle Identità (Identity provider o IdP) selezionato dall’utente in modalità “pull”.

La richiesta di autenticazione SAML, basata sul costrutto <AuthnRequest>, può essere inoltrata da un Service Provider all’Identity Provider usando il binding:

  • HTTP Redirect
  • HTTP POST

La relativa risposta SAML, basata sul costrutto <Response>, può essere, invece, inviata dall’Identity Provider al Service Provider solo tramite il binding HTTP POST.

Di seguito lo l funzionamento di un’autenticazione SPID bastata su SAML v2.0:

Come riportato sul sito developers.italia.it al link SPID – Regole Tecniche – Regole tecniche Service Provider il Service Provider deve implementare l’autenticazione in base alle seguenti indicazioni:

Il fornitore di servizi (Service Provider o SP) eroga i servizi agli utenti, richiede l’autenticazione agli Identity Provider e gestisce la procedura di autorizzazione al servizio per la realizzazione dei profili SSO previsti, SP-Initiated Redirect/POST binding e POST/POST binding, deve mettere a disposizione le seguenti interfacce:

  • IAuthnResponse: ricezione delle risposte di autenticazione SAML
  • IMetadataRetrieve: permette il reperimento dei SAML metadata del Service Provider da parte dell’Identity Provider.

Per quanto riguarda processamento della <Response> ovvero l’implementazione dell’interfaccia IAuthnResponse devono essere osservate le seguenti indicazioni:

Alla ricezione <Response> qualunque sia il binding utilizzato il Service Provider prima di utilizzare l’asserzione deve operare almeno le seguenti verifiche:

  • controllo delle firme presenti nella <Assertion> e nella <response>;
  • nell’elemento <SubjectConfirmationData> verificare che:
    • l’attributo Recipient coincida con la assertion consuming service URL a cui la <Response> è pervenuta
    • l’attributo NotOnOrAfter non sia scaduto;
    • l’attributo InResponseTo riferisca correttamente all’ID della <AuthnRequest> di richiesta

Il fornitore di servizi deve garantire che le asserzioni non vengano ripresentate, mantenendo il set di identificatori di richiesta (ID) usati come per le <AuthnRequest> per tutta la durata di tempo per cui l’asserzione risulta essere valida in base dell’attributo NotOnOrAfter dell’elemento <SubjectConfirmationData> presente nell’asserzione stessa.

Per quanto riguarda invece l’implementazione dell’interfaccia IMetadataRetrieve devono essere osservate le seguenti indicazioni:

Le caratteristiche del Service Provider devono essere definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettare le condizioni di seguito indicate:

Nell’elemento <EntityDescriptor> devono essere presenti i seguenti attributi:

  • entityID: indicante l’identificativo univoco (un URI) dell’entità
  • ID univoco, per esempio basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità)

L’elemento <KeyDescriptor>
contenenete il certificato della corrispondente chiave pubblica dell’entità, utile per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAML-Metadata, par. 2.4.1.1);

  • deve essere l’elemento <Signature> riportante la firma sui metadata. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Metadata, cap. 3) utilizzando chiavi RSA almeno a 1024 bit e algoritmo di digest SHA-256 o superiore;

Per la massima tutela della privacy dell’utente il Service Provider deve rendere minima la visibilità dei servizi effettivamente invocati. In questa logica occorre rendere ove possibile indifferenziate le richieste relative a servizi che condividono lo stesso set minimo di attributi necessari per l’autorizzazione.

Infine quanto riguarda invece la disponibilità dei Metadata devono essere osservate le seguenti indicazioni:

I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso l’interfaccia IMetadataRetrive alla URL https://<dominioGestoreIdentita>/metadata, ove non diversamente specificato nel Registro SPID, e saranno firmate in modalita detached dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

Per quanto riguarda la sicurezza sul canale di trasmissione nei documenti REGOLAMENTO RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014) e Avviso nr. 1 del 25 febbraio 2016 GESTIONE DELLA SICUREZZA DEL CANALE DI TRASMISSIONE viene riportato quanto segue:

Il profilo SAML SSO raccomanda l’uso di SSLv.3.0 o TLS 1.0 nei colloqui tra Asserting party (Identity Provider e Attribute Authority ), le Relying Party (Service Provider) e lo user agent. In ambito SPID si rende obbligatorio l’impiego di TLS nella versione più recente disponibile.

In relazione all’impiego di TLS (paragrafo 1.2.2.3 delle regole tecniche), al fine di fornire un riferimento più puntuale si precisa che, allo stato delle conoscenze, la versione raccomandata è la 1.2 e che, in casi particolari e temporanei, può essere adottata la versione 1.1, fermo restando che la versione 1.2 deve essere adottata lato server.

Conseguentemente, le versioni più obsolete dei browser, che non supportano le versioni del protocollo indicate, non devono essere utilizzate e, i livelli minimi accettati per l’accesso ai servizi SPID, devono essere documentati nei confronti degli utenti.

Oltre a implementare le interfacce per necessarie allo scambio d’informazioni tra SP e IP al fine di eseguire l’autenticazione sarà necessario, sia per una questione di user experience che di immagine del sistema, la standardizzazione delle interfacce, della comunicazione e dell’utilizzo del logo spid in base alle regole prodotte da AgID (a riguardo si veda il seguente LINEE GUIDA SULLE INTERFACCE E SULLE INFORMAZIONI IDP/SP).

Per quanto riguarda l’implementazione delle interfacce di comunicazione e l’adeguamento delle interfacce grafiche è possibile fare riferimento ai repository pubblicati su GitHub da developers.italia.it (la comunità italiana degli sviluppatori di servizi pubblici) disponibili all’interno del Repository GitHub Italia.

Per maggiori informazioni si vedano:

Procedura per l’implementazione di SPID da parte di una Pubblica Amministrazione

In sintesi una Pubblica Amministrazione (PA) per adeguare i sistemi informativi alle regole tecniche e alle regole di design dedicate a SPID deve completare due procedure, una tecnica e una amministrativa.

Procedura Tecnica

Il completamento della procedura tecnica richiede i seguenti passi.

Passo 1: implementare le interfacce di comunicazione basate su SAML v2 e adeguare le interfacce grafiche alla user experience richiesta da SPID.

A meno che la PA non abbia sviluppato in modo autonomo l’applicativo web su cui è necessario implementare SPID per renderlo accessibile in modo da favorire e semplificare l’utilizzo da parte di tutti i cittadini, tali operazioni vengono normalmente eseguite dal produttore dell’applicativo.

Passo 2: Elaborare un metadata come descritto nell’Avviso n. 6 del 29/07/2016 NOTE SUL DISPIEGAMENTO DI SPID PRESSO I GESTORI DEI SERVIZI tenendo presente che gli attributi richiesti per l’erogazione di ogni servizio online dovranno essere attinenti e non eccedenti.

A meno che PA non abbia sviluppato in modo autonomo l’applicativo web, anche in questo caso la PA dovrà coordinarsi col produttore dell’applicativo per l’elaborazione del metadata che di fatto è un documento XML contenente le informazioni necessarie per l’interfacciamento dei sistemi di un service provider con quelli delle entità con cui deve interagire (Identity provider e Attribute Provider).

Ogni service provider, secondo le regole tecniche SPID, deve mettere a disposizione un solo metadata (indipendentemente dal numero di servizi erogati dal Service Provider).

Passo 3: Dopo aver elaborato il primo metadata la PA dovrà renderlo disponibile su una url https della PA stessa e darne comunicazione segnalandolo al sistema di supporto per le pubbliche amministrazioni, selezionando la categoria “Comunicazione metadata”. Il metadata verrà verificato e, se necessario, sarà richiesto di apportare modifiche utili a garantire il rispetto delle regole tecniche, in questo caso sarà necessario ripetere la procedura di invio del metadata.

Il metadata dovrà essere firmato tramite chiavi RSA di almeno 1024 bit e algoritmo di digest SHA-256 o superiore (a riguardo si veda [SAML-Metadata] cap3).

Per la firma del metadata è possibile utilizzare un certificato a disposizione della PA con i requisiti richiesti oppure generarne uno autofirmato.

Nel Repository GitHub Italia – SPID Metadata Signer sono disponibili Tools e Scripts per la firma del metadata SAML SPID in ambienti Linux e MacOS.

Per firmare metadata SAML SPID in ambiente Windows è possibile utilizzare il porting del repository SPID Metadata Signer che ho reso disponibile GitHub al seguente SPID Metadata Signer in ambiente Windows.

Come detto precedentemente il metadata dovrà essere reso disponibile su una url https della PA come ad esempio https://<dominioGestoreIdentita>/metadata. Per assolvere a tale requisito la PA se non ha già a disposizione un sito istituzionale in https con certificato conforme ai requisiti all’interno del quale pubblicare il metadata, può acquistare un certificato o utilizzare Let’s Encrypt per ottenere un certificato tramite cui implementare la pubblicazione in https.

Per una guida su come configurare IIS, il web server nativo in Windows, per l’utilizzo ei certificati Let’s Encrypt si veda Implementazione di Let’s Encrypt in ambiente Windows Server 2016.

Se possibile per maggiore semplicità la scelta ottimale sarebbe quella di avere un host dedicato al web server che ospiterà il metadato rispondendo ad un sottodominio dedicato (per esempio spid.dominioserviceprovider) per consentire una maggior scalabilità e indipendenza della parte infrastrutturale dedicata all’autenticazione rispetto a quella dedicata alla parte applicativa.

Un server dedicato consente infatti una più semplice gestione della sicurezza permettendo di applicare configurazioni al livello del web server più restrittive e una modularità maggiore dell’infrastruttura che permette anche scenari ibridi in cui il web server che pubblica i metadati sia in cloud e il server applicativo on premisis.

Il web server che ospita il metadata dovrà infatti essere adeguatamente protetto per evitare compromissioni o mancate disponibilità del metadata stesso.

Nel caso il metadata venga esposto tramite IIS è possibile applicare una serie di best practices finalizzate all’hardenig del web server a riguardo si veda al esempio il mio post Hardening di IIS tramite le HTTP Response Headers.

Passo 4: Dopo che il metadata sarà accettato dagli Identity Provider, i servizi online potranno essere “interfacciati” a SPID per successivi test e messa in produzione.

Procedura Amministrativa

Una volta che i primi servizi interfacciati a SPID saranno pronti per essere pubblicati, il legale rappresentate della PA dovrà compilare e firmare la convenzione e dovrà essere compilato anche il file con l’indicazione dei servizi accessibili tramite SPID. Entrambi i documenti dovranno poi essere inviati all’indirizzo: protocollo@pec.agid.gov.it.

Per concludere il processo di adesione a SPID sono necessarie due figure di riferimento:

  • Referente tecnico per tutte le attività di implementazione del sistema di autenticazione SPID
  • Rappresentante legale per la firma della convenzione

Sicurezza

L’identità SPID è costituita da credenziali con caratteristiche differenti in base al livello di sicurezza richiesto per l’accesso. Scendendo nel dettaglio esistono tre livelli di sicurezza ognuno dei quali corrisponde a un diverso livello di identità SPID, i livelli di sicurezza di SPID corrispondono anche ad altrettanti livelli specificati nella norma internazionale ISO-IEC 29115:

  • Livello 1: permette di accedere ai servizi online attraverso un nome utente e una password scelti dall’utente. A tale livello è associato un rischio moderato e compatibile con l’impiego di un sistema autenticazione a singolo fattore (password associata alla digitazione di una UserID). Il Livello 1 corrisponde al Level of Assurance LoA2 dello standard ISO/IEC DIS 29115.
  • Livello 2: necessario per servizi che richiedono un grado di sicurezza maggiore permette l’accesso attraverso un nome utente e una password scelti dall’utente, più la generazione di un codice temporaneo di accesso (one time password). A tale livello è associato un rischio ragguardevole e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori, non necessariamente basato su certificati digitali (password e OTP associati alla digitazione di una UserID). Il Livello 2 corrisponde al Level of Assurance LoA3 dello standard ISO/IEC DIS 29115.
  • Livello 3: oltre al nome utente e la password, richiede un supporto fisico (es. smart card) per l’identificazione. A tale livello è associato un rischio altissimo e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori basato su certificati digitali e criteri di custodia delle chiavi private su dispositivi che soddisfano i requisiti dell’Allegato 3 della Direttiva 1999/93/CE. Il Livello 3 corrisponde al Level of Assurance LoA4 dello standard ISO/IEC DIS 29115.

Pubbliche amministrazioni e privati definiscono autonomamente il livello di sicurezza necessario per poter accedere ai propri servizi digitali, ma ad oggi sono disponibili solo identità SPID di primo e secondo livello (come riportato nella FAQ).

Per maggiori dettagli si veda l’Avviso nr 4 del 09/06/2016 Livelli di servizio minimo per funzionalità omogenee.

Conclusioni

Come riportato nella pagina Diffusione del sistema pubblico di identità digitale (SPID) del sito governativo ItaliaSemplice.gov.it i risultati attesi sulla diffusione di SPID erano di 3 milioni di utenti con un’identità digitale a settembre 2015 e di 10 milioni di utenti a dicembre 2017.

I dati aggiornati dello Stato di attuazione dell’agenda digitale di cui SPID fa parte sono disponibili alla pagina Avanzamento Crescita Digitale e al 05/05/2017 i dati erano i seguenti:

  • amministrazioni attive: 3.720
  • identity provider accreditati: 5
  • servizi disponibili tramite SPID: 4.273
  • identità SPID erogate: 1.384.375

Sebbene i dati reali di diffusione siano per il momento al di sotto dei valori attesi non si può negare che tale sistema di autenticazione non stia prendendo piede anche grazie ad azioni di Governo, come per esempio il bonus 18App e Carta del Docente, inoltre l’obbligo per le Pubbliche Amministrazioni di aderire al circuito SPID entro il 31 dicembre 2017 darà sicuramente un’ulteriore spinta.

Un altro elemento che aumenterà la diffusione di SPIP sarà l’attivazione del Livello 3 di sicurezza la cui assenza per il momento scoraggia le grandi realtà private come gli istituti di credito ad aderire al sistema.

Per avere informazioni sulle Pubbliche Amministrazioni che erogano i servizi abilitati SPID si veda la pagina Dove puoi usare SPID.i